Why Is My Website Slow? Core Web Vitals for Business Owners

Most small-business websites are slow for four reasons: too much JavaScript from page builders, plugins and widgets; images uploaded at full size; a server that is slow to answer the first request; and third-party embeds like maps, fonts and booking tools. Google measures the result with three Core Web Vitals. You can check your own site free in about two minutes.

"Your site is slow" is not a diagnosis. It is a symptom. Almost every slow small-business site we open comes down to one or more of the same four causes.

1. Too much JavaScript. Page builders, plugins, chat widgets, pop-up tools and tracking pixels each add scripts. The browser has to download, read and run every one of them before the page feels usable. You never see any of it. Google measures all of it.
2. Images that were never resized. A photo straight off a phone can be several thousand pixels wide and a few megabytes. Drop it into a page that displays it at a few hundred pixels wide and every visitor still downloads the full file.
3. A server that is slow to answer. Before anything can draw, the browser asks your server for the page. On shared hosting, with a database-driven site and no caching, that first answer can take longer than the whole page should.
4. Third-party embeds. Google Maps, web fonts, YouTube video, review widgets and booking calendars all load from someone else's server. You do not control how heavy they are or how fast they answer.

You do not need a developer to see which of these is hitting you. Google publishes the tools, and they are free.

Core Web Vitals are three measurements Google uses to describe how a page feels to a real person. Each has a published "good" threshold. The definitions and the thresholds come from Google's own developer site, web.dev, so you can look them up yourself.

• LCP, Largest Contentful Paint. How long until the biggest thing on the screen shows up. On most business sites that is the big photo at the top or the main headline. Good is 2.5 seconds or less.
• INP, Interaction to Next Paint. How long the page takes to respond when someone taps or clicks. Menus, form fields, the "call now" button. Good is 200 milliseconds or less. Slower than that and the page feels sticky.
• CLS, Cumulative Layout Shift. Whether the page jumps around while it loads. You go to tap a button, a font or an ad loads late, everything moves, and you tap the wrong thing. Good is a score of 0.1 or less.

One detail matters. Google grades these from the slower real visits by Chrome users who share usage data, not from a lab test. A page that is fast on your office Wi-Fi and slow on a phone in a parking lot counts as slow.

You can check your website speed free with Google's PageSpeed Insights. Two minutes. No login, no software.

1. Open PageSpeed Insights.
2. Paste your homepage address and run it. Then run it again with one of your service pages. The homepage is usually the most tuned page on a site; service pages are where people actually land from search.
3. Read the top section first. The label on it says it shows what your real users are experiencing. That is field data: what your real visitors experienced over the last 28 days. Enough traffic and it shows pass or fail for each vital. Not enough data is normal for a small site and not a problem in itself.
4. Read the score below it separately. That is the lab score (Google calls the test Lighthouse), run on a simulated slow phone. It is useful for finding what to fix, but it is not what Google grades you on. A low lab score with passing field data is not an emergency, and a high lab score with failing field data is not a win.
5. Stay on the Mobile tab. Most local searches happen on a phone, and mobile is where slow sites fail first.

Then log in to Google Search Console and open the Core Web Vitals report under Experience. This shows the whole site instead of one page: how many URLs are good, need improvement or poor, and which measurement is driving it. Look at mobile.

What to screenshot and keep: the field-data section for the homepage and one service page on mobile, the lab score for each, and the Search Console mobile summary. Put the date in the file names. This is your baseline. Anyone who tells you they fixed your speed should be able to show you the same three screenshots, after.

Scroll down the lab section and you get a list of recommendations written for developers. Here is the translation.

Rows one to three you can act on yourself or with your host. Rows four and five are things to hand to whoever maintains your theme, with the screenshot attached.

Mostly the first row? JavaScript, and the fix that lasts is a build that never ships the builder. Mostly the second? Images, usually the cheapest fix. Third? Hosting or caching. The last two are build quality.

Search "WordPress slow" and the same three answers come up: install a caching plugin, put a CDN in front of the site, buy better hosting. They all help. Here is what each one does and where it stops.

