Images without dimensions (CLS risk)
image_no_dimensionsShort answer
Some <img> elements have no width/height attributes (and no CSS aspect-ratio), so the browser cannot reserve space before the image loads and the content shifts when it arrives. That shift is Cumulative Layout Shift, one of the Core Web Vitals. Add the intrinsic width and height to every image; CSS can still scale it responsively.
Why it matters
CLS is measured from real users and is part of Google's page-experience signal; images without reserved space are its most common cause. Modern browsers compute the aspect ratio from the width and height attributes even when CSS sets width: 100%; height: auto, so there is no layout cost to adding them.
How Glimana detects it
The rule fires when a page has at least one image with neither width+height attributes nor an inline aspect-ratio; the evidence shows the count. The Speed page shows whether CLS is actually poor in the field.
How to fix it
- Find the affected pages in Glimana. Open Issues › Images without dimensions (CLS risk). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
WordPress adds width and height to images inserted through the editor. Missing dimensions come from theme images, page builders with lazy-load options, or images inserted as raw HTML; enable "Add missing image dimensions" in your performance plugin (WP Rocket, Perfmatters) or add them in the template.
Use the
image_tagfilter withwidthandheight, or{{ image | image_url: width: 800 | image_tag: widths: '400, 800, 1200' }}which outputs dimensions; older themes withimg_urlneed the attributes added by hand.Store intrinsic dimensions with each image and output them; for responsive images use
aspect-ratioin CSS. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when images on the affected pages have dimensions. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when images on the affected pages have dimensions.