University websites are slow for structural reasons, not lazy reasons. Decades of departmental sub-sites, legacy CMS instances, and every college wanting its own hero video have compounded into pages that take four to eight seconds to load on the phones prospective students actually use. Fixing it is a program, not a project. Here is the working playbook we use with universities in 2026.
Why are university websites so slow?
Five compounding causes:
- Sub-site sprawl. Twelve colleges plus twenty programs plus every research center run separate templates.
- Legacy CMSes. Cascade, Sitecore, or an old Drupal 7 still powers a nontrivial share of the pages.
- Third-party bloat. Analytics, chat, tour, video, form, and accessibility widgets stacking on every page.
- Hero video autoplay. A 12 MB looping video on the homepage is standard and standardly damaging.
- Under-invested hosting. Shared or unrightsized infrastructure that groans under the September admissions rush.
How do we measure the real problem?
Do not benchmark on the homepage. Benchmark on the pages that matter: top-visited program pages, top-referred landing pages, the RFI form, and the giving page. For each, capture:
- Largest Contentful Paint on mobile (target under 2.5s)
- Interaction to Next Paint (target under 200ms)
- Cumulative Layout Shift (target under 0.1)
- Total blocking time and total page weight
Use PageSpeed Insights, WebPageTest, and Chrome UX Report field data. The field data is what Google actually uses.
Which fixes move the needle fastest?
/1. Kill the autoplay hero video
Replace the looping video with a compressed hero image and a "watch our story" button that loads the video on interaction. This one change often shaves two seconds off homepage LCP.
/2. Compress and modernize every hero image
Convert to WebP or AVIF at the actual display size. Serve responsive images. A 2.8 MB PNG becomes a 140 KB WebP.
/3. Audit third-party scripts brutally
Every tag, every widget, every embed. Keep the two you actually use. Move the rest to load on interaction or defer entirely. Your accessibility overlay, if you have one, is very likely making the site both slower and less accessible.
/4. Consolidate CSS and JavaScript across templates
Twelve colleges shipping twelve slightly different theme bundles is twelve times the payload. Move to a shared design system with per-college theming layered on top.
/5. Move to a CDN and modern hosting
Cloudflare, Fastly, or Akamai in front, with WP Engine, Pantheon, or Acquia behind. This is the single biggest reliability investment a university can make in its site.
How do we prevent it from getting slow again?
Instrument performance as a governance rule, not a one-time cleanup. Publish a page-weight budget per template (for example: 1.2 MB total for a program page, 200 KB for CSS/JS combined) and enforce it in CI. New templates that exceed the budget fail the build.
Does site speed affect enrollment?
Yes, and the effect is measurable. Every additional second of load time drops prospective-student engagement by 8 to 15 percent depending on program type. On mobile, that effect roughly doubles. Slow sites also underperform in AI Overviews and Google's Discover feed, both of which increasingly send traffic to universities.
What about the many legacy sub-sites we cannot rebuild this year?
Do the four cheap fixes on every legacy sub-site: compress images, defer non-critical scripts, remove autoplay video, and put a CDN in front. You will not hit A-grade Core Web Vitals, but you will move from red to yellow, which is enough to protect ranking and enrollment until a full rebuild is funded.
Where to go next
Read the nine web development factors for growing colleges, how to choose a college website platform, and the seven features colleges need. Or book a performance audit with our higher-ed 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.
