Speed up your sites with PageSpeed for Nginx

By Jeff Kaufman, Software Engineer, Make the Web Faster Team

When we released mod_pagespeed in 2010, we gave webmasters a way to speed up their sites without needing to become web performance optimization experts. As an Apache module, however, it was unavailable to sites running Nginx, the popular high performing open source web server that powers many large web sites. Today that changes: we're releasing PageSpeed Beta for Nginx, aka ngx_pagespeed.

Running as a module inside Nginx, ngx_pagespeed rewrites your webpages to make them faster for your users. This includes compressing images, minifying CSS and JavaScript, extending cache lifetimes, and many other web performance best practices. All of mod_pagespeed's optimization filters are now available to Nginx users.

After three months of alpha testing on hundreds of sites, ngx_pagespeed has proven its ability to serve production traffic. It's ready for beta, and it's ready for you to start using it on your site.

MaxCDN, a content delivery network provider, recently published a blog post on their experience testing ngx_pagespeed: “With PageSpeed enabled, we shaved 1.57 seconds from our average page load, dropped our bounce rate by 1%, and our exit percentage by 2.5%. In sum, we squeezed out extra performance with nothing but a few extra lines in our nginx config files... We are continuing to test the module with the PageSpeed team, and our goal is to make it available across our CDN and to all of our customers – stay tuned!”

ZippyKid, a popular WordPress hosting provider, is also one of the early beta testers of ngx_pagespeed: “PageSpeed for ZippyKid is the world’s first WordPress optimization service powered by ngx_pagespeed, designed to automatically apply web performance best practices to deliver fast WordPress sites. Our benchmarks indicate that PageSpeed for ZippyKid will deliver up to a 75% reduction in page sizes and a 50% improvement in page rendering speeds.”

Development of ngx_pagespeed is open source, with contributions by developers from Google, Taobao, We-Amp, and many other individual volunteers. Thanks everyone for helping us reach the Beta milestone!

To start using ngx_pagespeed, follow the installation instructions on GitHub.


Jeff Kaufman works on PageSpeed, an open-source server module that helps make the web faster, and is interested in experiment measurement. He also plays for contra dances, organizes other dances, and blogs about dancing, giving, and tech.

Posted by Scott Knaster, Editor

PageSpeed Service makes mobile sites faster

By Ram Ramani, Engineering Manager

PageSpeed Service (PSS) is an online service to speed up the rendering of your web pages by rewriting and serving them through Google. While PSS’s optimization techniques benefit most platforms and browsers, today I’d like to focus on some of the PSS rewriters that are especially effective on mobile web pages. PageSpeed Service optimizes the web pages in such a way that users can start viewing and interacting with your pages as soon as possible.



Prioritize Critical CSS: To avoid page reflows, modern browsers do not render pages until the CSS is downloaded and parsed. These CSS files are often tens of KBs because they include all the styles needed for the entire site. These blocking requests are especially bad on mobile devices, where network round trip times are high. The Prioritize Critical CSS rewriter speeds up rendering by identifying the minimal CSS required to render that page and including it in the HTML file. This not only saves an extra round trip to download additional files but also reduces the CPU consumed by the browser. Finally, a reference to the original CSS file is included at the end of the page to lazy-load the non-critical CSS.

Defer JavaScript: The HTML specification requires the browser to stop, download, and execute each synchronous JavaScript file before proceeding to build and render the page - this requirement can significantly slow down rendering. PSS circumvents this behavior by rewriting the HTML to defer execution of all JavaScript until after the page is first rendered. This benefits pages that are mostly rendered via HTML markup rather than JavaScript.

Optimize Images: Mobile screens are almost always smaller than their desktop counterparts. Large, high quality images translate to excessive bytes on the wire, slowing down page loads. PSS can resize images on the server to fit required dimensions and re-compress them to the optimal format, without perceptible visual loss. For very large images above the fold, PSS can also inline a low quality preview image for initial rendering. Once the rest of the page content loads, it is replaced by the original image, creating a seamless experience. Furthermore, images below the fold can be lazy-loaded, which prevents them from competing with the rest of the page load.

PageSpeed Service includes several rewriters that speed up the rendering of web pages. Using PageSpeed Service, the mobile pages of TopNewsToday and Net1News are now 61% faster and 68% faster respectively. Alex Tsvetanov of TopNews Today says, “With Google PageSpeed Service, we increased our unique visitors and total pageviews by 100%, while reducing our bounce rate by 30%”. Massimo Romanello, CEO of Net1News says, "Thanks to Google PageSpeed Service, we have been able to reach 200,000 unique daily visitors with the same existing infrastructure and have made our site one of the quickest in the news sector".

PageSpeed takes just a few minutes to set up and requires no code changes on your site. Check out how much PageSpeed can speed up your site. I encourage you to try out these features by signing up for PageSpeed Service and letting us know what you think at page-speed-service-discuss@googlegroups.com.


Ram Ramani is an Engineering Manager on the Make the Web Faster Team in Mountain View. He is a believer in "Faster is better".

