WebsiteSettings

Website Speed Settings

Updated 26 September 2026 · 5 min read

Website speed is mostly physics and extras: bytes on the wire, round trips, and JavaScript that blocks the first paint. You do not need a mythology of “performance culture” to make a small business site feel usable on a phone. This guide covers caching headers, compression (gzip and Brotli), image formats and sizes, lazy loading, fonts, fewer scripts, and measuring with free tools. Change one thing at a time. Examples use example.com.

Measure with free tools, then repeat

Pick the homepage and one inner page. Test on a phone-sized profile and on a desktop profile. Browser developer tools (Network panel) show each file’s size, status, and whether it was cached. Free lab tools from browser vendors and other public testers can add a score; treat scores as hints, not a grade for your business.

Write down: largest files, any request that waits on another, and how the page feels. Then change settings, purge caches, and test again on the same URLs. If you cannot see a difference, revert. Speed work that breaks a form is a net loss.

Test over HTTPS, because that is what visitors use. TLS is rarely the main delay next to a 3 MB image. Certificate setup is covered in HTTPS and SSL certificates.

Caching headers

Caching headers tell browsers and CDNs whether they can reuse a file. HTML you edit often should be revalidated quickly. Versioned assets (app.3f2c.css) can be cached for a long time.

# Example intent, not a copy-paste for every server
# HTML: short cache
Cache-Control: max-age=0, must-revalidate

# Fingerprinted CSS/JS/images: long cache
Cache-Control: public, max-age=31536000, immutable

If HTML is cached for a week in the browser, customers will see yesterday’s hours after you change them. If CSS has no fingerprint and a long max-age, they will see a broken layout after a redesign until they hard-refresh. Match header policy to how you deploy.

CDNs add another layer. Know how to purge. Redirects should land on the final URL in one hop so you do not cache a chain; see 301 vs 302 redirects.

Compression: gzip and Brotli

Text files (HTML, CSS, JS, SVG, JSON) shrink well with compression. gzip is widely supported. Brotli often compresses text even smaller and is common on modern browsers over HTTPS. Images that are already JPEG, PNG, WebP, or AVIF usually should not be gzipped again; they are already compressed, and double wrapping wastes CPU.

Enable compression at the server or CDN. Confirm in the Network panel that Content-Encoding is gzip or br for HTML and CSS. If you see uncompressed 400 KB of JavaScript, turn compression on before you buy anything else.

Do not minify so aggressively that you break scripts, then add more scripts to fix them. Minification is a small gain next to compression and next to deleting the script.

Images: format and size

Serve images at the size they display. A 4000-pixel photo in a 400-pixel column is the usual own-goal. Resize before upload or in a build step. Use srcset when you have several widths, so phones do not download the desktop file.

Format rules of thumb:

  • Photographs: JPEG or WebP (or AVIF where you can provide fallbacks).
  • Graphics with few colors or transparency: SVG or PNG.
  • Avoid PNG for large photos.
  • Do not animate a huge GIF when a short video or a static frame would do.

Compression quality is a visual judgment. If text in the image goes muddy, you overdid it — or that text should have been HTML. Decorative images can be smaller than product photos a customer must inspect.

Lazy loading

Lazy loading defers off-screen images until they approach the viewport. Native loading="lazy" on <img> is enough for many sites. Keep the Largest Contentful Paint image (usually the hero) eager, or the first screen waits for a scroll that has not happened.

<img src="/hero.jpg" width="1200" height="600" alt="Shop interior">
<img src="/later.jpg" width="800" height="500" alt="" loading="lazy">

Width and height (or CSS aspect-ratio) reduce layout jump. Lazy-loading background images in CSS is harder; prefer real img tags for content photos. Do not stack two lazy-load libraries.

Fonts

Every font weight is a file. Four families times four weights is a slow first text paint. Use two weights if you can, subset if you know how, and font-display: swap so text stays visible while the webfont arrives. Hosting font files you have a license to host can remove a DNS lookup to a third party; that is a legal/licensing choice as much as a speed choice.

System font stacks (the fonts already on the device) are the fastest option for admin screens and some brochure sites. If brand type matters, still limit weights. Avoid putting paragraph text in an image to “keep the font.”

Fewer scripts

JavaScript is the usual reason a page looks loaded but does not respond. Inventory tags: analytics, chat, heatmaps, three social widgets, a page builder runtime, a slider. Each may inject more files. Remove anything you do not read reports from or staff as a real inbox.

Load remaining scripts with defer unless they must run before parse (rare). Put analytics after you have a question it will answer. Chat widgets that download a megabyte for a business that answers email once a day are not speed settings; they are product decisions.

Third-party embeds (maps, videos) should not all start on page load if a static image plus a link would do until click. That pattern is often called facade loading; even a simple “click to load map” helps.

HTML size itself matters. A page builder that emits nested wrappers will dwarf a hand-written article. If the CMS lets you, prefer simpler blocks. Extra CSS frameworks you barely use still download.

A practical order of work

  1. Measure two URLs; note the largest bytes.
  2. Resize and recompress images; fix the hero.
  3. Turn on gzip/Brotli for text.
  4. Set caching headers that match how you deploy.
  5. Remove unused scripts and extra fonts.
  6. Lazy-load below-the-fold images only.
  7. Then consider a CDN if your visitors are far from the server.

Host-level page cache for dynamic sites is a related topic; it is not a header you paste into HTML. After each step, confirm forms and checkout still work. If you publish a sitemap of huge media URLs, crawlers will fetch them too; keep robots.txt and XML sitemaps honest so you are not inviting extra load for junk URLs.

Checklist

  • Before/after notes on the same two URLs.
  • Images sized to display width; hero not lazy-loaded.
  • Text compressed; images not double-compressed as gzip.
  • HTML cached briefly; fingerprinted assets cached longer.
  • Font weights cut; scripts you cannot justify removed.
  • No speed change that breaks a form.

Do the image pass this week. It is the change visitors feel even when a score barely moves.

Related guides


General technical information; test changes carefully and keep backups of your settings.