5 ms·

> which has a JS runtime taking several minutes to load on 2G source? the entire goal of AMP is to load pages quickly

deleted 10y ago
[deleted]
SquareWheel 10y ago
Well, it would have to be downloaded once. It'd stay cached after that though so it's not really a concern. They use version numbers for cache busting.
- flukus 10y ago
  On mobile cache sizes are very limited, and with the size of modern web pages it has to get reclaimed regularly. You can't rely on caching to solve poor performance.
acdha 10y ago
Minutes might be slightly overselling it but AMP has a bit over 100KB of render-blocking JavaScript alone before you get the actual content. Here's the current top story when I hit news.google.com in a mobile browser: https://news.google.com/news/amp?caurl=https%3A%2F%2Fwww.washingtonpost.com%2Famphtml%2Fnews%2Fbusiness%2Fwp%2F2017%2F02%2F08%2Ftrump-lashes-out-at-nordstrom-in-a-tweet-for-dropping-his-daughters-apparel-line%2F https://news.google.com/news/amp?caurl=https%3A%2F%2Fwww.was... Loading that in a simulated 2G connection takes about 80 seconds and at least 30 seconds of that is waiting to display anything you care about. Looking at the content breakdown shows why: ~200KB of webfonts, 1.2MB of JavaScript, 275KB of HTML, etc. https://www.webpagetest.org/result/170208_DV_R2R1/2/details/#waterfall_view_step1 https://www.webpagetest.org/result/170208_DV_R2R1/2/details/... https://www.webpagetest.org/result/170208_5Y_R404/1/details https://www.webpagetest.org/result/170208_5Y_R404/1/details Loading the same page without JavaScript pulls the content render time down into a couple seconds, still over 2G: https://www.webpagetest.org/result/170208_5Y_R404/1/details/#waterfall_view_step1 https://www.webpagetest.org/result/170208_5Y_R404/1/details/...
- kuschku 10y ago
  On my throttled 2G connection, it’s ~2½ minutes, and because I rarely visit pages with AMP, it’s never cached.
  - acdha 10y ago
    I live in a major city, have an iPhone 6S with good LTE coverage according to benchmarks, etc. and still routinely have AMP take 15+ seconds to render after the HTML has been received. I don't know if that's Mobile Safari applying strict cache limits or an issue in Google's side but the sales pitch isn't delivering.
    - Bahamut 10y ago
      I have all of those as well, and AMP takes < 1s for me to load pages. Sounds like either a configuration issue on your end or maybe your wireless carrier.
      - acdha 10y ago
        Note that I did not say it always happens — when everything is cached, it performs as well as any other mobile-optimized site — or that it's specific to my device/carrier – it also happens on WiFi, Android, etc. The problem is simply a brittle design which depends on a ton of render-blocking resources. The assumption is that those will be cached but my experience is simply that fairly regularly I'll click on a link, see the page title load (indicating the HTML response has started), and then have to wait a long time for the content to display. Many news sites also load a ton of stuff but since fewer of them block content display waiting for JavaScript, the experience under real-world wireless conditions is better in the worst case and no worse in average conditions.

deleted 10y ago

[deleted]

Well, it would have to be downloaded once. It'd stay cached after that though so it's not really a concern. They use version numbers for cache busting.

flukus 10y ago
On mobile cache sizes are very limited, and with the size of modern web pages it has to get reclaimed regularly. You can't rely on caching to solve poor performance.

acdha 10y ago

Minutes might be slightly overselling it but AMP has a bit over 100KB of render-blocking JavaScript alone before you get the actual content. Here's the current top story when I hit news.google.com in a mobile browser: https://news.google.com/news/amp?caurl=https%3A%2F%2Fwww.washingtonpost.com%2Famphtml%2Fnews%2Fbusiness%2Fwp%2F2017%2F02%2F08%2Ftrump-lashes-out-at-nordstrom-in-a-tweet-for-dropping-his-daughters-apparel-line%2F https://news.google.com/news/amp?caurl=https%3A%2F%2Fwww.was... Loading that in a simulated 2G connection takes about 80 seconds and at least 30 seconds of that is waiting to display anything you care about. Looking at the content breakdown shows why: ~200KB of webfonts, 1.2MB of JavaScript, 275KB of HTML, etc. https://www.webpagetest.org/result/170208_DV_R2R1/2/details/#waterfall_view_step1 https://www.webpagetest.org/result/170208_DV_R2R1/2/details/... https://www.webpagetest.org/result/170208_5Y_R404/1/details https://www.webpagetest.org/result/170208_5Y_R404/1/details Loading the same page without JavaScript pulls the content render time down into a couple seconds, still over 2G: https://www.webpagetest.org/result/170208_5Y_R404/1/details/#waterfall_view_step1 https://www.webpagetest.org/result/170208_5Y_R404/1/details/...

kuschku 10y ago
On my throttled 2G connection, it’s ~2½ minutes, and because I rarely visit pages with AMP, it’s never cached.
- acdha 10y ago
  I live in a major city, have an iPhone 6S with good LTE coverage according to benchmarks, etc. and still routinely have AMP take 15+ seconds to render after the HTML has been received. I don't know if that's Mobile Safari applying strict cache limits or an issue in Google's side but the sales pitch isn't delivering.
  - Bahamut 10y ago
    I have all of those as well, and AMP takes < 1s for me to load pages. Sounds like either a configuration issue on your end or maybe your wireless carrier.
    - acdha 10y ago
      Note that I did not say it always happens — when everything is cached, it performs as well as any other mobile-optimized site — or that it's specific to my device/carrier – it also happens on WiFi, Android, etc. The problem is simply a brittle design which depends on a ton of render-blocking resources. The assumption is that those will be cached but my experience is simply that fairly regularly I'll click on a link, see the page title load (indicating the HTML response has started), and then have to wait a long time for the content to display. Many news sites also load a ton of stuff but since fewer of them block content display waiting for JavaScript, the experience under real-world wireless conditions is better in the worst case and no worse in average conditions.