10 ms·

Google PageSpeed Service Reviewed

49 points by xpose2000 14y ago

dubcanada 14y ago
I'm not sure the "cloudflare has been getting worse and worse" that links to a single page written by you referencing a single twitter post. Really helps the article any. However it was mostly a terrible read.
- druiid 14y ago
  Yeah, what's with this 'Cloudflare is terrible and will make your pages slower !!11!!' stuff around HN lately? I pass at least a few million req/day through their service and only every once in a good while are there hiccups.
  - xpose2000 14y ago
    I linked to what GoogleBot thinks of Cloudflare. http://x-pose.org/wp-content/uploads/2012/12/topiama-googlebot.png http://x-pose.org/wp-content/uploads/2012/12/topiama-googleb... Cloudflare response times to the far left and PageSpeed response times to the far right. I'm not sure what else to say.
    - druiid 14y ago
      No offense, as I know little about your website, but you're one site out of thousands/tens of thousands on Cloudflare at this point. Your results without substantial research and supporting evidence of this being a trending problem with other sites is not enough to say (per your article) 'As I mentioned earlier, avoid Cloudflare at all costs'. First, have you contacted Cloudflare support regarding your purported page slowdowns? If not, they are actually very good about both fixing things and getting back to you, even on the piss-ant level plans. Second, what optimization features exactly do you have enabled? Do you set proper cache headers? Those are especially important to Cloudflare and without them being properly set (especially on JS and CSS objects) I imagine your page speeds will be pure crap. That isn't to say that Cloudflare is without issue. We've had them, they exist. But if you're going to present an issue and blame it on the service, do your homework first and present full evidence, otherwise don't spread it as it's just an unproven lie.
      - xpose2000 14y ago
        Yes, I have contacted Coudflare about slowdown issues. I tried to use Cloudflare across a few sites with many weeks of testing. I agree that they are extremely helpful and responsive. One specific support ticket was about the time it took for ajax requests to complete. Cloudflare was adding up to one FULL second of latency. I also mentioned response times reported by GoogleBot. They had no real answers. Though they did acknowledge some Ajax slowdown that was supposedly fixed. Some days are better than others, but overall Cloudflare did not speed anything up. Perhaps free users don't get as good of a performance boost? I had similar features enabled with Cloudflare as I do with Google PageSpeed. The sentence right before the one you quoted says: "The response times to the far left are a result of Cloudflare’s Full Caching features with Rocket Loader enabled.". Essentially that graph shows what happens when all of Cloudflare's "CDN + Full Optimizations" features are enabled compared to most of Google's PageSpeed Service. It's the closest comparison that I can make.
        druiid 14y ago
        Hard for me to say what happens for 'free' accounts. We only use pro or higher (A good number higher than pro). I would say not counting the additional performance features you get at the pro level, if they're purposefully slowing things down for free accounts that would be pretty crummy. That still doesn't answer what you're doing with your cache headers. I took a basic look at your fantasysp site and I wonder if there isn't some changes you could make on the cache-control settings. You seem to be setting no-cache quite a bit.
        xpose2000 14y ago
        Caching is specified as: FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4)$" Header set Cache-Control "public" Header set Expires "Thu, 15 Apr 2016 20:00:00 GMT" Header unset Last-Modified FilesMatch "\.(html|htm|xml|txt|xsl)$" Header set Cache-Control "max-age=7200, must-revalidate" FilesMatch "\.(js|css)$" Header set Cache-Control "public" Header set Expires "Thu, 15 Apr 2016 20:00:00 GMT" Header unset Last-Modified
    - druiid 14y ago
      I just realized actually one very likely reason you would see a significant increase like this. I imagine that the GoogleBot and Pagespeed servers are on the same network, or at least regionally close enough to make a big difference. Cloudflare is not going to be on the same network as Google for any of their servers as they host their own gear around the world. If you want to see the real speed decrease from switching it should be a set of tests between Cloudflare and Pagespeed from outside both of their respective networks (and a couple locations if possible). That would give you closer to real numbers... or the google services are on totally different networks and what you saw was real-world, which I couldn't answer.
  - walls 14y ago
    Obviously I have little to no idea how many sites I visit daily are using CloudFlare, however: * Over the last two weeks, the number of CloudFlare 'down' pages I have seen has grown quite rapidly on sites that were never unavailable in the first place. (And, typically, the 'live' link ends up at the correct, working, page) * imgur load time has gotten exponentially worse since the addition of CloudFlare. (Whether or not performance would have degraded the same without it is clearly debatable.)
    - druiid 14y ago
      A couple things here I'd say. The first is that you have to be careful with the 'live' page stuff on Cloudflare and blaming it directly on Cloudflare. I can't know the exact circumstances that lead you to see the error, but in our experience the couple times that we've had a problem with this, it's been an actual issue on our side that wasn't presenting itself at great frequency, but enough to trigger a live-site error once in a while. As for imgur, I'd have to look around their site, but I'd say perhaps they didn't do their homework completely? I mentioned it on a previous post but you have to be extremely careful with setting headers for objects or every request will be proxying for an image from Cloudflare, back to the internet, then to your servers, then back through the internet, through Cloudflare and then finally to the user. Instead, you want to make sure that Cloudflare is caching mostly everything EXCEPT for the page body if at all possible. A developer accidentally turned off proper headers a while back and well, we noticed it in page load speed issues pretty quickly. Edit: Also, you probably want to see if you can cache the page body as well ;).
      - walls 14y ago
        It's good to hear some insight into this, as it's really been grating on me lately, so thanks! I'm somewhat curious about what kind of problem you could have that would allow the 'live' site to work, but break through CloudFlare. That seems entirely counter to the functionality... do you happen to remember or are you able to comment on what was happening?
        druiid 14y ago
  - badgar 14y ago
    1 million req/day is 11 qps; a few million req/day isn't enough to knock over a Pentium III.
    - druiid 14y ago
      Sorry, not about to reveal realistic traffic counts (also this is getting off-topic)... but I will say that we generally push somewhere around 120-160Mbit/s.
      - badgar 14y ago
        It's on-topic because you're presenting yourself as an authority on Cloudflare's reliability then dropping small numbers to back it up. 150 Mbps isn't really interesting as a data point on speed/reliability either. What you've described so far fits in a single rack several times over.
  - Benferhat 14y ago
    It's just the inevitable pushback against the litany of Cloudflare-related posts lately.
