Page Speed 1.6 Beta was released today. There are a few big changes, but the most important fix is compatibility with Firefox 3.6. If you’re running the latest version of Firefox visit the download page to get Page Speed 1.6. Phew!
I wanted to highlight some of the new features mentioned in the 1.6 release notes: new rules and native library.
Three new rules were added as part of Page Speed 1.6:
- Specify a character set early – If you don’t specify a character set for your web pages or specify it too low in the page, the browser could parse it incorrectly. You can specify a character set using the META tag or in the Content-Type response header. Returning charset in the Content-Type header will ensure the browser sees it early. (See this Zoompf post for more information.)
- Minify HTML – Top performing web sites are already on top of this, right? Analyzing the Alexa U.S. top 10 shows an average savings of 8% if they minified their HTML. You can easily check your site with this new rule, and even save the optimized version.
- Minimize Request Size – Okay, this is cool and shows how Google tries to squeeze out every last drop of performance. This rule sees if the total size of the request headers exceed one packet (~1500 bytes). Requiring a roundtrip just to submit the request hurts performance, especially for users with high latency.
The other big feature I wanted to highlight first came out in Page Speed 1.5 but didn’t get much attention – the Page Speed C++ Native Library. It probably didn’t get much attention because it’s one of those changes that, if done correctly, no one notices. The work behind the native library involves porting the rules from JavaScript to C++. Why bother? Here’s what the release notes say:
Making Page Speed run faster is great, but the idea of implementing the performance logic in a C++ library so the rules can be run in other programs is very cool. And where have we seen this recently? In the Site Performance section recently added to Webmaster Tools. Now we have a server-side tool that produces the same recommendations found from running the Page Speed add-on. Here are the rules that have been ported to the native library:
added in 1.5:
|
added in 1.6:
|
Webmaster Tools Site Performance today shows recommendations based on the rules in native library 1.5. Now that more rules have been added to native library 1.6, webmasters can expect to see those recommendations in the near future. But this integration shouldn’t stop with Webmaster Tools. I’d love to see other tools and services integrate native library. If you’re interested in using native library, check out the page-speed project on Google Code and contact the page-speed-discuss Google Group.
Ofer Wald | 02-Feb-10 at 12:49 am | Permalink
I have a question here, wrt your stance on the html minify feature.
1. won’t minified pages fail validation?
2. any programs that actually do that?
which ruleset is better, yahoo’s or google’s?
Billy Hoffman | 02-Feb-10 at 6:54 am | Permalink
Ofer,
1- It depends. If by “minify” are simply removing HTML and non-conditional HTML comments than it will not effect validaiton. Some commerical/shareware HTML minifiers will do things like removing closing tags (like ), removing quotes from attributes, things like that. Those you should stay away from because will break validation.
Check out this article for more safe HTML minification tips: http://perfectionkills.com/optimizing-html/
2-HTML Tidy should do basic minification no problem. Just be careful when running it on PHP or ASP.NET files instead of pure HTML files. It might strip out some of the server-side application code!
Billy Hoffman | 02-Feb-10 at 6:55 am | Permalink
sorry, that posted prematurely! How embarrassing! :-)
I meant to say that basic removing of whitespace and removing HTML comments that are not conditional comments should not affect validation at all.
Steve Souders | 02-Feb-10 at 9:25 am | Permalink
@Ofer: There’s room for minifying HTML and still passing validation. I think it would be good to have an option in the minifier to do this, or to be more aggressive if the developer wants to. I often use the W3C validator.
Right now, you should run both Page Speed and YSlow. There are about 25 rules that overlap, but each tool has 5-10 rules that are unique, and some of these rules are critical. That’s why I’m excited about the native library. We could move in a direction where there’s a common set of rules that is shared by all tools, so developers don’t get varied results depending on their choice of OS, browser, and tool.
Sergey Chernyshev | 02-Feb-10 at 2:25 pm | Permalink
WOW – I missed native library part in 1.15!
I’d love to have a daemon that runs rules and then sends them as a beacon to ShowSlow and all that without a browser – that’d be just perfect!
kangax | 02-Feb-10 at 2:49 pm | Permalink
@Billy Hoffman
Actually, removing quotes around attributes or dropping optional tags does not always affect document validity. If we are talking about HTML 4.01 (which most of the documents on the web are _served_ as, even with misleading XHTML doctype stamped on top), there’s absolutely nothing invalid about, say, “P” or “LI” elements with omitted closing tags — HTML 4.01 doctype allows it (http://www.w3.org/TR/REC-html40/sgml/dtd.html). You might have noticed that even in “Agressive optimizations” section of my post (http://perfectionkills.com/optimizing-html/#agressive_optimizations), I mentioned that none of the transformations invalidate a document.
@Steve
Clicking on “Minify HTML” in PageSpeed brings to a page that has no such section. PageSpeed also always shows “ok” icon, even when on non-minified pages. Am I missing something? What’s the exact criteria for this rule to start alerting about performance problem?
Steve Souders | 02-Feb-10 at 3:12 pm | Permalink
@kangax: Documentation for these new rules should be there soon. (Our tech writer was on vacation!)
Vincent Flanders | 03-Feb-10 at 4:56 pm | Permalink
The Minify HTML seems to be screwed up and mangling the pages (although they display correctly). Validate http://www.webpagesthatsuck.com/articles.html — which has 3 errors caused by Google — against the “minified” version http://www.webpagesthatsuck.com/articles-screwed-up.html — which has 577 errors.