• A caching plugin saves a finished copy of each page so the server does not rebuild it from the database on every visit. That fixes "Reduce initial server response time." It does nothing about what is inside the page.
• A CDN stores copies of your files on servers closer to the visitor. Files arrive faster. The same number of files still arrive.
• Faster hosting answers the first request sooner. The browser then still has to download and run everything the page ships.

That is the plateau. A page that ships a page builder, six plugins and a chat widget is still shipping a page builder, six plugins and a chat widget. Caching hides the server. It does not hide what the page ships.

Yes, and you can measure it yourself, because a static site removes most of the four causes above at the source. A static site is built once, ahead of time, into plain HTML files. When someone visits, the server hands over a finished file. That is the whole transaction.

• No database query on each visit. Nothing to cache, because nothing is being assembled.
• No plugins to load. Features are built into the pages, not bolted on as scripts.
• Images sized at build time. Every image is resized and converted to modern formats automatically, in every size the page needs.
• Fonts and scripts under control. Only what the page uses, loaded in the order that lets content draw first.

The receipts are public. Open thecritterguy.ca or batsandwildlife.ca in PageSpeed Insights, on mobile, and read the lab scores yourself. Both are brands we build on this architecture. Perfect Lighthouse scores are the standard every build ships against, and that click is the proof. That is how every site we build is put together.

Two warnings. Moving a WordPress site to a static build has to preserve every URL and the rankings attached to them, or the speed gain gets paid for in lost traffic. We wrote up how that is done properly in WordPress-to-static migration without losing rankings. And if you have ever watched a site go quiet in search after a redesign, that is what a rebuild done badly looks like. Traffic dropped after a website relaunch walks through why it happens and how to recover.

A faster website ranks a little higher, and not the way most people hope.

Google has confirmed that Core Web Vitals are a ranking signal. It has also been clear that it is a modest one. Content and relevance come first. Speed mostly acts as a tiebreaker between pages that are otherwise similar. If a competitor has a better page on a slower site, the better page usually still wins. Do not expect a rebuild to move you from page three to page one on speed alone, and be careful of anyone who promises it will.

The business case is somewhere else.

• Slow pages lose the person who already clicked. You paid for that visit with an ad or earned it with a ranking. They arrive, the screen is blank, they hit back. Often you never see it in your analytics, because the analytics script had not loaded yet either.
• A fast, light site gets crawled and drawn more completely. Crawlers spend limited effort on each site. Pages that need heavy JavaScript to show their content cost more of it, and many AI crawlers do not run JavaScript at all. We covered that in Do AI crawlers run JavaScript? If your content is in the HTML, every crawler sees it on the first pass.

Speed does not win the ranking. It makes sure the ranking you earn turns into an enquiry instead of a visitor who leaves.

You do not need to understand the fixes. You need questions a competent builder can answer in one message and a weak one cannot.

1. "What are the field-data numbers for mobile?" The real-user LCP, INP and CLS from PageSpeed Insights or Search Console, not the lab score. The lab score is easier to dress up for one run; the field numbers are what your visitors actually got. If there is not enough field data yet, ask for the mobile lab numbers instead, and for the same numbers after the fix.
2. "How many scripts load on the homepage?" They can count them in the browser in under a minute. If the answer is "I'm not sure," that is the answer.
3. "What do the images weigh?" Total kilobytes on the homepage and on a service page. Ask for the number, not "they're optimized."
4. "Can you show me a site you built that passes?" A live URL you can run through PageSpeed yourself. Not a screenshot.
5. If the site is being rebuilt: "How will the URLs and rankings be preserved?" You want to hear about a URL inventory, a redirect map, and a Search Console check before and after. Our migration guide lists what that plan should contain.
6. "Will I own the domain, the DNS and the hosting?" In your name, in accounts you control. If the answer is anything other than yes, read Take back your website: domain, DNS and hosting first.

You send your PageSpeed screenshots, or just your URL, through the form. It goes to the person who will fix it, in Mississauga, in your time zone, one thread. We build sites that pass the same test you just learned to run, and every one we ship is live for you to check before you talk to us.

If your site is slow and you want to know exactly why, send us the URL. You will get a real reply from the people who would fix it, not a sales rep.