Posted by Scott Knaster, Editor

SiteGround, IISpeed and Google Chrome make the web faster with PageSpeed

By Ilya Grigorik, Developer Advocate and Web Performance Engineer

At Google we want the whole web to be faster, and there is no better way to achieve this goal than through helping our partners, both commercial and open-source, to deliver web optimization products to their users and clients. The PageSpeed Optimization Libraries, which are developed as part of our Make the Web Faster initiative, are a cornerstone of this strategy, enabling a growing list of products and integrations, developed both inside and outside Google.

SiteGround, a popular web hosting provider, announced mod_pagespeed support to their customers: "SuperCacher plugin is the first and only plugin that fully integrates Google’s mod_pagespeed with cPanel. Simply put, mod_pagespeed speeds up your site and reduces page load time automatically, with no additional knowledge required on the users’ side. It also optimizes your website for mobile view and for better browser rendering."

With SiteGround, you can enable PageSpeed optimizations on your site with one click. Then, you can hand-tune and configure your site to match your specific needs through advanced customizations provided by mod_pagespeed.

However, that’s not all. The portfolio of PageSpeed integrations continues to expand:

• The We-AMP team has announced a beta release of IISpeed, which enables PageSpeed web content optimization within the Microsoft IIS web server. "IIS and ASP.NET are very popular technologies on the web, powering millions of websites, and we are excited to bring the full power of PageSpeed optimization to the Windows platform," said Otto van der Schaaf and Kees Spoelstra.
• Thanks to open-source contributions, mod_pagespeed is now integrated with CPanel and WHM, an easy-to-use server control and management panel for web hosts and website owners.
• Google Chrome has adapted PageSpeed to power the recently announced Chrome data compression proxy, which significantly reduces data usage and speeds up page load times on cellular networks.

To find out how to leverage PageSpeed on your site or service, or how to integrate the open source PageSpeed Optimization Libraries into your own product, visit the PageSpeed site.


Ilya Grigorik is a Developer Advocate and Web Performance Engineer at Make the Web Faster.

Posted by Scott Knaster, Editor

New mod_pagespeed: cache advances, progressive JPEGs

Bharath

Jan-Willem

Joshua

By Joshua Marantz, Jan-Willem Maessen, and Bharath Bhushan, PageSpeed Team

When mod_pagespeed launched in November 2010, one of its benefits was to help websites better exploit browser caching by signing URLs with the resource content hash. This improves the user experience coming back to the same site, and navigating within a site.

In mod_pagespeed 1.2 we have released two new features that improve the caching experience for users coming to a site for the first time: canonicalize_javascript_libraries and insert_dns_prefetch. For additional speedups, converting jpegs to progressive format has been added to the Core Filter Set, and the scope of optimization has been extended to include resources served by external servers, even if they are not running mod_pagespeed.

Your web page loads faster when JQuery is preloaded in users' browser

Numerous web sites use common JavaScript libraries such as jQuery and jQuery UI. But when one library is stored on many sites, browsers end up re-downloading that library for each new site – a waste of time and bandwidth. The new canonicalize_javascript_libraries filter in mod_pagespeed finds such libraries on your site and replaces them with links to the equivalent libraries on ajax.googleapis.com. With the optimization, a browser will notice that your site is requesting the library from the same shared library provider as a previous site it visited, and will use the copy in its cache.

It’s possible to do this by hand, but there are a number of reasons why you might prefer to automate the process. Most important is that you may be using third-party code on your web sites that includes some of these libraries. Using canonicalize_javascript_libraries lets you replace these with hosted versions without having to touch third-party code. It also lets you use local, un-minified JavaScript source code for these libraries while you are debugging your site, and then transition automatically to using minified hosted code when you deploy. The filter spots external libraries using a hash signature; we’ve added a new configuration file, pagespeed_libraries.conf, that stores these signatures, so that you can upgrade the signature configuration without disrupting the rest of your apache installation.

Resolving DNS entries early for critical assets saves hundreds of milliseconds

DNS resolution time varies from <1ms for locally cached results, to hundreds of milliseconds due to the cascading nature of DNS. This can contribute significantly to total page load time. Below is a WebPagetest waterfall showing how DNS lookup time can affect page load time.

The new insert_dns_prefetch filter inserts <link rel="dns-prefetch"> tags to allow the browser to pre-resolve DNS for resources on the page. The waterfall below shows the improvement after inserting the hints.

<link rel="dns-prefetch"> is supported on Chrome, Firefox and Internet Explorer.

Improved performance by optimizing external resources and progressive JPEG

In addition to these new capabilities, mod_pagespeed 1.2 can proxy and optimize resources from trusted domains. This feature enables you to optimize resources even from servers that don't run mod_pagespeed. Beyond compressing and cache-extending such resources, this can improve performance of sites running SPDY where the best practices for performance are to serve all resources from the same domain (see mod_spdy).

Further, convert_jpeg_to_progressive is now a ‘core’ filter. Large JPEG images are now transcoded to progressive. This both improves the browser experience and makes such files smaller.