zapt02 14y ago
this was a poorly written article. random numbers all over the place, no understanding from author about how the services actually work. awful.
- xpose2000 14y ago
  Sorry if it's a bit scatter-brained and unorganized. I threw it together late last night and am posting to help show others what to expect. "no understanding from author about how the services actually work". I gave my interpretation of the data I was presented with. I am no expert in deferred javascript. If you'd like you can ignore the entire article's text and just look at the pretty graphs.
chris_mahan 14y ago
Getting rid of javascript altogether and sticking with validating html5 worked for me.
cbr 14y ago
> Not to be confused with mod_pagespeed, which is an Apache module PageSpeed Service proxies your site, but aside from that the optimizations it makes are very similar to mod_pagespeed (and ngx_pagespeed). Which makes sense: they're closely related Google projects. (I work on all three, but mostly ngx_pagespeed these days.)
cbr 14y ago
With defer_javascript on, browser-reported page load times tell less of the picture. The problem is that what browsers report back to your analytics service is the amount of time that passes before the onload event while defer_javascript [1] postpones javascript execution until the onload event. This means that with defer_javascript off you were counting javascript execution time but when you turned it on you stopped counting it. We're trying to optimize something like "time until the page is visually complete and usable", and there's not currently a good metric for that. Speed index [2] does visual completeness well, but I don't know of any algorithmic way to measure time-until-usable. (I work on the PageSpeed team at Google, mostly on ngx_pagespeed.) [1] https://developers.google.com/speed/docs/mod_pagespeed/filter-js-defer https://developers.google.com/speed/docs/mod_pagespeed/filte... [2] https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index https://sites.google.com/a/webpagetest.org/docs/using-webpag...
- cbr 14y ago
  Checking with some people here, it's actually more complicated than this: what I described is true for IE9 and below, but for Firefox, Chrome, and IE10 measured page load time will include execution of these deferred scripts.
  - xpose2000 14y ago
    I appreciate the responses and updated the article with links to your comments. I've been very impressed by what I've seen so far! I was going to include Google Analytics site speed data, but it seemed less accurate than NewRelic's Real User Monitoring.
    - cbr 14y ago
      What seemed less accurate? They should be doing almost exactly the same thing.
      - briandoll 14y ago
        Google Analytics site speed data is only based on 1%[1] of your traffic while New Relic's Real User Monitoring aims to track all of your traffic. I'm sure that can lead to differences in accuracy. (Disclosure: I used to work for New Relic) [1] https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingTiming#sampleRate https://developers.google.com/analytics/devguides/collection...
