Guide · Websites
Why is my website
so slow?
A slow site is rarely one big fault. It is usually four or five small ones that piled up: a photo straight off the camera, a slider someone liked in 2019, a chat widget nobody answers, a plugin for every small job. Here is how to measure it properly, what the numbers mean, and which fixes are yours to make.
Published 2026-11-09 · Formory Marketing Group
Short answer
Run your home page through PageSpeed Insights on the Mobile tab, read the real-user data first and test two or three times. Good means LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less. Usual causes: oversized photos and sliders, too many plugins, third-party widgets, slow hosting.
Measure it properly first.
Open PageSpeed Insights (pagespeed.web.dev), paste your home page address and run it. The report has two parts, and they answer different questions.
- Real-user data at the top comes from the Chrome User Experience Report: how the page actually loaded for real Chrome visitors over the previous 28 days. This is the part that describes your customers.
- Lab data below it, with the score out of 100, is one simulated load on a single device and a fixed network. For mobile, Google simulates a mid-tier phone on a mobile network. It is useful for finding causes, not for judging the experience.
Three habits make the test worth trusting. Look at the Mobile tab first: Google indexes and ranks the mobile version of your pages, and the lab test simulates an ordinary phone. Run the test two or three times, because lab results vary from run to run. And do not panic if the real-user section is empty: Google says a page may not have enough data if it is new or has few visitors, and then it falls back to the whole site or shows nothing.
On the lab score, Google treats 90 or above as good, 50 to 89 as needing improvement and below 50 as poor.
The three numbers that matter, in plain words.
Google calls them Core Web Vitals. Each is judged at the 75th percentile of visits, separately for phones and computers, so a page passes only if three out of four visits are good.
| Metric | What it means | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long until the biggest thing in the first screen (a photo, a video frame or a block of text) appears | 2.5 s or less | over 4 s |
| Interaction to Next Paint (INP) | How quickly the page reacts when someone taps, clicks or types | 200 ms or less | over 500 ms |
| Cumulative Layout Shift (CLS) | How much the page jumps around while it loads | 0.1 or less | over 0.25 |
Anything between good and poor is "needs improvement". Scrolling and hovering do not count towards INP; taps, clicks and key presses do.
How much speed matters to Google.
Somewhat, and less than people are sold. Google's own page experience guidance says Core Web Vitals are used by its ranking systems, recommends good scores, and in the same breath says a good score does not guarantee a top position. Relevance comes first: Google shows the most relevant page even if its experience is weak. Where many pages are equally helpful, a better experience can help.
Google also warns that chasing a perfect score only for search may not be the best use of your time. The better reason to fix a slow site is the visitor who gives up on a phone before your phone number appears.
A heavy first screen.
On small business sites the slowest part is usually what loads first. A full-width photo exported at 5,000 pixels and several megabytes. A slider with five such photos and a script to rotate them. A background video. Since LCP counts the largest image, video frame or text block in the first screen, that one element often decides the whole result.
- Resize photos to the size they are shown at and compress them. Google's guidance names AVIF and WebP as more efficient formats.
- Replace the slider with one good photo and a clear sentence about what you do.
- Do not lazy-load the main photo in the first screen; Google says lazy-loading the LCP image always delays it. Lazy-load photos further down instead.
- Set width and height on images and embeds, so the page does not jump when they arrive.
A typical case: a renovation company's home page opens with a slider of five project photos, each about 4 MB straight off the camera, plus a chat widget and a video background. On mobile it scores in the 20s, and the main heading appears after nine or ten seconds. Resizing the photos to the width they are shown at, keeping only the first one in the first screen, and loading the chat widget after the page brings the same page into the 90s, with the heading on screen in about two seconds. Nothing on the page changed for the visitor; it just stopped carrying 20 MB to show one photo.
Plugins, apps and scripts you did not write.
Every plugin on WordPress and every app on Shopify or Wix can add its own code to every page, whether that page uses it or not. Third-party scripts are the same problem from outside: chat widgets, booking pop-ups, social feeds, review badges, heat maps, two analytics tools doing one job. Google's guidance on third-party code says any significant amount of JavaScript can slow a page, that a script loaded the old synchronous way holds up the rest of the page, and that you should audit these scripts regularly and remove the ones you do not need.
Heavy scripts also hurt INP: while the browser is busy running code, a tap on the menu waits. Make a list of every plugin, app and widget, and next to each write who uses it and when you last looked at its results. Anything without an answer goes.
Hosting, page builders and fonts.
Hosting. Nothing appears until the server sends the first byte, and on a cheap, crowded shared plan that wait can be long before your page does anything. Google's LCP guidance recommends fewer redirects and serving the site from a content delivery network close to the visitor.
Page builders. Drag-and-drop builders and heavy themes tend to load their full set of styles and scripts on every page. Some of that can be trimmed; some of it is the builder.
Web fonts. Text can wait for a custom font to download before it shows, and a font that is larger or smaller than the fallback makes the text jump when it arrives. Use one or two font families, in as few weights as the design needs.
What you can fix yourself, and what needs a developer.
| Fix | Who |
|---|---|
| Resize and compress photos, replace the slider | You |
| Delete unused plugins, apps and widgets | You, after a backup |
| Remove a second analytics or tracking tool | You |
| Load scripts after the page, preload the main image | Developer |
| Fix layout jumps, trim theme or builder code | Developer |
| Move to better hosting or a CDN | Developer |
After each change, run PageSpeed Insights again on mobile, two or three times. The real-user section updates over 28 days, so give it a month before judging that part.
When rebuilding is cheaper than fixing.
If the slowness comes from the platform itself — a builder you cannot trim, a theme nobody can update, a host you cannot leave — paying a developer by the hour to work around it can cost more than starting again. Our rebuilds are $990 for up to six pages and $1,900 for up to fifteen, paid after delivery. Read when a redesign is worth it first, or see how a rebuild works.
Before deciding, run your address through our free site check to see what else is wrong besides speed.
Sources.
- web.dev — Web Vitals (Core Web Vitals and thresholds)
- web.dev — Largest Contentful Paint (LCP)
- web.dev — Interaction to Next Paint (INP)
- web.dev — Cumulative Layout Shift (CLS)
- web.dev — Optimize Largest Contentful Paint
- web.dev — Third-party JavaScript
- Google for Developers — About PageSpeed Insights
- Google Search Central — Mobile-first indexing best practices
- Google Search Central — Understanding page experience
Get a quote
Slow site? Send us the address: fix or rebuild, we will tell you honestly.
Websites from $590, and you pay after the site is built and you have seen it — no deposit, no contract. Tell us what you do and we reply within one business day with what we would build and the price. What is included and what it costs.
Or call (416) 989-3208. One of us answers; there is no sales team.
Questions
What people ask us.
How do I check how fast my website is?
Run your home page through PageSpeed Insights, open the Mobile tab and read the real-user data first. Run it two or three times, because the lab score varies between runs.
What is a good PageSpeed score?
Google treats a lab score of 90 or above as good, 50 to 89 as needing improvement and below 50 as poor. The real-user Core Web Vitals matter more than the score.
What are Google's Core Web Vitals thresholds?
Good is LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of visits.
Will a faster website rank higher on Google?
Core Web Vitals are used by Google's ranking systems, but Google says good scores do not guarantee a top position and relevance comes first. Speed matters most for visitors who leave before the page loads.
What slows down most small business websites?
Usually oversized photos and sliders in the first screen, too many plugins or apps, third-party widgets, slow shared hosting and heavy page builders. Several of these you can fix yourself.
Now check your own
You have read the numbers.
Where does your site stand?
Type your address and we will open your site the way a visitor would, then tell you plainly what is wrong with it — including when the answer is nothing. Ten seconds, no email, nothing stored.
If you want
one built.
We build the site, you look at it, and you pay once it is finished and you are happy with it. Hosting, edits and the Google listing carry on monthly, cancellable any month.