Text compression

Silktide loads your pages in a real browser and checks whether text-based files, such as the page itself, stylesheets, and scripts, are compressed while being transferred. Files sent uncompressed are reported along with the data that compression would save.

Why this matters

Text compresses extremely well - , , and typically shrink by 60-80% when compressed in transit. Every modern browser supports this automatically, so serving uncompressed text means every visitor downloads several times more data than necessary, on every page view, for no benefit. It is one of the cheapest performance wins available: a server setting, not a website change.

How to fix it

Enable compression on your web server. All mainstream servers support gzip, and most also support Brotli, which compresses better - enabling it is usually a one-line configuration change:

# Response header when compression is working
Content-Encoding: br

If you use a or managed hosting, compression is a platform setting and is often just a checkbox.
If you serve text dynamically from your own application (such as an API), check that your framework's compression middleware is enabled.

How Silktide tests this

Load the page in a real browser and identify text-based responses, such as HTML, CSS, JavaScript, and JSON data.
Check whether each was delivered with compression.
For uncompressed files, calculate what compression would have saved, and report each file with its current size and potential saving, largest first.

Troubleshooting

Compression is enabled but files are still reported

Check the specific files reported: compression is often enabled for some file types but not others (JSON and SVG are commonly missed), and files served by a different subdomain, proxy, or third party don't inherit your main server's settings. Very small files may also be skipped by servers deliberately, which is fine - the saving would be negligible.