Pictures dominate page weight. Here is what the quality setting actually changes, when targeting a kilobyte figure makes sense, and why resizing before compressing beats every other trick.
When a page feels slow, the culprit is usually not JavaScript but pictures that are heavier than they need to be. Image compression is how you hand a visitor the same picture using a fraction of the bytes, and done properly nobody can tell. This article explains what the quality setting really controls, when working to a target file size makes sense, and how the order of your steps changes the result.
For the hands-on part, the image compressor and the image resizer work as a pair; if the container has to change too, use JPG to WebP or PNG to AVIF. Tightening the frame also buys bytes, and the image cropper often beats compression outright for that.
A visitor keeps feeling that a page is loading until the largest visible element has been painted. On most pages that element is a picture. So a hero shot that weighs 220 KB instead of 1.8 MB shows up directly in perceived speed. Over a typical mobile connection, that 1.5 MB difference is more than a full second of waiting.
There is a second, quieter effect. Heavy pictures do not only delay themselves; they hold fonts and stylesheets in the queue behind them on the same connection. Halve the total image weight of a page and you will see unrelated elements arrive earlier too.
Quality is not a percentage of anything you can see. It is a threshold that decides how much detail the encoder is allowed to discard. The range runs from 20 to 95 with 82 as the default, and the scale is not linear. Dropping from 95 to 85 shaves off a noticeable slice of the file with no visible change. Going below 60 starts producing blotches in flat areas and smears the edges of type.
A practical routine: export the same picture at 85, 75 and 65, view all three at their intended display size, and stop one step above the first one that bothers you. That threshold moves with subject matter. A portrait can stay clean at 70, while a cover with fine lettering may fall apart below 85.
Sometimes “looks fine” is not the requirement and a hard ceiling is: a marketplace caps uploads at 500 KB, an email template wants everything under 200 KB. In target-size mode you do not pick the quality value at all; the encoder walks it down until the file fits. The ceiling for a target is 5120 KB, so even a 5 MB budget is expressible.
The trap is that an unrealistic target collapses quality silently. Squeezing a 3000-pixel-wide photograph into 80 KB is technically possible and practically useless. When you find yourself there, the answer is fewer pixels, not more compression.
Keeping a picture at 4000 pixels wide and dropping quality to 50 is a very different bargain from scaling it to 1600 pixels and leaving quality at 85. The second option wins nearly every time, on both weight and appearance.
Serving one file to every screen is easy and expensive: a phone downloads the version prepared for a desktop monitor. Generating a separate file for every breakpoint, on the other hand, quickly becomes unmanageable. Three sizes cover most projects: roughly 640 pixels wide for phones, 1280 for laptops and 1920 for high-density displays. That set removes the worst waste while keeping the number of files sane.
It is also worth nudging quality up a notch on the smaller variants. As a picture shrinks, each pixel carries more information, and artefacts invisible in a large file become obvious in a small one. Saving the 1920-pixel copy at 80 and the 640-pixel copy at 88 keeps both looking clean and still leaves total weight low.
| Step | Typical saving | Visible risk | When to use it |
|---|---|---|---|
| Halving the dimensions | 70% – 75% | None, if display size is right | Always first |
| Quality 95 down to 82 | 35% – 50% | Very low | On photographs |
| PNG replaced by WebP | 25% – 35% | None | Graphics and screenshots |
| WebP replaced by AVIF | 20% – 30% | None | Hand-picked hero art |
| Quality below 60 | 15% – 25% | High | Preferably never |
The ordering matters as much as the numbers: the biggest win carries the smallest risk. Most teams invert it, squeeze quality first, never touch dimensions, and end up with pictures that are both ugly and still heavy.
For batch work, a queue accepts up to 20 files at a time and each one has to stay under the 24 MB per-file ceiling. Those two numbers shape how you split a large job. If you are starting from camera originals, spend the first pass purely on dimensions; the second pass then has far less to do.
Three numbers are enough to know if the effort paid off: total image weight on the page, the weight of the single largest picture, and the moment that picture becomes visible. A browser network panel hands you the first two directly. For the third, load the page with connection throttling on, which comes closest to what a real visitor experiences.
Targets help too. Keeping total image weight on a content page under 500 KB, with no single picture above 150 KB, is achievable for most projects and generous in practice. Hitting that bar almost never comes from one setting; it comes from dimensions, container and quality pulling in the same direction.
Because across a wide range of subjects it sits close to the lowest value nobody notices. Higher inflates the file, lower starts leaving traces on certain pictures. If your own library suggests a different number, use it; a default is a starting point, not a rule.
No. Compression reduces the data used to describe the pixels, not the number of pixels. Changing width and height is a separate operation, and it should happen first.
The pipeline receives the upload, processes it and returns the result; no permanent archive is kept. Even so, with documents that contain personal details it is a good habit to crop the sensitive regions out before uploading anywhere at all.
Serving a modern format with a fallback for old clients is a well-established pattern. Maintaining two copies by hand is error-prone though, and on smaller sites picking one format and optimising it well is usually the healthier decision.
For how the container itself shifts these numbers, see how to choose an image format; if you are about to process dozens of files at once, the batch image conversion workflow covers sequencing.
