Page weight is the most fixable performance problem on the web. Images alone account for the majority of bytes on a typical page — and most of them are larger than they need to be.
Website speed is not an aesthetic preference. It changes how many people stay, how many convert, and how search engines rank you. And the largest single contributor to slow pages is not code complexity or server latency — it is file size, mostly images.
What page weight actually costs
Every byte on a page must travel from a server to a device, over a connection that may be a fibre line or a congested mobile network on a train. The difference between those two scenarios is enormous. A 4 MB page that loads in under a second on a desktop connection can take fifteen seconds or more on a poor mobile connection.
Consistently across published industry research, bounce rate climbs sharply with load time, and conversion rate falls. The direction of the relationship is not seriously disputed. Users abandon pages that make them wait, and mobile users abandon fastest because they are most often in a hurry and on the worst connections.
How this connects to SEO
Search engines measure real-world loading experience and use it as a ranking input. The relevant metrics are grouped as Core Web Vitals, and two of the three are directly affected by file size.
Largest Contentful Paint
LCP measures how long until the largest visible element finishes rendering. On most pages that element is the hero image. If your hero is a 3 MB unoptimised photograph, LCP will be poor regardless of how well everything else is engineered. Compressing and correctly sizing that one image is frequently the single biggest performance win available.
Cumulative Layout Shift
CLS measures unexpected movement of content while loading. Images without declared dimensions cause content to jump as they arrive — and the slower they arrive, because they are too large, the more disruptive the shift.
Interaction to Next Paint
INP measures responsiveness. Heavy JavaScript payloads block the main thread, so a page can appear loaded while ignoring taps and clicks. Script weight matters as much as image weight here.
There is also a crawl-efficiency dimension. Search engine crawlers operate within a resource budget per site. Heavy, slow pages consume more of that budget per URL, which can mean fewer pages crawled and slower discovery of new content — particularly relevant for large sites.
Where the bytes actually are
On a typical content page the breakdown looks roughly like this, in descending order of weight:
- Images — usually the majority of total page weight, and usually the easiest to fix.
- JavaScript — frameworks, analytics, tag managers, chat widgets, and advertising scripts.
- Web fonts — several hundred kilobytes if you load many families and weights.
- Video — enormous when autoplaying, negligible when behind a poster image.
- CSS and HTML — normally small by comparison.
Because images dominate, an image-focused effort delivers the best return for the least risk. It requires no code changes and cannot break functionality.
A practical reduction plan
Step 1: Right-size every image
This is the biggest and most commonly missed win. Serving a 4000-pixel-wide photograph into a container 800 pixels wide discards roughly 96% of the transferred data at render time. Resize to the maximum display width, doubled for high-density screens, using the Image Resizer.
Step 2: Compress to the lowest acceptable quality
For photographic content, quality around 80 to 85 is usually indistinguishable from maximum at normal viewing size while producing a far smaller file. Sweep through settings with the Image Compressor and stop at the point where you can just begin to notice a difference, then step back one level.
Step 3: Choose the right format
WebP typically delivers 25 to 35% smaller files than JPG at equivalent perceived quality, with support in every current browser. Test each image with the Image Converter — flat graphics and photographs behave differently, so let the file sizes decide rather than a rule of thumb.
Step 4: Lazy-load below the fold
Images the visitor has not scrolled to do not need to load immediately. Native lazy loading is a single HTML attribute and removes their weight from the initial load entirely. Keep hero and above-the-fold images eagerly loaded so LCP is not delayed.
Step 5: Declare dimensions
Always specify width and height, or an aspect ratio, so the browser reserves space before the image arrives. This eliminates layout shift at zero cost.
Step 6: Audit third-party scripts
Analytics, heat mapping, chat widgets, and marketing tags accumulate quietly and are rarely reviewed. List every script on your site and remove anything nobody has looked at in six months. This is often the second largest available win after images.
Step 7: Trim documents you host
Downloadable PDFs count too. A 30 MB brochure is a poor experience on mobile data. Run it through the PDF Compressor, and consider splitting long documents into sections with Split PDF so visitors download only what they need.
Sensible targets
- Total page weight: under 1 MB is excellent, under 2 MB is respectable, over 4 MB needs attention.
- Hero image: under 200 KB after compression and correct sizing.
- Content images: 50 to 150 KB each.
- Hosted PDFs: under 5 MB.
- LCP: under 2.5 seconds on a mid-range mobile device on a 4G connection.
Measure, do not guess
Use your browser's network panel to sort every request by size — the offenders are usually obvious within seconds. Then test with a throttled mobile profile rather than your own fast connection, because your connection is not representative of your audience. Fix the largest item, measure again, and repeat. Three iterations of that loop typically transforms a page.
File size is the rare optimisation that is simultaneously good for users, good for search rankings, and cheap to implement. There is very little reason not to do it.