Les nouveautés et Tutoriels de Votre Codeur | SEO | Création de site web | Création de logiciel

seo Add SPDY support to your Apache server with mod_spdy 2013

Seo Master present to you:
Author Photo
Bryan
Author Photo
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:


single thread

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.


multiple threads

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

seo Introducing Page Speed Online, with mobile support 2013

Seo Master present to you:

At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.



In addition, we’ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.

Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.

Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.2013, By: Seo Master

seo CSS: fast to load, easy to maintain 2013

Seo Master present to you:
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


2013, By: Seo Master

seo Page Speed for Chrome, and in 40 languages! 2013

Seo Master present to you:

(Cross-posted from the Google Webmaster Central Blog.)


Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

2013, By: Seo Master

seo Making APIs Faster: Introducing Partial Response and Partial Update 2013

Seo Master present to you: At Google, we strive to make the web faster. Today, we’re proud to take our first big step in making APIs faster by introducing two experimental features in the Google Data Protocol, partial response and partial update. Together, partial response and partial update can drastically reduce the network, memory, and CPU resources needed to work with Google APIs.

It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.

With the addition of partial response, however, you can now use the fields query parameter to request only relevant information -- in this case, event titles and times. Constructing such a request using the fields query parameter is simple:

GET http://www.google.com/calendar/feeds/zachpm@google.com/private/full?fields=entry(title,gd:when)

By including the entry argument and specifying title and gd:when, this request ensures that the partial response contains only the title and time for each event, along with a small amount of wrapping metadata.

But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP PATCH verb to send the modified data back to the server. The server then intelligently interprets your PATCH, updating only the fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data remains server-side and untouched.

Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.

As of today, partial response and partial update are supported in four Google APIs:
... and we’re planning on adding support for most of the APIs that are built on the Google Data Protocol soon. Stay tuned for more information, and if you can’t wait, feel free to lobby for partial update and partial response in your favorite API’s public support group. And for those of you who’ll be at Google I/O this year, be sure to check out the Google API sessions that are in store.

Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!

2013, By: Seo Master

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

Seo Master present to you: Author PhotoBy 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."

SiteGround PageSpeed control panel

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
2013, By: Seo Master

seo Your Web, Half a Second Sooner 2013

Seo Master present to you: At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.

The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.

How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.

The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.

And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.

2013, By: Seo Master

seo How we improved performance on Google Code 2013

Seo Master present to you:

If you're a frequent visitor to code.google.com for product updates and reference materials for Google APIs you're working with, you might have noticed that the page loading time (or page rendering time depending on how you see it) has reduced in varying degrees in the past several weeks.

As you'll see below, we've made several changes to help reduce user-perceived latency. This is not an exhaustive list of all improvements we've made recently, but these are the major ones we've made.

As Steve Souders emphasizes as the "Performance Golden Rule" in his book High Performance Web Sites, "only 10-20% of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page (p.5)".

We agree. That's why we focused our effort on reducing the number and size of downloads (HTTP requests) for the "components" throughout Google Code.
  • Combined and minimized JavaScript and CSS files used throughout the site
Downloading JavaScript and CSS files blocks rendering of the rest of the page. Thus, to reduce the number of HTTP requests made on the initial page load, we combined frequently-used JavaScript and CSS files into one file each. This technique has brought down 20 HTTP requests down to just 2. We also minimized the files by stripping out unnecessary whitespace and shortening function/variable names whenever possible.
  • Implemented CSS sprites for frequently-used images
There are 7 images prominently used throughout Google Code, including the Google Code logo, the googley balls at the bottom of every page, the plus and minus signs as well as the subscribe icon inside each blog gadget.

Although browsers usually download several images in parallel, we concatenated these images into one image so only one HTTP request would be made. Of course, concatenating several images into one required us to make several changes in HTML/CSS. For example, instead of having:

<img src="/images/plus.gif" />


We had to change it to:

<div style="background-image:url(/images/sprites.gif); background-position:-28px -246px; width:9px; height:9px">&amp;</div></span>


where sprites.gif is the concatenated image and background-position and width/height carefully calculated.
  • Implemented lazy loading of Google AJAX APIs loader module (google.load)
