How Fast Should a Business Website Load?
There is no single load-time number that defines a good website. Use Core Web Vitals, real-user evidence and task testing to set practical performance expectations.
Part of our guide: The Complete Guide to Website Speed for Business Owners
A business website should make its main content visible promptly, respond quickly to interactions and avoid disruptive layout movement for most visitors. Rather than relying on one universal load-time claim, use Google’s Core Web Vitals thresholds, real-user data and practical testing of important customer journeys.
For the Core Web Vitals, “good” currently means an LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile of visits. Those measures describe different parts of the experience; none is simply “the whole page loaded”.
Why one load-time target is misleading
A webpage does not arrive all at once. The browser may show a heading, then a photograph, then enable an interactive booking widget. Different tools choose different points to report.
Conditions also vary by device, connection, location, cache state and server load. A fast office laptop on broadband does not represent a customer’s older phone on a mobile connection.
Use a target to create accountability, but define the metric, page and testing conditions alongside it.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Use Core Web Vitals as shared reference points
Largest Contentful Paint measures main content loading
LCP records when the largest relevant image or text block in the viewport is rendered. For many business pages, that could be a hero image or prominent heading.
The good threshold is 2.5 seconds or less. Investigate oversized main images, slow server response, blocking resources and rendering delays when LCP is poor.
Interaction to Next Paint measures responsiveness
INP observes interaction latency across a visit and reports a representative value. The good threshold is 200 milliseconds or less.
A page may look complete while JavaScript work delays a menu or form response. Reduce long tasks and unnecessary client-side processing.
Cumulative Layout Shift measures stability
CLS measures unexpected movement. The good threshold is 0.1 or less.
Set image dimensions, reserve space for embeds and avoid inserting banners above content without warning. A shifting page can cause someone to press the wrong control.
Google’s PageSpeed Insights documentation explains the thresholds, field data and lab diagnostics.
Understand the 75th percentile
Core Web Vitals are assessed at the 75th percentile when enough real-user data exists. In simple terms, at least three quarters of measured visits should meet the good threshold for each metric to pass the assessment.
This avoids optimising only for the fastest visitor or reporting an average that hides difficult experiences. It still does not mean every visit will be identical.
Compare real-user and laboratory results
Field data in PageSpeed Insights comes from the Chrome User Experience Report and covers a rolling 28-day period. It captures real conditions but may be unavailable for pages with insufficient samples.
Lab data uses Lighthouse in a simulated environment. It is useful for debugging and repeatable comparisons, but it represents one modelled visit.
Use field data to understand reported experience and lab data to investigate causes. If they disagree, consider the different period, devices and conditions rather than choosing whichever result looks better.
The complete website speed guide explains how these tools fit into a wider performance process.
Which business pages should you test?
Do not use the homepage as a proxy for everything. Test:
- the most important service or product page;
- a common search landing page;
- the contact, quote or booking journey;
- an article with a featured image;
- a gallery or portfolio;
- pages containing maps, video, chat or other embeds.
Test mobile and desktop. Repeat the same URL several times and record meaningful changes to images, scripts or hosting.
Set targets around customer tasks
A practical target combines technical thresholds with behaviour:
- important information appears without a long blank screen;
- navigation works promptly;
- the page remains readable while loading;
- the form responds and confirms submission;
- content does not move under the pointer;
- the journey works on an ordinary phone.
Ask someone unfamiliar with the site to complete the task. Observe delay and hesitation, then compare their experience with the diagnostics.
What commonly prevents a fast load?
Main images are too large
Serve images close to the displayed size, use appropriate formats and avoid forcing mobile visitors to download a desktop-sized photograph.
The server responds slowly
Hosting, uncached database work and application processing can delay the initial response. Measure before optimising front-end details.
Scripts block the browser
Large bundles and third-party tools can delay rendering or interaction. Remove unused code and load non-essential functionality later where appropriate.
Fonts and styles delay display
Too many font files and blocking styles can slow the first useful render. Use a restrained type system and efficient loading.
Embedded services add uncertainty
Maps, video, review widgets and booking tools may load from other providers. Test their business value and failure behaviour.
Read why is my website so slow? for a diagnostic sequence.
How speed affects search and enquiries
Google uses Core Web Vitals in its ranking systems, but good metrics do not guarantee top positions. Relevance and useful content remain essential. Our article on website speed and Google rankings covers that relationship.
Commercially, delay can interrupt a journey, but avoid claiming that a particular second always causes a fixed sales loss. Your audience, offer and page all matter. Measure actual form completions, suitable enquiries and task success where possible.
See how slow pages can affect sales and enquiries without treating correlation as proof.
Should every page meet exactly the same target?
Use consistent quality expectations, but recognise that pages differ. A text service page and an interactive booking tool have different work to do.
Do not excuse avoidable delay because a page is complex. Instead, define what must be available first, progressively reveal secondary features and test whether the functionality justifies its cost.
A simple performance brief for a supplier
Ask the supplier to:
- name representative URLs;
- record field data where available;
- run repeatable mobile and desktop lab tests;
- explain major bottlenecks in plain language;
- propose changes and likely trade-offs;
- retest under comparable conditions;
- verify forms and important tasks manually;
- monitor after launch.
Avoid guarantees of a permanent score. Content, third-party services and test conditions change.
How to compare performance before and after a redesign
Use the same URLs or equivalent page types, the same test tool and comparable conditions. Include the real photographs, fonts, consent tools and integrations required at launch. A stripped-down preview will naturally appear faster than the finished service.
Record several runs and describe the median or stable range rather than selecting the best result. Keep screenshots or exported reports with the date and test environment.
After launch, wait for enough field data before treating the 28-day real-user report as a verdict. In the meantime, use lab diagnostics, server monitoring and manual task tests to catch immediate faults.
Compare business outcomes cautiously. A new website may launch alongside a campaign, seasonal change or revised offer. Those changes make it difficult to attribute every difference in enquiries to speed alone.
What should appear first?
Prioritise the content that helps visitors decide whether they are in the right place: the service, audience, location and next step. A decorative background video or review widget should not block that information.
Progressive loading can be useful when secondary media and tools arrive after the core page. It must not hide essential content or leave controls changing position. Test the order on a slow connection and with JavaScript delayed, where practical.
The page should be understandable and usable while the remaining assets load.
Frequently asked questions
Should a website load in under two seconds?
It is a useful ambition for prompt visible content, but “load” must be defined. Use the current LCP threshold of 2.5 seconds alongside responsiveness and stability rather than applying one slogan to every page.
Is 90 a good PageSpeed score?
Google labels a Lighthouse performance score of 90 or above as good, but that laboratory score is not the same as passing real-user Core Web Vitals. Use its diagnostics and field section separately.
Why does the result change between tests?
Network, server, location and test variation can affect results. Repeat tests and focus on persistent patterns rather than one run.
Does a faster site guarantee more sales?
No. Speed removes friction, but the offer, content, trust and contact process still determine whether someone enquires or buys.
Aim for a reliably fast customer journey
A useful speed target describes real experience across loading, interaction and stability. Measure important pages, understand the data source and prioritise changes that help customers complete their task.
If the current implementation repeatedly prevents improvement, Afterworks can prepare a lightweight replacement for you to inspect. Explore website rebuilds or contact us to discuss your performance findings.
