By Matthew Steele, PageSpeed Insights Team

Just over two years ago, we launched mod_spdy, a plugin for the popular Apache Web Server that adds support for the SPDY protocol. At the time, our goal was both to speed up the web and help fuel the growth and adoption of SPDY by making it easy for Apache 2.2 users to install and enable SPDY on their sites. Today, SPDY is now widely adopted, officially supported by several web servers and many popular sites, and the IETF is using it as the basis for the upcoming HTTP/2.0 protocol. The time seems right for mod_spdy to cease being a third-party add-on, and to instead become a core part of Apache httpd.

We’re pleased to announce that Google has formally donated mod_spdy’s code to the Apache Software Foundation, and it is now a part of the Apache httpd codebase.

“The intent is to work on making it fully part of [Apache] 2.4 and, of course, a core part of 2.6/3.0” - Jim Jagielski, co-founder of the ASF.

Being a part of Apache core will make SPDY support even more widely available for Apache httpd users, and pave the way for HTTP/2.0. It will also further improve that support over the original version of mod_spdy by better integrating SPDY and HTTP/2.0’s multiplexing features with the core part of the server.

We’re grateful for all the adoption and feedback we’ve gotten from mod_spdy users over the past two years, and we’re very excited to see the Apache Software Foundation take it from here!

Matthew Steele is a Software Engineer on the Google PageSpeed Insights Team in Cambridge, MA. He and his team focus on developing tools to help site owners make their sites faster and more usable.

Posted by Louis Gray, Googler

By Matthew Steele and Doantam Phan, PageSpeed Insights Team

/via the Google Webmaster Blog

To help developers and webmasters make their pages mobile-friendly, we recently updated PageSpeed Insights with additional recommendations on mobile usability. 


Poor usability can diminish the benefits of a fast page load. We know the average mobile page takes more than 7 seconds to load, and by using the PageSpeed Insights tool and following its speed recommendations, you can make your page load much faster. But suppose your fast mobile site loads in just 2 seconds instead of 7 seconds. If mobile users still have to spend another 5 seconds once the page loads to pinch-zoom and scroll the screen before they can start reading the text and interacting with the page, then that site isn’t really fast to use after all. PageSpeed Insights’ new User Experience rules can help you find and fix these usability issues. 

These new recommendations currently cover the following areas: 

• Configure the viewport: Without a meta-viewport tag, modern mobile browsers will assume your page is not mobile-friendly, and will fall back to a desktop viewport and possibly apply font-boosting, interfering with your intended page layout. Configuring the viewport to width=device-width should be your first step in mobilizing your site.
• Size content to the viewport: Users expect mobile sites to scroll vertically, not horizontally. Once you’ve configured your viewport, make sure your page content fits the width of that viewport, keeping in mind that not all mobile devices are the same width.
• Use legible font sizes: If users have to zoom in just to be able read your article text on their smartphone screen, then your site isn’t mobile-friendly. PageSpeed Insights checks that your site’s text is large enough for most users to read comfortably.
• Size tap targets appropriately: Nothing’s more frustrating than trying to tap a button or link on a phone or tablet touchscreen, and accidentally hitting the wrong one because your finger pad is much bigger than a desktop mouse cursor. Make sure that your mobile site’s touchscreen tap targets are large enough to press easily.
• Avoid plugins: Most smartphones don’t support Flash or other browser plugins, so make sure your mobile site doesn't rely on plugins.

These rules are described in more detail in our help pages. When you’re ready, you can test your pages and the improvements you make using the PageSpeed Insights tool. We’ve also updated PageSpeed Insights to use a mobile friendly design, and we’ve translated our documents into additional languages.

As always, if you have any questions or feedback, please post in our discussion group. 

Posted by Louis Gray, Googler

By Jan-Willem Maessen, Software Engineer

Recent betas (1.5 and later) of mod_pagespeed and ngx_pagespeed introduce new optimizations that render pages up to 2x faster, particularly on mobile devices. This webpagetest video shows the results:



This speedup comes thanks to two new PageSpeed optimizations:

• prioritize_critical_css finds the CSS rules that are used to initially render your page.
• The critical image beacon identifies the images that appear on screen when your page is first rendered and uses this to guide lazyload_images and inline_preview_images.

These combine with two existing PageSpeed optimizations:

• defer_javascript prevents scripts from running until the page has loaded.
• convert_jpeg_to_webp reduces the size of images that are downloaded by webp-capable browsers.

What happens when you turn on these optimizations

Let’s compare the behavior of the page before and after optimization:
Before optimization, first render doesn’t occur until the CSS has arrived (vertical gray bar at 2.3s), and images (purple) don’t finish downloading until substantially later. The large above the fold image dominates above the fold rendering time (vertical blue bar at 3.4s).
During optimization, the prioritize_critical_css filter inlines the CSS required to render the page directly into the HTML. The inline_preview_images filter creates a low-quality version of the large above the fold image and inlines that in the page. The core image optimization filter also inlines some of the smaller above the fold images. The above the fold content is fully rendered after only 2.0s (vertical orange line).

Only after the page is rendered is the JavaScript code run thanks to the defer_javascript filter. At the same time the full-resolution version of the above the fold image is loaded; since convert_jpeg_to_webp is enabled, it is served in webp format and is smaller than the original even though the quality is the same. The full resolution version of the page is available after 3.1s (vertical gray line – still faster than the original page). The lazyload_images filter means the remaining images won’t be loaded until the page is scrolled (or, in the most recent version of PageSpeed, after all the other page content has been loaded).

Enabling these optimizations

To enable these optimizations in mod_pagespeed, download and install the latest beta. To do a test like the one you see here, simply add these lines to your pagespeed.conf file:
ModPagespeedEnableFilters prioritize_critical_css,defer_javascript
ModPagespeedEnableFilters convert_jpeg_to_webp
ModPagespeedEnableFilters lazyload_images,inline_preview_images

If you use ngx_pagespeed, install from the latest source and enable the filters in your configuration:
pagespeed EnableFilters prioritize_critical_css,defer_javascript;
pagespeed EnableFilters convert_jpeg_to_webp;
pagespeed EnableFilters lazyload_images,inline_preview_images;

Compare your results to pages loaded with ?ModPagespeed=off or with ?ModPagespeedFilters=core. If you see breakage on your site with the new filters, try omitting defer_javascript and/or lazyload_images from the list of enabled filters.

Conclusion

We hope you’ll try out the latest optimizations and let us know how they work for you. Meanwhile we’ll continue our quest for better optimizations and faster page performance. If you’re interested in joining the conversation, check out https://code.google.com/p/modpagespeed/ and subscribe to our discussion list, [email protected].


Jan-Willem Maessen is a Software Engineer on the PageSpeed team, and helped build many of the optimizations including the ones you see here. He's been known to hit otherwise reasonable consenting software engineers about the head with a steel longsword.

Posted by Scott Knaster, Editor

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

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

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

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

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