5 ms·

(Author here) You can run the test yourself on the AMP and non-AMP versions of an identical article to see yourself. (Note: sometimes the numbers are off the

(Author here) You can run the test yourself on the AMP and non-AMP versions of an identical article to see yourself. (Note: sometimes the numbers are off the first couple of times you run tests. If you run them multiple times, the AMP articles tend to score (sometimes significantly) lower.) Non-AMP: https://unlikekinds.com/article/google-amp-page-speed https://unlikekinds.com/article/google-amp-page-speed (Results: https://imgur.com/OVpdwyh https://imgur.com/OVpdwyh) AMP: https://unlikekinds.com/amp/article/google-amp-page-speed https://unlikekinds.com/amp/article/google-amp-page-speed (Results: https://imgur.com/I3ha7Gi https://imgur.com/I3ha7Gi) Edit: More data here: https://news.ycombinator.com/item?id=19630846 https://news.ycombinator.com/item?id=19630846

taytus 8y ago
The AMP version gives me better results: https://www.dropbox.com/s/g4jchw76sh9x49k/Screenshot%202019-04-10%2021.37.39.png?dl=0 https://www.dropbox.com/s/g4jchw76sh9x49k/Screenshot%202019-... Non AMP version:https://www.dropbox.com/s/lclqqdbdliuofjf/Screenshot%202019-04-10%2021.40.12.png?dl=0 https://www.dropbox.com/s/lclqqdbdliuofjf/Screenshot%202019-... My email is on my profile if you want to talk about this. Maybe we can help. Edit: If you compare against the cached version, the version that your mobile users are going to hit, the results are much much better: https://www.dropbox.com/s/c2y5akqclcim7tm/Screenshot%202019-04-10%2021.44.23.png?dl=0 https://www.dropbox.com/s/c2y5akqclcim7tm/Screenshot%202019-...
- deleted 8y ago
  [deleted]
- whalabi 8y ago
  I had run it a few times before until I felt it wasn't a coincidence But just now I ran it until I got bored of running it, alternating between amp/non-amp, chrome on Windows 10 (normally I'm Chromium on Fedora, but let's try mainstream) AMP: 75 90 91 91 91 89 80 91 (avg 87.25) Non-AMP: 95 95 96 96 95 94 96 (avg 95.29) So I feel pretty confident about that. Also appears more consistent (and apparently faster than the amp cached one somehow - probably because it wasn't prefetched by Google)
- DCoder 8y ago
  > My email is on my profile The 'Email' field in the profile is not visible to other users. You should add it to the 'About' field.
  - taytus 8y ago
    Updated. Thank you.
ehsankia 8y ago
I got the same score on both. And yes, I agree that if you hand optimize your site, you can achieve speeds as good as AMP, but the point of AMP is to standardize it and force bloat off of these pages.
- whalabi 8y ago
  See here for more data: https://news.ycombinator.com/item?id=19630846 https://news.ycombinator.com/item?id=19630846 I realise it isn't scientific but I think it's pretty clear
- dmitriid 8y ago
  AMP pages are bloated. You don’t see that because most of the JS and some data is preloaded while you search. It’s trivial to make a site that’s more performant than AMP. But then Google gives exclusive preference to AMP by hosting it in its cache, preliading assets etc. And by penalizing your website.
RhodesianHunter 8y ago
The numbers are always going to be different for different people based on your geographic location and provider, and whether amp or your CDN has closer servers.
jefftk 8y ago
PageSpeed and Lighthouse measure the site load mark you down for things it thinks you could fix. For a head to head comparison like this WebPageTest is often a better tool: non-amp: https://www.webpagetest.org/result/190411_1B_7c5b8e0d2f067add83e1c67a07148b6f/ https://www.webpagetest.org/result/190411_1B_7c5b8e0d2f067ad... amp: https://www.webpagetest.org/result/190411_RF_776066ee3b0226f31ece13591401b5f9/ https://www.webpagetest.org/result/190411_RF_776066ee3b0226f... Your site does pretty similarly with non-AMP and AMP. On the median of 9 runs PLT and fully loaded time are better on AMP, but speed index and time to interactive are better on non-AMP. Digging into it more, the time difference is completely due to how long it takes your site to serve HTML, and the biggest thing you could do to speed your site up would be making the server return the HTML sooner, perhaps by adding a cache. Testing with curl, your site takes 880ms on average to serve non-AMP, but 1120ms to serve non-AMP. Graph: https://i.imgur.com/BlWqSoo.png https://i.imgur.com/BlWqSoo.png That's not an AMP thing, that's a your-serving-stack thing. (Disclosure: I work at Google, and used to work on mod_pagespeed)
- whalabi 8y ago
  (Edit: another thought, maybe your curl testing took longer with all the extra CSS in the download and writing to disk if that's what you did - an AMP requirement. But did your curling pull down the external CSS/JS for non-AMP?) According to the webpagetest.org results you linked, which ran the test 9 times on each page, the mean time to first byte for the AMP page is 1005, and for non-AMP it's 989. Which is just 16 ms. But the time to visually complete for example on non-AMP is 1955, and on AMP it's 2166. Which is a difference of 211 ms (which percentage wise is almost 10x bigger (I think, I'm not super mathy) This implies to me that the problem is AMP not the server. But if your data is correct then perhaps something is up. The thing is, I know how the site is coded. The AMP version just excludes things almost exclusively. Although it does have to render the CSS in place (the fragment is cached) rather than just link to a stylesheet. But here's the thing, even if that is the problem, the only reason it's like that is because that's what AMP requires. Maybe there's changes we could make on the server, but according to this webpagetest site, the problem doesn't appear to be the server nearly as much as the rest of the render process.
  - 8y ago

