Images are usually the largest thing a page downloads, so that is where to start — but the biggest single win is often something nobody remembered was there.
Open the browser's network panel, reload with the cache disabled, and sort by size. The list is almost always surprising — one forgotten background image or a single embed usually dominates everything you assumed was the problem.
Cap each image at the largest size it is displayed, doubled for high-density screens. This is the biggest and safest saving available, because file size scales with pixel count and most pages ship images several times larger than they can show.
Quality 78–85, and convert to WebP for another 25–35% at no visual cost. Do this after resizing, not instead of it.
Lazy-load images below the fold — but never the hero. Defer non-critical scripts. Subset your fonts and drop weights you do not use. A page that needs 400 KB to become usable is fast regardless of what loads afterwards.
Analytics, chat widgets, maps, video embeds and ad scripts each bring their own payload and their own connections. These are frequently the largest single item on the page and the easiest to remove, because someone added them years ago and nobody has looked since.
Images are usually the largest resource type on a content page by total bytes, and they are also the easiest to fix — reducing an image's dimensions carries no functional risk, unlike removing a script.
They also compound. A page with twenty images that are each three times larger than necessary is carrying an enormous amount of waste, and a single pass of resize-and-compress removes most of it without anyone touching the code.
A page can be heavy and feel fast, or light and feel slow. What matters is how much has to arrive before the page is usable, and in what order.
Two pages of identical total weight behave completely differently if one loads its hero image first and defers everything else, while the other blocks rendering on a font and a third-party script. Optimise the critical path, not the total.
This is why lazy loading is so effective: it does not reduce total weight at all, it just moves most of it out of the way.
Web fonts are small relative to images but disproportionate in effect, because text cannot render until the font resolves — which is a delay in the thing people actually came to read.
Three cheap fixes: use font-display: swap so text appears immediately in a fallback; subset the font to the characters you actually use; and drop weights you do not need. Most sites ship four or five weights and use two.
Long cache headers on images, CSS and fonts mean returning visitors download almost nothing. That does nothing for a first visit, which is what most performance tools measure, but it matters a great deal for real people who come back.
Give static assets a content hash in the filename and cache them for a year. It costs nothing and removes them from every subsequent visit.
These run in your browser on any device, so nothing is uploaded and there is nothing to install.
One setting across a whole folder, processed in parallel, downloaded as a ZIP.
Open the toolBy pixels or percentage, aspect ratio locked, across a whole batch.
Open the toolTypically 25–35% smaller at matched quality. The standard web win.
Open the toolFull resolution kept, quality still invisible to the eye.
Open the toolQuestions
Every answer below is present in the page source, expanded, so it can be read without opening anything.
Total weight matters less than how much must arrive before the page is usable. As a working target, keep everything above the fold under about 1 MB and lazy-load the rest — that produces a page that feels fast regardless of how much imagery sits further down.
On a typical content page, images are the largest resource type by bytes — usually a substantial majority. That is why they are the first place to look, and why a single resize pass often halves a page's weight.
Indirectly. Lighter pages generally have better Largest Contentful Paint, which is a Core Web Vitals metric used as a ranking signal. It is a page-experience factor, not a relevance one — speed will not rescue content nobody wants.
It helps a great deal but fixes nothing structural. Lazy loading moves bytes out of the initial load without reducing them, so a visitor who scrolls still downloads everything. Resize and compress as well, and never lazy-load the LCP image.
Rarely necessary. Subsetting to the characters you use, dropping unused weights and setting font-display: swap usually removes the problem while keeping the typography. Removing them entirely is a design decision, not a performance requirement.
Open the browser's network panel, reload with caching disabled, and sort by size. It takes a minute and is almost always more informative than a score out of 100 — you see the actual files, in order of how much they cost.
From the blog
More background from the blog.
Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.
8 min read
WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.
9 min read
Quality 80 is not 80% of anything. It is an index into a quantisation table. Measured on one photograph: dropping from 100 to 90 removes 77% of the file and 4.2 dB of fidelity; dropping from 40 to 30 removes 17% and costs almost as much.
8 min read