Cutting Page Weight Without Losing Image Quality
Page weight is the quietest performance problem there is. Nobody adds four megabytes to a website deliberately. It accumulates a hero image exported at full camera resolution, a gallery added for a campaign that ended two years ago, a second font family for one heading, a plugin that loads its scripts on every page for a feature used on one.
The good news is that most of that weight is recoverable without the site looking any different. Compression has improved enormously, browsers now handle modern formats universally, and the largest single saving usually requires no compression at all just serving images at the size they are actually displayed.
Key Takeaways
- The median page is around 2.4 MB on desktop and 2.2 MB on mobile, and images are the single heaviest resource type at roughly 911 KB on a median mobile page.
- The biggest saving is usually dimensional, not compressive: stop serving a 3,000-pixel image into a 600-pixel space.
- AVIF has been supported across all major browsers since January 2024; WebP is typically 25–34% smaller than JPEG at comparable quality.
- Never lazy-load your Largest Contentful Paint image it is the most common way a good optimisation makes a site slower.
- JavaScript is the second-largest contributor at around 632 KB on the median mobile page, and it is more expensive per byte than images.
Know where the weight actually is
Before optimising anything, look at the distribution. According to the HTTP Archive Web Almanac, on the median mobile home page the breakdown runs roughly like this: 911 KB of images, 632 KB of JavaScript, 122 KB of fonts, 77 KB of CSS and 22 KB of HTML.
Two things follow. First, images are the largest single category, which is why they are the right place to start. Second, JavaScript is not far behind and because scripts must be parsed and executed rather than merely decoded, each of those kilobytes costs more on a mid-range phone than an equivalent kilobyte of image data.
It is also worth knowing the spread. At the 90th percentile, pages reach roughly 9.2 MB on desktop and 8.3 MB on mobile. If your site is anywhere near that, the wins available are very large indeed.
Run your own numbers first. Optimising the wrong category is a common way to spend an afternoon and gain nothing.
The largest saving requires no compression at all
The most common and most expensive mistake in WordPress is a dimensional mismatch: an image uploaded straight from a camera or a stock library at 3,000 or 4,000 pixels wide, then displayed in a 600-pixel column. The browser downloads every pixel and discards most of them.
Fixing this is not subtle. Resizing a 3,500-pixel photograph to the 1,600 pixels a full-width hero actually needs can remove 80% of the file size before any compression is applied, with no visible difference whatsoever.
Two habits solve it permanently:
Resize before upload. Establish a maximum width that matches your layout typically 1,600 to 2,000 pixels for full-width imagery, 800 to 1,200 for in-content images and never upload anything larger.
Let responsive images do their job. WordPress generates multiple sizes and outputs a srcset so the browser can choose an appropriate one for the device. This only works if your registered image sizes match your actual layout. A theme with sensible size definitions serves a phone a phone-sized file; a theme that registers one enormous size serves everyone the enormous one.
Choose the right format for each job
Format choice is now straightforward, because browser support is no longer a constraint.
AVIF is supported in Chrome from version 85, Firefox from 93, Safari from 16 and Edge from 121 meaning full support across all major browsers since January 2024. It delivers the smallest files at a given visual quality and is the best choice for photographic content.
WebP is the safe universal workhorse, typically 25–34% smaller than JPEG at comparable quality, with support that is effectively total.
JPEG remains a perfectly reasonable fallback and is still the most widely used format on the web.
PNG should be reserved for images that genuinely need lossless quality or transparency with hard edges screenshots, diagrams with fine text.
SVG is the correct answer for logos, icons and simple illustrations. It is usually a fraction of the size and stays sharp at any resolution. Restrict uploads to trusted sources, since SVG can carry script.
Converting a large existing library by hand is impractical, which is where WordPress image optimization plugins earn their place: they handle conversion and fallbacks automatically as you upload.
A sensible policy: AVIF first with a WebP fallback for photographs, SVG for anything vector, PNG only where lossless is genuinely required.
Compress with intent, not with a slider set to maximum
Lossy compression discards information the eye is poor at detecting. Pushed too far it produces banding in gradients, blocking around high-contrast edges and mushy detail in textures. Used sensibly it is invisible.
For photographic content, a quality setting in the 75–85 range is the usual sweet spot; below about 70 artefacts start appearing in demanding images. The important discipline is to test on your hardest images a gradient sky, a product against a plain background, fabric texture, anything with fine typography inside the image rather than on a forgiving one.
Two further rules save trouble later. Compress once, from the original; repeatedly re-compressing an already-compressed file compounds the damage. And keep your originals somewhere outside the site, so you can re-export at a different setting without starting over.
Load images at the right moment
Reducing bytes is half the work. The other half is sequencing.
Lazy-load what is below the fold. Images outside the initial viewport should not compete for bandwidth with content the visitor can already see. WordPress applies loading="lazy" automatically to most images.
Never lazy-load the LCP image. This is the single most common self-inflicted wound in image optimisation. If your hero image is the Largest Contentful Paint element and it is marked lazy, the browser deliberately delays the very asset your score depends on. Exclude above-the-fold imagery from lazy loading, and consider fetchpriority="high" on the hero so the browser fetches it ahead of lower-priority resources.
Always set width and height. Explicit dimensions let the browser reserve the correct space before the image arrives, which is what keeps Cumulative Layout Shift low.
Do not put your LCP image inside a slider. If it only begins loading after JavaScript initialises, you have added the entire script execution time to your largest paint.
The other half of the budget
Once images are under control, the remaining weight is mostly scripts and fonts.
Fonts. Subset to the character ranges you need for a Bulgarian site, typically Latin plus Cyrillic and nothing else. Limit yourself to two families and the weights you genuinely use. Self-host and preload the critical face, and use font-display: swap so text is readable while the font loads.
JavaScript. Audit your plugins honestly. Anything installed for a past campaign and never removed is still enqueuing assets. Load scripts conditionally where the theme allows it, defer anything non-critical, and treat every third-party embed chat widgets, analytics, social feeds, review scripts as a cost to be justified rather than assumed.
A workflow that keeps weight down permanently
| Stage | What to do |
|---|---|
| Before upload | Resize to your maximum layout width; crop properly; keep the original elsewhere |
| At upload | Compress at quality 75–85; generate AVIF/WebP with a fallback |
| In the template | Correct srcset sizes; explicit width and height; SVG for icons |
| At render | Lazy-load below the fold; exclude and prioritise the LCP image |
| Quarterly | Re-audit page weight; remove unused plugins, fonts and media |
Where the server does the work for you
Some of this belongs to the platform rather than the site. Modern compression applied in transit, HTTP/2 so many small files are delivered efficiently over a single connection, sensible cache headers so returning visitors re-download nothing, and server-level caching so pages are served without invoking PHP at all.
Jump.BG's hosting runs LiteSpeed with built-in caching and HTTP/2 across all plans, which means the delivery side is handled and your optimisation effort goes entirely into the assets themselves.
Conclusion
Cutting page weight is not a trade against quality. Almost all of the excess on a typical site is redundant: pixels nobody sees, an older format doing a job a newer one does better in half the space, a script from a project that finished last year, four font weights where two would do.
Work in order dimensions, then format, then compression, then loading behaviour, then scripts and fonts and measure after each step. A site that goes from four megabytes to one while looking identical is an ordinary result, not an exceptional one.
Want the delivery side handled for you? Jump.BG's hosting plans include LiteSpeed with built-in caching, HTTP/2 and SSD storage, and our WordPress Support service offers a slow-site audit if you would like a second opinion on where your weight is going. Call 02 428 8888 or email [email protected].