Page Speed often gets confused for a few things. Here's how it really breaks down:
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.
The hard numbers don't tell the whole story, though.
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.
There are a couple of thing missing in your list, and those are quite important:
Number of requests needed to load all your assets, latency and blocking.
Browsers only load limited number of assets in parallel, so if you have a lot they will wait. Latency makes things bad (especially on mobile), but in case you have a lot of assets it makes it even worse. Also, keep in mind, that most often it is the latency that kills the speed of the loading. It does not really matter if it takes 20 or 60ms to download your asset if the latency is 10x that.
Blocking: your #4 is not exactly right, browsers can start rendering the page at once, but if you try to load scripts first they will block rendering. Hence the importance of understanding where to request your css and js and how to load them.
Agreed, my list was more of a general view of the whole process. Asset latency, blocking and requests all fit in Page Rendering in my mind. Actually, DOM processing and Page Rendering are very closely related.
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.
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.