MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you:

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

2013, By: Seo Master

Seo Master present to you:

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

2013, By: Seo Master