isalmon 14y ago
It's a great article, thanks a lot for sharing this. The most amazing part of all of it is that Google offers it for free while many other companies charge a lot of money for the same (or even worse) functionality.
- hippich 14y ago
  Cloudflare offers their service for free too and anyone can register there right away without any special invitation.
- detst 14y ago
  PageSpeed Service is currently offered free of charge to a limited set of webmasters during this trial period. Pricing will be competitive and details will be made available later. You can get an idea from what they are charging for PageSpeed on App Engine. It may be competitive but it's not cheap. Perhaps they've learned that price increases aren't taken well and have priced it high with the possibility to reduce it when it's widely available.
joshfraser 14y ago
It would be interesting to know what the before/after load time histograms look like. The averages that New Relic give can hide a lot of the details of what's actually happening. Rant on why averages are bad for looking at performance data: http://highscalability.com/blog/2012/5/23/averages-web-performance-data-and-how-your-analytics-product.html http://highscalability.com/blog/2012/5/23/averages-web-perfo...

49 points by xpose2000 14y ago

I'm not sure the "cloudflare has been getting worse and worse" that links to a single page written by you referencing a single twitter post. Really helps the article any. However it was mostly a terrible read.

druiid 14y ago
Yeah, what's with this 'Cloudflare is terrible and will make your pages slower !!11!!' stuff around HN lately? I pass at least a few million req/day through their service and only every once in a good while are there hiccups.
- xpose2000 14y ago
  I linked to what GoogleBot thinks of Cloudflare. http://x-pose.org/wp-content/uploads/2012/12/topiama-googlebot.png http://x-pose.org/wp-content/uploads/2012/12/topiama-googleb... Cloudflare response times to the far left and PageSpeed response times to the far right. I'm not sure what else to say.
  - druiid 14y ago
    No offense, as I know little about your website, but you're one site out of thousands/tens of thousands on Cloudflare at this point. Your results without substantial research and supporting evidence of this being a trending problem with other sites is not enough to say (per your article) 'As I mentioned earlier, avoid Cloudflare at all costs'. First, have you contacted Cloudflare support regarding your purported page slowdowns? If not, they are actually very good about both fixing things and getting back to you, even on the piss-ant level plans. Second, what optimization features exactly do you have enabled? Do you set proper cache headers? Those are especially important to Cloudflare and without them being properly set (especially on JS and CSS objects) I imagine your page speeds will be pure crap. That isn't to say that Cloudflare is without issue. We've had them, they exist. But if you're going to present an issue and blame it on the service, do your homework first and present full evidence, otherwise don't spread it as it's just an unproven lie.
    - xpose2000 14y ago
      Yes, I have contacted Coudflare about slowdown issues. I tried to use Cloudflare across a few sites with many weeks of testing. I agree that they are extremely helpful and responsive. One specific support ticket was about the time it took for ajax requests to complete. Cloudflare was adding up to one FULL second of latency. I also mentioned response times reported by GoogleBot. They had no real answers. Though they did acknowledge some Ajax slowdown that was supposedly fixed. Some days are better than others, but overall Cloudflare did not speed anything up. Perhaps free users don't get as good of a performance boost? I had similar features enabled with Cloudflare as I do with Google PageSpeed. The sentence right before the one you quoted says: "The response times to the far left are a result of Cloudflare’s Full Caching features with Rocket Loader enabled.". Essentially that graph shows what happens when all of Cloudflare's "CDN + Full Optimizations" features are enabled compared to most of Google's PageSpeed Service. It's the closest comparison that I can make.
      - druiid 14y ago
        Hard for me to say what happens for 'free' accounts. We only use pro or higher (A good number higher than pro). I would say not counting the additional performance features you get at the pro level, if they're purposefully slowing things down for free accounts that would be pretty crummy. That still doesn't answer what you're doing with your cache headers. I took a basic look at your fantasysp site and I wonder if there isn't some changes you could make on the cache-control settings. You seem to be setting no-cache quite a bit.
        xpose2000 14y ago
        Caching is specified as: FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4)$" Header set Cache-Control "public" Header set Expires "Thu, 15 Apr 2016 20:00:00 GMT" Header unset Last-Modified FilesMatch "\.(html|htm|xml|txt|xsl)$" Header set Cache-Control "max-age=7200, must-revalidate" FilesMatch "\.(js|css)$" Header set Cache-Control "public" Header set Expires "Thu, 15 Apr 2016 20:00:00 GMT" Header unset Last-Modified
  - druiid 14y ago
    I just realized actually one very likely reason you would see a significant increase like this. I imagine that the GoogleBot and Pagespeed servers are on the same network, or at least regionally close enough to make a big difference. Cloudflare is not going to be on the same network as Google for any of their servers as they host their own gear around the world. If you want to see the real speed decrease from switching it should be a set of tests between Cloudflare and Pagespeed from outside both of their respective networks (and a couple locations if possible). That would give you closer to real numbers... or the google services are on totally different networks and what you saw was real-world, which I couldn't answer.