We like to eat our own dogfood. Among other APIs, we use our very own AJAX Feed API on product homepages inside the blog gadgets and the AJAX Search API on the search page. These Google AJAX APIs require the Google loader module (google.load) to be loaded first before any of the specific AJAX APIs (i.e. AJAX Feed API, AJAX Search API, Maps API) can be initialized and used. Traditionally, the Google AJAX APIs loader module would be loaded by including the following <script> tag in the <head> section:
    <script type="text/javascript" src="http://www.google.com/jsapi"></script>
This works well in most cases, but when optimizing for the display of static content, this blocks the browser from rendering the rest of the page until it's finished loading that script, thus impacting the user-perceived latency. So instead of loading the Google AJAX APIs loader module upfront, we are now loading it lazily only on the pages where it's required. This is made possible as follows (please note that this is a stripped-down version of what we have on Google Code):

First, in the <head> section, we load the Google AJAX APIs loader module via DOM scripting only on the pages where it's required:

if (needToLoadGoogleAjaxApisLoaderModule) {
// Load Google AJAX APIs loader module (google.load)
var script = document.createElement('script');
script.src = 'http://www.google.com/jsapi?callback=googleLoadCallback';
script.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(script);
}
It's important to add the 'callback' parameter in the src attribute, 'callback=googleLoadCallback'. This callback handler will then be called whenever the Google loader module is finished loading.

Then, in the Google loader callback handler (googleLoadCallback()), we initialize the AJAX Feed API and provide the function name that utilizes the AJAX Feed API (startUsingAjaxFeedAPI):
function googleLoadCallback() {
// Initialize AJAX Feed API
google.load('feeds', '1', {callback: startUsingAjaxFeedAPI});
}

function startUsingAjaxFeedAPI() {
// Start using AJAX Feed API
var feed = new google.feeds.Feed(someFeedUrl);
...
}

In effect, we're loading the AJAX Feed API on-demand through the use of two consecutive callback handlers, first to load the Google AJAX APIs loader module (google.load) and then to initialize the AJAX Feed API before it's used. Similar technique can be used for the Maps API and the AJAX Search API.

By now you're probably wondering just how much of an impact did these changes have on Google Code anyways? According to our latency measurement stats, the user-perceived latency on Google Code dropped quite a bit, anywhere between 30% and 70% depending on the page. This is a huge return for relatively small investments we've made along the way, and we hope you'll find these techniques useful for your own web development as well.2013, By: Seo Master

seo Steve Souders: Life's Too Short, Write Fast Code (part 2) 2013

Seo Master present to you: By Steve Souders, Member of Technical Staff

I've been working on a follow-up book to High Performance Web Sites called Even Faster Web Sites. As I finish chapters, I talk about the findings at conferences and tech talks. The first three chapters are Split the Initial Payload, Load Scripts Without Blocking, and Don't Scatter Inline Scripts. You can hear about those best practices in my video from Google I/O.

This talk presents the next three chapters: Couple Asynchronous Scripts, Use Iframes Sparingly, and Flush the Document Early.

The adoption of JavaScript is growing, but the blocking behavior of external scripts is well known. That's why it's important to use one of the techniques to load scripts without blocking (see the Google I/O talk). But loading scripts asynchronously means that inlined code that uses symbols from the script must be coupled in some way. Without this coupling, undefined symbol errors occur when the inlined code is executed before the external script arrives.

There are five techniques for coupling asynchronous scripts: hardcoded callback, window onload, timer, script onload, and degrading script tags. All of the techniques work. Degrading scripts tags is the most elegant, but isn't well known. Script onload is the most versatile technique and is the one I recommend people use. In the talk, I then go into detail, including many code examples, on how to load scripts asynchronously and use these coupling techniques to speed up your web page.

Iframes have a negative impact on web pages. They are the most expensive DOM element to create. They block the parent's onload event (although there's a workaround to this problem in Safari and Chrome). Also, the main page can block resources in the iframe. It's important to understand these interactions if you use iframes in your page.

