Database Queries on a Brochure Site

What happens on every visit

A content system stores your pages as records rather than as files.

So a visit triggers a sequence: work out which page, fetch the content, fetch the settings, fetch the menu, fetch anything each plugin wants, and assemble the result.

That is dozens of database queries and a measurable amount of work, repeated for every visitor.

For a page that has not changed since 2021, all of that produces exactly the same output every time.

Where it shows

• A long wait before anything arrives.
• The delay before the first byte, in a test.
• Slowness that images do not explain.
• Worse under load, when several people visit.
• Slower on cheap hosting.

The second is the specific measurement. Speed tools report the wait before the server responds at all, and where that is high, the problem is on the server rather than in the page.

Tell the difference first

Since the remedy depends entirely on which half is slow.

Split the load time into two: the wait before the server responds, and everything after that.

A long first part means the server is doing too much work, which is this subject.

A short first part and a long second means the page is too heavy, which is images, fonts, and scripts.

Most speed tools show both, and a great deal of effort is wasted optimising the wrong half.

Anything over about half a second before the first response is worth looking at.

Caching removes the work

Which is the direct answer for a page that does not change.

Page caching stores the assembled result and serves that to the next visitor, so the database work happens once rather than every time.

For a brochure site, where content changes monthly at most, that means almost every visitor gets a pre-built page.

The saving is the whole of the assembly time, which on cheap hosting can be a second or more.

This is the case where caching genuinely is the fix rather than a substitute for one.

Confirm it is working by checking that the wait before the first response has fallen, rather than assuming.

A worked example

A business had a site where every page took about two seconds before anything appeared, on top of a light and well-optimised page.

The images were correct, the scripts were few, and nothing explained it.

Testing showed nearly all of the delay was before the server responded.

Their site ran a content system with nineteen plugins, several of which ran queries on every page whether or not that page used them.

Enabling page caching brought the first response under two hundred milliseconds for visitors, and removing four unused plugins improved it for the uncached case too.

Nothing about the design or the images changed and the site felt entirely different.

Plugins are usually the cause

Since a plain content system is not slow on its own.

Many plugins run on every page regardless of whether that page uses their feature, because it is easier to load everywhere than to detect where.

Nineteen plugins each doing a small amount of work is a large amount of work per visit.

The fix is the same as elsewhere: remove what nobody uses, and ask whether the rest need to run everywhere.

Some hosts and tools can report which plugins consume the most time per request, which turns this into a list rather than a guess.

Ask whether that is available, since it identifies the two or three responsible quickly.

Hosting is the other half

Because the same work is faster on a better machine.

On shared hosting the processing is divided among many accounts, and a busy neighbour affects you.

Moving to a plan with more allocated resource frequently halves the assembly time with no change to the site.

That is a legitimate answer where the site genuinely needs to be dynamic and the work cannot be reduced further.

Compare the cost of a better plan against the effort of optimisation, since for a small business the plan is sometimes cheaper.

Ask what actually needs to be dynamic

The question underneath all of this.

A booking system, a shop, and a search need to be assembled per visit.

A service page, an about page, and a contact page do not, and on most small business sites those are almost the entire site.

Recognising that the site is mostly static, with two dynamic parts, points at the right arrangement rather than at incremental tuning.

Which is the subject of tomorrow rather than of today.

Check it when nobody else is looking

Since server-side slowness varies with load in a way page weight does not.

Test the same page at a quiet time and at your busiest hour, and compare the wait before the first response.

A figure that doubles under load means the server is at its limit, which is a hosting conversation rather than an optimisation one.

A figure that stays the same means the work per request is simply too much, which is caching and plugins.

That comparison takes two tests and tells you which of the two answers applies, which is otherwise a guess.

The counter-case

Dynamic is not a fault.

A content system exists so people can edit pages without a developer, which is worth a great deal more than a fraction of a second.

Modern hosting also assembles pages fast enough that this is invisible on many sites.

And caching resolves it for most small businesses without any of the deeper questions.

Split the load time in two, enable page caching if the first half is long, remove unused plugins, and consider the hosting.

What to check

1. Split the time at the first response.
2. Note whether it exceeds half a second.
3. Enable page caching if it does.
4. Confirm the first response improved.
5. Count the plugins running everywhere.
6. Ask which consume the most time.
7. Compare a better plan against the effort.

Step one prevents the common waste, since optimising images on a site whose delay is entirely before the first response changes nothing at all.

What the system is doing underneath is covered in databases for people who do not use them.

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.