To see more details about the release, check out the release notes and mod_pagespeed download page.


Joshua Marantz runs Google’s PageSpeed team in Cambridge, MA, which is dedicated to making the web faster for everyone. Josh has been working on making software run fast for several decades, at Google and before that on accelerated chip simulation.

Jan Maessen wrote the earliest version of the image and JavaScript filters in mod_pagespeed and has been with the team ever since. Before joining Google, he was a co-designer and library implementer for the Fortress programming language.

Bharath Bhushan works on making website performance better. He has a Masters in CS from IIT Madras, India.

Posted by Scott Knaster, Editor

Scaling automatic web optimization with mod_pagespeed and memcached

By Jud Porter, Software Engineer, PageSpeed Team

Making your website fast is crucial to creating a great user experience – but doing so can be complicated, with many factors to consider. That’s why we created mod_pagespeed, an open-source Apache module designed to optimize your web pages automatically and easily. We recently introduced our milestone 1.0 release, and today, we’re following it up with the release of mod_pagespeed 1.1.23.1 to our beta channel.

With this release we've reduced server load time and improved utilization for large, multi-server environments. We accomplished this by adding support for memcached (a popular, scalable cache), and improving logging and statistics reporting. With memcached, multiple Apache servers share and fetch the same resources optimized by mod_pagespeed. Logging and reporting have been improved to make it easier to keep track of resource consumption and optimization effectiveness across multiple sites hosted by a single Apache installation. These new features make mod_pagespeed even better for high-traffic sites and network providers hosting many individual websites on their infrastructure.

We’ve also added a number of other new features and optimizations including:

• Improved CSS optimization. CSS media queries are now supported, and the new fallback_rewrite_css_urls filter allows partial optimization of CSS containing unsupported or proprietary extensions.
• The default set of optimizers now includes the flatten_css_imports filter, improving out-of-the-box performance.
• Improved mod_spdy interaction with support for custom mod_pagespeed configuration and filters for SPDY enabled clients. This makes it easier to deploy SPDY on your site, which can significantly decrease page load times.

Check out the release notes for all the new features and improvements. For more information about mod_pagespeed, please see our documentation, and if you have any questions or issues let us know on our issue tracker or discussion group.


Jud Porter is a software engineer working on mod_pagespeed, an Apache module designed to automatically make websites faster. In his free time he enjoys experimenting with cocktails, brushing up on his foosball game, and discovering obscure music.

Posted by Scott Knaster, Editor

Make the web faster with mod_pagespeed, now out of Beta

Ilya

Joshua

By Joshua Marantz and Ilya Grigorik, Google PageSpeed Team

Cross-posted with Google Webmaster Central Blog and other Google blogs

If your page is on the web, speed matters. For developers and webmasters, making your page faster shouldn’t be a hassle, which is why we introduced mod_pagespeed in 2010. Since then the development team has been working to improve the functionality, quality and performance of this open-source Apache module that automatically optimizes web pages and their resources. Now, after almost two years and eighteen releases, we are announcing that we are taking off the Beta label.

We’re committed to working with the open-source community to continue evolving mod_pagespeed, including more, better and smarter optimizations and support for other web servers. Over 120,000 sites are already using mod_pagespeed to improve the performance of their web pages using the latest techniques and trends in optimization. The product is used worldwide by individual sites, and is also offered by hosting providers, such as DreamHost, Go Daddy and content delivery networks like EdgeCast. With the move out of beta we hope that even more sites will soon benefit from the web performance improvements offered through mod_pagespeed.

mod_pagespeed is a key part of our goal to help make the web faster for everyone. Users prefer faster sites and we have seen that faster pages lead to higher user engagement, conversions, and retention. In fact, page speed is one of the signals in search ranking and ad quality scores. Besides evangelizing for speed, we offer tools and technologies to help measure, quantify, and improve performance, such as Site Speed Reports in Google Analytics, PageSpeed Insights, and PageSpeed Optimization products. In fact, both mod_pagespeed and PageSpeed Service are based on our open-source PageSpeed Optimization Libraries project, and are important ways in which we help websites take advantage of the latest performance best practices.

To learn more about mod_pagespeed and how to incorporate it in your site, watch our recent Google Developers Live session or visit the mod_pagespeed product page.


Joshua Marantz is the technical lead for mod_pagespeed. Ilya Grigorik is the Developer Advocate for Make the Web Fast.

Posted by Scott Knaster, Editor

Lossless and Transparency Modes in WebP

By Jyrki Alakuijala, WebP Team

At Google, we are constantly looking at ways to make web pages load faster. One way to do this is by making web images smaller. This is especially important for mobile devices where smaller images save both bandwidth and battery life. Earlier this month, we released version 0.2 of the WebP library that adds support for lossless and transparency modes to compress images. This version provides CPU and memory performance comparable to or better than PNG, yet results in 26% smaller files.

