The State of Web Performance in Higher Education

Some in this community might say I’m a bit of a web performance curmudgeon. Five of my six HighEdWeb presentations have in some way had a focus on performance. And to be honest, at the rate we’re going, next year is going to be as well.

Let’s take a walk down memory lane

In 2012 I noted that the average industry web page was 1042 KB. Of the 34 higher ed homepages that were using Responsive Web Design (RWD), the average was 1.4 MB on mobile. So we were easily above average. But that was still the early days of RWD. It was easily one of the biggest topics for the 2012 conference. In fact, there were ten presentations that year that mentioned RWD in either the title or description. So maybe we were still figuring it out. Maybe we’d get better.

Maybe I’m wrong.

The not so happy truth

The number of higher ed homepages I track for performance purposes has grown quite a bit since 2012. The current count is 1,770, and not all are responsive. I’ve run every one of them through WebPageTest to try and get a handle on how we’re doing today.

First, let’s look at the industry as a whole. According to the HTTPArchive, the desktop median size (based on over 4 million urls) is 1.95 MB, and the mobile median is 1.75 MB. Certainly a climb from 2012. But higher ed is doing much worse.

 

Render Start  Visually Complete Load TIme Speed Index Requests Download Size
Desktop 1.9s 7.7s 8.5s     4,107 96 4.3 MB
Mobile 7.4s 21s 26s 12,449 86 3.9 MB

All stats are the median score
Mobile stats measured using iPhone 8, 3G connection

I’d like to pause for a moment to address the fact that the median load time for mobile is twenty-six seconds. Stop reading, open your phone, load a browser window, and count to 26. Go ahead, I’ll wait.



Welcome back. Now imagine how you’d feel waiting that long just to view the homepage of a college or university you’re interested in attending. Because while we tend to test our sites on top-of-the-line mobile devices and screaming fast university wifi networks, the fact is, many of our potential students don’t have that luxury.

For instance, my 16-year-old son is right about the grade and age of many of our target demographics, and he’s rocking an iPhone 6 (released September 2014) and it will likely remain his phone for a couple years. And even his device would be considered more capable than many average Android devices these days.

So what do we do about it?

It’s difficult to make blanket recommendations about how to fix slow websites. After all, every site is unique. Well… unless you have a hero video. And if you do, step one is to remove the hero video. Congratulations, you’ve probably just fixed your most egregious performance issue. After that, you need to task your developers with tracking down and fixing the low-hanging fruit such as uncompressed/incorrectly sized images, and unnecessary javascript. This can be done with a variety of free tools available on the market and in browsers, such as Lighthouse and WebPageTest. And once your performance issues have been addressed, either set up monitoring, or set a calendar reminder to run tests, or use automated testing. The important thing is that you do it on a regular schedule. And if you’re curious where your site ranks in the list of 1,770, contact me from your university email account and I’d be happy to share.

We need to remember who our homepage is for. It’s not for our internal audience or our marketing team. While we have access to top-of-the-line devices and high-speed connections, not all of our users do. Dial-up and sub-3G connections are still common in America. So if the fancy on our homepage is going to cause a less than adequate experience for visitors on low to mid-range mobile devices, then fancy’s gotta go. Focus on the content. Wow them with a clear and concise user experience. Get them to the information they need quickly.

Let’s be honest. Your visitors may not consciously notice that your site is fast and easy to use… but they will certainly notice if it is not.