taytus 8y ago

The AMP version gives me better results: https://www.dropbox.com/s/g4jchw76sh9x49k/Screenshot%202019-04-10%2021.37.39.png?dl=0 https://www.dropbox.com/s/g4jchw76sh9x49k/Screenshot%202019-... Non AMP version:https://www.dropbox.com/s/lclqqdbdliuofjf/Screenshot%202019-04-10%2021.40.12.png?dl=0 https://www.dropbox.com/s/lclqqdbdliuofjf/Screenshot%202019-... My email is on my profile if you want to talk about this. Maybe we can help. Edit: If you compare against the cached version, the version that your mobile users are going to hit, the results are much much better: https://www.dropbox.com/s/c2y5akqclcim7tm/Screenshot%202019-04-10%2021.44.23.png?dl=0 https://www.dropbox.com/s/c2y5akqclcim7tm/Screenshot%202019-...

deleted 8y ago
[deleted]
whalabi 8y ago
I had run it a few times before until I felt it wasn't a coincidence But just now I ran it until I got bored of running it, alternating between amp/non-amp, chrome on Windows 10 (normally I'm Chromium on Fedora, but let's try mainstream) AMP: 75 90 91 91 91 89 80 91 (avg 87.25) Non-AMP: 95 95 96 96 95 94 96 (avg 95.29) So I feel pretty confident about that. Also appears more consistent (and apparently faster than the amp cached one somehow - probably because it wasn't prefetched by Google)
DCoder 8y ago
> My email is on my profile The 'Email' field in the profile is not visible to other users. You should add it to the 'About' field.
- taytus 8y ago
  Updated. Thank you.

ehsankia 8y ago

I got the same score on both. And yes, I agree that if you hand optimize your site, you can achieve speeds as good as AMP, but the point of AMP is to standardize it and force bloat off of these pages.

whalabi 8y ago
See here for more data: https://news.ycombinator.com/item?id=19630846 https://news.ycombinator.com/item?id=19630846 I realise it isn't scientific but I think it's pretty clear
dmitriid 8y ago
AMP pages are bloated. You don’t see that because most of the JS and some data is preloaded while you search. It’s trivial to make a site that’s more performant than AMP. But then Google gives exclusive preference to AMP by hosting it in its cache, preliading assets etc. And by penalizing your website.

RhodesianHunter 8y ago

The numbers are always going to be different for different people based on your geographic location and provider, and whether amp or your CDN has closer servers.

jefftk 8y ago

PageSpeed and Lighthouse measure the site load mark you down for things it thinks you could fix. For a head to head comparison like this WebPageTest is often a better tool: non-amp: https://www.webpagetest.org/result/190411_1B_7c5b8e0d2f067add83e1c67a07148b6f/ https://www.webpagetest.org/result/190411_1B_7c5b8e0d2f067ad... amp: https://www.webpagetest.org/result/190411_RF_776066ee3b0226f31ece13591401b5f9/ https://www.webpagetest.org/result/190411_RF_776066ee3b0226f... Your site does pretty similarly with non-AMP and AMP. On the median of 9 runs PLT and fully loaded time are better on AMP, but speed index and time to interactive are better on non-AMP. Digging into it more, the time difference is completely due to how long it takes your site to serve HTML, and the biggest thing you could do to speed your site up would be making the server return the HTML sooner, perhaps by adding a cache. Testing with curl, your site takes 880ms on average to serve non-AMP, but 1120ms to serve non-AMP. Graph: https://i.imgur.com/BlWqSoo.png https://i.imgur.com/BlWqSoo.png That's not an AMP thing, that's a your-serving-stack thing. (Disclosure: I work at Google, and used to work on mod_pagespeed)

whalabi 8y ago
(Edit: another thought, maybe your curl testing took longer with all the extra CSS in the download and writing to disk if that's what you did - an AMP requirement. But did your curling pull down the external CSS/JS for non-AMP?) According to the webpagetest.org results you linked, which ran the test 9 times on each page, the mean time to first byte for the AMP page is 1005, and for non-AMP it's 989. Which is just 16 ms. But the time to visually complete for example on non-AMP is 1955, and on AMP it's 2166. Which is a difference of 211 ms (which percentage wise is almost 10x bigger (I think, I'm not super mathy) This implies to me that the problem is AMP not the server. But if your data is correct then perhaps something is up. The thing is, I know how the site is coded. The AMP version just excludes things almost exclusively. Although it does have to render the CSS in place (the fragment is cached) rather than just link to a stylesheet. But here's the thing, even if that is the problem, the only reason it's like that is because that's what AMP requires. Maybe there's changes we could make on the server, but according to this webpagetest site, the problem doesn't appear to be the server nearly as much as the rest of the render process.
- 8y ago