How to Test Website Speed: TTFB, Core Web Vitals, and Practical Fixes

A website that feels fast on its owner’s computer can still be slow for customers. Local caching, strong Wi-Fi, a modern device, and proximity to the server hide problems that become obvious on mobile networks and low-powered phones. A reliable assessment therefore examines several layers: server response, transferred files, main-content rendering, interaction responsiveness, visual stability, and real-user experience.

Start with the free website speed audit. BB STUDIO’s tool checks DNS, connection, TLS, TTFB, HTML weight, compression, caching, and resource composition. It provides a quick server-side diagnosis before deeper browser profiling.

Speed is not one number

“The site loaded in three seconds” is incomplete without context. A visitor experiences a sequence:

1. the browser resolves the domain;

2. it creates a connection and negotiates HTTPS;

3. it waits for the first HTML byte;

4. it downloads styles, fonts, scripts, and images;

5. it renders the largest visible element;

6. it responds to taps and clicks;

7. it keeps the layout stable.

A fast server can still deliver a huge hero image. A page may appear ready while its menu freezes under JavaScript work. It can render in one second and then move a button when a banner appears. Different metrics describe these different failures.

Essential performance metrics

Core Web Vitals thresholds use the 75th percentile of field visits and are assessed separately for mobile and desktop. One fast run on a powerful machine cannot represent the majority of visitors.

Understanding TTFB

Time to First Byte runs from navigation start until the first response byte arrives. It can include redirects, service-worker startup, DNS, connection and TLS negotiation, and backend processing.

Because TTFB comes before meaningful rendering, a slow response shifts the entire loading sequence. It is not, however, a Core Web Vital or a complete speed score. A fast HTML response may be followed by megabytes of client-side code, while a server-rendered page with a slightly higher TTFB can still show useful content sooner.

Interpreting TTFB

• below 0.2 s is an exceptionally quick response in favourable conditions;

• 0.2–0.8 s is a practical range to assess with location and architecture;

• 0.8–1.8 s deserves investigation;

• above 1.8 s materially restricts loading performance.

These are diagnostic ranges rather than promises. Repeat tests, compare regions, and distinguish cold from warm caches.

A repeatable testing method

Test representative pages

Do not stop at the homepage. Include a major service page, ecommerce category, product detail, article, contact page with a map, and authenticated area where relevant.

Run a series

The first request may hit a cold cache while the second receives generated output. The difference exposes cache dependence. Compare the median rather than selecting the best score.

Separate mobile and desktop

Mobile tests throttle network and processing power, so they normally score lower. This is useful: weaker devices expose expensive scripts, excessive DOM size, and oversized resources.

Separate laboratory and field data

Lab tests reproduce a controlled scenario and help identify causes. Field data shows what real visitors experienced. When they conflict, examine time windows, locations, device classes, page groups, and sample size.

Record a baseline

Save URLs, date, device, region, metrics, and release version. Repeat the same scenario after changes. Without a baseline, network and cache variance can be mistaken for improvement.

LCP: rendering the main content

Largest Contentful Paint is usually a hero image, banner, large heading, or prominent text block. A good LCP does not mean everything has downloaded; it means the visitor saw the primary element promptly.

LCP consists of server delay, resource discovery delay, transfer duration, and render delay. A hero image inserted late by JavaScript or hidden in CSS may be discovered too slowly. Critical media should use appropriate HTML, responsive sources, correct priority, and no lazy loading above the fold.

INP: responding to users

Interaction to Next Paint measures click, tap, and keyboard latency throughout a visit. Poor INP commonly appears when the main thread is occupied by long JavaScript tasks.

Frequent sources include large bundles, multiple animation libraries, complex product filters, repeated large-DOM rendering, chat widgets, trackers, and handlers performing unnecessary synchronous work. Diagnose actual interactions, split long tasks, load non-critical modules later, and reduce the work triggered by each action.

CLS: keeping the layout stable

Cumulative Layout Shift captures unexpected movement. Common causes include images and iframes without dimensions, banners inserted above existing content, font swaps that change text size, recommendations without reserved space, and cookie notices that push the whole page.

Reserve space with dimensions or aspect-ratio, use carefully matched fallback fonts, and avoid injecting content above the user’s current position without an explicit action.

Images: the most common opportunity

Images often account for most transferred bytes. Compression alone is incomplete; review format, intrinsic dimensions, responsive sources, lazy loading, above-the-fold priority, and transparency.

Use the image SEO checker to identify missing alt text, excessive weight, unsuitable formats, and loading issues. Individual files can be processed with the WebP image converter, which performs conversion locally in the browser.

A practical sequence:

1. crop to the intended aspect ratio;

2. generate widths for different screens;

3. use WebP or AVIF for photography and SVG for vectors;

4. select quality without visible artefacts;

5. configure srcset and sizes;

6. do not lazy-load the LCP image;

7. set width, height, or aspect-ratio.

Caching and compression

Caching exists at several layers. The browser stores static assets, the server can store generated HTML, a CDN keeps copies closer to visitors, and object caching stores database results.

