Nobody launches a slow university website. They launch a fast one and then spend four years adding things to it. Slowness on a .edu is almost never a hosting problem and almost always an accumulation problem. Here is how the accumulation happens, in roughly the order it shows up.
Why does a university website get slower every year?
Because the site keeps gaining weight nobody removes: marketing tags added and never retired, uncompressed images uploaded by hundreds of editors, plugins and modules installed for a single campaign, third-party embeds for tours and chat, and a caching layer that quietly stops working after an upgrade. Each addition is defensible. The total is not.
Which of those costs the most?
In the audits we run, three items account for the majority of the damage:
- Editor-uploaded images. A 4MB hero image on a program page will outweigh every optimisation the build team did.
- Third-party scripts. Chat widgets, tour embeds, analytics, ad pixels, and consent tools frequently add over a second on mobile between them.
- Uncached dynamic pages. Course catalogues and event calendars that were excluded from caching for a good reason in 2021 and never revisited.
How do we find out what is actually slow?
Measure field data, not lab scores. Pull Core Web Vitals from the Chrome UX Report for your top 20 templates, on mobile, on a 4G profile. Lab tools tell you what a page could do on a good connection. Field data tells you what a prospective student in a rural county actually experienced. Then look at LCP element by template, not sitewide.
What fixes it fastest?
A four-week sequence that does not require a rebuild:
- Week 1. Tag audit. Remove every script no one can name an owner for. This is usually the single largest win and costs nothing but meetings.
- Week 2. Image pipeline. Automatic WebP or AVIF conversion, responsive sizes, and a hard upload cap so editors cannot reintroduce the problem.
- Week 3. Caching and CDN. Restore full-page caching, add edge caching for anonymous traffic, and fix the exclusions list.
- Week 4. Front-end. Defer non-critical JavaScript, preload the hero, and self-host fonts.
Most institutions get from a failing mobile score to a passing one inside that window.
Why does it come back?
Because nothing in the publishing workflow prevents it. Speed is a governance problem wearing an engineering costume. Put a performance budget in the definition of done, run an automated check in the deploy pipeline, and review the tag list once a semester. Institutions that do this hold their gains. Institutions that treat performance as a one-off project pay for the same sprint every two years.
Does site speed still matter for AI search?
Yes, indirectly and directly. Crawlers on a tight budget fetch fewer pages from a slow site, so less of your catalogue gets indexed and summarised. And a slow page that a student abandons never becomes the source anyone cites. Why a university goes invisible in AI search covers the rest of that picture.
Where to go next
Read why university websites get slow and hard to manage, seven university website issues that cause slowdowns, and the complete guide to fixing university websites. Or book a working session and we will run the diagnostic with your team.
Seattle, WA
A full-service digital agency working in WordPress, Drupal, Shopify, Webflow, React, and React Native. We partner with universities, governments, and growing brands to ship sites and products that hold up after launch.
