Why is my website slow? The honest answer is that a page is rarely slow for just one reason. Most small business sites lose time in a few predictable places: the server takes too long to send the first bytes of HTML, the main image is far larger than it needs to be, the browser discovers that image late because JavaScript or CSS has to load first, or render-blocking files hold everything back. The fix starts with measuring real visitor data in PageSpeed Insights, finding your Largest Contentful Paint element, and then working through each delay in order.
This guide walks through that process in plain language. It is written for owners who manage their own site and for small agencies who have to explain speed problems to clients without drowning them in jargon. One warning before you start: a single lab score is a starting point, not a verdict. We made the same argument about accessibility in why a Lighthouse accessibility score of 100 is not WCAG compliance, and it applies just as much to speed: the number that matters is what real visitors experience.
What does a slow website actually mean?
Speed feels subjective, but Google has spent years turning it into something you can measure. Its Web Vitals initiative exists so that site owners do not have to be performance experts to understand the experience they deliver. The core of that initiative is a small set of metrics called the Core Web Vitals, which apply to every web page and show up across Google's tools.
When people say a site is slow, they usually mean one of three things. The main content takes too long to appear, the page feels sluggish when they tap or click, or the layout jumps around while it loads. Each of those has its own metric, and each has its own fixes.
What are the three Core Web Vitals?
According to web.dev, the current set focuses on loading, interactivity and visual stability. Largest Contentful Paint (LCP) measures loading, and a good experience means LCP happens within 2.5 seconds of the page starting to load. Interaction to Next Paint (INP) measures interactivity, and pages should have an INP of 200 milliseconds or less. Cumulative Layout Shift (CLS) measures visual stability, and pages should keep CLS at 0.1 or less.
These metrics do change over time. INP was developed as an experimental metric to cover runtime performance problems more fully than the older First Input Delay, was promoted to pending status in 2023, and became a stable Core Web Vital in 2024, replacing First Input Delay. If you read an older article that talks about FID, it is out of date.
For most small business sites, LCP is where the biggest and most visible problem lives, so most of this guide focuses on it. LCP measures the time from when a visitor starts loading the page until the largest image or text block in the visible area is rendered, as the web.dev LCP guide explains. On a typical service business homepage, that element is often the hero photo or the big headline at the top.
Why does Google judge speed at the 75th percentile?
Google does not judge your site by its best day. Web.dev recommends measuring at the 75th percentile of page loads, split between mobile and desktop. In practice, that means you want at least 75% of visits to hit the good threshold. A page is treated as passing when it meets the targets at the 75th percentile for all three metrics.
This matters for small businesses because your own experience is misleading. You probably load your site on a fast office connection with a warm cache. Many of your customers arrive on a phone, on a weaker network, seeing your homepage for the first time. The web.dev LCP guide notes that home pages tend to be visited by new users, are often loaded cold without cached content, and are often the slowest pages on a website.
How do I run a website speed test the right way?
The most common mistake is running one lab test, seeing a red score, and panicking. A good website speed test separates what real visitors experience from what a simulated test shows.
What is the difference between field data and lab data?
Field data comes from real people using your site. The Chrome User Experience Report (CrUX) collects anonymized measurements from real Chrome users, and it powers the real user sections of Chrome DevTools, PageSpeed Insights and the Core Web Vitals report in Search Console, according to web.dev.
Lab data comes from a tool like Lighthouse loading your page under set conditions. The web.dev LCP guide is clear that lab tools give a wealth of information to explain and improve LCP, but lab tests alone may not represent what your actual users experience. When Lighthouse and CrUX disagree, CrUX likely gives the more accurate picture.
The practical rule is simple. Use field data to decide whether you have a problem. Use lab data to figure out why.
How do I read PageSpeed Insights?
PageSpeed Insights has two main areas. The top section, labeled Discover what your real users are experiencing, shows CrUX field data. The bottom section, labeled Diagnose performance issues, shows more detailed lab data from Lighthouse. Web.dev advises that if CrUX data exists for your website, you should always concentrate on the real user data first.
PageSpeed Insights can show up to four views of field data: mobile and desktop for the specific URL, and mobile and desktop for your whole origin, which means your entire domain. You can switch between them with the controls at the top of that section. If a single page does not have enough traffic for its own data, the tool shows origin data instead. That is useful, but be careful: the origin LCP can be very different from one page's LCP. Comparing the four views tells you whether a problem is specific to one page or affects the whole site, and whether it hits mobile, desktop or both.
In the Lighthouse section, you can filter the audits to show only those relevant to LCP. There is also a diagnostic called Largest Contentful Paint element, which names the element and breaks down the timings that made up your LCP. That single diagnostic is often the best starting point for any slow website fixes.
What if my site has no real user data at all?
Many small sites do not get enough traffic to appear in CrUX. Web.dev suggests supplementing CrUX with real user monitoring (RUM) data collected by JavaScript running on your own pages. Its Web Vitals overview goes further and strongly recommends that sites set up their own real user monitoring, because CrUX does not provide the detailed per-pageview data needed to diagnose and react to regressions quickly. The easiest route it describes is the web-vitals JavaScript library, a small wrapper that measures each metric the same way Google's tools report it. Until you have that data, lab tests are still useful for diagnosis, as long as you treat the numbers as directional.
Why is my website slow? What are the most common causes?
Web.dev offers a helpful way to think about this. For LCP, you start by looking at just two network requests: the initial HTML document and the LCP resource, such as the hero image. The timing of those two requests reveals whether your page is set up well for LCP. Almost every slowdown fits into one of four parts of that process.
Is my server or hosting the problem?
The first part is Time to First Byte (TTFB), the time from when a visitor starts navigating to your page until the first bytes of HTML arrive. The web.dev LCP guide warns that a high TTFB can make a 2.5 second LCP challenging or even impossible. It lists several causes: multiple server redirects, visitors located far from the nearest server, visitors on poor network conditions, and an inability to use cached content because of query parameters. The MDN article on image LCP adds incorrect cache headers and an unoptimized cache strategy to the list.
If your TTFB is high, no amount of image work will fully rescue the page. That is the point where you look at redirects, caching and where your server sits relative to your customers.
Are my images too big?
An article on the MDN blog about image LCP notes that images make up a big part of most websites and are often the largest element on screen, which makes them the LCP element. The resource download time is what most people picture when they think of a slow loading image, and it gets worse when the image is large and unoptimized, or when off-screen images and other non-critical files download at the same time and compete for the network.
The examples in that article are striking. One LCP image was 1MB and took about 3 seconds to download in a throttled lab test. Converted to AVIF at 80% quality, it shrank by 95% to a 46KB file. In another example from the same article, a page served a 2.26MB image at 1920 by 1080 pixels even on a mobile viewport. Photos uploaded straight from a camera or a stock site are the classic small business version of this problem. We see it in our own scans too: across more than 300 web agency front pages in our research papers, about 7% carried an oversized image, and that is a segment whose whole business is building websites.
Is JavaScript delaying my main content?
The second part of LCP is resource load delay, which is how long it takes the browser to discover your main image and start requesting it. MDN explains that this is slow when the image sits in a request chain, when it is lazy loaded, or when it is inserted into the page by JavaScript, even JavaScript placed directly in the HTML, because the browser has to parse and run that script before it can find the image.
A request chain happens when one file has to load before the next one can start. If JavaScript loads your hero image, the browser has to download the HTML, download the JavaScript, run it, and only then start downloading the image. MDN points out that the cost of running JavaScript is often worse on low-end devices, which is exactly what many of your mobile visitors use.
Web.dev offers a quick diagnostic here. A large gap between First Contentful Paint (FCP) and LCP suggests the LCP resource was not immediately available to the browser, for example because it is managed by JavaScript rather than present in the initial HTML, or that the browser was busy with other work first.
Are render-blocking files holding the page back?
The final part is element render delay, the gap between the image arriving and actually appearing. MDN lists render-blocking resources that are still downloading, a blocked main thread, and very highly compressed image formats that take longer to decode. Web.dev adds that a large gap between TTFB and FCP can mean the browser has to download a lot of render-blocking files, or that the site leans heavily on client-side rendering.
It is worth knowing that, unlike CSS, image downloads do not block the rest of the page from loading. The image itself is rarely what freezes the page; it is everything the browser has to process around it.
How do I improve website loading speed step by step?
Web.dev makes an important point before you start: it is rare that a quick fix to a single part of a page results in a meaningful improvement to LCP. You need to look at the whole loading process. The steps below follow that process from start to finish.
How do I find my Largest Contentful Paint element?
Open PageSpeed Insights, run your homepage, and check the field data first. Then scroll to the Lighthouse diagnostics and find the Largest Contentful Paint element entry. It tells you which image or text block is your LCP and shows a breakdown of where the time went. Web.dev also mentions Chrome DevTools and WebPageTest as tools that can identify the LCP element. The Performance panel in DevTools can show your local LCP next to CrUX field data, which helps you reproduce what real visitors see.
Write down which of the four parts takes the longest. That tells you where to spend your effort.
How do I shrink and modernize my images?
If download time dominates, start with the image file. MDN recommends modern formats: WebP, which is widely supported and compresses well, and AVIF, a newer format with even better compression. It mentions the Squoosh web app as a way to convert images. Keep browser support in mind, and note that MDN suggests serving different formats so browsers can choose, or configuring your server to pick the right format based on what the browser accepts.
Next, stop sending desktop-sized images to phones. MDN describes responsive images using the srcset and sizes attributes, which give the browser small, medium and large versions to choose from based on screen width. That way, a phone does not waste bandwidth on an image built for a large monitor.
Should I lazy load my hero image?
No, not the image that is your LCP element. Lazy loading delays a download until the image is near or inside the visible area, and MDN lists it as one of the causes of resource load delay. Lazy loading can help for images further down the page, since off-screen images that download early compete for bandwidth with the one that matters most. Just make sure the main image at the top is excluded.
How do I tell the browser what to load first?
To break a request chain, MDN suggests placing the image as a regular image tag directly in the HTML instead of injecting it with JavaScript, or using a preload link in the head of your HTML so the browser starts downloading it as early as possible.
You can also raise the image's priority with the fetchpriority attribute set to high, which tells the browser to download it ahead of competing resources. MDN notes this works with preload too, and is especially useful when the LCP image is a CSS background image that the browser would otherwise discover late, after the CSS has downloaded and been parsed. In one example it describes, preloading the whole request chain for an LCP image and marking it high priority meant the image downloaded much earlier.
How do I cut server response time?
Work through the TTFB causes web.dev and MDN list. Remove unnecessary redirects, especially chains where one redirect leads to another. Check that your cache headers are set correctly so pages and files can be reused. Watch for query parameters that stop cached content from being used. If many of your customers are far from your server, ask your host or developer what options exist to serve content closer to them. These fixes often take the longest to arrange, but they lift every page on the site, not just one.
What about interactivity and layout shifts?
LCP gets most of the attention, but INP and CLS matter too. Web.dev maintains separate guides for optimizing each, plus best practice guides on topics that commonly affect small business sites: fonts, carousels, cookie notices, tags and tag managers, and third-party embeds. If your site runs a homepage slider, several marketing tags and an embedded booking or chat widget, those guides are worth reading before you add anything new.
There is a broader lesson here as well. Small technical shortcuts tend to pile up in more than one area at once. We have written about how small code quality issues quietly break accessibility, and the same habits that bloat a page often hurt its usability for everyone.
Does website speed affect my Google rankings?
Yes, but probably less dramatically than some vendors suggest. Google's Core Web Vitals documentation recommends that site owners achieve good Core Web Vitals for success with Search and for a great user experience generally, and its page experience documentation confirms that Core Web Vitals are used by its ranking systems.
The same page adds important caveats. Good results in Search Console or third-party tools do not mean your pages will rank at the top, because there is more to page experience than Core Web Vitals scores. Google also says that trying to get a perfect score just for SEO reasons may not be the best use of your time. Its systems always seek to show the most relevant content, even if page experience is below par, but when many helpful pages compete for a query, a great page experience can contribute to success.
Google generally evaluates page experience page by page, though it also has some site-wide assessments. Its self-assessment questions go beyond speed: whether pages are served securely, display well on mobile, avoid excessive ads and intrusive interstitials, and make the main content easy to distinguish. If the security side is on your list, our guides to mixed content and TLS mistakes that break HTTPS and HTTP security headers cover what to look at.
How should agencies build a Core Web Vitals checklist for clients?
If you run a small agency, a written Core Web Vitals checklist makes speed work repeatable and easier to explain. A sensible order follows the logic of this guide. Begin by checking field data in PageSpeed Insights for mobile and desktop, at both page and origin level, and note whether the client has enough traffic to appear in CrUX at all. Then identify the LCP element and record which of the four parts is slowest. After that, review server response, redirects and caching, then image format, size and responsiveness, then whether the hero image is lazy loaded, injected by JavaScript, or buried in a request chain. Finish by reviewing third-party tags, embeds, fonts and carousels against the web.dev best practice guides.
Record the field numbers before and after each change, and remember that field data reflects real visits over time, so improvements will not appear instantly. Setting up real user monitoring with the web-vitals library gives you ongoing evidence instead of a single snapshot. If you want more step-by-step material on related problems, our guides library is a good next stop.
How can I check my site for heavy pages and oversized images?
PageSpeed Insights tells you how fast a page is. It does not tell you what else the same page is getting wrong. A free Sitejar scan of up to five pages, no signup needed, flags oversized images and pages that weigh too much as technical quality findings, next to the accessibility, security and privacy problems that tend to come from the same shortcuts. Use it alongside PageSpeed Insights, not instead of it: one measures speed in the field, the other lists the defects in the page you can fix at the source.
Frequently asked questions
How fast should my small business website load?
For the main content, web.dev's target is an LCP of 2.5 seconds or less for at least 75% of page visits, measured separately on mobile and desktop. Interactivity should come in at an INP of 200 milliseconds or less, and layout shifting at a CLS of 0.1 or less. Hitting all three at the 75th percentile is what counts as passing.
Why does PageSpeed Insights show no real user data for my site?
The field data in PageSpeed Insights comes from the Chrome User Experience Report, and pages with too little traffic do not get page-level data. If your origin has enough data, the tool shows that instead. If neither exists, web.dev suggests collecting your own real user data with JavaScript, for example using the web-vitals library.
Will one fix make my website fast?
Usually not. Web.dev states that a quick fix to a single part of a page rarely makes a meaningful difference to LCP. Compressing your hero image helps download time, but if the server is slow or the image is discovered late, LCP stays high. Work through server response, discovery, download and rendering in turn.
Is a perfect PageSpeed score worth chasing?
Google itself says that chasing a perfect score purely for SEO may not be the best use of your time, and that good scores do not promise top rankings. Aim for good Core Web Vitals in real user data, then spend your remaining effort on content, mobile usability and security.
Should I trust Lighthouse or real user data when they disagree?
Web.dev advises that if Lighthouse and CrUX disagree, CrUX likely gives the more accurate picture of your users' experience. Make sure the CrUX data you are looking at is for the page in question rather than the whole origin before acting on it, and use Lighthouse mainly to diagnose causes.
Sources
web.dev: Optimize Largest Contentful Paint
Google Search Central: Understanding Core Web Vitals and Google search results
Google Search Central: Understanding page experience in Google Search results
MDN: Fix your website's Largest Contentful Paint by optimizing image loading
This guide is educational and reflects Sitejar's point of view. It is not professional advice. For your specific situation, consult a qualified professional.