WebP’s improved compression comes from advanced techniques such as dedicated entropy codes for different color channels, exploiting 2D locality of backward reference distances and a color cache of recently used colors. This complements basic techniques such as dictionary coding, Huffman coding and color indexing transform. We think that we've only scratched the surface in improving compression. Our newly added support for alpha transparency with lossy images promises additional gains in this space, helping make WebP an efficient replacement for PNG.

The new WebP modes are supported natively in the latest Beta version of Chrome. The bit stream specification for these new WebP modes has been finalized and the container specification has been updated. We thank the community for their valuable feedback and for helping us evolve WebP as a new image compression format for the web. We encourage you to try these new compression methods on your favorite set of images, check out the code, and continue to provide feedback.

Dr. Jyrki Alakuijala is a Software Engineer with a special interest in data compression. He is a father of five daughters, and sings in the Finnish Choir in Zürich. Before joining Google, Jyrki worked in neurosurgical and radiotherapy development.

Posted by Ashleigh Rentz, Editor Emerita

Turbocharging web sites with new PageSpeed Service optimizations

Kishore

Rahul

By Rahul Bansal and Kishore Simbili, PageSpeed Team

We spend a lot of time working to make the web faster. Last year, we introduced PageSpeed Service, an online service that automatically speeds up loading of web pages.

We are constantly working on new optimizations (rewriters) that can make pages load even faster. Along these lines, we are introducing a new rewriter called "Cache and Prioritize Visible Content". This rewriter enables users to start interacting with the web page and consuming the content much sooner. It accomplishes this by optimizing the page as a whole using the following web page-aware techniques and with minimal configuration needed:

• Make HTML cacheable. Typically, most web pages are not cached because they contain small amounts of personalized information or other non-cacheable data. This rewriter separates the non-cacheable portions from the HTML and enables caching for the rest of the content on PageSpeed servers. When the page is loaded, PageSpeed servers send the cacheable parts immediately while non-cacheable parts are fetched from the origin server & patched into the browser later.
• Prioritize visible content rendering. Rendering of a modern web page requires several network resources, but not all of them are needed right away. This rewriter automatically determines and prioritizes the content that is above the fold of the browser, so that it doesn’t have to compete with the rest of the page.
• Defer Javascript. JavaScript execution is deferred until page load so that it doesn’t block rendering of visible content.

Early deployment of these techniques has shown significant improvements in user-perceived page load times. Below is a filmstrip view that compares the loading of pages on Power Line, a US-based political commentary website.

Joe Malchow, Publisher of Power Line says "With this rewriter the most important bytes, our content, load first and fast. To our readers, Power Line appears to be completely instantaneous, prompting deeper and lengthier reading sessions and more profound engagement with the site."

This rewriter works best when the page content is mostly generated on the server rather than via Javascript and only small portions of it are personalized. To see how this rewriter would benefit your site, you can check it out here. If you are satisfied with the results, you can sign up for PageSpeed Service here. If you already use PageSpeed Service, you can find more details about enabling this rewriter here. This rewriter will also be available to App Engine users of PageSpeed Service in the near future.


Rahul Bansal and Kishore Simbili are Software Engineers on Google’s PageSpeed Team in Bangalore, India, which is dedicated to making the web faster.

Posted by Scott Knaster, Editor

Measure and optimize with mod_pagespeed experiments

By Jeff Kaufman, Software Engineer, PageSpeed Team

Making your site fast shouldn’t require lots of manual optimization. With mod_pagespeed, an open-source Apache module, you can automatically apply web performance optimization best practices like cache extension, image optimization, and css inlining to speed up your site without a lot of hassle. As of version 0.10.22.4, mod_pagespeed now supports A/B tests integrated with Google Analytics, allowing you to measure how much it speeds up your site on live traffic and experimentally determine the best settings.

When running an experiment, mod_pagespeed randomly assigns visitors to experimental configurations based on percentages you choose. You can run an experiment on 1% of your traffic, 100%, or anywhere in between without affecting other visitors. It also injects JavaScript to report experiment assignments back to your Google Analytics account in a custom variable. Within Analytics you can track the impact of experimental configurations on page load times, bounce rates, conversions, or any other Analytics metric.

We ran an example experiment, comparing mod_pagespeed running with default settings to mod_pagespeed in pass-through mode, on a small blog. This required adding the following lines to our pagespeed.conf:

ModPagespeedRunExperiment on
   ModPagespeedAnalyticsID "UA-XXXXXXXX-Y"

   # half the users get the pagespeed optimizations
   ModPagespeedExperimentSpec id=3;percent=50;default

   # half get an unoptimized site
   ModPagespeedExperimentSpec id=4;percent=50

While this site was static and contained mostly text, it did use some JavaScript and images and had not been manually optimized. We ran the experiment for a month, over which Analytics observed 11K page views, and we saw a 20% improvement in average page load time:

Average page load time is sensitive to outliers, however, so to better understand the effects it’s helpful to check a histogram:

The clearest change is that mod_pagespeed moved about 7% of page loads from taking 1-3 seconds down to 0-1 second, but there is also an improvement in the long tail.

