Browser Caching and Compression: The Easiest Speed Wins

# Browser Caching and Compression: The Easiest Speed Wins

Most website speed advice tells you to rebuild your site, switch hosts, or hire a developer. But two of the biggest performance improvements — browser caching and compression — are often a few configuration changes away. No redesign. No code rewrite. Just telling your server to do what it should have been doing all along.

If your website takes more than three seconds to load, caching and compression alone could cut that time in half. Here is how they work, why they matter, and how to check whether your site is using them.

Why Load Time Is a Business Problem

A slow website costs you money. Google research shows that as page load time increases from one second to three seconds, the probability of a visitor bouncing increases by 32 percent. At five seconds, that number jumps to 90 percent.

For a small business, every visitor matters. If you are paying for ads or relying on search traffic, a slow site means you are paying to send people to a page they leave before it finishes loading.

Google also uses page speed as a ranking signal. Their Core Web Vitals — metrics measuring real user experience — directly influence where your site appears in search results. Two of these metrics, Largest Contentful Paint (LCP) and Interaction to Next Paint (INP), are heavily affected by whether your site uses caching and compression properly.

The good news: these are the lowest-effort, highest-impact fixes most small business sites can make.

What Browser Caching Actually Does

When someone visits your website, their browser downloads everything needed to display the page: HTML, stylesheets, JavaScript, images, and fonts. Every file requires a separate request to your server.

Browser caching tells the visitor's browser: "You already downloaded this file. Use your local copy instead of asking for it again."

Here is what that looks like in practice:

First visit (no cache):

• Browser requests your homepage
• Server sends the HTML, plus 15 images, 3 CSS files, 2 JavaScript files, and 2 fonts
• Total: 22 separate requests, 2.4 MB downloaded
• Load time: 4.8 seconds

Second visit (with caching enabled):

• Browser requests your homepage
• Server sends only the HTML (it may have changed)
• Browser loads the other 21 files from its local cache
• Total: 1 server request, 45 KB downloaded
• Load time: 1.1 seconds

Those numbers reflect a realistic scenario for a typical small business site with product images and a standard WordPress theme.

How Caching Headers Work

Your server tells browsers what to cache using HTTP headers — small instructions attached to every file it sends. The two that matter most:

Cache-Control sets how long a browser should keep a file before checking for a new version:

• Cache-Control: max-age=31536000 means "keep this file for one year"
• Cache-Control: max-age=3600 means "keep it for one hour"
• Cache-Control: no-cache means "always check with the server first"

ETag is a fingerprint for the file. When the browser's cached copy expires, it sends the ETag back to the server. If the file has not changed, the server responds with a tiny "304 Not Modified" instead of re-sending the whole file.

Static files like images, fonts, and CSS should be cached for weeks or months. HTML pages should have short or no cache duration so visitors always see your latest content.

What Should Be Cached and for How Long

What Compression Does

While caching eliminates repeat downloads, compression shrinks files before they are sent the first time.

Your server compresses text-based files — HTML, CSS, JavaScript — before sending them. The browser decompresses on arrival. The file works exactly the same; it is just smaller in transit.

Two compression methods matter:

Gzip has been the standard for over two decades. It typically reduces file sizes by 60 to 80 percent. Nearly every browser and server supports it.

Brotli is a newer algorithm from Google that compresses 15 to 25 percent better than Gzip. All modern browsers support it. If your server offers it, use it.

Real Numbers

Here is what compression does to typical small business website files:

That is a 75 to 80 percent reduction in transfer size. On a mobile connection, this can mean the difference between a two-second load and a six-second load.

Images are already compressed in their file format (JPG, PNG, WebP), so Gzip and Brotli do not help much with those. Image optimization is a separate topic, but caching still helps enormously with images on repeat visits.

How to Check If Your Site Uses Caching and Compression

You do not need to read server configuration files. There are straightforward ways to check.

Method 1: Run a Free Audit

The fastest way is to run your site through FreeSiteAudit. It checks both caching and compression automatically and tells you exactly which files are missing proper headers.

Method 2: Use Browser Developer Tools

1. Open your website in Chrome
2. Press F12 to open Developer Tools
3. Click the Network tab
4. Reload the page
5. Click on any file in the list
6. Look at the Response Headers

For caching, look for Cache-Control or Expires headers. If they are missing, caching is not configured for that file.

For compression, look for Content-Encoding: gzip or Content-Encoding: br (Brotli). If this header is missing on HTML, CSS, or JS files, compression is not enabled.

Method 3: Check Google PageSpeed Insights

Google PageSpeed Insights flags missing caching and compression under the "Diagnostics" section. Look for:

• "Serve static assets with an efficient cache policy"
• "Enable text compression"

If either appears, your site is leaving speed on the table.

How to Enable Caching and Compression

The steps depend on your hosting setup. Here are the most common scenarios.

If You Use WordPress

Install a caching plugin. The best free options:

• WP Super Cache — Simple and reliable, made by Automattic
• W3 Total Cache — More options, including browser caching and compression settings
• LiteSpeed Cache — Best if your host runs LiteSpeed server

Any of these will add proper caching headers and enable Gzip compression with minimal configuration. Install one, activate it, and use the default settings. That handles 90 percent of the work.

