A Site That Takes Eleven Seconds to Load

The site

A local business site on a common platform with a purchased theme, eleven seconds to become usable on a mid-range phone on a normal connection.

The owner had been told the hosting was slow and was preparing to move to a more expensive plan.

The server responded in well under a second, which is the first thing to check and the thing that was fine.

Everything after that was the page itself, which is where the eleven seconds lived and where nobody had looked.

Where the weight was

• Images: roughly two thirds of the total.
• Fonts: five families, four unused.
• Plugin code: eleven plugins loading on every page.
• Two sliders, one invisible.
• Third-party scripts: chat, analytics, two trackers.
• Video embedded and autoplaying.

The first item alone accounted for more than everything else combined, which is the usual proportion and the reason it is the place to start.

The images, in detail

The home page carried nineteen images totalling around fourteen megabytes.

The largest was a header photograph at camera resolution, several thousand pixels wide, displayed at a fraction of that size, weighing more than four megabytes on its own.

Six gallery thumbnails were full-size images scaled down by the browser, so each was downloading at full weight to be shown at postage-stamp size.

None were in a modern format and none were compressed beyond what the camera produced.

Resizing them to the dimensions actually displayed, and compressing them, took the nineteen images from fourteen megabytes to under one, with no visible difference.

That single change removed roughly six seconds.

The fonts

Five font families were being loaded: two from the theme, one from a plugin, and two the previous designer had used and abandoned.

Each family was loading multiple weights, most of which appeared nowhere on the site.

Removing the four unused families and reducing the remaining one to two weights cut most of a second and removed a delay before text became visible.

That second effect mattered more than the time saved, because text appearing late is what a visitor experiences as slowness even when the number improves.

The plugins

Eleven plugins were active. Four were used on one page each and loading their code on all of them.

Two were inactive in practice: a booking system replaced a year earlier and a social feed that had stopped working.

One was a page builder loading a substantial amount of code to render layouts that were mostly text.

Removing the two dead plugins and restricting three others to the pages that needed them cut around a second and a half.

The page builder stayed, because replacing it meant rebuilding the site, which is a decision rather than a fix.

The third-party scripts

A chat widget nobody had monitored for months, loading from an external service.

Analytics, which is reasonable, plus two advertising trackers from campaigns that had ended.

An embedded video set to autoplay, which began downloading immediately whether or not anybody watched it.

Removing the chat, the two dead trackers, and switching the video to load only when clicked removed about two and a half seconds.

Those are the easiest gains in any audit, because they are things nobody wanted, still running because nobody removed them.

Where it ended

Eleven seconds to about two and a half, on the same hosting.

Images accounted for the majority of the improvement, scripts for most of the rest, and fonts and plugins for the remainder.

Total work was roughly a day, most of it resizing images.

The hosting upgrade was not needed and would not have helped, since the server had never been the constraint.

That is the common finding: hosting is blamed because it is the thing a business owner knows they are paying for, and it is rarely the cause.

What the owner had actually been told

Worth recording, since it is why the diagnosis had gone wrong for two years.

Two suppliers had told him the site was slow because of the hosting, and one had quoted for a migration.

Neither had opened the page and looked at what it was downloading, which takes about five minutes with tools built into any browser.

Hosting is an easy thing to blame because it is a line item the owner recognises, and because recommending an upgrade is simpler than explaining image compression.

Anybody told their site is slow because of hosting should ask what the server response time is, since that single figure settles it and a supplier who cannot answer has not looked.

Do it in this order

Because the effort and the return are unevenly distributed.

Measure first, on a phone, and note the figure so the change is visible afterwards.

Check the server response time to rule hosting in or out before spending anything.

Fix the images, which is most of the problem in almost every case.

Remove dead scripts and unused plugins, which is fast and free.

Reduce the fonts.

Then measure again, and only consider hosting or a rebuild if the number is still poor.

Keeping it fixed

Because a site optimised once drifts back, and this one had been fast when it launched.

The images arrived one at a time, uploaded straight from a phone or a camera by whoever was adding a page.

The plugins accumulated as things were tried and not removed.

Set a rule that images are resized before upload, or install something that does it automatically, since expecting people to remember is what produced the original problem.

Then measure once a quarter, which takes two minutes, and treat a rising figure as a prompt to look rather than a crisis.

The counter-case within the site

Not everything heavy was worth removing.

The gallery images genuinely mattered to this business, and the answer was resizing them rather than removing them.

The page builder was inefficient and replacing it would have cost more than the remaining second was worth.

Analytics is a real cost and worth paying, since the alternative is having no idea what the site does.

The question is never what is heaviest, it is what is heavy and not earning its weight.

What to change

1. Measure on a phone and note the figure.
2. Check server response before blaming hosting.
3. Resize images to displayed dimensions.
4. Compress them and use a modern format.
5. Remove dead scripts and unused plugins.
6. Cut fonts to one family, two weights.
7. Measure again before spending anything.

Step two is the one that saves money, since a business about to pay more for hosting is frequently about to fix something that was never broken.

Finding which page to start with is covered in the slowest page on your site.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.