We encourage you to follow the experiment framework guide and start measuring the effect mod_pagespeed has on your site.


Jeff Kaufman works on mod_pagespeed, an open-source Apache module that helps make the web faster, and is interested in experiment measurement. He also plays for contra dances, organizes other dances, and blogs about dancing, giving, and tech.

Posted by Scott Knaster, Editor

EdgeCast Networks makes the web faster with Google’s mod_pagespeed

Hayes

Josh

by Joshua Marantz, Google PageSpeed Team, and Hayes Kim, EdgeCast Networks

At Google we want the whole web to be faster. We've built a fast browser, improved image encodings, developed better network protocols, and provided PageSpeed tools and optimization libraries. In November 2010, we launched mod_pagespeed, an open-source Apache module that speeds up web sites by rewriting HTML, JavaScript, CSS and images to reduce size, eliminate HTTP requests, and improve browser performance.

mod_pagespeed adoption is growing rapidly. Now EdgeCast Networks, one of the world’s largest CDN operators, has integrated mod_pagespeed into the core of its content delivery network and is making it available as an option in its Application Delivery Network (ADN) service offering.

Hayes Kim, EdgeCast Senior Product Manager, had this to say: "Edgecast has integrated mod_pagespeed alongside our HTTP engine and deployed this to our ADN edge locations worldwide. Our solution enables optimizations in real-time and local to the end user, leveraging the full compute capacity of our edge nodes. We leverage the local edge caches for the unoptimized resources and then cache the subsequent optimized resources processed by mod_pagespeed. EdgeCast's integration can speed up millions of websites either served directly by EdgeCast or indirectly through hosting providers using our technology."

Hayes says that early results show up to a 77% pageview performance improvement when leveraging the ADN service with mod_pagespeed, and a 33% performance improvement from mod_pagespeed alone.

Gogotech, an e-commerce solution provider, has been evaluating EdgeCast's ADN and edge optimizer services, with promising results so far. "This solution looks to be a strong contender for further improving our offerings to Gogotech clients, and we are looking forward to seeing it develop," said Alex Bolduc, IT Director at Gogotech.

The following images and this video show how mod_pagespeed and EdgeCast's ADN are speeding up a Gogotech site.



You can find more details about EdgeCast's mod_pagespeed integrated offerings here. And you can find information on Google’s PageSpeed technologies and tools here.


Joshua Marantz is a Software Engineer on Google’s Pagespeed Automatic team in Cambridge, MA, which is dedicated to making the web faster for everyone. Josh has been working on making software run fast for several decades, at Google and before that on accelerated chip simulation.

Hayes Kim has over eleven years of product development and leadership experience in online advertising, e-commerce, web acceleration, and social media. At EdgeCast, Hayes manages the development of the core HTTP technology that powers the CDN and Application Delivery Network.

Posted by Scott Knaster, Editor

SPDY performance on mobile networks

Michael

Ben

Matt

By Matt Welsh, Ben Greenstein, and Michael Piatek,
Mobile Web Performance Team

SPDY is a replacement for HTTP, designed to speed up transfers of web pages by eliminating much of the overhead associated with HTTP. SPDY supports several optimizations that give it an edge over HTTP when it comes to speed. SPDY is gaining a great deal of traction -- it has been implemented in Chrome, Firefox, and Amazon Silk, has been deployed widely by Google, and there is now SPDY support for Apache through the mod_spdy module.

We wondered what the performance of SPDY would be compared to HTTP for popular websites, using a Samsung Galaxy Nexus (running Android), a modern, SPDY-enabled browser (Chrome for Android), and a variety of pages from real websites (77 pages across 31 popular domains).

The net result is that using SPDY produced a mean page load time improvement of 23% across these sites, compared to HTTP. This is equivalent to a speedup of 1.3x for SPDY over HTTP. Much more work can be done to improve SPDY performance on 3G and 4G cellular networks, but this is a promising start.

The following graph shows the page load time for HTTP and SPDY, in milliseconds, across the 77 pages that were measured. As the graph shows, in all but one case, SPDY reduces load times, sometimes by as much as 50%.

Check out the full article for more details on the measurement methodology and results.


Matt Welsh, Ben Greenstein, and Michael Piatek are software engineers on Google’s Mobile Web Performance Team based in Seattle. They are working to speed up mobile web performance globally, and as part of their jobs, they run up impressive mobile bandwidth bills every month.

Posted by Scott Knaster, Editor

Add SPDY support to your Apache server with mod_spdy

Bryan

Matthew

By Matthew Steele and Bryan McQuade,
PageSpeed Insights Team

At Google, we strive to make the whole web fast. Our work in this area includes PageSpeed, Google Chrome, and the SPDY protocol, among other efforts. In December of 2011, to make it easy for you to enable the SPDY (pronounced "SPeeDY") protocol on your sites, we released an early beta of mod_spdy, an Apache module that adds SPDY support to the Apache HTTPD server. We’ve spent the last few months working with our early adopters to fix bugs and tune performance of the module. Today, we’re launching a version of mod_spdy that we encourage you to try on your web server.

