1) App Server Response. How long it takes your application to issue a successful response?
2) Network Speed. A server response for a 500MB file is fast, but downloading it isn't
3) DOM Processing. Great, you've reached the user's browser, now how long does it take the page to load into the DOM
4) Page Rendering. Only done after all the "assets" are downloaded. This is usually the final state of the page.
Yes, if your Google Page Speed number is super high, you've got a problem. But it helps to be able to break down each step of that number, to identify where the bottleneck is.
Also, as the author mentioned, be aware that every computer is different. One really slow internet connection will drastically affect your page speed averages.
A small benchmark for you, one of my applications has an average app server response time of about 350ms. But, one page has an average Page Speed of 5 seconds. I'm diagnosing why that page is so slow, it looks like a few external assets are causing the slowdown.
For example, something like Kayak.com takes a very long time (~10-15 seconds) to load a results list. However, the whole experience feels very fast because the data layer is separated from the presentation layer, and the presentation layer comes up very quickly, with data allowed to load incrementally "below the fold".
Put another way, part of "page speed" is also how fast the user can start interacting with any of it, even if it's just to start looking at the initial search results.
Actually, using your logic, #4 is right. I worded it wrong, "Only done after all the "assets" are downloaded" should be "Only completed after all the "assets" are downloaded". More often that not, you'll see high (6 seconds+) Page Speed scores because Page Rendering isn't completed due to missing or slow assets.
You are right. This is precisely the reason why we are looking at CDNing. Our server response time is under 300 ms and our page speed score is 96/100