- walls 14y ago
  Obviously I have little to no idea how many sites I visit daily are using CloudFlare, however: * Over the last two weeks, the number of CloudFlare 'down' pages I have seen has grown quite rapidly on sites that were never unavailable in the first place. (And, typically, the 'live' link ends up at the correct, working, page) * imgur load time has gotten exponentially worse since the addition of CloudFlare. (Whether or not performance would have degraded the same without it is clearly debatable.)
  - druiid 14y ago
    A couple things here I'd say. The first is that you have to be careful with the 'live' page stuff on Cloudflare and blaming it directly on Cloudflare. I can't know the exact circumstances that lead you to see the error, but in our experience the couple times that we've had a problem with this, it's been an actual issue on our side that wasn't presenting itself at great frequency, but enough to trigger a live-site error once in a while. As for imgur, I'd have to look around their site, but I'd say perhaps they didn't do their homework completely? I mentioned it on a previous post but you have to be extremely careful with setting headers for objects or every request will be proxying for an image from Cloudflare, back to the internet, then to your servers, then back through the internet, through Cloudflare and then finally to the user. Instead, you want to make sure that Cloudflare is caching mostly everything EXCEPT for the page body if at all possible. A developer accidentally turned off proper headers a while back and well, we noticed it in page load speed issues pretty quickly. Edit: Also, you probably want to see if you can cache the page body as well ;).
    - walls 14y ago
      It's good to hear some insight into this, as it's really been grating on me lately, so thanks! I'm somewhat curious about what kind of problem you could have that would allow the 'live' site to work, but break through CloudFlare. That seems entirely counter to the functionality... do you happen to remember or are you able to comment on what was happening?
      - druiid 14y ago
