A dynamic site builds each page on request. That flexibility is the point, and it is also where the performance and security problems come from — because every request now does work that a static file would not.
No caching layer at all
Every page view hits the database, often several times, for content that changes once a week. It works fine in testing with one user. It falls over the first time the site is genuinely busy, which is usually the day a campaign lands.
Cache the output of anything that is not personalised. Most pages on most business sites are not personalised.
Images shipped at original size
This remains the largest single cause of slow pages. A 3 MB photograph from a phone, displayed at 600px wide, downloaded in full by every visitor including those on mobile data.
Resize, compress, serve modern formats, and set explicit width and height so the layout does not shift while images load. Layout shift is both a ranking signal and the reason people tap the wrong thing.
Editing production directly
No staging environment, so changes get made on the live site — sometimes during business hours, usually with the reasoning that the change is small. Small changes break sites as reliably as large ones.
Validating forms only in the browser
Client-side validation is a convenience for the user. It is not a control: anything can post directly to the endpoint. Server-side validation is the only validation that counts, and a form without it is the most common way a small business site ends up compromised or drowning in spam.
No structured data
Search engines and AI assistants both lean on structured data to understand what a page is about. Without it they have to infer it from the text, and inference loses to explicit markup.
For a business site the baseline is small: organisation details, breadcrumbs on pages below the root, and article markup on anything that reads like an article. It is an afternoon of work with a disproportionate payoff in how the site gets represented.
Building for the developer, not the editor
The site is delivered, the developer moves on, and the marketing team discovers that changing a headline requires a ticket. Six months later the content is stale because updating it is someone else's job.
Whoever will maintain the content should be able to do it without help. Ask to see them do it before signing off.
Where to start if the site already exists
Run a page speed test on your busiest page and look at what it says is slow. It is almost always images, then uncached queries, then third-party scripts. Fixing those three in that order recovers most of the available performance without touching the architecture.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