Installing mod_spdy

To install mod_spdy on your Apache 2.2 server, simply download the appropriate mod_spdy Debian or RPM package for your platform, or compile from source. Once installed, your Apache server will begin using SPDY to communicate with SPDY-compatible browsers (e.g. Google Chrome, Android, and recent versions of Firefox). SPDY runs over HTTPS, so any HTTP (non-HTTPS) traffic on your site will not be affected by mod_spdy. Further, since SPDY requires server-side support for the NPN TLS HTTPS extension, which is not available in most current Apache environments, a version of mod_ssl with NPN support is included with the mod_spdy packages.

Enabling SPDY for your site improves performance in several ways:

• The server and browser can compress HTTP headers, saving bytes on the network.
• Multiple resource requests can be multiplexed over a single TCP connection, saving connections on the network.
• The browser can request all page resources at once instead of a few at a time, which reduces the number of network round-trips needed between server and client.

We've tested mod_spdy using locally-mirrored pages from popular websites, and have seen significant speedups compared to serving via plain HTTPS – comparable to the gains that Google’s own servers achieve by using SPDY – with no extra configuration and negligible effect on Apache’s CPU and memory usage. In extreme cases, for example, pages with many small resources, we’ve seen mod_spdy reduce load times by more than 50%.



How mod_spdy works in Apache

Implementing SPDY in Apache posed several interesting challenges. For example, multiplexing is an important performance feature of SPDY which allows for multiple requests in a single SPDY session to be processed concurrently, and their responses interleaved down the wire. However, due to the serialized nature of the HTTP/1.1 protocol, the Apache HTTP server provides a one-request-per-connection architecture. Apache’s connection and request processing normally happens in a single thread, like so:

This works well for HTTP, but it presents a problem for multiplexed protocols like SPDY because in this flow, each connection can only process one request at a time. Once Apache starts processing a request, control is transferred to the request handler and does not return to the connection handler until the request is complete.

To allow for SPDY multiplexing, mod_spdy separates connection processing and request processing into different threads. The connection thread is responsible for decoding SPDY frames and dispatching new SPDY requests to the mod_spdy request thread pool. Each request thread can process a different HTTP request concurrently. The diagram below shows the high-level architecture.

Happily, all this is almost completely invisible to users and server administrators alike--you can continue to use your existing Apache modules and configurations.

Download mod_spdy for your platform and give it a try, and let us know what you think on our mailing list. mod_spdy is an open-source project and we welcome contributions. We are continuing to add new features, tune performance, and improve support for up-and-coming versions of the SPDY protocol.


Matthew Steele and Bryan McQuade are Software Engineers on the Google PageSpeed Insights Team in Cambridge, MA. When not working on mod_spdy, they focus on developing tools to help site owners understand how to speed up their sites.

Posted by Scott Knaster, Editor

CSS: fast to load, easy to maintain

Josh

Matt

By Matt Atterbury and Joshua Marantz, Pagespeed Automatic Team

Fast web pages are important, but so are maintainable ones. For example, CSS @import helps web designers modularize the implementation of their sites. The drawback to using @import is performance. Each @import is a new HTTP request, and every level of @import costs an additional serial round-trip between browser and server, since the browser does not know the URI of the imported CSS file until it downloads, parses, and executes the file that’s importing it. Here’s a waterfall diagram of a simple HTML page that uses @import to load a CSS file that includes a background image:

Web designers deserve the same benefits enjoyed by programmers, who get to use optimizing compilers and other tools to employ modularity without sacrificing performance. Driving toward this goal, we recently announced mod_pagespeed 0.10.21.2, which supports the new feature flatten_css_imports.

Using this feature, the same web page is automatically optimized by flattening the imported CSS files into their parent. This reduces the number of HTTP requests, and more importantly, the number of serial round trips. In this case, the small background image also got inlined into the combined CSS file, reducing the serial round-trip count by 2:

