Optimizing All Site Assets for Speed, Not Just Images and Scripts

Most developers run a performance audit and immediately jump to the same suspects: oversized images, render-blocking scripts, and unminified CSS. Those things matter. But they are only a fraction of what a browser has to fetch before your page works. The rest of your assets sit there, quietly bloating load times, and nobody touches them.

Why Most Performance Audits Stop Too Early

Tools like Lighthouse and PageSpeed Insights are brilliant starting points. They flag large images, unused JavaScript, and poor Core Web Vitals scores. Developers act on those reports and see genuine gains. But those tools have a scope problem. They measure what the browser renders, not every file your server is responsible for.

Think about what else you host. White papers in the downloads folder. Technical PDFs linked from a landing page. Icon libraries loaded in full even when a page uses three icons. Custom web fonts serving character sets your content never references. Tracking tags from five different vendors injecting scripts before your own code runs.

None of these show up clearly in a standard Lighthouse report. That is the gap a complete asset audit is designed to close.

The True Weight of a Modern Web Page

The HTTP Archive tracks page weight trends across millions of sites. The median desktop page now transfers well over 2MB of data. Mobile is not far behind. Images account for a large share of that, yes. But scripts, fonts, and other resource types collectively represent a significant portion that many developers never audit properly.

As established in authoritative browser performance resources, reducing the total byte count sent over the network is one of the highest-leverage improvements you can make to perceived and actual load speed. This applies to every content type, not just the ones your audit tool highlights.

The math is simple. A faster server response still means nothing if the browser has to download a 15MB PDF during page load, or if a font file serves a full Unicode range for a site that only uses Latin characters.

Starting With What You Already Know: Images and Scripts

Since you are probably already working on images and scripts, it helps to use them as the baseline mindset for everything else. With images, the rule is: deliver only what the screen needs, in the most compressed format the browser supports. You convert to WebP or AVIF, you lazy-load below-the-fold images, and you serve responsive sizes using srcset.

With JavaScript, you tree-shake unused code, split bundles, defer non-critical scripts, and minify everything before it ships. With CSS, you remove unused rules and inline critical styles to avoid render-blocking requests.

That logic , deliver only what is needed, in the smallest format possible, as late as you can without hurting the user , applies to every asset type on your server. Internalize that principle and the rest of this checklist becomes intuitive.

Web Fonts: The Silent Bandwidth Thief

Web fonts are among the most commonly overlooked performance drains. A typical font family loaded from a hosted source can easily reach 300KB or more if you are not subsetting. Subsetting means you only include the characters your content actually uses, stripping out scripts and glyphs your pages will never render.

Beyond subsetting, the font-display: swap strategy prevents invisible text from appearing during font loading. Preloading critical font files with a <link rel="preload"> tag tells the browser to fetch them early, before the CSS parser even reaches the font-face declaration.

Self-hosting fonts removes a third-party DNS lookup. Every external domain your page contacts adds latency. Eliminating unnecessary connections is its own category of optimization, and fonts are a frequent culprit.

Icon Sets and SVGs: Load Only What You Use

A full icon library loaded as a single file can weigh 200KB or more. Most pages use a handful of icons from that set. Loading the whole library is the equivalent of serving a full-size image when a thumbnail would work perfectly.

The fix is to use SVG sprites containing only the icons your page actually references, or to inline critical SVG icons directly in the HTML. Tree-shaking works for icon packages too, if your build tool supports it. If you are still using an icon font, audit which glyphs you reference and consider switching to targeted SVG files instead.

Third-Party Scripts: Auditing What You Did Not Write

Analytics tags, chat widgets, A/B testing scripts, retargeting pixels. Every marketing tool your team installs hands a third party the ability to inject code into your pages. Each of those scripts adds network requests, parse time, and sometimes long tasks that block the main thread.

The right approach is to keep a running inventory of every third-party tag on your site. Assign each one to a team member who owns it. Then regularly ask whether the data it collects justifies the performance cost. Scripts that are no longer actively used should be removed, not simply disabled in a tag manager and forgotten.

