Toronto business owners are told their website is slow because of hosting. Hosting is occasionally the cause. On most of the sites we are asked to look at, it is third, behind images that were never resized and a stack of third-party scripts nobody has audited since they were added.
The distinction matters because moving hosts is expensive and disruptive, and compressing images is neither.
What Core Web Vitals actually measure
Google publishes three field measurements, and each corresponds to a specific way a page feels broken.
Largest Contentful Paint is how long the biggest thing on screen takes to appear — the hero image, the heading. Under 2.5 seconds is the threshold. This is the one users describe as “slow”.
Interaction to Next Paint is how quickly the page responds to a tap. Under 200 milliseconds. This is the one users describe as “stuck”, and it is usually JavaScript occupying the main thread while somebody is trying to press a button.
Cumulative Layout Shift is how much the page moves while loading. Under 0.1. This is the one users describe with a swear word, because they tapped a link and an advert loaded above it.
These are a modest ranking input, and the ranking argument is the least interesting reason to care about them. The interesting reason is that a page failing all three loses enquiries from people who were ready to make one.
The four things that are actually slowing your site
Images. By a distance the most common cause. A photograph straight off a phone is several megabytes and four thousand pixels wide, displayed in a slot eight hundred pixels across. Resizing to the display size, converting to a modern format, and lazy-loading everything below the fold routinely removes 70 to 90 per cent of a page’s weight, and it is the cheapest work in this list.
Third-party tags. Analytics, a chat widget, a review embed, two advertising pixels, a heat-mapping tool somebody trialled in 2023. Each was added by somebody who assumed it was free. Together they are frequently the largest JavaScript cost on the page, and they run on every single view.
Page builders. Elementor, Divi and their relatives ship a fixed payload of CSS and JavaScript regardless of what a given page uses. The first version is quick to produce and every version after it is heavier, and the weight is structural rather than fixable.
Fonts. Four weights of two families, loaded from a third-party host, each blocking text from appearing. One variable font, self-hosted and preloaded, does the same visual job at a fraction of the cost.
Fix these first
In order of payoff per hour spent:
- Resize and compress every image. Serve modern formats, size them to their display slot, lazy-load below-the-fold images and never lazy-load the hero.
- Audit third-party scripts. List everything loading, ask what each one is for, and delete what nobody can justify. This step alone often takes a second off.
- Reserve space for anything that loads late. Width and height attributes on images, fixed dimensions for embeds and ads. This is what fixes layout shift, and it is close to free.
- Self-host fonts and preload the one the heading uses. Cut the count of weights.
- Defer what does not need to run at load. Chat widgets, analytics and video embeds can almost all wait until interaction or until the page is idle.
Only after those five is it worth discussing hosting.
When optimisation stops being worth it
There is a point where speed work becomes propping something up. If a site is built on a page builder whose payload is the bottleneck, each round of optimisation buys a smaller improvement than the last, and the next content update undoes part of it.
The signal is regression. When a site that was tuned six months ago is slow again with no obvious cause, the platform is producing the problem faster than the optimisation can remove it, and a rebuild is the cheaper answer over any horizon longer than a year.
What good looks like
For reference, incepticode.com measures Largest Contentful Paint at around one second under 4× CPU throttling on a Slow 4G profile — well inside the 2.5-second threshold — with Cumulative Layout Shift at zero and under 10 kB of first-party JavaScript. Those numbers come from a script in the repository that runs before deploys, which is the only way a published performance figure stays honest.
Nothing exotic produced them. The stack is a static build with CSS inlined per page, one self-hosted variable font preloaded, images sized and converted at build time, and a deliberate refusal to add third-party scripts without a reason. Most business websites could get most of the way there on the first two fixes in the list above.
If you want to know which of the four causes is costing you the most, send the address — we will run it and tell you what we would fix first, in order.