You tap your own link on your phone and wait. The screen stays white, then half a page appears, then the whole thing jumps as a banner drops in. Maybe a customer mentioned it, or an agency sent you a red score with a quote attached. Now you are wondering whether a website slow to load is costing you calls, and whether the fix is a plugin, a new host or a whole new site. You can answer the first question yourself, for free, in about fifteen minutes. That measurement often points to one or two specific problems, and they are usually smaller jobs than the quote in your inbox suggests. Once you know which kind of slow you have, you can decide what to fix first and what to leave alone.
Key Takeaways
Test your most important page on mobile in PageSpeed Insights and note whether it shows real-visitor data before you pay for hosting, plugins or a rebuild.
Main content visible in 2.5 seconds or less (LCP), taps answered in 200 milliseconds or less (INP), and layout movement of 0.1 or less (CLS), for at least 75% of visits.
The test tells you which element is the Largest Contentful Paint. When it is an oversized hero image, resizing it is a small maintenance job.
Hosting is worth a look only when repeated tests show slow server response. It cannot make a heavy image or a blocking widget disappear.
Google says Core Web Vitals are used in ranking, but good results do not guarantee top rankings, so judge any fix by real visits and inquiries.
Know in Fifteen Minutes Whether Your Website Is Actually Slow
The quickest website slow check uses two free Google tools and your own phone. You do not need a developer, and you do not need to understand code. The goal is a short written baseline: three numbers, one named element and a list of the extra tools running on the page. That list is what you hand to anyone you hire, and it is what they should measure their work against.
Test your most important page on mobile
Open PageSpeed Insights and enter your home page. Make sure the Mobile tab is selected, since that is how anyone checking you on a phone will meet you. Then run it again on one page that brings in business, such as your contact, booking, service or product page.
The report has two parts. The top section, when it appears, is field data: real visits from Chrome users over the previous 28 days. The lower section is a lab test, one controlled load of the page run by Lighthouse. Field data tells you what customers lived through. The lab test is best for finding causes.
If the top section says there is not enough data, that is common for a smaller site. It does not mean your site is fast or slow. It only means Chrome has not collected enough qualifying visits to report on, so the lab test becomes your main guide.
Read the three numbers in plain words
Google publishes a "good" threshold for each of its three Core Web Vitals on web.dev. Each one describes something your visitor feels.
| Metric | What the visitor feels | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | The main thing on the screen shows up | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | The page reacts when they tap | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | The page stays still while they read and tap | 0.1 or less | Over 0.25 |
Anything between good and poor is labeled "needs improvement." Google measures each metric at the 75th percentile, which means at least three out of four visits should meet the good mark. A green result is a strong sign, but some visits can still be slow. The full definitions are on web.dev for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
The big 0 to 100 score at the top of the lab section is a Lighthouse assessment of one test. It is useful for spotting problems, but it is not a Google ranking score, and it is not what your customers experienced.
Find the element holding the page up
Scroll through the lab diagnostics until you find the Largest Contentful Paint element. The report names it, often with a small thumbnail. On a small business site it is usually the big hero image at the top, or a block of headline text.
If it is an image, check two things. Is the original file much larger than the size it shows on screen? And is it set to load lazily, meaning it waits until other things load first? Either one can slow down the moment your page looks ready.
Next, look at the page itself and list every third-party tool on it: chat, reviews, maps, scheduling, video, social feeds, tracking pixels and tag managers. Count them by what they do, not by how many boxes you see. Repeat the whole check on your money page.
Check the pattern in Search Console
If you have Google Search Console set up, open its Core Web Vitals report. It groups your pages by mobile and desktop and shows which groups are good, need improvement or are poor, based on real use over the same 28-day window. This separates a problem on one page from a problem across a whole template, which matters a great deal when you decide what to fix.
This check gives you evidence, not a diagnosis of everything. It will not show every server problem, and a single score should never be the reason you rebuild a site.
Put a Name to the Kind of Slow You Are Seeing
"My website is slow" can mean three different things, and each has a different fix. You might call it lag, taking forever or freezing, and any of those words is fair. The useful step is matching what you see to one of the three numbers.
If the screen sits blank or half built for a long time, that is loading, and LCP measures it. If the page looks ready but nothing happens when you tap a button or open a menu, that is responsiveness, and INP measures it. If text or buttons move while you are reading, so you tap the wrong thing, that is layout shift, and CLS measures it.
Testing on your office Wi-Fi with a desktop computer can hide all three. Your visitors are often on an ordinary phone with an ordinary connection, and the mobile test is the closer match to their day.
Find the Usual Cause Before You Pay for a Fix
There is no authoritative study that ranks what slows down small business sites by how often it happens, so any exact "top ten" is guesswork. What web.dev documents, and what HTTP Archive's page-weight data supports, is a practical order worth checking. Your own test may put these in a different order, especially on a store or booking site.
- Oversized visible images: A hero photo uploaded straight from a camera or phone, far larger than the space it fills, or a visible image set to load lazily. Google's guide to image performance covers why this is the first thing to check.
- Piled-up scripts: Code added by themes, plugins, page builders and tag managers. JavaScript costs more than its file size, because the phone has to process it as well as download it.
- Third-party embeds: Chat windows, review widgets, video players, maps and social feeds, each loading code from someone else's server. Google explains the cost in its guide to third-party JavaScript.
- Slow server response: The host takes a long time to send the first byte, often because pages are built fresh on every visit with no caching.
- Fonts and styles that block the page: Several font families and large style files that must load before anything appears.
- Missing size reservations: Images, ads and embeds with no space set aside, so the page jumps when they arrive.
For a sense of scale, HTTP Archive's 2025 page-weight chapter found that the median mobile home page in July 2025 carried 911 KB of images, 632 KB of JavaScript and 122 KB of fonts. Images and JavaScript were the two largest categories.
What nobody can give you is a reliable figure like "this plugin costs two seconds." The real cost depends on the visitor's network, their phone's processor, whether files are cached, the page template, the order scripts load in and the other company's server. Your test result, and the element it names, is the evidence that counts for your site.
If your site runs on WordPress, the same list applies. A website slow to load on WordPress usually comes back to the same suspects: large images, stacked plugins, a heavy page builder and third-party embeds. The platform name is not the diagnosis. The test is.
Fix the Biggest Problem First, for the Least Money
A website slow loading fix works best in a set order: start with whatever the test named, then clear out what you do not need, then tidy how the rest loads. Google's guide to optimizing LCP follows the same logic. The job sizes below are scope labels, not prices, because your platform and how much testing is needed decide the real effort.
| Fix | What it involves | Rough job size |
|---|---|---|
| Resize and compress the hero image | Right dimensions, efficient format, do not lazy-load it, lazy-load images further down | Small, if you have the originals and access to your site |
| Remove unused plugins, tags and widgets | Check that forms and tracking still work after each removal | Small to medium |
| Defer scripts that are not needed right away | Load chat or review code after the main content, change font loading, trim styles | Medium, with visual and function testing |
| Reserve space for images and embeds | Set dimensions so nothing jumps when it loads | Medium |
| Add caching or a CDN, or move hosts | Server setup, with care over DNS, email and a way to roll back | Medium |
| Rework a page-builder template or replace an old theme | Rebuild heavy templates or custom code | Large |
Start with the named element. If your hero image is the Largest Contentful Paint, resize it to the size it actually displays, compress it, and make sure it is not set to lazy-load. Lazy loading helps images further down the page, but on the visible hero it can delay the very moment your LCP measures.
Next, go through your list of third-party tools and remove anything that no longer earns its place: an old tracking tag, a second analytics tool, a social feed nobody watches. Keep tools that bring in business. A chat window or booking tool that produces real inquiries can be worth its weight, and Google's guide to loading third-party JavaScript efficiently shows how to load it later rather than drop it.
After each change, run the test again and send yourself a test inquiry through every form. A faster page that no longer sends leads is a worse page. If your tracking stops counting visitors after a cleanup, our guide to Google Analytics showing zero or wrong visitors walks through what to check.
Know When New Hosting Is Worth It
A new host is an easy thing to suggest for a slow site, and sometimes it is the right one. It is worth investigating when repeated tests, run without a cached copy, keep showing slow server response. It is also worth a look when your host limits processing or database work, or when a simple, already optimized page stays slow before any third-party tools have loaded.
It is not worth paying for when the test points at a large image, a blocking widget or a heavy front end. A new host cannot make any of those disappear. Moving hosts also carries its own work and risk, because DNS, email and a rollback plan all need care, so it should follow evidence rather than a hunch. Cheap shared hosting is not automatically slow, either. Test the server response before you assume.
When the evidence does point at the server, web hosting with caching and enough capacity is a fair fix, and the before-and-after test will show whether it worked.
Know When a Rebuild Is the Right Call
A slow site does not usually need to be torn down. A rebuild makes sense when the problem lives in the structure of the site rather than on one page. That looks like a theme or page builder that loads the same heavy files on every page and cannot be told to stop, pages with far more hidden structure than their content needs, two frameworks doing the same job, key features that depend on plugins nobody updates anymore, or changes that keep breaking the layout.
If several of those are true, fixing them one by one can cost more than starting over, and a web design project built for speed from the start can be the better spend. Google's material on rendering performance explains why a bloated front end stays slow no matter where it is hosted.
If only one page is slow, or the named element is a single image, a rebuild is the wrong tool. That is a maintenance fix.
Set Fair Expectations for Rankings and Sales
Speed matters to Google, but in a specific way. Google's page experience documentation says Core Web Vitals are used by its ranking systems. It also says that good results in the Core Web Vitals report "doesn't guarantee" top rankings, and that relevant content can still rank with a weaker page experience. Its guidance says the benefit matters most when many helpful pages are competing for the same search.
In practice, treat speed as part of how visitors experience your business, and as one competitive factor among many. It is not a switch that moves you to the top of Google, and a perfect 100 score is not a goal worth paying for. Google itself says chasing a perfect score purely for SEO may not be the best use of your time.
On sales, the most cited evidence is Deloitte's Milliseconds Make Millions study from March 2020, commissioned by Google. It looked at natural changes in mobile speed across 37 European and US brand sites over four weeks and more than 30 million sessions. A 0.1-second improvement went along with 8.4% higher conversion for retail sites and 10.1% for travel sites. Those are correlations across large brands, not a controlled experiment, and not a promise for a small business site. Measure your own inquiries before and after a fix, in your analytics, instead of borrowing someone else's percentage.
Decide Whether You Need to Pay Anyone at All
Sometimes the right amount of speed work is none. If your field data is good and the lab test finds nothing a visitor would notice on your key pages, you can stop here and check again every few months. If the problem is a single original hero image, one redundant embed or a tag added last month, it is a targeted fix, not a redesign, and not a premium optimization package.
If your site has too little traffic for field data, nobody can tell you from "no data" how real visitors fare. A limited lab diagnostic and occasional checks from your own phone may be all you need.
When you do hire help, ask for three things. First, the baseline: the numbers and the named element before any work starts. Second, a written list of what will be removed, changed or deferred, and why. Third, a follow-up test after the change, plus confirmation that every form, booking tool and tracking tag still works. Field data takes time to catch up, so give it a few weeks before you judge the result. Anyone who promises a perfect score, a first-page ranking or a fixed jump in sales is promising something the evidence does not support.
How well can you read a slow website test?
Pick an answer to begin.
1. PageSpeed Insights says there is not enough real-user data for your site. What does that mean?
2. The test names your hero image as the Largest Contentful Paint element. What should you try first?
3. Does a good Core Web Vitals result guarantee you a top Google ranking?
Frequently Asked Questions About website slow to load
How do I check if my website is slow?
Run your most important page through PageSpeed Insights on mobile, then look at the Core Web Vitals report in Search Console if you have it. Together they show real-visitor results and the specific element slowing the page.
How fast should a business website load?
Google's good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, for at least 75% of visits. Over 4 seconds for LCP is rated poor.
What should I fix first on a slow website?
Fix the element the test names as the Largest Contentful Paint, often the hero image, then remove scripts and widgets you no longer need. Retest and check your forms after each change.
Is my hosting making my website slow?
Only testing can say. If repeated tests show slow server response, or a simple optimized page stays slow, hosting is worth investigating. A new host will not fix a heavy image or widget.
Why is my website slow on mobile but fine on desktop?
Phones often have slower processors and connections than an office computer on Wi-Fi, and JavaScript takes longer to process on them. Always test the mobile version, since that is closer to what a phone visitor sees.
Do I need a new website if mine is slow?
Usually not for one slow page or image. A rebuild makes sense when a theme or page builder loads heavy files everywhere, key features rely on outdated plugins, or changes keep breaking the layout.
What This Means for You
A slow website is something you can measure yourself before anyone sends you a quote. Test your key pages on mobile, write down the three numbers, find the element holding the page up and list the extra tools running on it. That short record tells you whether the fix is an image, a cleanup, a hosting change or, rarely, a rebuild.
Fixing what the evidence names, and nothing more, gets you a page that shows up promptly, reacts when people tap and stays still while they read. It also leaves you with fewer plugins and widgets to maintain, so the site is less likely to slow down again as campaigns and tools come and go.
If you want a second set of eyes on your results, Web Leveling can run the baseline with you and fix what it shows. Our website maintenance work covers image fixes, script cleanup and retesting, with your forms and tracking checked after every change, and if the numbers say your site is already in good shape, we will say so. We work with small and medium businesses across the country and overseas. Send us the page that feels slow, and we will tell you what we find.
Terms
Speed terms in this post
Tap a term to see what it means.
Core Web Vitals. Google's three measures of how a page feels to use: loading, responsiveness and visual stability.
Largest Contentful Paint (LCP). How long the biggest visible element, often a hero image or headline, takes to appear.
Interaction to Next Paint (INP). How quickly the page responds after a visitor taps, clicks or types.
Cumulative Layout Shift (CLS). How much the page moves around unexpectedly while it loads.
Field data. Measurements from real Chrome visitors over the previous 28 days.
Lab data. A single controlled test of a page, used to find the cause of a problem.
Lazy loading. Holding back an image until the visitor scrolls near it.
