Re:Google AMP – A 70% drop in our conversion rate
by Vinnl on Wednesday August 08, 2018 @05:43PM
(#17719765)
OP'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?
Re:Google AMP – A 70% drop in our conversion rate
by berns on Wednesday August 08, 2018 @06:35PM
(#17720170)
Why not use AMP? If you don't use the special caches, it's just another library.
Re:Google AMP – A 70% drop in our conversion rate
by technion on Wednesday August 08, 2018 @07:09PM
(#17720418)
I 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.
Re:Google AMP – A 70% drop in our conversion rate
by minitech on Wednesday August 08, 2018 @07:46PM
(#17720598)
The 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.
Re:Google AMP – A 70% drop in our conversion rate
by technion on Wednesday August 08, 2018 @08:52PM
(#17720936)
The recommendation you describe is a violation of the AMP standard, which strictly disallows this for performance reasons.
Re:Google AMP – A 70% drop in our conversion rate
by minitech on Wednesday August 08, 2018 @11:56PM
(#17721552)
Sorry, 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?
Re:Google AMP – A 70% drop in our conversion rate
by technion on Thursday August 09, 2018 @05:40AM
(#17722771)
Likewise, 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.
Re:Google AMP – A 70% drop in our conversion rate
by londons_explore on Thursday August 09, 2018 @06:09AM
(#17722911)
When surver push of resources gets better supported by browsers, I bet AMP will be updated to change this restriction.
Re:Google AMP – A 70% drop in our conversion rate
by megaremote on Wednesday August 08, 2018 @07:29PM
(#17720525)
Ok, but that does not sound like a real world example.
Re:Google AMP – A 70% drop in our conversion rate
by technion on Wednesday August 08, 2018 @08:57PM
(#17720955)
Why 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.
- 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/