4 ms·

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

by 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.
- jefftk 8y ago
  For the curl testing I did: for prefix in article amp/article; do echo $(for i in {1..9} ; do (time curl -sS https://unlikekinds.com/$prefix/google-amp-page-speed > \ /dev/null) 2>&1 | grep real | awk '{print $2}' done) done Do you see the same results? I shouldn't have focused so much on the difference between the AMP and non-AMP times, though. The main thing I wanted to point out is that if your server is taking almost a second to return html there's a lot you could do to improve pageloads right there.
  - whalabi 8y ago
    I hear ya. It's rails running (with its database) on a single small VPS, so I'm pretty pleased with how it's running, particularly given the load yesterday. And thanks for sort of fact checking, for a second I thought whoa, that could be it, all on the server side. Don't think it is though. I might set up some performance testing on a local copy to check the difference between the two just to be sure (especially because the article ended up getting a lot of attention.) That's some pretty badass shell scripting, I'll give it a try in a bit.
    - jefftk 8y ago
      If you put varnish or something in front of rails to cache your responses you could probably cut 400-600ms off your loading time.

by jefftk 8y ago

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.

jefftk 8y ago
For the curl testing I did: for prefix in article amp/article; do echo $(for i in {1..9} ; do (time curl -sS https://unlikekinds.com/$prefix/google-amp-page-speed > \ /dev/null) 2>&1 | grep real | awk '{print $2}' done) done Do you see the same results? I shouldn't have focused so much on the difference between the AMP and non-AMP times, though. The main thing I wanted to point out is that if your server is taking almost a second to return html there's a lot you could do to improve pageloads right there.
- whalabi 8y ago
  I hear ya. It's rails running (with its database) on a single small VPS, so I'm pretty pleased with how it's running, particularly given the load yesterday. And thanks for sort of fact checking, for a second I thought whoa, that could be it, all on the server side. Don't think it is though. I might set up some performance testing on a local copy to check the difference between the two just to be sure (especially because the article ended up getting a lot of attention.) That's some pretty badass shell scripting, I'll give it a try in a bit.
  - jefftk 8y ago
    If you put varnish or something in front of rails to cache your responses you could probably cut 400-600ms off your loading time.