4 ms·
No, it's not only about size and js restrictions. Here is a summary of the strategies employed (edited from [0]). - Execute all AMP JavaScript asynchronously
by berns 8y ago
No, it's not only about size and js restrictions. Here is a summary of the strategies employed (edited from [0]).
- Execute all AMP JavaScript asynchronously
- Size all resources statically
- AMP uncouples document layout from resource layout. Only one HTTP request is needed to layout the entire doc.
- All CSS must be inline and size-bound
- Minimize style recalculations
- Only run GPU-accelerated animations
- Prioritize resource loading
- The new preconnect API is used heavily
- When AMP documents get prerendered for instant loading, only resources above the fold are actually downloaded. Resources that might use a lot of CPU (like third-party iframes) do not get downloaded.
[0]: https://www.ampproject.org/learn/about-how/ https://www.ampproject.org/learn/about-how/
- Vinnl 8y agoOP's point was that those are all techniques that you don't need AMP to implement. So their question is: if those are the reason for you to use AMP, why use AMP and not just implement them directly?
- berns 8y agoWhy not use AMP? If you don't use the special caches, it's just another library.
- technion 8y agoI really question this "inline all CSS". Consider: - 1K of HTML with 40K of CSS in a file with a long term cache. Clicking a different page on the site downloads another 1K of HTML. - A 41K file with everything inlined. Clicking a link downloads another 41K.
- megaremote 8y agoOk, but that does not sound like a real world example.
- technion 8y agoWhy not? The Medium link we're all looking at right now has a 43KB CSS stylesheet. It's sent with browser headers giving it a long cache. In the AMP world, this whole stylesheet would end up inlined, and you would download it again the next time someone posted a Medium link on HN.
- minitech 8y agoThe recommendations are to inline the important (render-blocking) CSS, so at most only the part of the CSS that applies to the 1K of HTML should be inlined.
- technion 8y agoThe recommendation you describe is a violation of the AMP standard, which strictly disallows this for performance reasons.
- minitech 8y agoSorry, I was commenting generally. Don’t know about AMP. How does that make sense, though? What performance reasons could there possibly be for inlining CSS that doesn’t apply to any element in a page?
- technion 8y agoLikewise, I'm sorry, I didn't mean "you have to inline CSS that doesn't apply". However, if you have non-render blocking CSS, or CSS that's used for below the fold or generally lower down the page content, "only render critical CSS inline" is usually coupled with "and then have the rest of your CSS in an external stylesheet". Which you are not allowed to do. Accordingly, it's ALL inline, all the time.
- londons_explore 8y agoWhen surver push of resources gets better supported by browsers, I bet AMP will be updated to change this restriction.
- ohBlahDeeBlah 8y agoYou're long-term cache is a fantasy. I use incognito/private browsing mode everywhere I go, and dump my browser state nearly every 5 minutes, by exiting the process at the OS level, to trash cookies and history. The cache rarely survives more than three clicks deep, and often only on trusted properties like Wikipedia, at that. So, maybe that would chop 124K down to 44K, saving 80K total, which is still reasonable, in aggregate across millions of users and billions of hits, but this degree of pessimism isn't the peak of avoidant behavior. Even if it's the minimum return, it needs to be accounted for as a potential norm.