Why your website is slow, and what it is costing you

Your website is slow for one of three reasons, and almost always in this order: the images are far too big, too much software runs on every page load, or you are paying four dollars a month for hosting. Everything else is a rounding error next to those three.

The good news is that the first one is usually fixable in an afternoon by someone who is not a developer. The bad news is that if your site was built on a heavy page builder theme with thirty-odd plugins stacked on top, no amount of optimization will make it genuinely fast, and you can easily spend more chasing seconds than a rebuild would have cost.

Here is how to tell which situation you are actually in.

What counts as a slow website in 2026?

Google measures three things, collectively called Core Web Vitals. The thresholds have not moved in a while, and these are the current ones.

Metric	What it actually measures	Good	Needs work	Poor
LCP (Largest Contentful Paint)	How long until the biggest visible thing, usually your hero image or headline, finishes drawing	2.5s or less	2.5s to 4.0s	Over 4.0s
INP (Interaction to Next Paint)	How long the page takes to visibly respond when someone taps a button or opens a menu	200ms or less	200ms to 500ms	Over 500ms
CLS (Cumulative Layout Shift)	How much the page jumps around while it loads, the reason you tap the wrong link	0.1 or less	0.1 to 0.25	Over 0.25

A page only passes if all three land in the good column. Two out of three is a fail, which catches a lot of people who fixed their images and never looked at layout shift. INP replaced the older First Input Delay metric in 2024 and it is stricter, because it measures the full round trip until the screen visibly changes rather than just the delay before the browser starts working.

Why your site feels fast to you but slow to Google

Because Google is not measuring your experience. Core Web Vitals scores come from the Chrome User Experience Report: anonymized data from real Chrome users who opted in, aggregated over a rolling 28-day window and reported at the 75th percentile.

That last part matters more than people expect. Three out of four visits have to be good, so your average can look fine while a quarter of your visitors stare at a white screen.

Most of those visits are on a phone. Not your phone on the office wifi with the page already cached, but a five-year-old Android on two bars of LTE. A parent checking your school calendar from a parking lot. A discharge planner comparing home care agencies from a hospital hallway. Someone pulling up your contact page at a gas station off 94 near St. Cloud. That is the real test, and your desktop never runs it.

How do I check how fast my site actually is?

Ten minutes, four steps, all free.

1. PageSpeed Insights. Paste your URL. Read the panel at the top labeled with real-user data first. The 0-to-100 score underneath is a lab simulation on a throttled phone. It is a useful diagnostic and a terrible goal.
2. Google Search Console, Core Web Vitals report. This groups all your URLs and tells you which templates are failing, so you fix a page type once instead of a page at a time.
3. Your own phone, off wifi, in a private window. No cache, no excuses. Count out loud.
4. WebPageTest.org for the waterfall, which shows every file the page loads and how long each one blocked everything else. This is where the surprises live.

One warning. Chasing a 100 score in PageSpeed Insights is a vanity project. Sites that load in 1.8 seconds routinely score in the 70s because of a font or an analytics tag. Fix the field data, ignore the number.

Cause 1: Your images are enormous

This is the answer more often than everything else combined. Someone uploaded a 4,000-pixel-wide photo straight off a phone or a stock site, the theme scaled it down with CSS, and every visitor now downloads 4 MB to see a 800-pixel-wide picture.

How to check: Open the page, right-click, choose Inspect, and go to the Network tab, then reload. Sort by size. Anything over 300 KB is suspect. Anything over 1 MB is the problem.

DIY fix: Resize images to roughly twice their display width and no more, then convert to WebP. Squoosh.app does this free in the browser, and on WordPress a plugin like ShortPixel or Imagify converts your existing library in bulk for a few dollars. Turn on lazy loading below the fold, and set explicit width and height attributes, which also kills a lot of layout shift.

Get help when: you have 500 images across a decade of blog posts, or your theme generates its own copies and you cannot tell which one is being served.

Cause 2: Too many plugins

Every active WordPress plugin can add its own CSS file, its own JavaScript, and its own database queries, and most of them add all three to every page whether that page uses the feature or not. A slider plugin used on the homepage often loads its assets on the contact page too.

