Optimising website images: what my portfolio taught me
Updated on
My first portfolio had animation and a clear visual identity. Yet the site stuttered as I scrolled. I spent time examining scripts, caching and loading behaviour before looking at a much simpler problem: the images were too heavy for the way I was using them.
Visuals played a large part in that project, including effects and masks. Compressing them and reconsidering their format noticeably improved my experience of the site. That does not mean images cause every slowdown. It is a reminder to measure what a page loads before deciding to rewrite the way it works.
Contents
Find out what is actually being downloaded
Open the browser’s developer tools and inspect the files transferred as the page loads. Identify the largest images, how many are requested and their actual dimensions. Repeat the observation under representative mobile conditions, rather than relying entirely on a powerful computer with a fast connection.
Separate the symptoms. A first image appearing late, a slow overall page load and an animation that stutters can have different causes. File size matters, but rendering, image dimensions and the work performed by the browser can also contribute. Describing the symptom precisely helps you choose what to investigate next.
Record a baseline before making changes. Without one, it becomes difficult to tell whether a modification helped or whether the impression comes from different conditions. Keep the page, device and network setup comparable when you return to measure the result after an adjustment.
Match image dimensions to their use
A photograph exported for print does not necessarily belong unchanged in a card only a few hundred pixels wide. Prepare dimensions appropriate to the display area and the expected sharpness. Consider how the image is used rather than treating the original export as the only available resource.
On a responsive site, several sizes can let the browser choose an appropriate version. That requires correct integration. Reducing the displayed width with CSS alone does not reduce the downloaded file. A visually small image can therefore remain expensive to transfer if the original resource is unnecessarily large.
The web.dev image course discusses responsive resources and the compromises between formats and quality. Its guide to images on the web provides a useful starting point. Use those principles alongside checks on your actual page, rather than applying a setting without examining what visitors receive.
Compress while checking the visual result
In my portfolio, WebP and compression formed part of the correction. The goal was a balance: a lighter file that retained enough quality for its intended use. A lower file size alone is not a successful result if the image stops doing its job.
Compare versions where they will appear. Degradation barely visible in a thumbnail may become distracting in a large photograph of a completed project. Examine edges, flat areas, fine detail and any text incorporated into the image. Evaluate the work at the size a reader will actually see.
Keep the originals separately. You can then produce another version without starting from an already degraded export. If several people update the site, give them a clear export process rather than a vague instruction to use light images. A repeatable method makes improvements easier to maintain after the initial cleanup.
Load images when they are needed
Images far below the beginning of a page can be loaded later when appropriate. The large image visible on arrival should not automatically receive the same treatment. Lazy loading is a performance tool, not a universal rule to apply indiscriminately to every image on every page.
After changes, inspect the whole page. Look for missing images, incorrect crops, poor mobile sharpness and unstable layout. Repeat the measurements under the same conditions as the baseline. The page should both behave better and retain the visual quality needed to present the business or product properly.
Comparison: resizing, compression and deferred loading
These actions are not interchangeable. Each addresses a different problem, and they can complement one another. Compare them through the downloaded resource, the appearance you need and the moment when the reader needs to see the image.
Resize an image with excessive dimensions
Problem: the file contains many more pixels than its use requires. Action: produce an appropriate version and the useful alternatives for different screens. Check: examine sharpness in the page, including on a dense display. Reducing dimensions blindly can create a blurry image. Always keeping the original can make people download detail they never benefit from. The right choice depends on where the resource appears.
Compress the file and compare formats
Problem: dimensions are suitable, but encoding still produces a large resource. Action: compare several exports with different formats and quality settings. Check: inspect edges, gradients and small details at the intended display size. The smallest file is not the best choice if a product or project becomes hard to appreciate. Record the chosen weight and keep an approved visual example for future exports.
Defer an image that will be seen later
Problem: the browser immediately requests images located far down the page. Action: defer the resources for which that makes sense. Check: scroll and observe when they appear. This does not reduce the file size; it changes the request timing. A key image in the first screen requires a different assessment. The web.dev image performance guidance explains that distinction and why loading priorities matter.
All three actions may belong in a gallery: provide suitable dimensions, choose an acceptable export and organise loading. For a single cover photograph, begin with its dimensions, weight and role at the start of the reading journey. Apply a method that addresses the observed problem rather than ticking every optimisation box.
Build a small before-and-after test
Choose a representative page and retain its starting version. Note the total image data transferred, the heaviest resources and the visible symptom. Keep conditions consistent: the same page, device or simulation, connection settings and cache treatment. A change in testing conditions can otherwise hide or exaggerate the effect of the correction.
Adjust the relevant image group first, then measure again. Check the visitor’s experience too: is the correct photograph shown, does the crop still work and does the text remain stable while images load? A technical improvement is unfinished if it damages the presentation of a product or portfolio.
Document the publishing process so the improvement lasts. Explain where to keep originals, which variants to produce and who approves the appearance. Someone adding a new project should be able to follow the method without understanding every implementation detail. This continuity helps prevent the same oversized resources from returning a few months later.
Diagnose the obstacle before rebuilding the site
This experience taught me to start with the resources actually used. A slow page does not necessarily require a complete redesign, and strong visual design does not remove the need to consider the work it asks the browser to perform. Measurements help separate a focused correction from a wider structural problem.
If the source of the slowdown is unclear, a technical website audit can help establish a diagnosis. When structure, content or journeys also need attention, a website redesign can then be assessed using concrete observations rather than a general impression that the site feels old or slow.
FAQ: optimising website images
Is there one maximum file size for every image?
A logo, thumbnail and full-width photograph have different needs. Set a budget suited to the page and compare exports in context. A single threshold can encourage damage to an important image while overlooking an accumulation of unnecessary small files. Examine both individual resources and the overall page, including the quality readers need to see.
Is converting to WebP enough to make a site fast?
A format change may help, but it does not fix excessive dimensions, unsuitable loading behaviour or an expensive animation. In my portfolio, image work addressed an identified problem. Another site needs its own investigation of loaded resources and possible causes. Verify the effect on the finished page instead of assuming that a format name guarantees performance.
Why keep the originals after compression?
They let you create new dimensions or formats when the design changes. Recompressing an already degraded file limits the quality available. Store originals separately from published resources, using names that identify the project or product. This also makes it easier to replace an incorrect version and maintain a consistent image process across the team.
When should the diagnosis go beyond images?
If suitable image resources do not resolve the symptom, examine scripts, rendering and exchanges with the server. A technical website audit can help prioritise those causes. The aim is to choose the next correction from evidence, before concluding that the whole website needs to be rebuilt or that every slow interaction has the same origin.