If You Use Squarespace, Wix, or Shopify

These platforms handle caching and compression automatically. Squarespace enables Gzip on all text files. Shopify uses Brotli compression and sets cache headers on static assets.

However, "automatically" does not always mean "optimally." Third-party scripts, custom code additions, and large unoptimized images can still slow things down. Running an audit will show you if anything is slipping through.

If You Have a Custom Site on Apache

Add this to your .htaccess file:

apache

# Enable Gzip compression

AddOutputFilterByType DEFLATE text/html text/plain text/css

AddOutputFilterByType DEFLATE application/javascript application/json

AddOutputFilterByType DEFLATE application/xml text/xml

AddOutputFilterByType DEFLATE image/svg+xml

# Set caching headers

ExpiresActive On

ExpiresByType image/jpeg "access plus 1 year"

ExpiresByType image/png "access plus 1 year"

ExpiresByType image/webp "access plus 1 year"

ExpiresByType text/css "access plus 1 month"

ExpiresByType application/javascript "access plus 1 month"

ExpiresByType font/woff2 "access plus 1 year"

If You Have a Custom Site on Nginx

Add this to your server block:

nginx

# Enable Gzip compression

gzip on;

gzip_types text/plain text/css application/javascript application/json image/svg+xml;

gzip_min_length 256;

# Set caching headers for static files

location ~* \.(jpg|jpeg|png|webp|gif|ico|css|js|woff2)$ {

expires 1y;

add_header Cache-Control "public, immutable";

}

If You Use a CDN (Cloudflare, Fastly, etc.)

CDNs like Cloudflare enable compression and caching by default, but verify these settings:

• Compression: Ensure Brotli is enabled (in Cloudflare: Speed → Optimization → Content Optimization)
• Browser Cache TTL: Set to at least one month (Caching → Configuration)
• Cache Level: Set to "Standard" at minimum

A properly configured CDN gives you caching and compression plus the bonus of serving files from servers geographically closer to your visitors.

Real Example: Sarah's Bakery Website

Sarah runs a bakery in Portland. Her WordPress site has a homepage with 12 product photos, a menu page, an about page, and a contact form. Customers were complaining that the site was slow on their phones.

Here is what an audit found:

Before fixes:

• No browser caching headers on any files
• No compression enabled
• Page load time: 6.2 seconds on mobile
• Total page weight: 4.1 MB
• LCP score: 5.8 seconds (Poor)

What Sarah did:

1. Installed WP Super Cache (10 minutes)
2. Enabled Gzip compression in the plugin settings (2 clicks)
3. Turned on browser caching (1 click)
4. Ran an audit to confirm the changes took effect

After fixes:

• All static files cached for one year
• Gzip compression active on HTML, CSS, and JS
• Page load time: 2.8 seconds on mobile (first visit), 1.3 seconds (repeat visit)
• Total transfer size: 1.6 MB (first visit), 0.3 MB (repeat)
• LCP score: 2.3 seconds (Good)

Total time spent: about 15 minutes. No developer needed. No code changed. Sarah's site went from failing Core Web Vitals to passing them, which improved her local search rankings over the following weeks.

Quick Checklist

Use this to verify your site is properly configured:

• [ ] HTML pages return a Content-Encoding: gzip or br header
• [ ] CSS files return a Content-Encoding: gzip or br header
• [ ] JavaScript files return a Content-Encoding: gzip or br header
• [ ] Images have Cache-Control headers with max-age of at least 30 days
• [ ] CSS and JS files have Cache-Control headers with max-age of at least 7 days
• [ ] Fonts have Cache-Control headers with max-age of at least 30 days
• [ ] HTML pages have short or no cache duration
• [ ] Google PageSpeed Insights does not flag caching or compression issues

Common Mistakes to Avoid

Setting cache times too short. If your images have max-age=3600 (one hour), browsers re-download them on every visit beyond an hour. Static assets should be cached for weeks or months.

Forgetting about third-party scripts. Your analytics, chat widget, and social media embed scripts have their own caching policies that you cannot control. These are often the slowest files on your page. Minimize the number of third-party scripts you load.

Not testing after changes. After enabling caching and compression, run another speed test. Misconfigurations can make things worse — for example, double-compressing files or caching dynamic pages like shopping carts.

Caching authenticated pages. If your site has a login area, customer dashboard, or shopping cart, make sure those pages are excluded from caching. Otherwise, one customer might see another customer's data.

What to Do Next

If you have not checked your site's caching and compression setup, now is the time. It takes five minutes to find out and often less than an hour to fix.

Run a free audit on FreeSiteAudit to see exactly which files are missing caching headers and where compression is not enabled. The report tells you what is working, what is not, and what to fix first.

These are not glamorous changes. Nobody will notice you enabled Gzip or added cache headers. But your visitors will notice that your site loads faster, Google will notice your improved Core Web Vitals, and you will notice when your bounce rate drops and your speed scores improve.

The easiest speed wins are hiding in your server configuration. Go get them.

Sources

• Web Vitals — web.dev
• Leverage Browser Caching — Google Developers
• Creating Helpful Content — Google Search Central
• HTTP Archive — State of the Web