On a small site you can make pages fast by hand. On a directory with tens of thousands of pages, hand tuning is a fantasy. You will never finish, and even if you did, the next import would undo it. Page speed at scale is a fundamentally different problem from page speed on a brochure site, and it requires a different mindset: you do not optimise pages, you optimise the templates and the infrastructure that produce them. Get that right and speed becomes a property of the system rather than a chore. This is how we approach it across the Kings Hospitality Group portfolio.
The leverage point is the template
A large directory is not really thousands of unique pages. It is a handful of templates rendered with different data. A listing template, a category template, a location template, an article template, and a few others. Every performance problem you have lives in one of those templates, and every fix you make to a template propagates instantly to every page built from it. That is the whole game. Our standing rule is that a recurring page type must be fast in its template before a single instance ships, because the alternative is trying to outrun your own publishing.
This reframes the work. Instead of a hopeless backlog of slow pages, you have a short list of templates to get right. When the listing template is fast, all forty thousand listings are fast. When it is slow, all forty thousand are slow, and no amount of individual heroics will catch up. This template first thinking is the same logic that drives how we hit Core Web Vitals on directory pages: solve the pattern, not the instance.
Caching is the biggest lever
For most directories the single largest speed win is caching, because the most expensive thing a page does is usually the database query that fetches its data. A category page that runs a fresh query for every visitor is doing enormous repeated work to produce a result that rarely changes between edits. Caching that result, and serving the cached version until the underlying data actually changes, can turn a slow page into an instant one.
The art is in invalidation: cache hard, but clear the cache the moment the underlying content changes so users never see stale data. Most directory pages are ideal for this because they change infrequently between edits. A listing's details, a category's contents, an article's body, all stable for long stretches. We cache at multiple levels: the rendered page, the database query, and the edge. Each layer catches what the one above it missed.
Serve from the edge
Where your content is served from matters as much as how fast it renders. A page generated quickly but delivered from a single distant server still feels slow to a user on the other side of the world. A content delivery network caches your pages and assets at locations near your users, cutting the physical distance the data travels. For a directory with a geographically spread audience this is not optional. It is one of the cheapest large wins available, and it pairs naturally with the caching strategy because the edge is just another cache layer.
Images, the perennial weight
Images are almost always the heaviest part of a directory page, and they multiply: every listing has a photo, often several. Solving images by hand is impossible at scale, so it has to be automated in the pipeline. Every uploaded image should be automatically converted to modern formats, generated in multiple sizes for different screens, compressed, and served lazily below the fold. None of this should require a human decision per image, because there are too many images for human decisions.
- Automatic format conversion to modern, efficient formats on upload.
- Responsive sizes generated automatically so phones do not download desktop sized images.
- Aggressive compression tuned once and applied everywhere.
- Lazy loading for everything except the one above the fold image that drives the largest paint.
Because this runs in the pipeline, it applies to images uploaded today and images uploaded in two years without anyone thinking about it. That durability is the point. A fix that depends on people remembering is not a fix at scale.
JavaScript discipline
Scripts accumulate quietly on directories: filters, maps, analytics, ad tags, and third party widgets, each added by someone solving a real problem, each costing speed. At scale the answer is a strict budget enforced in the template. Load only what the first view needs, defer the rest, and treat every third party script as a cost that has to be justified. We audit third party tags periodically and remove the ones that are no longer earning their weight, because they tend to outlive the reason they were added.
This connects directly to keeping pages crawlable as well as fast. A page that buries its content behind heavy client side rendering is both slow and harder to index, which is why we keep our markup straightforward and avoid making content depend on scripts to appear. The crawl side of that argument runs through our work on a flat, easily crawled architecture, and the two goals reinforce each other.
Measure the templates, not just pages
Because the unit of work is the template, the unit of measurement should be too. We monitor performance by page type, sampling representative pages from each template against real user field data. When a template regresses, every page built from it regresses together, and you see it as a whole category dropping rather than scattered noise. That makes regressions obvious and fixes verifiable: change the template, watch the whole group recover.
This is the same per type thinking we apply to indexation through section split sitemaps. Group by the thing you can actually act on, measure that group, and a vague worry becomes a precise signal. A directory that watches speed per template catches a slow regression in days instead of discovering a sitewide slowdown months later.
The mindset that holds at scale
Everything here comes back to one idea: at scale, speed is an architectural property, not a manual achievement. You earn it once, in the templates, the caching, the image pipeline, and the edge, and then it holds across every page the system produces, including the ones that do not exist yet. That durability is exactly what we mean when we talk about building things that compound in our building thesis.
So resist the urge to chase individual slow pages. Find the templates, make them fast, cache hard with clean invalidation, automate the image pipeline, discipline the scripts, serve from the edge, and measure per type. Do that and a directory of tens of thousands of pages can be genuinely fast, not because anyone tuned each page, but because the system was built so that no page could be slow.
At Kings Hospitality Group we hold a template level performance rule: every recurring page type must be fast in its template before a single instance ships, because on a large directory you fix speed once in the template or you never fix it at all.
Common questions
Why not just optimise the slow pages?
On a site with thousands of pages, manual page by page tuning never finishes. The pages are generated by a handful of templates, so you fix the template and every page built from it improves at once.
Does caching hurt freshness?
Not if you cache thoughtfully. Cache stable pages hard and invalidate on change. Most directory pages change rarely between edits, so they are ideal caching candidates.
What matters most for speed?
For most directories, images and uncached database queries are the two biggest costs. Solve those two well and the rest is refinement.