Why images dominate page weight
A typical HTML document with CSS and JavaScript might transfer 200–500 KB. A single unoptimized photograph can be 5–15 MB. On a mobile connection averaging 10–20 Mbps, a 10 MB image takes 4–8 seconds to download. Most visitors will not wait.
Images also affect Core Web Vitals — Google's metrics for page experience that influence search ranking. Largest Contentful Paint (LCP) measures how long it takes for the largest visible element to render. If that element is a hero image, its download time directly determines your LCP score. A slow LCP hurts both user experience and search ranking.
The usual suspects, and the fix for each
Slow image loading almost always traces back to one of these. Each has a quick fix and a meaningful payoff:
| Cause | Fix | Typical saving |
|---|---|---|
| Wrong format (PNG photo) | Convert to WebP or JPG | 80% or more |
| Full-resolution upload | Resize to about 2x the display width | 70-80% |
| Weak or skipped compression | Export at quality 75-85 | 3-5x vs quality 95 |
| No lazy loading | Add loading=lazy below the fold | Less data on first load |
| HEIC served raw | Convert to WebP or JPG first | Avoids broken images |
The wrong format for the content type
Using PNG for photographs is one of the most common image mistakes on the web. PNG is lossless and preserves every pixel, which matters for logos and screenshots but not for photos. A photograph saved as PNG can be 15–25 MB. The same photo as JPEG at high quality is 2–5 MB. As WebP it can be under 2 MB with identical visible quality.
The reverse is also a mistake: using JPEG for screenshots, diagrams, or images with text. JPEG introduces visible artifacts on hard edges and flat color areas, requiring high quality settings that produce large files. PNG or WebP handles this content smaller and cleaner.
Uploading images at full camera resolution
A photo from a modern smartphone is 12–50 megapixels and 3000–8000 pixels wide. Most web pages display content images at 600–1600 pixels wide. When you upload the full-resolution camera file to your website, the browser downloads all 8000 pixels and scales it to 800 pixels for display. You are transferring 10× more data than necessary.
Resizing the image to the largest width it will ever be displayed — roughly double the CSS display width for high-density screens — before uploading is often the single biggest size reduction available. A 4000-pixel image resized to 1600 pixels is typically 70–80% smaller before any quality compression is applied.
Skipping compression or using the wrong quality setting
Many content management systems accept and store uploaded images without compression. WordPress, Squarespace, Shopify, and similar platforms may apply some compression by default, but the settings vary and are often conservative. The uploaded original may be much larger than necessary.
For JPEG and WebP, a quality setting of 75–85 is appropriate for most photographs displayed on a web page. Below 75, compression artifacts become visible. Above 85, file size increases significantly with diminishing visual improvement. Many developers default to quality 95 or 100, which produces files 3–5× larger than quality 80 with no visible difference at normal viewing sizes.
No lazy loading on below-the-fold images
By default, browsers attempt to load all images on a page during initial render, including images that are far below the visible area (the fold). For a long article page with 10 images, the browser tries to download all 10 simultaneously even if the reader may never scroll to see most of them.
The loading="lazy" attribute on an <img> tag instructs the browser to defer loading the image until it is about to enter the viewport, which significantly reduces the data transferred on initial page load. Apply it to all images that are not visible in the first viewport. Do not apply it to the hero image or any image above the fold — those need to load as fast as possible for a good LCP score.
For the hero image specifically, add fetchpriority="high" so the browser fetches it ahead of scripts and other images. Use it on only one image per page — the LCP element — and leave the rest at the default.
<img src="photo.webp" loading="lazy" alt="description" /><img src="hero.webp" fetchpriority="high" width="1200" height="675" alt="hero" />
Missing width and height attributes
When a browser starts rendering a page, it does not yet know the dimensions of images it hasn't downloaded. Without explicit width and height attributes in the HTML, the browser cannot reserve the correct space, and the page layout shifts as images load — a jarring visual jump known as Cumulative Layout Shift (CLS). Adding explicit dimensions prevents layout shift and allows the browser to start layout without waiting for the image to download:
<img src="photo.webp" width="800" height="533" alt="description" />
HEIC or unusual formats uploaded directly
iPhones shoot HEIC by default. If HEIC files are uploaded to a website and served without conversion, they will fail to display in Chrome, Firefox, and Edge. Visitors on Windows and Android see a broken image icon. Always convert HEIC to JPEG or WebP before publishing.
A practical optimization checklist
PhotoTools handles the format conversion, resizing, and compression steps in your browser without uploading anything to a server. Process images before upload to keep your pages fast, and run through this checklist:
- Use WebP for photographs and most web images. Use PNG for graphics with text or transparency.
- Resize images to the largest width they will actually be displayed, approximately 2× the CSS display width for retina screens.
- Compress JPEG and WebP at quality 75–85 for standard web images.
- Add loading="lazy" to all below-the-fold images.
- Add explicit width and height attributes to all images.
- Convert HEIC files to JPEG or WebP before uploading.
- Verify final file sizes: a web image displayed at 800 CSS pixels wide should be under 200 KB in most cases.