What actually makes a school website fast
Lessons from rebuilding school websites in Next.js: static pages, almost no JavaScript, lighter images and technical SEO for parents searching locally.

Parents look up schools on their phones, often on mobile data, often while doing something else. A school website has a few seconds to show them the right campus, the curriculum and a way to get in touch. Most school sites I have seen are slow for the same handful of reasons, and none of them are hard to fix.
These are the things that made the biggest difference on the sites I rebuild.
Make every page a plain HTML file
Almost nothing on a school website changes between visitors. Fees, curriculum, staff and admissions steps are the same for everyone. So every page is generated once at build time and served as static HTML.
With Next.js that is the default for any page that doesn't fetch per request. The result is a page that is ready the moment it arrives, with nothing to wait for.
Ship almost no JavaScript
On the newest builds the only JavaScript in the browser is the mobile menu, the enquiry forms and a click-to-play video. Everything else is HTML and CSS.
That rules some things out:
- No CSS framework. The whole design system is one stylesheet of custom properties.
- No third-party scripts by default. Every chat widget and tracker has to earn its place, because each one is code the page has to download and run before it settles.
- No video that loads on page open. A poster image shows until someone presses play.
Fix the images first
The single heaviest file on one of the old sites was a 5 MB PNG on the home page. Converting heavy images to WebP, sizing them for where they actually appear, and lazy-loading anything below the fold usually does more than any other change.
A quick way to find them: open the network tab, sort by size, and look at the top five.
Technical SEO for local search
Parents search for things like "British school in Ajman" or "CBSE school in Al Qusais". To show up, a page needs to say clearly what and where the school is:
- A unique title and description for every page, written for a parent, not for a keyword list.
- Structured data that marks the site as a school, with its address and curriculum.
- A sitemap generated from the same data as the pages, so it is never out of date.
- Real text on the page. A curriculum described in an image is invisible to search.
Keep content out of the components
Every fact on the site lives in a data file: fees, staff, the curriculum, policies, contact details. The components only arrange it.
That means updating next year's fees is an edit to one file, and the sitemap, the structured data and the page all change together.
The checklist
If I had to fit this on a sticky note:
- Static HTML for every page.
- JavaScript only where something is interactive.
- Images in WebP, sized correctly, lazy below the fold.
- A real title, description and structured data on every page.
- Content in data, not in components.
None of this needs a new framework. It mostly needs saying no to things.