dotvitals

Loading the list of pages…

↑↓ to moveEnter to openEsc to close

Scripts and stylesheets are sent without compression

MediumConfirmedQuick winperf.assets.subresources-uncompressed

What this check looks for

‹count› text file(s) this page loads — JavaScript, CSS, JSON or SVG — arrived uncompressed, even though our request offered to accept gzip and Brotli.

Why it matters

Text compresses by roughly 70–90%. This is a server setting rather than a code change, and it is the largest saving per minute of work available on most sites.

When the check passes, your report says: “Scripts and stylesheets arrive compressed”.

What it costs your score

When this check fails it removes 8 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.assets family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity
medium
Default confidence
confirmed
Status when triggered
warn
Deduction
8 points
Family cap
performance.assets · 25
Category
Performance
Module
Perf assets
Fix owned by
user
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Turn on gzip or Brotli compression for text responses on whatever serves your static assets.

Compressible text is being sent in full on every visit, for the sake of one server setting; the files and the measured saving are listed above.

  1. Find out what actually serves these files. The paths in this finding will tell you whether it is your web server, a CDN, or an object store — the setting lives wherever that is.

  2. Enable compression for text/*, application/javascript, application/json and image/svg+xml. Do not compress images, video or WOFF2 fonts; they are already compressed.

  3. Prefer Brotli where the server supports it, with gzip as the fallback for clients that do not ask for br.

  4. Make sure Vary: Accept-Encoding is sent, or a shared cache may hand a compressed body to a client that cannot read it.

  5. If the assets are on an object store that cannot compress on the fly, pre-compress at build time and upload both variants with the right Content-Encoding.

How to confirm it worked

  • Re-run this scan and confirm the uncompressed count has dropped.

  • curl -sSI -H 'Accept-Encoding: br, gzip' https://‹host›/path/to/app.js | grep -i 'content-encoding' — expect br or gzip

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx
gzip on;
gzip_vary on;
gzip_min_length 256;
gzip_types text/css application/javascript application/json image/svg+xml;

# Brotli, only if the ngx_brotli module is compiled in:
# brotli on;
# brotli_types text/css application/javascript application/json image/svg+xml;
Apache
<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/css application/javascript application/json image/svg+xml
</IfModule>

<IfModule mod_brotli.c>
	AddOutputFilterByType BROTLI_COMPRESS text/css application/javascript application/json image/svg+xml
</IfModule>
Caddy
encode zstd gzip

  • text/html is compressed by nginx unconditionally and must not appear in gzip_types — listing it logs a duplicate-MIME warning. Brotli is not in a stock nginx build; nginx -V will tell you whether ngx_brotli is present before you uncomment those lines.

  • mod_deflate adds Vary: Accept-Encoding itself. mod_brotli ships with Apache 2.4.26 and later but is off by default — a2enmod brotli — and the IfModule guard keeps the config valid until it is enabled.

  • Caddy's encode negotiates the encoding and sets Vary: Accept-Encoding on its own. A stock build offers gzip and zstd, not Brotli, so do not write encode br and expect it to take effect.

Technical detail

Uncompressed text subresources: ‹count›.

‹summary›

‹detail›

**How this was measured, and what it could not see.** We fetched the page and then the subresources its HTML declares, and read what the server sent back. No browser was involved, so nothing here depends on how fast our machine is — but equally, **a resource that a script loads after the page arrives is invisible to this check**. A page that assembles its own asset list at runtime will look lighter here than it is. The number of subresources the page declared, and how many of those we asked about, are both stated in the page-weight finding; where they differ, this section examined a prioritised sample rather than the whole page.

**The saving above is measured, not estimated.** Each file listed was compressed with gzip during the scan and the difference between what the server sent and what gzip produced is what you see. Brotli would usually do better still. Where the figure is absent instead, the compressor was unavailable on the run and we decline to guess a ratio.

**This finding is about the files the page loads, not about the page itself.** The main document's compression is checked separately by http.headers.compression-not-applied, which fetches that response directly. If you see both findings they are two different responses and both need fixing; if you see only this one, the HTML is compressed and the assets are not — which usually means a separate asset host, a CDN or a storage bucket configured independently of the web server.

Compressing already-compressed formats — images, video, WOFF2 fonts — wastes CPU for no gain and should stay off. Files under a kilobyte are not reported at all: the gzip frame can make them larger.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the perf assets checker