Thursday, June 04, 2009 at 9:29 AM
At Google, we focus constantly on speed; we believe that making our websites load and display faster improves the user's experience and helps them become more productive. Today, we want to share with the web community some of the best practices we've used and developed over the years, by open-sourcing Page Speed.
Page Speed is a tool we've been using internally to improve the performance of our web pages -- it's a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn't actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.
Page Speed's suggestions are based on a set of commonly accepted best practices that we and other websites implement. To help you understand the suggestions and rules, we have created detailed documentation to describe the rationale behind each of the rules. We look forward to your feedback on the Webmaster Help Forum.
22 comments:
It looks a lot like the great YSlow plug-in from Yahoo. But the more tools available to fight against the poorly conceived websites, the better !
I think this could be a great help for webmasters and could make web designing faster.... I will give it a try..
So how is this not a shameless ripoff of YSlow?
Nic: It's a bit hard to rip something off if you've already been using it internally for years.
Say it with me now:
Step 1: Read
Step 2: Comprehend
You don't have to be the first to be the best. Sad for YSlow, but good for us.
Your documentation makes a number of extremely interesting points, and is full of thought provoking advice. For example, that ‘:hover’ is slower than putting presentational code into ‘onhover’ events in JavaScript is something I'd never heard before.
Unfortunately, this documentation provides no context for when this is true, nor does it cite any prior work supporting the claim, it doesn't reference any testing or figures or any kind of quantification for the level of performance impact.
You're effectively telling people to sacrifice long accepted standards for code organisation and maintenance techniques (that is, separating the behaviour and presentation layers cleanly into JS and CSS respectively), for blind pursuit of an unspecified performance increase.
Given the varied speed of web browsers (IE's JS engine is very slow, Safari's is very fast), are we to assume that ‘:hover’ is _always_ slower than JavaScript?
The docs are half-baked, and I think misleading when you put across such statements as unsupported facts. Iteration would be appreciated.
I think that if anyone other than Google were to have posted this without mentioning yslow it would simply come across as ignorance. The fact that it is from Google just suggests rudeness and an element of condescendence to the reader. This from a company that I respect far more than most in the tech market. I'm disappointed.
Wow, thanks for creating two directories right smack in my $HOME without even alerting me. And no configurable destination, even?
At the very least, the default should be "don't optimize assets". Or, I don't know, use temp directories like good OS citizens should? Writing willy-nilly to a user's home directory is bad form, guys.
Otherwise, very slick. The more tools the merrier.
I couldn't say it better than Adrian so I'm going to rip off his comment:
I think that if anyone other than Google were to have posted this without mentioning yslow it would simply come across as ignorance. The fact that it is from Google just suggests rudeness and an element of condescendence to the reader. This from a company that I respect far more than most in the tech market. I'm disappointed.
Fantastic addon. It was educating to read about CSS selectors and patterns.
The most useful part of PageSpeed in comparison to my current favorite YSlow is that it provides very specific action items. Very novice website owners can also follow the instructions. Saves a ton of time. Perfect! :)
A good addition would be a Printable Version of the report the way YSlow provides. It would be handy to manage to-do lists and exchange performance reports.
On Page Speed Activity tab, it seemed to be all messed up. It did the activity profiling for all pages open currently in the browser and not only for the specific page open in the current tab. Bug ? or did I miss some settings.
Only had a quick glance, but:
1) You state that Expires is more widely implemented than Cache-Control: max-age. On what do you base that? See also: http://www.mnot.net/blog/2007/05/15/expires_max-age
2) You advise to (almost) always set Cache-Control: public. That wastes bits; the only time you need to set public is when there are Authorization request headers being sent (i.e., HTTP auth is in use).By default, responses are implicitly public.
Cheers,
I see a few things in the documentation that, quite honestly, make me scratch my head. I've never seen any indication that using ":hover" has a more negative impact on performance than registering them via JS, and there's no concrete evidence proposed in the documentation to back that idea up.
Seriously, correct me if I'm wrong, but historically CSS has always been faster at parsing the DOM than JS.
On another note, I'd love to know why the documentation advocates using the following piece of code* for dynamically adding script tags, when Analytics itself uses a document.write() that's technically not even a valid function for XHTML documents.
*
// Add a script element as a child of the body
function downloadJSAtOnload() {
var element = document.createElement("script");
element.src = "deferredfunctions.js";
document.body.appendChild(element);
}
The average cookie size for all requests on this page is 368 bytes.
The following domains have an average cookie size in excess of 400 bytes. Reducing the size of cookies for these domains can reduce the time it takes to send requests.
* www.google.com has a cookie size of 527 bytes.
That comes because I have Google Custom Search on my page so may be you could do something about the cookies size.
AUTHOR:
Please remove comment by tdavis dated June4, 2009 4:16 PM. This comment borders on bullying and has no place within this discussion. The fact is you never said Google was using Page Speed for years, only that Google was using "best practices" for years. Perhaps tdavis should read and comprehend more carefully. You may also not publish this comment since I have not yet used and therefor should not comment on Page Speed.
For those of you concerned that Page Speed is a ripoff of YSlow, I'll take a wild guess and say Steve Souders--original author of YSlow, who now works at Google--might have had something to do with it. :)
Somehow I missed knowing about setting the expiration date, although I've been studying web development for several years. Anyway, I done several quick searches and I still have no idea how to actually set it. Google, would you tell me, please?
YSlow and Page Speed use some common "rules" that are based on industry best practices. There are however some rules such as deferring JavaScript until after the page has loaded that Page Speed implements exclusively. In addition, Page Speed provides web developers with an activity panel that allows them to do a "before and after" comparison when considering the implementation of Page Speed's suggestions. Finally, Page Speed is an open source tool that is open to community contributions.
@Daniel, bug filed here.
@Ben Ward, @mnot, @Ryan McGrath, thank you so much for your feedback! to encourage discussion, we're going to reply over to our discussion group .
Please join us there to discuss this in more detail.
@Steve, Issue filed
Ok! that is fine. But i am facing a different problem with
http://translate.google.com/translate_t?hl=en#auto|en|%E0%A6%AC%E0%A6%BE%E0%A6%B9!%20%E0%A6%B8%E0%A7%81%E0%A6%A8%E0%A7%8D%E0%A6%A6%E0%A6%B0%20%E0%A6%B8%E0%A6%AC%20%E0%A6%93%E0%A7%9F%E0%A7%87%E0%A6%AC%E0%A6%B8%E0%A6%BE%E0%A6%87%E0%A6%A4%E0%A5%A4%20%E0%A6%A7%E0%A6%A8%E0%A7%8D%E0%A6%AF%E0%A6%AC%E0%A6%BE%E0%A6%A6%20%E0%A6%97%E0%A7%8D%E0%A6%B0%E0%A6%B9%E0%A6%A8%20%E0%A6%95%E0%A6%B0%E0%A7%81%E0%A6%A8%E0%A5%A4
Please do something.
to all of you upset about the similarities between YSlow and Page Speed:
CALM DOWN, NERDS!!!
as the thread starter pointed out - the web is a better place when developers have more tools available to improve their sites. having developers (us) bitching about Page Speed ripping off YSlow is like real estate developers bitching about how there are too many reputable geologists available to help them assess property values.
If page speed is so important to to Google, then why is it that so many pages are very slow to load whilst waiting for "ssl.google-analytics.com"?
I experience big delays on many pages whilst waiting to Analytics.
Google should not be advocating page speed when their own analytics tracking is causing some of the worst slow-downs.
Hi everyone,
Since over a year has passed since we published this post, we're closing the comments to help us focus on the work ahead. If you still have a question or comment you'd like to discuss, free to visit and/or post your topic in our Webmaster Central Help Forum.
Thanks and take care,
The Webmaster Central Team
Post a Comment