Use a quiet week to test the home page and busiest pages on a real phone and in WebPageTest, find the heaviest items, and list the fixes to make in January.

A week with time to look

For many businesses the days before Christmas are quiet. Trades wind down, offices close early and the phone rings less than at any other time of year.

That makes this a good week to find out how fast the website really is: page by page, on the kind of phone most customers use, not by glancing at a score.

It is not a good week to change anything. A fix that breaks something tomorrow may stay broken until January.

So test now, write it all down, and fix it when everyone is back.

Which pages to test

The third is the one most often left out. Every visit to it is paid for, and a slow page wastes the click before the visitor reads a word.

Start with a real phone

Before any tool, use a phone. Turn off Wi-Fi, close the browser, and open each page the way a customer would, from a search result rather than a bookmark.

Note two moments on each page: when something useful first appears, and when you can tap the phone number or main button. A stopwatch on a second phone will do.

Repeat it on a weaker signal and, if there is one, an older phone. Customers do not choose their signal, and new phones hide a good deal of slowness.

What PageSpeed Insights tells you

PageSpeed Insights, Google's free tool, gives each page a score out of 100 for mobile and for desktop, with a list of suggested fixes.

The score measures how well the page follows a set of rules, such as compressing images, letting browsers keep files and not holding up the first view with scripts. It is not a timing.

So it is good at pointing to causes and poor at saying how a page feels. A page can score well and still crawl on a phone.

Copy the suggestions it marks as should fix into your notes for each page; they are usually the ones worth acting on.

What WebPageTest shows

WebPageTest loads the page in a real browser from a location and connection speed you choose, then shows what happened, file by file.

Pick a test location close to your customers and a mobile connection setting, and run each page three times, so one unlucky run does not mislead you.

Then note a few numbers: start render, when anything first appears; Speed Index, how quickly the visible page fills in; fully loaded time; total page weight; and the number of requests.

The filmstrip view shows the page appearing frame by frame. It is the easiest thing to show anyone who doubts there is a problem.

Finding the slowest items

The waterfall chart lists every file the page loaded, in order, with a bar for how long each took. Most pages have a few clear culprits.

Photographs straight from a camera are the usual one, often several megabytes each. Sliders, background videos and galleries that load every picture at once come next.

Then come scripts from other companies: chat boxes, social feeds, review widgets, maps and web fonts. Each calls another server, and any of them can hold up the rest.

If the first bar, the wait before the server sends anything, is long on every page, the problem lies in the hosting or the site's setup rather than its pictures.

A worked example

A pressure washing company with two trucks cleans driveways, decks, siding and gutters across a few suburbs, and has almost no work between mid-December and late February.

Its home page opened with a slider of before-and-after photographs, nine pairs, each uploaded straight from a phone. Below sat a Facebook feed and a chat box.

Last December, in the quiet week, the owner tested it on his phone with Wi-Fi off. The phone number appeared quickly; he gave up waiting for the first photograph.

WebPageTest showed why. The page weighed more than eight megabytes, almost all of it photographs the slider fetched before showing the first, and the feed and chat box added dozens of requests between them.

The server answered quickly, so the hosting was fine. He wrote a list instead of touching anything, and his web company worked through it in the first week of January.

The slider became a single resized pair, with the rest on a gallery page; the feed became a link and the chat box went. On the same phone, the first photograph now appears with the page.

Write a list for January

For each page, write down what you measured and what seems responsible: the page, the item, its size or delay, and the suggested fix.

Sort the list by how many visitors each page gets. A heavy image on the home page matters more than a slow script on a page few people open.

Keep the numbers from before any change. Without them, nobody will know in February whether the fixes worked.

Leave the fixes until January

Speed fixes touch things that break: image settings, scripts the theme depends on, caching rules and plugins. Made on a quiet evening before a holiday, they leave broken menus that nobody notices for a week.

A second caching or optimisation plugin on a site that already has one can make things worse rather than better.

The counter-case

A small site of a few light pages, already quick on a phone, needs a short check rather than an afternoon.

A business at its busiest right now, such as a shop in December, should leave this for another quiet week.

And a site due for a redesign in spring still deserves the test. The measurements become the standard the new site has to beat.

For most sites, an hour or two of testing in a quiet week produces a list worth more than any score.

Before Christmas

  1. List the pages that matter most.
  2. Open each on a phone with Wi-Fi off.
  3. Run each through PageSpeed Insights and save the suggestions.
  4. Test each in WebPageTest on a mobile setting.
  5. Find the heaviest items in the waterfall.
  6. Write the January list, busiest pages first.
  7. Change nothing until everyone is back.

Step four is the one that turns a hunch into a list. A score says something is wrong; a waterfall shows which file, how large and how late.

Why a site with several caches can show visitors the wrong page is covered in caching plugins fighting each other.


Frequently asked questions

Why test speed in the week before Christmas?

Because it is quiet for many businesses, so there is time to test properly. Leave the fixes until January, when someone is around if a change breaks something.

Which pages should I test?

The home page, the busiest landing pages in Analytics, the page your ads point to, the contact page, and the heaviest gallery or product page.

Is the PageSpeed Insights score a load time?

No. It scores how well a page follows a set of rules, such as compressing images. Its suggestions point to causes, but a page can score well and still feel slow.

What does WebPageTest show that a score cannot?

What actually happened: when the page started to appear, how it filled in, its total weight, and every file it loaded, in order, with how long each took.

What usually makes a page slow?

Photographs straight from a camera, sliders and galleries that load every image at once, and scripts from other companies such as chat boxes and feeds. Slow hosting shows on every page.

Should I install a speed plugin now?

Not this week. Plugins that cache or optimise can break menus and forms, and a second one can clash with the first. Make changes in January, deliberately and tested.

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.

Quiet week and a slow site?

Send us the pages that matter most. We will test them on a phone connection and send you a list for January.

Start a Conversation