Google PageSpeed Service Reviewed
x-pose.org
x-pose.org
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/filte...
[2] https://sites.google.com/a/webpagetest.org/docs/using-webpag...
I was going to include Google Analytics site speed data, but it seemed less accurate than NewRelic's Real User Monitoring.
(Disclosure: I used to work for New Relic)
[1] https://developers.google.com/analytics/devguides/collection...
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.)
However it was mostly a terrible read.
I pass at least a few million req/day through their service and only every once in a good while are there hiccups.
* 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.)
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 ;).
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?
The first seems to be that if a page is experiencing slow loading times on the upstream locations (and pretty much everyone using Cloudflare is likely just an 'upstream' entry in nginx), you can trigger the error. If the upstream server returns a 500 error I have seen certain circumstances where that will return a live page error... or, if the web-server on the remote end terminates the connection for whatever reason that will also cause it to happen.
For us the last time we had a problem it turned out to be pretty complicated. There was a bug (which we reported and was fixed in the last release) for the php NewRelic module. Whenever there was what the module considered a 'slow' mysql query, it would cause a segmentation fault. This particular day there was randomly a few 'slow' queries, thus when the segmentation fault occurred the php thread would die killing off the connection and bringing up the 'page is down' error from Cloudflare. That was a pain to diagnose. Strace for the win.
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.
Cache-Control: public, max-age=600
Cloudflare response times to the far left and PageSpeed response times to the far right. I'm not sure what else to say.
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.
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.
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.
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
"To mark a response as 'never expires,' an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
If an agent is precisely following the RFC, anything set to more than 1 year in the future is an invalid date and:
"HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value '0', as in the past (i.e., 'already expired')."
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.
Rant on why averages are bad for looking at performance data: http://highscalability.com/blog/2012/5/23/averages-web-perfo...
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.
"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.