#3816 - Performance-centric image overhaul
-
By Chris Graham
- Added
- 4 views
| Identifier | #3816 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Performance-centric image overhaul |
| Status | Completed |
| Tags |
Type: Performance (custom) |
| Handling member | Chris Graham |
| Addon | core |
| Description | We can do responsive images simply using something like width: 100% in CSS or width="100%" in HTML.
This makes things mobile-friendly, but it makes things less-friendly performance-wise as it requires a page reflow once the image metadata (width and height specifically) loads. Ideally we would be able to set intrinsic width/height in the HTML, or the aspect ratio, but there's no standard yet. There's another concern about image lazy-loading. People currently do this kind of thing with JS hacks, although there's a web standard coming. The web standard is a simple binary flag, but I think a precedence setting would be better. We can resolve both the above performance areas together with a JavaScript solution. We provide the <img> with a src="data: ..." holding image that has a width/height the same as the source image. We provide HTML width="100%". This should allow the browser to paint correctly without any future reflow. We then also supply a data-src attribute which our JavaScript handles, for the real image to then be loaded on top. And finally there'd be a precedence value that defines how soon the browser should load the image relative to others. To make things easy in templating, we'd handle it via a new Tempcode symbol, {$IMG_RESPONSIVE,url[,precedence][,further-HTML-properties]}. It'd automatically construct the HTML needed, as described above. From a Comcode point of view, an img/media/attachment would be able to have the following sizing methodologies configured: 1) Intrinsic size (the HTML width/height properties are set using the existing {$IMG_WIDTH} and {$IMG_HEIGHT} symbols) 2) Specific size (the HTML width/height properties are set simply) 3) Responsive (100%) - uses the {$IMG_RESPONSIVE} Tempcode symbol defined above And there would also be a lazy-loading precedence value too. We should also extend img/media/attachment to support srcset. |
| Steps to reproduce | |
| Additional information | Consider doing the same with a {$VIDEO_RESPONSIVE} symbol.
For core design images, like a logo header, we would not want to have JS processing them as we want them to come before JS is loaded and parsed. This scenario is best handled by embedding the image inside the CSS (which we can already do using the {$IMG_INLINE} symbol), which should also avoid the need for a re-paint. |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
So the "data:" stuff no longer applies, it will be automatic.
Essentially we are talking about:
- Lazy loading of images
- Not having CSS repaints happen when a responsive image finally loads
- srcset support for content authoring
- More precise control of image sizing
I'm nuking most of it on the basic of:
- Overcomplexity
- The web standards folks have got ahead of this issue
Lazy loading is now possible with loading="lazy" on the image tag. Very simple. I think we can reasonably assume any Comcode/attachment image in Composr should be lazy loaded, because that kind of image lines up almost perfectly with the kind of thing that should be (i.e. you want content images to be lazy loaded but fundamental design images not to be). We don't need to make it configurable because the user can always customise their own HTML.
*I have just added this.*
I think a precedence system for lazy loading is overkill, the browser can be trusted to do this (besides, it is parallelising requests).
CSS repaints was already fixed by browsers allowing CSS to tentatively assume the HTML-supplied width/height attributes in the HTML are correct hints to an images aspect ratio. A reasonable assumption that at worst creates a repaint (which would need to happen anyway) if the assumption proves wrong.
srcset is obviated by people using SVG images. v11 is going in very heavy with SVG. For the small and very thin remaining case of people wanting hi-dpi support for raster images shown for content, they can hand edit their HTML.
Making image sizing more precise is not really needed at the Comcode layer. At the CSS layer we now don't allow any images to overflow via our default CSS rules. Intrinsic size is the default. Specific size is possible by specifying width/height. Responsive is the default *FOR OVERFLOW*. I think that covers the vast majority of use cases without adding extra complexity.