University websites run comfortably for most of the year and struggle on a handful of busy days. The cause is rarely an undersized server. It is that on those days most pages can no longer be served from a stored copy. This article explains, in plain terms, how Drupal stores pages, what a CDN does and does not speed up, and where to start when you want the site to hold up.
A page loads in half a second in March and takes ten seconds on the first morning of registration. Same site, same code. The only thing that changed is how many pages the server had to build from scratch that day. Speeding up a Drupal site is mostly about reducing that number.
When does a university website actually slow down?
For most of the year, the majority of visitors are not signed in. Prospective students browse programmes, parents open the contact page, search engines crawl the news section. All of those visits can be answered from a stored copy, and the server barely works.
On busy days the mix changes. A large share of visitors are now signed-in students. Once someone signs in, the page becomes personal to them, and a copy stored for everyone no longer fits. The server starts building thousands of pages from scratch at the same time.
Two other things pile on. Seat counts and timetables are read from another system and cannot be held for long, because they must not go stale. And when the academic calendar or a university-wide announcement changes, every page showing that information has to be rebuilt.
When all three land in the same week, the site slows down. The goal is not to shave milliseconds off an average day. It is to get through those days without an outage.
How Drupal stores pages
After Drupal builds a page, it keeps a copy. The next person who asks for the same page gets the stored copy instead of waiting for it to be built again. This is the main reason a Drupal site feels fast, and it works out of the box.
For visitors who are not signed in
This is the easy case. Everyone sees the same page, so one stored copy serves everybody. Programme pages, news and contact details go out to thousands of people from the same copy, and the server does almost no work.
For signed-in users
The moment someone signs in, part of the page becomes theirs alone. Their name, their notifications, their courses. A single copy stored for everyone can no longer be used.
Drupal handles this by splitting the page in two. It still stores the parts that are the same for everybody and rebuilds only the personal parts on each visit. So a fraction of the page is rebuilt rather than the whole of it.
If those personal parts are still slow, BigPipe steps in. The approach was first developed at Facebook, and Drupal adopted it into core. What it does is straightforward. The shared parts of the page are sent immediately, and the personal parts follow as soon as they are ready, so the visitor watches a page fill in rather than staring at a blank screen. According to the Drupal documentation, this has been switched on by default in the standard installation since version 8.5, which means it is already running on most sites.
| Visitors not signed in | Signed-in users | |
|---|---|---|
| How the page arrives | From a stored copy | Shared parts stored, personal parts rebuilt |
| Cost to the server | Almost none | Some work on every visit |
| Risk on a busy day | Low | This is where the load sits |
What happens when content changes
The hard part of storing pages is not filling the store. It is refreshing the right pages at the right moment. On a university website the same piece of information appears in dozens of places. One academic's name sits in a department listing, on a course page and in a news item at the same time.
Drupal records which content each stored page depends on. When that content changes, it refreshes only the pages that depend on it and leaves the rest alone. One name change does not ripple across the whole site.
The real mistake here is the habit of clearing everything after every edit. That forces the entire site to be rebuilt, and it is usually done at the worst possible moment. The fix is to stop treating that button as part of the daily routine.
What a CDN speeds up, and what it does not
A CDN serves a site's files from servers spread around the world, so images, video and fonts arrive from somewhere near the visitor. On campus sites those files make up most of the page weight, so the gain is real.
On the Drupal side this is handled by the CDN module. One detail affects planning. The stable release works with Drupal 9 and 10, while support for Drupal 11 is still being tested. An institution already running Drupal 11 should know that in advance.
A common mistake follows the installation. Once the CDN is in place, the performance problem is assumed to be solved. But a CDN distributes finished files, it does not build pages. The personal page a signed-in student sees is built on the institution's own server every time, and that is where the load sits on a busy day.
University IT pages say this plainly. One large public university's Drupal guidance tells site owners that its CDN only applies to visitors who are not signed in, and that signed-in users bypass it entirely. Stanford takes the distinction a step further. Its IT services describe a centrally managed Drupal platform for department and unit sites, with a separate hosting option for sites that carry heavy traffic. Not every site is treated the same way.
Pages that show live data
Seat counts, timetables and results come from another system and cannot go stale. Because they cannot be stored, they are the most expensive pages on the site.
Three simple measures help. First, separate the live element from the rest of the page, so only that small piece is rebuilt each time while everything around it stays stored. Second, give it a short lifetime rather than none at all. A seat count that is up to a minute old is acceptable in most situations, and that minute spares the other system thousands of queries. Third, decide what the page shows when the other system does not answer. Showing the last known figure with a timestamp beats showing nothing.
We covered the data side of these pages in Drupal student information system integration.
Running many sites from one platform
Many universities run dozens of faculty and unit sites from a single setup. A common assumption follows: because the sites share a platform, the stored copies must be shared too. They are not. Each site keeps its own.
That has two consequences. An improvement made on one site does not carry over to the others on its own. And because sites sharing a server also share its resources, a busy week for one department can slow another department's pages.
The wider trade-offs of this setup are covered in managing university websites with Drupal multisite. For performance, the practical conclusion is to identify which sites peak and plan for those separately.
What to measure
Measurement tools have a blind spot worth knowing about. Most of them test the site without signing in, which means they never see the pages that struggle on a busy day. A homepage can score perfectly while the course selection screen falls over.
So two views are needed. The first covers the pages visitors see without signing in. Google's speed metrics assess that side and feed into search ranking, and we covered those in Drupal SEO. The second covers the pages signed-in users see, measured on the server rather than in a browser, and that is usually where the real problem is.
The most useful measurement is already available to you. Last year's server logs from your busiest week will tell you more than any testing tool. Which pages were requested at which hour, and which requests never finished, is recorded there.
Where to start
Starting at least a month before the peak and following this order works well.
Begin by confirming that the caching settings are switched on. It is a half-hour check, but on sites where something was turned off it makes the single biggest difference on the list.
Next, go through the pages signed-in users see and work out which parts are genuinely personal. On most sites those parts are fewer than expected, and everything else can be made storable.
Then separate the elements that show live data, give each one a sensible lifetime, and decide what each displays when the other system is unavailable.
Finally, run a test modelled on last year's busiest hour. That test has to run as a signed-in user, otherwise the pages causing the problem are never exercised.
It is worth setting expectations alongside the work. Drupal gives you strong tools here, but they do not arrive tuned to your institution. Deciding how stale each piece of information is allowed to be is an institutional call rather than a technical one, and it is made with the registrar in the room.
The Drupal platforms that the Drupal4edu team at Drupart builds for institutions such as Yeditepe University, Istinye University and Medipol University are set up to absorb these peaks in exactly this way. You can read more about our approach on the Drupal in higher education page.
Frequently asked questions about Drupal site speed
Will a bigger server fix the slowdown?
Up to a point, but it is the most expensive route. Most of the pages that struggle on busy days are being rebuilt because they cannot come from a stored copy. With the caching settings corrected, the same server handles far more visitors. The sensible order is to check the settings first, make everything that is not personal storable, and only then discuss hardware if it is still not enough.
Is a CDN enough on its own?
No. A CDN distributes images, video and fonts, which cuts page weight noticeably. But the personal page a signed-in student sees is built on the institution's own server regardless, and that is where the load sits on a busy day. Treating a CDN as a useful addition rather than the main answer gives a more realistic result.
Can live figures such as seat counts be stored at all?
They can be stored briefly, and in most cases they should be. A seat count that is up to a minute old is usually acceptable, and that minute prevents thousands of queries reaching the other system. What matters is choosing the lifetime deliberately and agreeing it with the registrar. It is equally important that the page does not come back empty when the other system is unavailable, and shows the last known figure with a timestamp instead.
Should the cache be cleared after every change?
No, and it is a habit worth breaking. Drupal records which content each stored page depends on, so it refreshes the affected pages by itself when something changes. Clearing everything forces the whole site to be rebuilt, and that usually happens at the busiest moment. Keep that button for exceptional situations rather than making it a daily reflex.