Why media is usually the speed problem
On a typical web page, images and video make up more than half of all the bytes downloaded. A single uncompressed hero photo can weigh more than all the page's code together. Because Google's Core Web Vitals, especially Largest Contentful Paint (LCP), measure how quickly the main content appears, heavy media directly affects both user experience and search visibility.
The good news: media problems are among the easiest speed issues to find and fix. This guide gives a repeatable 20-minute audit.
Step 1: Get a complete inventory
You can't fix what you can't see. Paste the page into the extractor. For the most complete list, open your page, scroll to the bottom so lazy-loaded files appear, then run our bookmarklet. It lists every image, video and stream the page actually requested, including CSS backgrounds.
Next, find the heavy ones. Open developer tools (F12), go to the Network tab, filter by Img and Media, reload, and click the Size column to sort big → small. The top ten files are where almost all your savings will come from.
Step 2: Flag images that are too heavy
Use these rough targets for compressed images on a typical site:
| Image role | Displayed width | Target size |
|---|---|---|
| Full-width hero | 1600–2000 px | under 200 KB |
| Content / blog image | 800–1200 px | under 120 KB |
| Product thumbnail | 300–500 px | under 40 KB |
| Icon or logo | any | SVG, under 10 KB |
Anything far above these numbers is a candidate. A 2 MB JPEG straight from a camera is the classic culprit.
Step 3: Check dimensions against display size
Each result shows the image's real pixel dimensions. Compare them with the size the image is shown on screen. A 4000 × 3000 photo displayed in a 400-pixel card wastes about 99% of its pixels. Export images at around 2× their largest display width, which keeps them sharp on high-density screens, and use srcset to give smaller screens smaller files.
Step 4: Check formats
Use the format filter chips. Common findings:
- Photos saved as PNG: convert to WebP or AVIF, often 70–90% smaller.
- No WebP/AVIF at all: serve modern formats with a JPEG fallback using
<picture>. - Large animated GIFs: replace them with a muted, looping MP4 or WebM video.
- Raster logos and icons: switch to SVG.
Our image format guide explains the trade-offs in detail.
Step 5: Review video
Filter to Videos. For each file, ask:
- Does it autoplay above the fold? A background video should be short (under 10 seconds), muted, compressed and shown after a lightweight poster image.
- Is it a single large MP4? For longer videos, adaptive streaming (HLS) or a video host lets viewers start quickly. See how HLS works.
- Is it loaded on every page? Use
preload="none"or load it only when it scrolls into view.
Step 6: Lazy loading and priorities
Images below the fold should use loading="lazy" so they download only when needed. Do the opposite for the main hero image. Don't lazy-load it, and consider fetchpriority="high" so the browser fetches it first. This one change often improves LCP noticeably.
A quick check: scan your page by URL without scrolling. Images found there are in the initial HTML; if a large one is far down the page, it should probably be lazy-loaded. Ask whether the visitor actually sees it right away. Ask whether the visitor actually sees it right away.
Step 7: Re-measure
After fixing the top offenders, repeat the Network-tab check and compare the total transfer size. Then confirm with a lab tool such as PageSpeed Insights or Lighthouse. Write down before and after numbers so you can see the gain.
Quick checklist
- ☐ No image over 200 KB without a good reason
- ☐ Images exported at ~2× display size, with
srcset - ☐ Photos in WebP/AVIF; graphics in SVG or PNG
- ☐ GIF animations replaced with video
- ☐ Below-the-fold media lazy-loaded; hero image prioritised
- ☐ Background videos short, muted and compressed