On most sites I audit, the first cause of slowness isn't the code. It's an image. A portrait exported as PNG, a screenshot never recompressed, a banner loaded too early or too late. Here are the image settings that really matter, plus an honest note: my own site isn't perfect on this point.
1. Always declare width and height
It's the simplest setting and the one most often forgotten. With width and height on the <img> tag, the browser knows the image's aspect ratio before downloading it. It reserves the space, and the surrounding text doesn't jump when the image arrives.
<img src="/assets/karting.png" alt="Site preview" width="600" height="340">Without these attributes, the page shifts at the moment the image shows up. That's exactly what CLS (Cumulative Layout Shift), one of the Core Web Vitals, measures. CSS can then fit the image to the available width (max-width: 100%; height: auto;) and the ratio is preserved.
On my site, every image has its dimensions declared. That part is done.
2. Lazy-loading, but not everywhere
The loading="lazy" attribute tells the browser to download the image only when it gets close to the screen. It's ideal for everything below the fold: galleries, project screenshots, a portrait at the bottom of the page.
The classic mistake is applying it to every image, including the one at the very top. That image is often the element that defines the LCP (Largest Contentful Paint), the moment the page feels "loaded". Deferring it slows down exactly what the visitor is waiting for. The rule I follow:
- the image visible on load: no
loading="lazy", and if it's the LCP element, I addfetchpriority="high"so the browser fetches it first; - all the others:
loading="lazy".
<img src="/assets/hero.webp" alt="…" width="1200" height="630" fetchpriority="high">3. The right format, not just the right size
PNG is made for flat colors, logos and images with few colors. For a rich screenshot or a photo, it's often much heavier than necessary. WebP and AVIF compress far better at comparable visual quality, and today's mainstream browsers can read them.
To stay safe with older browsers, you use <picture>: the browser picks the first format it understands and falls back to the classic image otherwise.
<picture>
<source srcset="/assets/portrait.avif" type="image/avif">
<source srcset="/assets/portrait.webp" type="image/webp">
<img src="/assets/portrait.jpg" alt="Portrait" width="420" height="420" loading="lazy">
</picture>No JavaScript, no library: it's plain HTML, and it works on a static site.
4. Serve the right size to each screen
A 2000-pixel-wide image displayed in a 400-pixel frame is wasted weight, especially on mobile. srcset and sizes let the browser choose among several versions:
<img src="/assets/projet-800.webp"
srcset="/assets/projet-400.webp 400w, /assets/projet-800.webp 800w, /assets/projet-1600.webp 1600w"
sizes="(max-width: 700px) 100vw, 600px"
alt="…" width="800" height="450" loading="lazy">You need to produce several files, which takes a bit of discipline at export time. But it's a setting you make once and it pays off on every visit.
What I still need to fix on my own site
I always check my own pages before giving advice. And the result is instructive. Dimensions are declared, lazy-loading is in place below the fold. But my visuals are still PNG: the portrait weighs about 2.9 MB, the karting project screenshot about 0.8 MB. That's too much for images displayed small. Converting them to WebP or AVIF, at a size matching their frame, is my next job on this front.
I'm saying it because it's exactly what I see with clients: the basics are often in place, and the gain hides in file weight. A quick image audit is usually enough to spot it.
In short
Declare dimensions, defer what's off-screen, never defer the main image, pick a modern format, serve the right size. Five settings, no framework, and a direct effect on perceived speed and on Core Web Vitals.
If your site loads slowly and you suspect your images, let's talk: I can look at your pages and tell you precisely where the useless kilobytes are.