> Page Speed Service fetches content from your servers, rewrites your pages by applying web performance best practices, and serves them to end users via Google's servers across the globe
I don't get it. Given that most websites have some dynamic content, that static assets can be updated, edited or otherwise altered at any time, Google must be fetching content on a request-by-request basis, i/e acting as a proxy. How can this be faster? You've got the existing latency of fetching your content, PLUS the extra latency of Google zipping and concatenating assets and forwarding the result on to the client.
Didn't make sense to me either. Now I realized it optimizes static content: css, javascrips and images on the firs run, then it serves optimized version until you update them. There is some latency to fetching dynamic content and that's the reason optimized sites are slower on this test.
The cache-and-optimize-offline strategy that Google Page Speed is using is fraught with problems for dynamic sites. We tried this at first with some CloudFlare optimizations and it was a disaster. We rewrote the system from scratch to do on-the-fly optimization so it works even with dynamic sites. Here's a blog post about it from some time ago:
I don't get it. Given that most websites have some dynamic content, that static assets can be updated, edited or otherwise altered at any time, Google must be fetching content on a request-by-request basis, i/e acting as a proxy. How can this be faster? You've got the existing latency of fetching your content, PLUS the extra latency of Google zipping and concatenating assets and forwarding the result on to the client.
Doesn't make any sense.