[HN Gopher] HTML-only conditional lazy loading (via preload and ...
___________________________________________________________________
HTML-only conditional lazy loading (via preload and media)
Author : netol
Score : 84 points
Date : 2026-01-11 11:24 UTC (11 hours ago)
(HTM) web link (orga.cat)
(TXT) w3m dump (orga.cat)
| DamonHD wrote:
| Nice pure-declarative responsive tweak!
| simonw wrote:
| > The accepted practice is to not add lazy-loading to images
| above the fold, especially the LCP image.
|
| I didn't know that. Apparently (at least according to Claude) you
| shouldn't use loading="lazy" on images that you expect to always
| display because doing so causes them to not be loaded until the
| browser has determined they are definitely in the viewport, which
| is a minor performance regression.
|
| LCP = Largest Contentful Paint, the Core Web Vitals metric for
| when the largest visual element finishes rendering. That's
| usually the largest above-the-fold image.
| alexandermorgan wrote:
| Yes but the post is explicitly about images that are initially
| loaded only on certain devices/screen sizes, hence the need for
| conditional application of lazy loading.
| alwillis wrote:
| Attempting to lazy load an LCP could delay the loading the
| image as much as 15% [1].
|
| _Lazy-loading is an effective technique we can use to delay
| non-critical resources at the beginning of the page load.
| However, a considerable problem occurs when we apply this
| technique to an LCP image. Lazy-loading prevents the browser
| from loading the image immediately because it takes time for it
| to realize that the image is in the viewport and needs to be
| loaded. According to some lab tests, this could cause a 15%
| regression in LCP performance. This might sound obvious for
| someone working on web performance, but the fact that nearly
| one in five web pages are doing it is a sign that it's not very
| well understood by most other web developers._
|
| [1]: https://calendar.perfplanet.com/2022/lazy-loading-lcp-
| images...
| bmacho wrote:
| > Not documented anywhere (but seems to work fine in major
| browsers)
|
| Which part of it is not documented? Putting device width
| dependent preloading in HTTP header? MDN says that the HTTP link
| header works the same way as the link element, and also that the
| link element a has media attribute :
| https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
| netol wrote:
| I could not find this hack documented or discussed anywhere,
| that's what I meant.
| eyelidlessness wrote:
| It's not a hack, but you may find more documentation for the
| equivalent preload values expressed as a <link> tag. There is
| (near) parity between that and the HTTP Link header. The
| values used in the article should work in HTML as well.
| alwillis wrote:
| > It's not a hack
|
| Yeah, this isn't a hack; this is what media queries were
| made for.
|
| Now, this is a hack!
|
| You had to do this to make :hover work correctly for IE6--
| IE8 [1]: body { behavior:
| url("csshover3.htc"); }
|
| [1]: https://pawelgrzybek.com/internet-explorer-just-hit-
| the-end-...
| lightningspirit wrote:
| I like this solution, it looks very simple and should've been
| consider as part of best practices if it works technically.
| However, I also think that this whole trade off is broken from
| the beginning, it should be part of browser's set of rules to
| either decide or not it should render the image or not by
| default, and the decision of eagerly load an image should just an
| hint given by the developer as a scape hatch. The current
| approach forces the decision to be forcefully deferred to the
| application which needs to guess what's the best approach for the
| current set of devices in the market which also adds a constant
| maintenance burden.
| DamonHD wrote:
| Browsers already have an early scanner to look ahead for things
| that it may need to load soon, such as images, and piles of
| heuristics. Those heuristics are hard in part because many HTML
| authors don't bother marking up their image dimensions. The
| lazy attribute helps avoid loading images that the author can
| be fairly sure will not be in the initial viewport, so is an
| optimisation hint to override some of those heuristics. So it
| saves some bandwidth and helps ensure that things above the
| fold are not fighting things below in the initial viewport
| construction. So we're about two levels of optimisation in
| here, but browsers do a reasonable job when fed good img tags
| anyway.
| onionisafruit wrote:
| Is it the "min-width=1024px" in the link that causes it to not
| load on smaller devices?
| netol wrote:
| To not preload, yes
| masklinn wrote:
| Yes, it's a media query (https://developer.mozilla.org/en-
| US/docs/Glossary/Media_quer...) on the <link>. Only if the
| media query passes will the link "activate".
| xnx wrote:
| Not a fan of lazy loading. My time is more valuable than
| bandwidth.
| abejfehr wrote:
| Isn't that why you should like it then? It saves your time
| because you'd get the page earlier
| tempaccsoz5 wrote:
| I guess it depends highly on what you value. I dislike site
| that eagerly load all their images below the fold, since on my
| mobile phone I have a metered data plan. Unlimited data is
| still uncommon or very expensive in many countries. For example
| I pay $13/mo for 650Mb of data, which is one of the best value
| plans (under $40/mo) from any provider.
| miyuru wrote:
| I dont think this works.
|
| I just tested on Chrome Android via remote inspect using
| developer tools. It loaded the image even when the image was
| below the fold.
| nchmy wrote:
| likewise - it always loads the image up front.
___________________________________________________________________
(page generated 2026-01-11 23:01 UTC)