How to check: Look at your active plugin count. Under 15 is healthy for a small business site. Over 30 and you have a performance problem regardless of what any individual plugin does. The free Query Monitor plugin shows what each one costs per page load.

DIY fix: Deactivate anything you cannot name a current use for, one at a time, checking the site after each. Delete rather than just deactivate, because dormant plugins still need updating and still carry security risk. Watch for duplicates, especially two SEO plugins or two caching plugins fighting each other.

Get help when: you are afraid to touch anything because you do not know what will break. That fear is legitimate, and it is exactly what a staging site is for.

Cause 3: The page builder and the theme

Elementor, Divi, WPBakery, and most multipurpose themes from marketplaces trade performance for drag-and-drop convenience. They wrap every element in extra markup and ship a large CSS and JavaScript bundle to every visitor.

This is the cause with no cheap fix. Asset optimization shaves a little off, but you cannot make a builder-heavy page as fast as a clean one, because the weight is the product.

How to check: View page source and look for a wall of nested divs with class names like elementor-element elementor-element-4a2b1c. That is the signature.

DIY fix: Limit builder features per page. Cut animations, parallax, icon libraries, and anything that renders a carousel. Turn off the builder’s global font and icon loading if it offers the option. Beyond that, the honest answer is a rebuild, which I get to below.

Cause 4: You are paying four dollars a month for hosting

Cheap shared hosting means your site sits on a server with hundreds of other sites competing for the same CPU and the same database. The symptom is a slow Time To First Byte, meaning the server takes a long time to send anything at all, before a single image is even requested.

How to check: In PageSpeed Insights or WebPageTest, look for server response time or TTFB. Under 200ms is good. Over 600ms and your host is a bottleneck no plugin will fix.

DIY fix: Move to managed hosting. For WordPress, $25 to $50 a month buys server-level caching, a current PHP version, and support that actually understands WordPress. We budget $10 to $50 a month for hosting across the projects on our pricing page, and the top of that range is money well spent on a database-driven site.

Get help when: you need the move done without downtime or broken URLs. If you are switching platforms at the same time, read our guide to moving a website without losing rankings first, because redirects are where those projects go wrong.

Cause 5: Render-blocking CSS and JavaScript

The browser will not paint anything until it has downloaded and parsed the stylesheets and scripts in the page head. Every one of those is a wall the page has to get past before a visitor sees a single word.

How to check: PageSpeed Insights lists them under “Eliminate render-blocking resources.”

DIY fix: A caching plugin like WP Rocket, or the free LiteSpeed Cache if your host supports it, will defer JavaScript and inline critical CSS with a checkbox. Test carefully afterward, because deferring the wrong script breaks menus and forms. Get help when the automated setting breaks something and you need someone to work out which script has to stay.

Cause 6: Third-party tags nobody remembers adding

This is the quiet one. A chat widget, a booking embed, a Facebook pixel, two Google Tag Manager containers, a review carousel, a heatmap tool from an agency you stopped working with in 2021. Each loads code from someone else’s server, and you are now as fast as their slowest server.

Web fonts belong here too. Loading four weights of two font families costs real time and shifts your text around when the fonts swap in.

How to check: WebPageTest’s waterfall, or the Network tab filtered by domain. Anything not on your own domain is a third party.

DIY fix: Remove what you no longer use. Self-host your fonts and cut to two weights, which covers most sites. If your chat widget is the heaviest thing on the page and produces two conversations a month, delete it. Get help when a widget is load-bearing, like a scheduling tool, and needs to be deferred until interaction rather than removed.

Cause 7: No caching and no CDN

Without page caching, your server rebuilds the same page from the database for every single visitor. Without a CDN, someone in Duluth and someone in Dallas both pull every file from one machine in one location.

DIY fix: Install a caching plugin and put Cloudflare’s free tier in front of the site. That is an hour of work and it is often the highest ratio of improvement to effort on this whole list. Static sites built with something like Astro sidestep this entirely, because there is no database query to cache.

Cause 8: The autoplay hero video

A background video in the header is the most expensive design decision on the modern web. Even a compressed 10-second loop is several megabytes, it competes with everything else for bandwidth, and on most phones it either does not autoplay or drains the battery when it does.

