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

Seo Master present to you:

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

2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you:
By Mark Davis, International Software Architect

Until now, it has been very difficult for web application designers to do something as simple as sort names correctly according to the user's language. And it matters: English readers wouldn’t expect Århus to sort below Zürich, but Danish speakers would.

Because linguistic sorting requires a sophisticated algorithm and lots of data, it was impractical to do this natively in JavaScript. Until now, the only full solution for sorting on the client side was to generate on a server a sortKey for every string that needed to be sorted, and send the sortkeys — base64-encoded — down to the client along with the strings. Pretty ugly! And what’s doubly frustrating is that the underlying operating systems have all been able to handle this, whether through International Components for Unicode (ICU) or Windows APIs.

The new internationalization specification for ECMAScript (the “official” name for JavaScript) changes this picture. It is already in the production version of Chrome, and is on track for other major browsers.

Linguistic sorting is not the only benefit—not only will users be able to see names sorted correctly, but also correct numeric values (“1,234.56” in English, but “1.234,56” in German), dates (“March 10, 2012” vs “10. März 2012”), and so on. While the results might not be precisely the same in every browser, they should be appropriate to the language, and are returned using a uniform API.

On any enabled browser — in its supported languages — web application developers can:

• compare strings correctly: choosing whether or not to ignore accents, case differences, etc.
• format numbers correctly: choosing decimal places, currencies, whether to use thousands-separator, etc.
• format dates and times correctly: choosing decimal places, numeric vs named months, etc.
• match locales: comparing the user’s desired locales (say Arabic and French) against the supported locales (say French, German, and English), to get the best match.

The API also allows for linguistic support in offline web applications, which wasn’t practical before. It builds on the industry standards BCP47 (for identifying languages and locales) and LDML (part of the Unicode Common Locale Data Repository (CLDR) project). For the gory details of the spec, see ECMA-402: ECMAScript Internationalization API Specification (just approved by the Ecma General Assembly).


Mark Davis is president and cofounder of the Unicode consortium, and founder of ICU and CLDR. Mark is fond of food, film, travel, and RPGs. Mark lived for 4 years in Switzerland, and is moving back in February.

Posted by Scott Knaster, Editor

2013, By: Seo Master