5 ms·
The article's discussion of AMP's limitations regarding images is somewhat inaccurate. Firstly, the claim that images must be supplied with a known height and
by wanda 11y ago
The article's discussion of AMP's limitations regarding images is somewhat inaccurate.
Firstly, the claim that images must be supplied with a known height and width is wrong. All you need to provide to AMP is the aspect ratio of the image.
You can give the width as "16" and the height as "9" and AMP will calculate exactly what size to display the image. It would use any exact measurements provided only to determine the aspect ratio. That's why this layout can be called 'responsive' at all.
Example:
<amp-img width="4"
height="3"
layout="responsive"
src="/assets/images/your_picture.jpg">
</amp-img>
will validate and the image will be rendered at the largest size possible in 4:3 aspect ratio, relative to its flow context/container.
In action:
https://wnda.github.io/amphtml-examples/layout/#development=1 https://wnda.github.io/amphtml-examples/layout/#development=...
https://wnda.github.io/amphtml-examples/basic-page/#development=1 https://wnda.github.io/amphtml-examples/basic-page/#developm...
---------------
Secondly, if you won't even know the aspect ratio of your images with any certainty, AMP doesn't give a damn about exact dimensions for background-images.
Proof:
http://wnda.github.io/amphtml-examples/experiments/background-image/#development=1 http://wnda.github.io/amphtml-examples/experiments/backgroun...
With background-size: cover, background-images are actually extremely effective for responsive web design as long as you're not supplying massive images.
You might think it's a problem because the background-images will not be lazyloaded , but technically they sort of will be, because AMP intercepts everything in your page and serves it via HTTP/2 from its CDN. You just can't link the lazyload up with JavaScript callback.
What you can do is estimate the time it will take to download the image and configure a CSS animation to fire after a certain amount of time using the animation-delay CSS property.
Just an idea.
- nailer 11y agoHow does `amp-img` work when viewing the page in a regular, non Google web browser?
- quarterto 11y agoThe custom elements are handled by the AMP runtime: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-components.md https://github.com/ampproject/amphtml/blob/master/spec/amp-h...
- nailer 11y agoAnswering own question: AMP runtime is a JS library.
- pmlnr 11y agoTherefore and AMP page is a mess with NoScript.
- gregable 11y agoPotentially. However, <noscript> tags can be used to deal with some of this. Most web pages probably won't do this though.
- wanda 11y agoAMP is not supposed to necessarily replace existing pages, but can rather be created by publishers as lightweight/performant alternatives for mobile visitors arriving via Google Search. Hence why you can declare <link rel="amphtml" href="/yourampversionofpage" /> in the normal page. Those with JavaScript switched off probably won't be suggested the AMP pages in Google Mobile SERP. So you could serve the JS-optional pages to all clients, progressively enhance for JavaScript users and offer AMP pages to mobile JavaScript users.
- tripzilch 11y agohaha :) I didn't even realize :) I've been running NoScript (in addition to my usual bloat-blockers uBlock and Ghostery) the past two weeks, to determine the trade-off between convenience and CPU/responsiveness on my low-end laptop (so far: so good!). The crazy thing is that the demo-page actually loads quicker with NoScript on. Okay, so I didn't see the images (and because the text was Lorem Ipsum, I didn't realize they were missing), I'm on a high-bandwidth connection so unless the images are secretly huge, the images on their own shouldn't be too much of a factor to account for the difference. So in other words, while AMP may be a useful line in the sand for responsive guidelines versus corporate politics / environment / product managers / etc, it's no replacement for just writing lean and efficient code in the first place (if at all possible). edit: turns out the comparison wasn't entirely fair because obviously I didn't have Google's JS code cached. On the second load there's less of a difference.