Every image, script, font and tracker is a separate fetch. Reducing the count matters as much as reducing the size, and third-party requests are the ones you control least and benefit from least.

What a page actually is

Not one file. A small instruction sheet, followed by a request for everything it mentions.

Images, stylesheets, scripts, fonts, icons, tracking pixels and embedded content are all fetched separately, and some of them then request further things of their own.

An ordinary small business page frequently makes fifty to eighty of these requests. A heavy one makes two hundred.

Each carries a small overhead, and on a mobile connection with higher latency that overhead is what makes a page feel sluggish even when nothing is large.

Where the requests come from

The third is the one that grows silently. A plugin used on the contact page frequently loads its files on every page of the site, including the ones that do not use it.

Third-party requests specifically

The category worth the most attention, because you control them least.

An embedded map, a chat widget, a review badge, a social feed and three tracking scripts are all requests to companies whose performance you cannot influence.

If one of them is slow today, your page is slow today. If one of them fails, your page may wait for it before finishing.

They also frequently load further files of their own, so one embed becomes eight requests.

The test worth applying to each: what does this do for the business, and would anybody notice if it were gone.

A worked example

A dental practice whose homepage made a hundred and forty requests.

Counting them: an embedded map, a chat widget nobody had answered in a year, a social feed showing posts from eighteen months earlier, two analytics scripts from an agency relationship that had ended, a review badge, and a booking widget used on one other page.

Together those accounted for over sixty requests, and the page waited on several of them.

Removing the chat, the social feed, the redundant analytics and the review badge, and replacing the map with a static image linking to directions, brought it to about fifty requests.

The page went from around seven seconds to under three on mobile.

Nothing that anybody used was removed. The practice had simply never taken anything away, only added.

The accumulation problem

Why this happens to every site eventually.

Adding something is a decision somebody makes. Removing it is a decision nobody makes, because nothing prompts it and nobody is responsible for noticing.

So a site accumulates: a campaign pixel, a tool trialled for a month, a widget added by a previous supplier, a script from a service you no longer pay for.

Each was justified once. None has been reviewed since, and together they are frequently the majority of the page.

Which makes an annual audit worth more than most optimisation work, because removing something is permanent and tuning it is not.

The counter-case

Where requests are worth keeping.

Anything genuinely producing enquiries. A booking widget that people use is worth its weight; the same widget nobody uses is not.

Analytics, singular, because measuring is worth a small cost. Analytics from three providers is not.

And anything required, such as a payment provider's script on a checkout page, where the alternative is not taking payment.

The test is not whether something adds weight. It is whether what it does exceeds what it costs, judged honestly rather than by whether it was somebody's idea.

Loading things only where they are needed

A refinement that helps once the obvious removals are done.

Many plugins load their files site-wide by default even though they operate on one page.

Restricting them to the pages that use them removes their cost from every other page, which on a site where most visits land on a service page is most of the benefit.

That is usually a setting rather than development work, and it is worth checking for anything heavy.

Combining files

A technique worth understanding, and less important than it used to be.

Older advice was to merge many small files into fewer large ones, because each request carried significant overhead.

Modern connections handle multiple requests far better, which means combining files matters less than it did, and on some setups it is now counterproductive.

What still helps is removing files entirely, which is why the audit above is worth more than any combining plugin.

If your host or platform offers combining as a setting, it is worth testing with and without rather than assuming it helps, because the answer now depends on the specific setup.

Counting your own

  1. Open your busiest page in a browser's developer tools, on the network tab.
  2. Reload and count the requests.
  3. Sort by size to find the heaviest.
  4. Sort by domain to see who else is involved.
  5. List anything from a company you do not recognise.
  6. Ask what each one is for.

The fifth reliably turns up something nobody in the business can account for, usually left behind by a previous supplier or a service that was cancelled years ago.

What removing things gains you beyond speed

Two benefits that are not about load time.

Each third-party script is somebody else's code running on your site, with access to what visitors do there. Fewer of them is a smaller surface for anything to go wrong.

And each one that collects data about visitors is something you are responsible for disclosing, which matters for your privacy policy and for what you tell people you do with their information.

A site loading trackers from four companies nobody in the business can name is difficult to describe accurately in a privacy policy, because nobody knows what they collect.

Removing the ones that do nothing simplifies that obligation as well as the page.

What to do with the list

Remove first, optimise second.

Deleting a widget nobody uses is faster, safer and more effective than any amount of tuning applied to it.

Then combine what remains where the platform allows, and defer anything that does not need to run before the page is readable.

And check the result rather than assuming, because removals occasionally break something visual that nobody realised depended on the thing you took away.

The heaviest single category on most sites is covered in the photograph that weighs four megabytes.


Frequently asked questions

What is a page actually made of?

An instruction sheet followed by separate requests for everything it mentions. An ordinary small business page makes fifty to eighty; a heavy one makes two hundred.

Why does the count matter as well as the size?

Each request carries overhead, and on a mobile connection with higher latency that overhead makes a page feel sluggish even when nothing is large.

Which requests deserve most attention?

Third-party ones. If a chat widget or review badge is slow today, your page is slow today, and you cannot influence it.

Why does this happen to every site?

Adding something is a decision somebody makes; removing it is a decision nobody makes. Nothing prompts a review, so sites only accumulate.

What about plugins loading everywhere?

Many load site-wide by default despite operating on one page. Restricting them is usually a setting and removes their cost from every other page.

How do I count my own?

Open the busiest page in developer tools on the network tab, reload, and sort by size and by domain. Anything from a company you do not recognise is worth questioning.

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.

Page loading from eleven different companies?

An annual audit that removes things beats any amount of tuning what is already there.

Start a Conversation