Why CMS cores should ship loading today
Browser-level lazy loading via the standardized loading attribute is no longer a proposal. It is part of the WHATWG HTML Standard and supported across major browsers. But standardization only helps when platforms actually use it. Content management systems power roughly 60% of websites, which makes them the most effective channel for putting the attribute to work at scale. WordPress, Joomla, and TYPO3 have already shipped support; this article lays out what their implementations teach other CMS platform developers.
Moving past the old objections
CMS cores historically resisted bundling non-standard browser features, preferring to leave them to plugins. That caution no longer applies here: with the loading attribute standardized, the main blockers—specification risk and browser coverage—have both cleared.
A separate recurring worry is that lazy loading increases the chance an image is not yet fetched when it enters the viewport. Unlike earlier JavaScript libraries, browsers deliberately use conservative distance-from-viewport thresholds and tune them from real-world usage data. The risk of a visible but unloaded image is minimal, and it is safe for a CMS to enable the attribute by default.
Recommendations for user experience
Require width and height first
Embedded content should always declare width and height so the browser can reserve the correct aspect ratio and avoid layout shifts. That advice predates lazy loading and applies whether or not an element is deferred. With lazy loading in place it matters slightly more. If a CMS cannot guarantee dimensions on every image or iframe, it should skip lazy loading for elements that lack both attributes.
Leave above-the-fold content alone
Adding loading="lazy" to images and iframes that are likely in the initial viewport can delay Largest Contentful Paint (LCP), in some cases significantly. CMSs do not have reliable client-side knowledge of element positions at render time, and viewport sizes vary, but a heuristic that excludes likely hero images is still worth implementing. The recommendation stands: omit lazy loading for content that probably appears above the fold, even if perfect detection is not possible.
Do not pair it with a JavaScript fallback
JavaScript-based fallbacks for older browsers force you to remove the src attribute initially, which delays loading for the browsers that actually support the native attribute. For a large-scale CMS, that also means shipping a frontend script across every page and increasing the potential for breakage. None of the major CMSs took that route before the native attribute existed; they should not bolt one on now.
Implementation guidance for platform developers
Enable by default, but keep scope controlled
The clearest win comes from enabling lazy loading by default, applying loading="lazy" to images and iframes that carry dimension attributes where reasonable. Per-image opt-in never reaches the same network savings. Where possible, the default should also respect the above-the-fold guidance, even if it is only an approximation for hero elements.
Provide an escape hatch per element
Enabling by default does not mean removing control. Individual images may need to load eagerly—for instance, elements that are candidates for LCP. A CMS aimed at technical users can expose a UI toggle on each image or iframe. Beyond that, an API for third-party developers to filter or override the attribute is valuable. WordPress, for example, exposes hooks to disable lazy loading for an entire tag or context, or for a specific element in content.
Retrofit existing content at render time
There are two ways a CMS can add the attribute: persist it when content is edited in the backend, or apply it on the fly when content is rendered in the frontend. The second approach is the one to choose. Adding the attribute during rendering retrofits every piece of existing content, not just pieces that get re-saved, and it makes future adjustments easier as browser-level lazy loading evolves.
When rewriting output, an existing loading attribute on an element must win. That prevents duplicate attributes and leaves room for editor-driven overrides or extensions.
Keep on-the-fly processing fast
Server-side middleware that rewrites markup needs to be efficient. In practice, a single regular expression that collects all img and iframe tags with their attributes and conditionally injects the loading attribute is the performant option compared with DOM traversal. WordPress goes one step further and uses one general regular expression for multiple on-the-fly content operations, of which lazy loading is just one. That consolidation is a secondary argument for putting the feature into the core instead of an extension: shared infrastructure keeps server-side costs low.
What you can do next
Check whether your CMS already has a feature request for browser-level lazy loading; if not, create one. If you are a platform developer, study how WordPress, Joomla, or TYPO3 handled the implementation and use their approaches plus the guidance above as the basis for a patch or pull request. Website builders who do not control the platform can still raise a ticket and point maintainers at implementations already in production.
