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.

A silver stopwatch resting on a stack of plain school exercise books

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.

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:

  1. Static HTML for every page.
  2. JavaScript only where something is interactive.
  3. Images in WebP, sized correctly, lazy below the fold.
  4. A real title, description and structured data on every page.
  5. Content in data, not in components.

None of this needs a new framework. It mostly needs saying no to things.

  1. 2 min read

    Building Sandglass: prayer times without a server

    How Sandglass calculates prayer times on the device, keeps its timer honest in background tabs, and works properly in Arabic.

    Next.js, TypeScript, Product

  2. 3 min read

    Locking down a CRM with Postgres row-level security

    How Postgres row-level security keeps each school's leads private in a Supabase admissions CRM, and lets an agency import leads without reading any.

    Supabase, PostgreSQL, Security