Flushing the document early allows the browser to start rendering the page and downloading resources in the page, even before the entire HTML document has arrived. But getting flushing to work can feel like trying to get the stars to align. You need to understand PHP's output_buffering, HTTP/1.1's chunked encoding, Apache's DeflateBufferSize, the impact of proxies, minimum HTML size requirements in Safari and Chrome, and the need for domain sharding to avoid having the HTML document block other downloads.

If your company wants a better user experience, increased revenues, and reduced operating costs, the key is to create even faster web sites. For more information on these best practices, watch the video below and read the slides.



Check out other talks in this tech speaker series:
2013, By: Seo Master

seo Introducing Page Speed mobile analysis, on Google Chrome for Android 2013

Seo Master present to you:
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.


Page Speed screen shot

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
2013, By: Seo Master

seo John Resig: Drop-in JavaScript Performance 2013

Seo Master present to you:

Although Mozilla is right across the street, their JavaScript evangelist, John Resig, hails from Boston. When he comes to town, it's a great opportunity to learn about his current explorations in the world of JavaScript. I was fortunate to be able to host him for a Google tech talk last week. The video and slides are now available. In addition to his evangelism role at Mozilla, John is the creator of jQuery and Dromaeo, author of Pro JavaScript Techniques, and member of the Firebug Working Group. He's currently working on Secrets of the JavaScript Ninja, due out sometime this year.

In this talk, John starts off highlighting why performance will improve in the next generation of browsers, thanks to advances in JavaScript engines and new features such as process per tab and parallel script loading. He digs deeper into JavaScript performance, touching on shaping, tracing, just-in-time compilation, and the various benchmarks (SunSpider, Dromaeo, and V8 benchmark). John plugs my UA Profiler, with its tests for simultaneous connections, parallel script loading, and link prefetching. He wraps up with a collection of many other advanced features in the areas of communiction, DOM, styling, data, and measurements.



Wow, a lot of material to cover in one hour. An added benefit of having this talk given at Google is the questions from the audience. At one point, a member of the Google Chrome team goes into detail about how parsing works in V8. Many thanks to John for sharing his work and insights with all of us.

2013, By: Seo Master

seo Go Daddy Makes The Web Faster by enabling mod_pagespeed 2013

Seo Master present to you:

As part of our Make The Web Faster initiative, Google announced the availability of mod_pagespeed, an open-source module for Apache webservers to automatically accelerate the sites they serve. Go Daddy, the top web hosting provider and world's largest domain name registrar, announced that they would roll out the mod_pagespeed feature for their Linux Web hosting customers. The feature is now available and is in use by Go Daddy customers who have already started to report faster webpage load times.

“Who on the Internet wouldn't want a faster website?” asked Go Daddy CEO and Founder Bob Parsons. “The benefits of mod_pagespeed are really a slam dunk. It’s built to boost users’ web performance, and ultimately, the bottom line for their business.”

By using several filters that implement web performance best practices, mod_pagespeed rewrites web page resources to automatically optimize their content. The filters improve performance for JavaScript, HTML and CSS, as well as JPEG and PNG images.

Mike Bender, co-creator of photo-blog AwkwardFamilyPhotos.com and Go Daddy customer, detected a 48% decrease, slicing the load time for his image-rich website from 12.8 to 6.6 seconds. mod_pagespeed speeds up the first visit of the site by reducing the payload size and improving compression. Repeat visits are accelerated by making caching more efficient and decreasing the size of resources such as CSS and HTML on the page as demonstrated in this chart (where smaller is faster):



“From the moment we enabled mod_pagespeed, the difference was noticeable,” said Bender. “It was a simple ‘flick of the switch,’ and the site started loading faster.”


For Go Daddy customers currently using the Linux 4GH web hosting platform, find out how to enable mod_pagespeed for your own website here. Other webmasters can install mod_pagespeed binaries or build directly from source.


2013, By: Seo Master

seo Fridaygram: faster web, stronger machines, prettier planet 2013

Seo Master present to you: Author Photo
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.
2013, By: Seo Master

seo Making the web speedier and safer with SPDY 2013

Seo Master present to you:
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
2013, By: Seo Master

seo Let's make TCP faster 2013

Seo Master present to you: Author Photo
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
2013, By: Seo Master
Powered by Blogger.