This feature is especially useful to WordPress users with child themes that override their parent theme (http://codex.wordpress.org/Child_Themes) because that feature uses @imports. But every web page and web user benefits from CSS that’s fast and well-structured, so if you’re an Apache administrator, download mod_pagespeed today and read more on our code site.


Matt Atterbury and Joshua Marantz are Software Engineers on Google’s Pagespeed Automatic team in Cambridge, MA, which is dedicated to making the web faster for everyone. When not coding, Matt is probably on his bike. Josh has been working on making software run fast for several decades, at Google and before that on accelerated chip simulation.

Posted by Scott Knaster, Editor

Introducing Page Speed mobile analysis, on Google Chrome for Android

Matthew

Libo

By Libo Song and Matthew Hillyard, Software Engineers

Nearly a year ago, we launched Page Speed for Chrome, which has enabled Chrome users to get Page Speed performance suggestions to make their desktop sites faster. Today, we are releasing an update to Page Speed for Chrome that supports mobile Page Speed analysis via Chrome for Android. With Page Speed for Chrome and Chrome for Android, you can perform Page Speed analysis on the mobile version of your web pages, as they are loaded in the Chrome for Android mobile browser.

Many web sites serve mobile-specific versions of their pages. Often, the mobile pages have very different Page Speed scores and Page Speed reports from their desktop counterparts. Page Speed on Chrome for Android makes it easy to analyze both the desktop and mobile versions of your web pages, so you can be sure that your pages load faster for the users of both your desktop and mobile sites.

When analyzing the mobile version of pages, Page Speed for Chrome tunes its analysis to reflect the unique performance characteristics of mobile devices and networks, suggesting the optimizations that will have the biggest impact on reducing load times for your mobile users. Using the powerful Chrome Developer Tools Extension APIs, Page Speed for Chrome can identify renderer performance optimizations that are especially relevant on mobile, such as removing unnecessary reflows and finding long-running scripts that slow down your pages. Page Speed for Chrome will also automatically minify and optimize your HTML, JavaScript, CSS, and image files and make them available for you to download, so you can easily deploy them on your web server.

To get started using Page Speed on Chrome for Android:

• Follow the instructions to install the Page Speed for Chrome extension on your desktop Chrome browser.
• Enable remote debugging in Chrome running on your Android device.
• Navigate to the remote Chrome Developer Tools page in your desktop browser (localhost:9222) .
• Select one of the Chrome tabs running on your Android device.

In addition to the full Chrome Developer Tools, you will see Page Speed in the Developer Tools panel. Click the Page Speed icon to switch to the Page Speed tab, then click Run Page Speed to generate mobile Page Speed suggestions for the web page that’s loaded on your Android device.

We hope you’ll give Page Speed for Chrome on Android a try. Please send us feedback via our discussion list and let us know what features you’d like to see us to add next. You may also be interested in watching our recent Google I/O talk on Page Speed performance best practices for mobile web sites.


Libo Song is a software engineer at Google Boston working on the Page Speed team to make the web faster.

Matthew Hillyard worked on the Page Speed team as an intern. He has since graduated with a Master’s degree in computer science from Johns Hopkins University and currently is a software engineer on the Google+ team.

Posted by Scott Knaster, Editor

Fridaygram: faster web, stronger machines, prettier planet

By Scott Knaster, Google Code Blog Editor

Everybody likes a faster web, and that theme has been evident this week here on Google Code Blog. On Monday, Yuchung Cheng wrote about Google’s research into making TCP faster through various proposals and experiments. Yesterday, Roberto Peon and Will Chan blogged about SPDY (pronounced speedy), Google’s protocol for speeding up the web’s application layer historically handled by HTTP. In related news this week, the chairman of the HTTPbis Working Group announced support for SPDY in a public post.

At Google, these projects are part of our Make the Web Faster initiative, although TCP improvements and SPDY are efforts of the whole community. Even if you’re not working on TCP or SPDY, you can find lots of useful resources at our Make the Web Faster site. For example, there are articles on compression, caching, metrics, and more, a set of tools for measuring and optimizing pages, and several discussion forums for communicating with other interested folks.

Sometimes stronger is more important than faster. Scientists looking to improve the durability of machinery have been studying the yellow fattail scorpion, which uses bumps on its back to resist damage from sandstorms. Researchers hope to use the scorpion’s design to create erosion-resistant surfaces for blades, pipes, and similar parts. Or maybe they’ll make machines that look like giant yellow scorpions.

Finally, take a step back from everything on Earth and have a look at NASA’s latest "Blue Marble" images of our planet. We have a beautiful home.


Let’s say this fast: Fridaygram posts are just for fun. Fridaygrams are designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. That definitely includes speed, space, and scorpions.

Making the web speedier and safer with SPDY

Will

Roberto

By Roberto Peon and Will Chan, Software Engineers

Cross-posted with the Chromium Blog

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even more closely with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.


Roberto Peon and Will Chan co-lead the SPDY effort at Google. Roberto leads SPDY server efforts and continues to tell people to be unafraid of trying to change the world for the better. Will works on the Chrome network stack and leads the Chrome SPDY efforts. Outside of work, Will enjoys traveling the world in search of cheap beer and absurd situations.

Posted by Scott Knaster, Editor

Let's make TCP faster

By Yuchung Cheng, Make The Web Faster Team

Transmission Control Protocol (TCP), the workhorse of the Internet, is designed to deliver all the Web’s content and operate over a huge range of network types. To deliver content effectively, Web browsers typically open several dozen parallel TCP connections ahead of making actual requests. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable.

Our research shows that the key to reducing latency is saving round trips. We’re experimenting with several improvements to TCP. Here’s a summary of some of our recommendations to make TCP faster:

1. Increase TCP initial congestion window to 10 (IW10). The amount of data sent at the beginning of a TCP connection is currently 3 packets, implying 3 round trips (RTT) to deliver a tiny 15KB-sized content. Our experiments indicate that IW10 reduces the network latency of Web transfers by over 10%.

2. Reduce the initial timeout from 3 seconds to 1 second. An RTT of 3 seconds was appropriate a couple of decades ago, but today’s Internet requires a much smaller timeout. Our rationale for this change is well documented here.

3. Use TCP Fast Open (TFO). For 33% of all HTTP requests, the browser needs to first spend one RTT to establish a TCP connection with the remote peer. Most HTTP responses fit in the initial TCP congestion window of 10 packets, doubling response time. TFO removes this overhead by including the HTTP request in the initial TCP SYN packet. We’ve demonstrated TFO reducing Page Load time by 10% on average, and over 40% in many situations. Our research paper and internet-draft address concerns such as dropped packets and DOS attacks when using TFO.

4. Use Proportional Rate Reduction for TCP (PRR). Packet losses indicate the network is in disorder or is congested. PRR, a new loss recovery algorithm, retransmits smoothly to recover losses during network congestion. The algorithm is faster than the current mechanism by adjusting the transmission rate according to the degree of losses. PRR is now part of the Linux kernel and is in the process of becoming part of the TCP standard.

In addition, we are developing algorithms to recover faster on noisy mobile networks, as well as a guaranteed 2-RTT delivery during startup. All our work on TCP is open-source and publicly available. We disseminate our innovations through the Linux kernel, IETF standards proposals, and research publications. Our goal is to partner with industry and academia to improve TCP for the whole Internet. Please watch this blog and http://code.google.com/speed/ for further information.


Yuchung Cheng works on the transport layer to make the Web faster. He believes the current transport layer badly needs an overhaul to catch up with other (networking) technologies. He can be reached at ycheng@google.com.

Posted by Scott Knaster, Editor

Fridaygram: goodbye to 2011

By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.

Speed metrics in Google Analytics

By Satish Kambala, Staff Software Engineer

At Google we believe that speed matters and a faster web is better for everyone. That’s why we started the Make The Web Faster initiative. To improve the speed of a website, we need to measure how fast web pages load. The Site Speed report, which is now available by default to all users of Google Analytics, provides just that: it enables website owners to measure page load time for their web pages.

You can use the Site Speed report to correlate speed with other metrics in Google Analytics, such as page views and conversions. This enables website owners to identify and optimize those pages that drive these metrics. Page load times can be analyzed by browser type or user location to understand if specific optimizations are required. Recently, we enhanced the Site Speed report by adding a new section called Technical (see screenshot below) which displays network and server time components of page load time.

You can learn more about the Site Speed report here. This report, along with powerful page speed analysis tools such as Page Speed Online, will help website owners delight their users by building fast and responsive websites.

Have ideas on how to make your website faster or ways to speed up the entire Web? Send us your thoughts.


Satish Kambala works at Google on stuff that helps in making the web faster. In his free time, apart from watching cricket and movies, Satish likes exploring places with his wife.

Posted by Scott Knaster, Editor

Mobile Web performance challenges and strategies

By Ramki Krishnan, Technical Program Manager

Consumers are increasingly relying on their mobile devices to access the Web, thrusting mobile web performance into the limelight. Mobile users expect web pages to display on their mobile devices as fast as or faster than on their desktops.

As part of Google’s effort to Make The Web Faster, we invited Guy Podjarny, CTO of Blaze.io, to talk about some of the major performance concerns in the mobile web and ways to alleviate these issues. Guy’s talk focused on Front-End Optimization and highlighted 3 areas: mobile network, software, and hardware. Each of these impacts performance in myriad ways. The full video is available here, and runs just under an hour. If you don’t have time to watch this enlightening talk, this post discusses some key takeaways.

Mobile networks have high latency, and reducing the number of requests and the size of downloads are well-known optimization strategies. Guy also mentions using on-demand image displays such as loading above-the-fold images by default and other images only as they scroll into view. To handle network reliability, he recommends non-blocking requests eliminating single points of failure, with a selective aggregation of files needed for content display. Periodic pinging of the cell tower by the client can also reduce latency associated with dropped connections, but judicious timeouts and battery drain on the mobile device need to be factored in.

Modern mobile browsers are built mobile-friendly, and they can be helped further by exploiting localStorage to store CSS and JavaScript files. Pipelining multiple requests on a connection is an option, but developers need to work around head-of-line blocking by using techniques such as splitting dynamic and static resource requests on different domains.

Mobile hardware CPUs are weaker than their desktop counterparts. Guy points out the need to minimize JavaScript when designing mobile-friendly web pages and avoid reflows or defer JavaScript until after page loads. Clever image rendering techniques such as automatically resizing images to devices and loading full resolution only on zoom can also help.

Guy’s presentation makes clear that mobile web optimizations need to mitigate latencies introduced by mobile networks, software, and hardware. Rapidly changing OSes and browsers add to the challenges facing publishers. New and evolved tools and technologies will help ensure an optimal web browsing experience for mobile users.


Ramki Krishnan works at Google on the "Make The Web Faster" team. When not at work, he dreams of being a tennis pro, a humorist, and a rock drummer all rolled into one.

Posted by Scott Knaster, Editor