Making Static Assets Lighter: Images, Scripts, Styles and Caching
A page's speed is often decided before any of its content is read, by the weight of its static assets: the images, scripts, stylesheets, and fonts that the browser must download before the page feels complete. A single unoptimised photograph can outweigh the rest of the page combined, an unminified script can carry thousands of characters of whitespace and comments that no visitor needs, and a missing cache header can force returning visitors to download everything again. These are not exotic problems, and they are not solved by a faster server alone, because the bytes still have to travel. The Static Asset Optimization Checker examines an asset list you supply, such as file names, sizes, and types, and reports which assets are heavy, which are unminified, and which lack the caching or compression settings that make repeat visits fast.
Static assets are the files that do not change per visitor: images, stylesheets, scripts, fonts, and icons. They are distinct from the page's dynamic content, and they have a useful property: because they change rarely, they can be cached aggressively, compressed once, and served from a nearby location, all of which make them cheap to deliver after the first visit. Optimisation works on three levers. The first is size: smaller files download faster, and size is reduced by choosing efficient formats, resizing images to their display size, and minifying code. The second is count: fewer requests mean less overhead, and count is reduced by combining files where sensible and by removing assets the page no longer uses. The third is caching: correct headers let browsers reuse files across visits instead of downloading them again, which makes repeat visits dramatically faster even when the first visit is unchanged.
How it works
A checker works from the asset information you supply, typically a list of files with their sizes, types, and, where relevant, their served headers. It applies a set of rules that reflect current practice. Images are flagged when they are far larger than their display size, when they use an inefficient format for their content, or when they lack modern alternatives. A photograph served as a large PNG, for example, is usually far heavier than the same photograph as a JPEG or a modern format, because PNG is designed for graphics with sharp edges and transparency, not for photographs. Scripts and stylesheets are flagged when they appear unminified, which the checker infers from size and content patterns, or when they contain large amounts of unused code. Fonts are flagged when they include weights and character sets the page never uses.
Caching and compression are checked from the headers you supply. A static asset should normally be served with a long cache lifetime and a content hash in its file name, so that a changed file gets a new name and is fetched fresh, while an unchanged file is reused for months. It should also be served compressed, because text files such as scripts and stylesheets typically shrink by two thirds or more under compression, and serving them uncompressed wastes bandwidth on every visit. The checker reports each finding with the asset it concerns and the approximate saving, so the team can fix the largest wins first rather than optimising assets that barely matter.
Worked example
Consider a sample page with four assets, using sample values for illustration. The hero image is a photograph, 2400 pixels wide, served as a PNG of 2.8 megabytes, displayed at 800 pixels wide. A script bundle is 640 kilobytes unminified, and a stylesheet is 180 kilobytes unminified. A font file includes four weights totalling 420 kilobytes, though the page uses only one weight. The total is about 4.0 megabytes. A checker would flag all four: the image is three times wider than displayed and in an inefficient format, the script and stylesheet are unminified, and the font carries three unused weights.
Fixing them in size order gives a clear picture. Resizing the image to 1200 pixels wide and serving it as a modern photograph format might reduce it from 2.8 megabytes to about 220 kilobytes, a saving of roughly 2.6 megabytes. Minifying the script might reduce it from 640 kilobytes to about 430 kilobytes, and the stylesheet from 180 kilobytes to about 130 kilobytes, saving about 260 kilobytes combined. Serving only the used font weight might reduce the font from 420 kilobytes to about 110 kilobytes, saving about 310 kilobytes. The new total is roughly 890 kilobytes, less than a quarter of the original, and the image alone accounts for most of the gain. That is typical: one oversized image usually outweighs all the code optimisation combined, which is why asset checks should start with images.
Mistakes to avoid
The most common mistake is optimising code while ignoring images, because code feels like the engineer's job and images feel like someone else's. Check the bytes, not the job titles, and fix the largest files first. A second mistake is resizing images by display attributes alone, setting a width of 800 pixels on an image that is still 2400 pixels wide, which makes the page look right while downloading the full file. Resize the file itself, not just its display size. A third mistake is caching aggressively without versioned file names, so that returning visitors keep seeing the old stylesheet or script after a deployment, and the team concludes the deployment failed when the cache is really at fault. Pair long cache lifetimes with content-hashed file names, so a changed file is a new file to the cache.
A fourth mistake is removing assets blindly to reduce request count, such as combining all scripts into one bundle that every page must download even though each page uses only part of it. Count matters, but so does relevance: a page should load the assets it uses, not the site's entire library. A fifth mistake is forgetting that optimisation must be verified on real devices and connections, not only on a fast office network. A page that feels instant on office broadband can still be painful on a mobile connection, and the asset sizes that matter most are the ones a mobile visitor actually downloads. Finally, the handling rule: asset lists and headers are not secret, but do not paste credentials, tokens, or internal addresses into a checker along with them.
Putting it into practice
Run an asset check whenever a page is built or redesigned, and again after any change that adds images, scripts, or fonts. Fix findings in size order, verify the result by reloading the page and comparing totals, and keep a short record of the before and after sizes, because the record makes the next check faster and proves the improvement. For neighbouring tools, the Image Optimizer handles the image side in detail, and the CSS Minify tool minifies stylesheets. For background reading, the related guide explains minification, which is one of the three levers, and the foundation for the script and stylesheet findings a checker reports.
Key points
- Page weight is usually dominated by images, then scripts, stylesheets, and fonts
- Optimise on three levers: smaller files, fewer requests, and longer caching
- Pair long cache lifetimes with content-hashed file names, or updates will not reach visitors
- Fix the largest assets first, and verify on a mobile connection, not only on office broadband