Do not apply one long lifetime to everything. Versioned CSS, JavaScript, and images can be cached aggressively, while HTML and personalised data require more conservative rules. Updated assets need a new URL or content hash to prevent stale versions.

Gzip and Brotli reduce text resources such as HTML, CSS, JavaScript, JSON, and SVG. Already compressed JPEG, WebP, and video gain little from another compression pass. Verify response headers, not only a plugin’s enabled switch.

Hosting and backend work

When TTFB is high, investigate the backend. Causes include constrained hosting, a distant data centre, slow storage, an old runtime, inefficient database queries, blocking external APIs, and missing page cache.

Good website hosting matters, but migration cannot automatically repair inefficient application code. Before moving, capture backend time, slow queries, resource use, caching, and external dependencies; then repeat identical tests after migration.

For dynamic platforms, inspect slow SQL, autoloaded settings, scheduled jobs, blocking APIs, page and object cache, background queues, error logs, and peak-load behaviour.

CSS, JavaScript, and fonts

The first screen needs critical styles quickly; less important CSS can arrive later. Blindly combining every stylesheet may create one oversized file and break cascade order, so validate each template visually.

For JavaScript:

• use defer where scripts do not need to block HTML parsing;

• load widgets after consent or interaction;

• split bundles by route and feature;

• remove unused libraries;

• avoid duplicate trackers, sliders, and frameworks;

• profile long tasks instead of guessing.

For fonts, keep only required families and weights, use WOFF2, preload only truly critical resources, and set an appropriate font-display strategy. Excessive preload can compete with the hero image and worsen LCP.

WordPress and WooCommerce

There is no universally fastest plugin combination. Performance depends on the theme, builder, hosting, catalogue, and integrations. A safe process is to create backups and staging, identify slow queries and plugins, configure page and object caching, optimise images and fonts, remove unused builder modules, defer marketing widgets, and retest checkout and multilingual behaviour.

Cart, checkout, and account pages usually cannot be cached like public static pages. For ecommerce, test categories, product galleries, variations, search, filters, and stock synchronisation—not just the homepage.

Lab versus field results

Laboratory data asks what happens in one controlled run now. Field data asks what real users experienced over time. The values can differ because of region, provider, hardware, cache state, login state, page mix, behaviour, seasonal load, and limited URL-level samples.

Do not chase a perfect score at the expense of useful functionality. Google explains that page experience includes several aspects and that a perfect report cannot guarantee top rankings. Within search engine optimisation, performance is an important technical foundation, while relevance, content, architecture, and authority remain essential.

Prioritising fixes

Sort recommendations by expected impact, affected traffic, implementation risk, and cost.

First address server failures, very high TTFB, multi-megabyte LCP assets, missing text compression, global render-blocking scripts, major button and form shifts, and frozen navigation or checkout.

Then improve cache policy, font loading, deferred third parties, unused CSS and JavaScript, and slow category or product templates. Leave small savings on rarely visited pages until they justify their engineering cost.

Measuring business impact

Speed removes friction rather than creating demand by itself. Monitor landing-page exits, form and checkout completion, mobile conversion, revenue per session, interaction errors, organic entry pages, crawl behaviour, and support contacts caused by technical failures.

Compare equivalent segments after release and account for source mix, seasonality, pricing, design changes, and campaigns. Do not attribute every improvement to performance when several variables changed together.

When professional help is appropriate

Compressing images or disabling an unused widget is relatively safe. Checkout caching, database work, infrastructure migration, critical CSS, and bundle changes require staging, monitoring, and rollback plans.

Ongoing website support is appropriate when regressions return after updates, the issue affects revenue, or several layers are involved. If architecture and templates impose permanent overhead, controlled website development may be more efficient than repeatedly treating symptoms.

Post-optimisation checklist

• representative templates have been retested;

• cold and warm cache results are compared;

• mobile and desktop journeys work correctly;

• forms, cart, payment, and accounts remain functional;

• Cache-Control and Content-Encoding headers are correct;

• the LCP element is discovered and loaded early;

• images use suitable formats, dimensions, and srcset;

• third parties do not block the first screen;

• fonts do not hide or shift text;

• field analytics and Search Console are monitored;

• backup and rollback procedures are available.

Cost of performance work

Cost depends on the cause, not the current score. Image conversion and baseline caching may be a small task. Rebuilding filters, restructuring a theme, migrating infrastructure, or optimising a large database is a separate engineering project.

If poor performance reflects a weak foundation and a new platform is under consideration, the guide to website costs in 2026 explains the main budget variables. Accurate estimation requires URLs, analytics, technology stack, hosting details, integrations, and profiling results.

Conclusion

Reliable speed work begins with diagnosis rather than installing a random plugin. Identify whether delay comes from the network, server, HTML, media, blocking code, or interaction. Test representative pages, combine lab and field evidence, prioritise by impact, and measure business outcomes after release.

For a technical audit and a safe optimisation plan, contact BB STUDIO.