Have had jobs where random marketing colleagues email the developers along the lines of "Why do we only score 7/10 in this test, 45.5% in this test, and 2 critical issues were found in this test?"
Don't get me wrong, they are useful, but people act the same way they would if their virus scanner found their computer was completely comprised. Unless the tools have a major tangible impact in something that affects the business, ie. SEO, I tend to ignore them unless they are a simple fix.
[0] https://developers.google.com/speed/pagespeed/service
[1] https://developers.google.com/speed/pagespeed/insights/
[2] https://code.google.com/p/page-speed/
[3] http://techcrunch.com/2015/05/06/google-shuts-down-pagespeed...
This is a nice tool to give you suggestions about things you might want to change but it's hard to use it as a predictor of page quality.
https://developers.google.com/speed/pagespeed/insights/?url=...
Anyway, the PSI 'score' is only a rough guide to help point you to problems. It can be kind of useful, in that if you get something like 97-100 then you can be pretty sure it's a very fast page... but it's also probably a page that doesn't do much beyond displaying something. With a more serious web app that does more interesting things, the score becomes a less useful indicator – it's often possible to make code changes that improve perceived performance but actually reduce the PSI score.
For example, it's impossible for PSI to really know if inlining a script is going to generally improve or worsen performance, because it doesn't know your site's usage patterns, or which parts of your UI need to render first for a user to feel that the your UI 'is fast', whatever that means. UI performance is a subtler art than, say, algorithmic performance, and much less quantifiable. That's why many people prefer webpagetest.org, which comes with much smarter tools to record and analyse how the page loads, so you can actually improve UI performance.
https://developers.google.com/speed/pagespeed/insights/?url=...
[1] https://developers.google.com/speed/pagespeed/insights/
[2] https://developers.google.com/speed/pagespeed/insights/?url=...
Here's an email I ended up sending yesterday in reply to a Google Page Speed Test report:
> We can address most of these issues with some further optimizations.
> One thing that will always appear in the Google Page Speed Test reports is the "Should Fix" issue with "Eliminate render-blocking JavaScript and CSS in above-the-fold content". This is a much discussed flag that Google returns that would really only work with non-modern websites, and a test that Google itself can't pass: https://developers.google.com/speed/pagespeed/insights/?url=....
If Google make a developer oriented tool then it is no surprise that it works brilliantly on the desktop and slightly sub-optimally on the mobile phone. I am quite useless at web design yet I can game Pagespeed to get 95% or higher in the score. Of course the javascript will be mashed into some black hole that can't be un-minified and the way things load will not be well suited for the visitor seeing more than one page (using cached things). I can't believe someone at Google could not have done what I do to 'game' Pagespeed. The fact that they haven't is good, you should never let scores from things like Pagespeed or YSlow determine how a web page is delivered, it is like using a 'defeat device'.
I do wish they would do something to Pagespeed as they have changed what it does over the years and the latest iteration didn't excite me, I preferred the previous one, in part because you could run it against 'localhost'.
I built an Android app for it as sort of a proof-of-concept back when Holo was a thing, and it was very straight forward. I'm actually kind of surprised that Google didn't build one themselves.