Website Performance: Beyond Lighthouse Scores

Lighthouse gives you a score. Users experience reality. The gap between them can be significant.

Real-world performance depends on factors that synthetic tests don’t fully capture: server response time, network latency, compression efficiency, and protocol optimization. These are the fundamentals that determine whether your site feels fast or slow.

What Users Actually Experience

When a user loads your page, they experience:

DNS lookup: Translating your domain to an IP address
TCP connection: Establishing a connection to your server
TLS handshake: Negotiating encryption (for HTTPS)
Time to First Byte (TTFB): Waiting for the server to respond
Content download: Receiving HTML, CSS, JS, images
Parsing and rendering: Browser processing

Steps 1-4 happen before any content appears. Optimizing these “connection” phases often matters more than shaving kilobytes off your JavaScript bundle.

Time to First Byte (TTFB)

TTFB measures how long until the first byte of the response arrives. It includes:

Server processing time
Network latency
SSL/TLS overhead

What’s a Good TTFB?

Under 200ms: Excellent
200-500ms: Good
500-1000ms: Needs improvement
Over 1000ms: Poor

Causes of Slow TTFB

Slow database queries: Unoptimized queries or missing indexes
No caching: Regenerating pages on every request
Overloaded servers: Not enough capacity
Geographic distance: Server far from users
Slow third-party services: Waiting on external APIs

Fixing TTFB

Cache rendered pages (Redis, Varnish, CDN)
Optimize database queries
Use a CDN to reduce geographic latency
Scale server resources if CPU/memory bound
Profile server-side code for bottlenecks

HTTP/2 and HTTP/3

HTTP/2 significantly improves performance over HTTP/1.1:

HTTP/1.1 Limitations

One request per connection: Browsers open 6 connections per domain
Head-of-line blocking: Slow responses block fast ones
Uncompressed headers: Repeated headers waste bandwidth

HTTP/2 Benefits

Multiplexing: Multiple requests over one connection
Header compression: HPACK reduces header overhead
Server push: Send resources before they’re requested
Stream prioritization: Important resources first

Most hosts support HTTP/2 by default. Check yours with our Performance Checker.

HTTP/3 (QUIC)

HTTP/3 uses UDP instead of TCP:

Faster connection establishment
Better handling of packet loss
Improved mobile performance

HTTP/3 is increasingly common but requires specific server support.

Compression

Compression reduces the size of text resources (HTML, CSS, JavaScript, JSON) dramatically.

Gzip vs Brotli

Algorithm	Compression	Browser Support	CPU Cost
Gzip	Good	Universal	Low
Brotli	Better (15-25% smaller)	Modern browsers	Higher

Brotli produces smaller files but takes more CPU to compress. For static files, pre-compress with Brotli. For dynamic content, Gzip might be more efficient.

What Should Be Compressed

HTML documents
CSS stylesheets
JavaScript files
JSON API responses
SVG images

What Shouldn’t Be Compressed

Already compressed formats (JPEG, PNG, WebP, MP4, WOFF2)
Very small files (overhead exceeds benefit)

Checking Compression

Look for the Content-Encoding response header:

Content-Encoding: br      # Brotli
Content-Encoding: gzip    # Gzip

Our Performance Checker verifies compression for any URL.

Caching Headers

Proper caching prevents browsers from re-downloading unchanged resources.

Cache-Control Header

Cache-Control: public, max-age=31536000, immutable

public: Can be cached by CDNs and browsers
max-age: Seconds to cache (31536000 = 1 year)
immutable: Won’t change even on refresh

Caching Strategies

Versioned assets (CSS, JS with hash in filename):

Cache-Control: public, max-age=31536000, immutable

HTML pages:

Cache-Control: no-cache

(Validate with server on each request)

API responses:

Cache-Control: private, max-age=60

(User-specific, cache briefly)

ETag and Last-Modified

For resources that might change, use validation headers:

ETag: "abc123"
Last-Modified: Wed, 08 Feb 2026 12:00:00 GMT

Browsers send If-None-Match or If-Modified-Since on subsequent requests. If unchanged, the server returns 304 Not Modified without the body.

CDN Benefits

A Content Delivery Network (CDN) caches your content on servers worldwide:

Reduced latency: Content served from nearby servers
Decreased origin load: Most requests never reach your server
DDoS protection: Distributed infrastructure absorbs attacks
Automatic optimization: Many CDNs offer compression, HTTP/2, image optimization

Popular CDNs: Cloudflare, Fastly, AWS CloudFront, Vercel Edge Network.

Measuring Performance

Lab Data (Synthetic)

Tools like Lighthouse run in controlled environments:

Consistent conditions
Reproducible results
May not reflect real users

Field Data (Real User Monitoring)

Data from actual users:

Reflects real-world conditions
Varies by device, network, location
Requires implementation (Google Analytics, custom RUM)

Core Web Vitals

Google’s key metrics:

LCP (Largest Contentful Paint): Main content visible
FID/INP (Interaction to Next Paint): Responsiveness
CLS (Cumulative Layout Shift): Visual stability

These are ranking factors and appear in Search Console.

Server-Side Optimization

Before optimizing the frontend, ensure your server is fast:

Check Your TTFB

If TTFB is over 500ms, fix that first. No amount of frontend optimization compensates for a slow server.

Enable Compression

Verify Gzip or Brotli is working. Check with:

curl -I -H "Accept-Encoding: gzip, br" https://example.com

Look for Content-Encoding in the response.

Verify HTTP/2

Most modern hosting includes HTTP/2. Check with browser dev tools (Network tab, Protocol column) or our Performance Checker.

Configure Caching

Set appropriate Cache-Control headers for different resource types.

Our Performance Checker

Our Performance Checker analyzes the server-side factors that affect performance:

HTTP/2 support: Is your server using modern protocols?
Compression: Is Gzip or Brotli enabled?
TTFB: How fast does your server respond?
Caching headers: Are resources cacheable?

It’s a quick way to identify server configuration issues that affect real-world performance.

Optimization Priority

Fix issues in this order:

TTFB: Get under 500ms
HTTP/2: Enable if not already active
Compression: Enable Gzip or Brotli
Caching: Configure appropriate headers
CDN: Add one for static assets
Frontend optimization: Code splitting, image optimization, etc.

Take Action

Run your site through our Performance Checker
Address any server configuration issues
Verify improvements in real user data

For help with performance optimization or server configuration, get in touch.