DIY fix: Replace it with a still image and, if you want the video, a play button. Nobody has ever chosen a vendor because of a header video.

Which fixes are worth the effort?

Fix	Effort	Typical effect
Compress and resize images	2 to 4 hours, no developer needed	Usually the largest single improvement on an image-heavy site
Add page caching	30 minutes	Large drop in server response time, low risk
Put a CDN in front of the site	1 hour, free tier	Moderate, and helps most for visitors far from your server
Remove unused plugins and tags	1 to 3 hours	Moderate to large, depending on how bad it was
Self-host fonts, cut to two weights	1 hour	Small on load time, often noticeable on layout shift
Upgrade from shared to managed hosting	Half a day plus $25 to $50 a month	Large when TTFB is the bottleneck, nothing when it is not
Defer render-blocking JavaScript	1 to 4 hours, some risk	Moderate, needs testing
Drop the autoplay hero video	30 minutes	Large on mobile
Replace a page builder theme	Rebuild project	Largest possible, and the only fix that lasts

Work down that list in order. The first four cover most sites and cost almost nothing.

What is slow actually costing you?

Honestly, I do not know your number, and anyone who quotes you a precise one made it up.

What is well established is the shape of the curve. Google’s own research on mobile pages found that the likelihood of someone bouncing climbs sharply as load time goes from one second to three, and much more sharply beyond that. Abandonment does not rise in a straight line. It hockey-sticks.

The practical way to think about it: if you get 1,000 visitors a month and slowness costs you even five percent of them before the content renders, that is 50 people who were interested enough to click and never saw your phone number. For a home care agency where one placement is worth thousands of dollars a year, that math gets uncomfortable quickly.

Speed also compounds with everything else. If your site has traffic that never converts, speed is one suspect among several, and our breakdown of why a website gets traffic but no leads covers the rest.

When you should not spend money on this

If your site loads in about three seconds and gets 300 visits a month, speed is not your problem. Do not hire us. Do not hire anyone. Compress your images, install a caching plugin, and go spend the money on getting found in the first place, because a fast website nobody visits is still a website nobody visits. Start with why your site is not showing up on Google instead.

The same goes for Squarespace and Wix. You do not control the server, the caching layer, or the JavaScript those platforms ship. Your only real levers are smaller images, fewer blocks per page, and fewer third-party embeds. If a vendor quotes you a four-figure Squarespace speed optimization, that is mostly billable hours against a ceiling neither of you can raise. Our Squarespace versus WordPress comparison walks through what each platform does and does not let you touch.

And if you are already planning a redesign in the next six months, do not optimize the old site first. You would be paying twice for the same result.

When is a rebuild cheaper than optimizing?

A serious optimization pass on an existing WordPress site runs roughly 8 to 20 hours, which at $95 to $150 an hour works out to about $800 to $3,000. That is worth it when the site’s structure is sound and the problems are additive.

It is not worth it when the weight is baked into the foundation. Rough test: if the site runs a marketplace multipurpose theme plus a page builder, has more than 30 plugins, and still fails Core Web Vitals after you fix the images and add caching, you are renovating a house with a bad foundation.

At that point a rebuild in the $3,500 to $9,000 business range, or $1,800 to $3,500 for a genuinely small site, buys you a fast site that stays fast, rather than one that regresses every time a plugin updates. Full ranges are on the pricing page, and if you want to understand the structural difference, our comparison of WordPress versus a custom-built site covers the trade-offs.

One thing makes the rebuild math easier than it looks: your content usually moves over as-is, so you are paying for structure and design rather than starting from a blank page.

If you go that route, keep the URLs. Losing your rankings to a redesign is a far more expensive mistake than a slow page, and it is entirely preventable with a redirect map. The website redesign checklist has the steps.

Where to start this week

Run PageSpeed Insights on your three most important pages. Open the Network tab and find your largest image. Count your plugins. Those three numbers tell you almost everything, and none of them cost anything.

If the answer turns out to be structural and you want a second opinion before you spend money, get in touch. We will tell you if it is a two-hour fix, and we will tell you if it is not worth fixing at all.