Test your top twenty pages individually rather than relying on a homepage score. The slowest is usually a gallery, a product listing, or a page with an embed nobody remembers adding.

Why site-wide figures mislead

Almost everybody tests their homepage and treats the result as their site's speed.

The homepage is usually the most carefully built page you have, and frequently the fastest.

Meanwhile a product listing, a gallery, or a page somebody built for a campaign three years ago takes four times as long, and nobody has ever tested it.

The visitors on those pages are having an experience nothing in your reporting describes.

Test pages individually

The method is dull and takes about half an hour.

Take your twenty most visited pages from your analytics, which is a list you can produce in two minutes.

Test each one, on mobile, with a throttled connection, and record when useful content appeared rather than when loading finished.

Put the results in a list and sort it.

What you are looking for is not the average. It is the gap between the fastest and the slowest, which on most sites is a factor of five or more and always surprises the owner.

Where the slowest page usually is

The third is the one that catches people, because a contact page feels lightweight and an embedded map brings a substantial amount of code with it.

Diagnosing one page

Once you have found it, the network waterfall tells you why in about five minutes.

Open developer tools, empty the cache, load the page, and sort the requests by size.

Usually one or two items account for most of the weight, and they are almost always images or a third-party embed.

Then look at the timing rather than the size, because a small file from a slow server can hold up more than a large one from a fast one.

Between those two views, most pages explain themselves without any expertise beyond knowing where to look.

A worked example

A design firm tested their homepage regularly and were satisfied with it.

Testing their twenty most visited pages found the homepage was the second fastest.

Their portfolio page, which was the most visited page on the site and the one prospects looked at before making contact, took about fourteen seconds to become usable on a throttled mobile connection.

It was loading forty-one photographs at full resolution, all at once, because lazy loading had never been enabled on that template.

Resizing the images and loading them as the visitor scrolled brought it to about three seconds.

Enquiries rose over the following two months.

They had been testing the wrong page for two years, and the page they were not testing was the one that decided whether anybody called.

Weight the list by importance

Traffic is not the only measure of which page matters.

A page with modest traffic that sits immediately before an enquiry or a purchase carries more weight than a busy page nobody acts on.

Add your key pages to the test list even if they are not in the top twenty by visits: the main service page, the pricing page, the contact page, and whatever comes just before your form.

Then fix in order of traffic multiplied by importance rather than by how slow something is, since a very slow page nobody visits is not the priority it appears to be.

Template problems and page problems

A distinction worth drawing early, because it changes the size of the job.

If several pages sharing a template are all slow in the same way, the problem is the template and fixing it once fixes all of them.

If one page is slow and its neighbours are fine, the problem is on that page: an embed, a large image, or something added by hand.

Test two or three pages of the same type before diagnosing, since that comparison tells you immediately which kind of problem you have.

Template problems are more work and better value. Page problems are usually ten minutes.

The page built outside the system

A specific case worth looking for deliberately.

Most sites contain at least one page that was made differently: a landing page from a campaign, something built by a previous developer, a page copied from elsewhere.

These frequently load their own scripts and stylesheets on top of the site's normal ones, sometimes duplicating them, and they are rarely covered by whatever performance settings apply everywhere else.

They are also invisible in a review of the main navigation, because nothing links to them.

Find them by listing every page in your sitemap and comparing that with your menu, since anything reachable and unlinked is worth a look for several reasons beyond speed.

Retest after anything changes

Performance decays quietly.

A page that was fast becomes slow because somebody added an image, embedded a video, installed a plugin, or pasted in a widget.

None of those feels like a performance decision at the time and no report announces the change.

Retest your top twenty twice a year, and retest a specific page whenever it is edited substantially. Both take minutes and prevent the situation where the slowest page has been slow for three years.

The counter-case

Not every slow page is worth fixing.

A page with genuine reason to be heavy, such as an interactive tool or a large data table, may be slow because it is doing something, and the visitor arrived expecting it to take a moment.

An archive page nobody visits is also not a priority, whatever its score, and time spent there is time not spent on the pages people actually use.

The judgement is what the visitor came for. Somebody using a calculator will wait three seconds. Somebody checking whether you are open will not.

The audit

  1. List your twenty most visited pages.
  2. Add key pages that sit before an enquiry.
  3. Test each on mobile, throttled, with an empty cache.
  4. Record when content appeared, not when loading finished.
  5. Sort the list and look at the gap, not the average.
  6. Compare pages sharing a template to identify the cause.
  7. Fix by traffic and importance, not by how slow.

Half an hour, and it usually finds one page nobody had ever tested doing most of the damage.

Why a site feels slow on a phone is covered in why your site feels slow on a phone.

Frequently asked questions

Why is testing my homepage not enough?

Because the homepage is usually the most carefully built page you have and frequently the fastest. A gallery or listing page may take four times as long and has never been tested.

How do I find the slowest page?

Take your twenty most visited pages, test each on mobile with a throttled connection, and record when useful content appeared. Sort the results and look at the gap, not the average.

Which pages are usually slowest?

Galleries and portfolios, product listings showing many items, contact pages with an embedded map, old campaign pages built outside the template, and anything with a feed.

How do I diagnose one page?

Open the network waterfall with an empty cache and sort by size. One or two items usually account for most of the weight, then check timing for slow third-party responses.

Is it a template problem or a page problem?

Test two or three pages of the same type. If they are all slow the same way, fixing the template fixes all of them. If one is slow and its neighbours are fine, it is that page.

Should every slow page be fixed?

No. An interactive tool or a large data table may be slow because it is doing something the visitor expected to take a moment. Fix by traffic and importance, not by score.

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.

Only ever tested your homepage?

Test your top twenty. On most sites the slowest is five times the fastest, and it is not the page you expect.

Start a Conversation