- badgar 14y ago
  1 million req/day is 11 qps; a few million req/day isn't enough to knock over a Pentium III.
  - druiid 14y ago
    Sorry, not about to reveal realistic traffic counts (also this is getting off-topic)... but I will say that we generally push somewhere around 120-160Mbit/s.
    - badgar 14y ago
      It's on-topic because you're presenting yourself as an authority on Cloudflare's reliability then dropping small numbers to back it up. 150 Mbps isn't really interesting as a data point on speed/reliability either. What you've described so far fits in a single rack several times over.
- Benferhat 14y ago
  It's just the inevitable pushback against the litany of Cloudflare-related posts lately.

zapt02 14y ago

this was a poorly written article. random numbers all over the place, no understanding from author about how the services actually work. awful.

xpose2000 14y ago
Sorry if it's a bit scatter-brained and unorganized. I threw it together late last night and am posting to help show others what to expect. "no understanding from author about how the services actually work". I gave my interpretation of the data I was presented with. I am no expert in deferred javascript. If you'd like you can ignore the entire article's text and just look at the pretty graphs.

chris_mahan 14y ago

Getting rid of javascript altogether and sticking with validating html5 worked for me.

cbr 14y ago

> Not to be confused with mod_pagespeed, which is an Apache module PageSpeed Service proxies your site, but aside from that the optimizations it makes are very similar to mod_pagespeed (and ngx_pagespeed). Which makes sense: they're closely related Google projects. (I work on all three, but mostly ngx_pagespeed these days.)

cbr 14y ago

With defer_javascript on, browser-reported page load times tell less of the picture. The problem is that what browsers report back to your analytics service is the amount of time that passes before the onload event while defer_javascript [1] postpones javascript execution until the onload event. This means that with defer_javascript off you were counting javascript execution time but when you turned it on you stopped counting it. We're trying to optimize something like "time until the page is visually complete and usable", and there's not currently a good metric for that. Speed index [2] does visual completeness well, but I don't know of any algorithmic way to measure time-until-usable. (I work on the PageSpeed team at Google, mostly on ngx_pagespeed.) [1] https://developers.google.com/speed/docs/mod_pagespeed/filter-js-defer https://developers.google.com/speed/docs/mod_pagespeed/filte... [2] https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index https://sites.google.com/a/webpagetest.org/docs/using-webpag...

cbr 14y ago
Checking with some people here, it's actually more complicated than this: what I described is true for IE9 and below, but for Firefox, Chrome, and IE10 measured page load time will include execution of these deferred scripts.
- xpose2000 14y ago
  I appreciate the responses and updated the article with links to your comments. I've been very impressed by what I've seen so far! I was going to include Google Analytics site speed data, but it seemed less accurate than NewRelic's Real User Monitoring.
  - cbr 14y ago
    What seemed less accurate? They should be doing almost exactly the same thing.
    - briandoll 14y ago
      Google Analytics site speed data is only based on 1%[1] of your traffic while New Relic's Real User Monitoring aims to track all of your traffic. I'm sure that can lead to differences in accuracy. (Disclosure: I used to work for New Relic) [1] https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingTiming#sampleRate https://developers.google.com/analytics/devguides/collection...

isalmon 14y ago

It's a great article, thanks a lot for sharing this. The most amazing part of all of it is that Google offers it for free while many other companies charge a lot of money for the same (or even worse) functionality.

hippich 14y ago
Cloudflare offers their service for free too and anyone can register there right away without any special invitation.
detst 14y ago
PageSpeed Service is currently offered free of charge to a limited set of webmasters during this trial period. Pricing will be competitive and details will be made available later. You can get an idea from what they are charging for PageSpeed on App Engine. It may be competitive but it's not cheap. Perhaps they've learned that price increases aren't taken well and have priced it high with the possibility to reduce it when it's widely available.

joshfraser 14y ago

It would be interesting to know what the before/after load time histograms look like. The averages that New Relic give can hide a lot of the details of what's actually happening. Rant on why averages are bad for looking at performance data: http://highscalability.com/blog/2012/5/23/averages-web-performance-data-and-how-your-analytics-product.html http://highscalability.com/blog/2012/5/23/averages-web-perfo...