For those that remain, load them with async or defer attributes where possible. Move them below the fold if they are not critical to first-paint rendering. Every millisecond saved on third-party load time is a millisecond returned to your users.

The Asset Type Most Developers Never Audit: Documents

This is where audits almost always stop short. A developer will spend an afternoon optimizing hero images and compressing JavaScript bundles, then leave a 25MB PDF linked on the same page without a second thought.

Downloadable documents are assets too. They live on your server. They consume bandwidth. They slow the connection for users who click the link, and in some cases they are embedded directly in the page via an iframe or a PDF viewer component, adding significant weight to the initial load before any user action.

PDF files in particular accumulate size from embedded images, duplicate fonts, metadata layers, and document revision history. A marketing team creates a white paper at print quality and drops it in the downloads folder. That file might be 20MB. The same document, properly optimized, could sit under 1MB with no visible quality loss for screen readers.

The practical first step is to compress PDF files before you host them. This is exactly the same logic as converting a PNG to WebP: you are removing data the end user cannot perceive. A compressed PDF loads faster, consumes less bandwidth, and does not penalize users on metered mobile connections.

Once compression is handled, think about where documents appear in the page structure. If a PDF is embedded in an iframe on a landing page, that download happens at page load time regardless of whether the user wants it. Moving it behind a download button means the browser only pulls it when the user requests it. That is lazy-loading logic applied to documents, and the gains can be dramatic.

Asset Types Compared by Optimization Impact

Server-Level Wins That Apply to Every File Type

No matter what file type you serve, a few server-side settings help every asset category at once. Enabling Brotli or Gzip compression at the server level reduces transfer size for text-based files. This includes HTML, CSS, JavaScript, SVG, and certain font formats. It costs nothing beyond configuration and consistently cuts transfer sizes by 60 to 80 percent for eligible content types.

Setting long cache expiry headers for static assets means repeat visitors do not re-download files they already have stored locally. Using a content delivery network puts your assets on servers physically closer to each user, reducing latency for every file type regardless of category.

HTTP/2 and HTTP/3 change the equation further. Multiplexing lets the browser fetch multiple assets simultaneously over a single connection, reducing overhead from serving many small files. If your server is still running HTTP/1.1, upgrading is a foundational step worth addressing before you micro-optimise individual asset sizes.

Running a Full Inventory Instead of a Partial Scan

The most useful thing you can do right now is build a complete inventory of everything your server delivers. That means images, scripts, stylesheets, fonts, icons, third-party tags, and every PDF or document sitting in your downloads folder.

Run that inventory through the same weight-reduction thinking you already apply to images. Ask whether each file is as small as it can be. Ask whether it loads at the right moment, or earlier than necessary. Ask whether it comes from your domain or requires an external connection. Ask whether a different format or compression level would reduce its size without affecting what users actually see.

A monthly or quarterly review of that inventory catches newly added assets before they accumulate. Marketing teams add PDFs without flagging them. Developers install new plugins. Designers upload fresh icon sets. Without a review cycle, asset weight grows silently in the background between formal audits, and the gains you worked for quietly erode.

When Every File on Your Server Earns Its Place

Performance is not a feature you apply to images and scripts while ignoring everything else you ship. Every file on your server represents a choice about what you are asking users to download. That choice deserves deliberate attention regardless of file type, extension, or which team added it.

Apply the same discipline to documents, fonts, icons, and third-party tags that you already apply to hero images and JavaScript bundles. The principle does not change based on file format. Smaller files load faster. Deferred files do not block rendering. External dependencies carry latency and risk. These facts hold for every byte your server delivers.

Start with whatever is largest in your inventory. A single uncompressed PDF or a full icon library loading on every page can represent more weight than all your script optimizations combined. Work through the asset inventory methodically, and the speed gains will reach your users across every connection type and device they use to reach your site.