It will automatically strip inline css and js out of a html page and then create links to an external version. It will automatically set very long cache times. It minifies css and javascript on the fly, strips whitespace and comments from the html.
Then for images, it automatically rescales them, strips out meta data and recompresses. It even converts img tags to use data: uris when it's safe and efficient to do so.
That's pretty cool, though the biggest slowdown for most sites are all of the third-party scripts being loaded from remote servers. If people really realized how much page speed matters in usability, they would be loathe to add in all the scripts from facebook and digg and google and 12 different analytics services.
Ad networks are a particular culprit. For many (banner) ad networks, HTTP requests get bounced around so many servers that it can really slow things down.
From the first link: "this practice might not be welcome by Google".
I don't know what's the second link for, as analytics are asynchronous per se?
EDIT: By the date on the second url, very probably is a hack for an older version of Analytics.
EDIT 2: First link is an unaccepted answer on an stackoverflow-like site on the topic for using an against the rules of Google hack. And Google doesn't need much help for closing your account and your money.
Re: Analytics; I'm not sure if the default code google gives you for analytics is async _now_ but based on this http://code.google.com/apis/analytics/docs/tracking/asyncTra... it certainly seems like it, at least at one point, it was not. Again, that may have changed.
Here is another link for async adsense with code included. The author has also posted his e-mail conversation with a rep. from the Google Adsense team. There is nothing fancy going on here, just iframes, really.
Yeah, its because many of the ad networks that you may load into it simply cannot work asynchronously (document.write). So they have to enforce synchronous loading on the ad manger code.
Those banner networks deserve to lose customers to the banner networks that do support asynchronous loading. Does anybody have a list of which banner networks allow it and which don't?
Not if they are contextual and demand the host script to be in the top level document. (and this is against the terms of use of many advertising services)
The longer it takes me to load your page, the less likely I will ever see it (because I back out to my previous page) or will ever come back to it (because of the bad experience).
Put script tags at the end of the body, not in the header. If you still have a problem, dynamically add the script tags after the page has already loaded and displayed.
I'm sure there is going to be tons of positives to this from the community, many I can identify myself, but can someone list some NEGATIVEs that may arise by using this?
This is a tool that mindlessly applies optimisations that are lossy or change behavior of the page. Sometimes it may break things (e.g. I use `input[type=text]` selector in my CSS, and removal of "redundant" `type="text"` attribute from source would break it).
It also wastes some processing time on applying on-the-fly code changes you could do yourself in the source.
If you follow performance best practices, you may optimize pages better yourself (you need to judge what is better to inline, what can be made async. Simple heuristics of this module uses may be too crude).
I use Smarty as a templating engine and sometimes I have to generate a few lines of javascript or css dynamically on the page based on php variables at runtime. I wouldn't want these to be stripped out and cached.
Usually I do a lot of optimization in the templates. For example, Smarty lets you wrap your output in {strip} tags to remove whitespace and newlines. And I have a script to concatenate and minify javascript and css. Plus mod_deflate on the server. I serve images from s3/cloudfront and there is a script that will use smush.it to compress everything in an s3 folder and set the expires tags.
CSS sees DOM attributes (what you get from element.getAttribute('type')), and not DOM properties (element.type).
These are different things kept roughly in sync by setters/getters (called "reflected properties" in HTML spec).
The `type` attribute is also supposed to have default value implied by the DTD, but that could only work in "validating" SGML/XML parsers (which browsers aren't).
I didn't know that. I tested it myself and you're right. The "Elide Attributes" filter seems fairly pointless anyway. I can't imagine it making that much of a difference in performance even if it was safe.
Given two image filenames: "pogo-sticks.png" and "ic.HASH.x,pogo-sticks,p.png", I'm willing to bet the former will rank higher and lead to more pogo stick traffic and sales because of the straightforward filename.
From the horse's mouth: "optimizing your image filenames and alt text makes it easier for image search projects like Google Image Search to better understand your images."
Anything that makes it harder for Google to understand your site is a losing business proposition.
I'd rather use PageSpeed for Firefox (optimize in dev, set the appropriate filenames, then deploy to production) to avoid any possible ranking penalties caused by this filter in production.
If you click on the individual filters to read their descriptions, they all have a "Risks" section at the bottom of the page. For example, the inline css removal filter has this:
The 'Inline CSS' filter is low to moderate risk. It should be safe for most pages, but it could potentially break scripts that walk the DOM looking for and examining <link> or <style> tags.
I agree with this comment. Interestingly they're trying to implement it on Go Daddys systems for 8.5 million customers. This suggests they must be fairly confident that the optimisations are safe for the vast majority of sites.
I wonder which filters Go Daddy will enable and how many problems it will cause.
I would use this to quickly test any possible enhancements could be done to site in order to improve performance, but later - turn it off and implement everything in code.
I love the idea of this, but these days I always have something else sitting in front of apache (usually nginx), it seems like this is where i'd want a module like this to be running.
If apache rewrites the html with such things like temporary optimized versions of files, nginx presumably won't know anything about serving them, so it'll break (date urls being an exception here I guess).
For things like media, I really want to keep apache out of the loop completely.
Doesn't matter. I ditched Apache completely for nginx and didn't look back since then. Every apps get proxied through nginx: PHP scripts run as FastCGI (php-fpm), Rails and Sinatra apps run on Unicorn ...
This made me realize just how strongly Google is tied to the success of 'the internet' vs the traditional desktop. There isn't much in their strategy that doesn't make sense if you stop trying to figure out how it ties into seach/advertising and if you see how it just enhances the internet as a whole.
edit: of course enhancing the internet increases the number and frequency of people interacting with their search, adwords on pages, and feeling comfortable with web apps (helping create lead for Google Apps B2B)
Put nginx in front of apache and allow it to buffer responses. That way apache can move on to rendering the next request while nginix empties the buffer. Each apache process still uses just as much memory, but they can get more work done, because they aren't tying up memory while they push the buffered response out.
Most of these are micro optimizations that matter most on a larger site. Most large site do not use Apache for static content. I agree, nginx would be a better first choice for a module.
One thing that may not be obvious about minimization is that it does not yield much size reduction when coupled with gzip. You may see 30% decrease in size with minimization on the plain file, but when you gzip both the plain and minimized you may only see a difference for a couple of hundred bytes. If you are worried about speed, you should be using gzip for static content.
I've found using minimization to give up 40% smaller files even after gzip. Even so, combining multiple JS or CSS files into single one and using image sprites will probably be your biggest win.
I've seen similar results. It's nice to see it everything do it on the fly but I'm guessing doing all these optimizations on a large website will take up more processor cycles?
Has anyone found/done any benchmarks showing what performance impact running mod_pagespeed will have on your /server/?
I'm all for optimizing the crap out of page serving, but if this is going to double our Apache load, a) I'd like to know about it ahead of time and b) it might be worth just applying optimizations by hand.
Somewhat ironically, one of the biggest slowdowns on my websites has been using Google Analytics. I only realised this after I switched completely to my own installation of Piwik - give it a try, the load times can be quite surprising.
Nah, and to be fair, this was a while ago - when the async stuff had barely been released in beta. I hope the situation's improved somewhat now because of it :)
As another option - you can cache GA js code locally and combine it with the rest site's js code. That's what Google Analytics module for Drupal is doing. Result - no third-party requests at all.
Google has been accused by free software luminaries that, while it respects the letter of the GPL, it does not respect the spirit of the license, as it does not share its optimized versions of the Linux kernel, Apache server, and many other GPL software. Of course, as it's GPL, not AGPL, they are not legally in the wrong. This nice piece of infrastructure is a step forward, let's hope they release more of their custom infrastructure.
For those worried that it might break something on their site, a word of advice. You shouldn't expect anything to "just work," and should, like any technology that you make use of, evaluate and test it out to see if it's right for you.
There's no details on it, but I wonder if GoDaddy has some plan to provide a way to turn specific things off. If not, this sounds like it could be a disaster.
All great ideas. I'm in a bit of a knowledge-base limbo where I spend just enough time setting up my server so that it survives a load test. I use nginx as my daily driver; I think I'll try to level up some admin skill and try to apply some of these principles to my setup. Who knows, maybe I'll do a write up.
Firefox has a more powerful plugin system than Chrome, and I would bet that most web developers have Firefox installed, even if only for testing and for Firebug.
http://code.google.com/speed/page-speed/docs/filters.html
It will automatically strip inline css and js out of a html page and then create links to an external version. It will automatically set very long cache times. It minifies css and javascript on the fly, strips whitespace and comments from the html.
Then for images, it automatically rescales them, strips out meta data and recompresses. It even converts img tags to use data: uris when it's safe and efficient to do so.
I love it.