Making Our Sites Faster, Part 2: How We Measure Up

This is the second post in a 4-part series discussing performance on the GeorgiaGov platform.

In my last post, I talked about why site performance matters. In a nutshell, it’s because the size of your web pages, and the time it takes them to load affects whether or not many constituents can access your information.

Web guru Jeffrey Zeldman summarized this trend in his 2015 Year in Design review:

⇛ Nobody waits. Speed is to today’s design what ornament was to yesterday’s. #yearindesign

— Jeffrey Zeldman (@zeldman) December 23, 2015

Now that we’ve identified our goal to speed up our websites, the first step is to see where we are now. How quickly do our platform websites load?

Our Baseline

Back in November 2015, we ran some performance tests on about 15 pages across our platform, including 8 homepages, to get a baseline for how fast our sites load in general, and how we measure up against other state websites. We used a free tool at www.webpagetest.org to run the tests. At that time, we found that many of our platform’s homepages, including georgia.gov, load on a broadband connection in under 2 seconds. Below is a small snapshot of our findings.

We also started to look more closely at the bytes downloaded, not just page speed. Page speed can come from a number of factors, but the thing that affects a user’s data caps is just how much data we’re serving up.

Georgia.gov was serving 719 KB of data — that’s 0.7MB, and would cost an average of $.04-$.05 to download on a cheap US data plan. Many other homepages on our platform serve more than twice that much — typically because they use a rotating image banner on their homepages.

Comparison To Similar Sites

Next, we compared our page load speed to that of many other state portal homepages, and found that ours load 2 to 6 times faster than any of the other state portal homepages we tested. That’s right … Some state websites take over 10 seconds to load on a broadband connection. Yikes!

But on a mobile device with a slow 3G connection, that same georgia.gov homepage that loaded in under 2 seconds on broadband was taking 8 seconds to load on mobile — and that was the fastest page load of the bunch. (This also means most of the other state portal homepages took over 30 seconds to load on this connection!) Again, a small view of some of our tests is below.

Numbers are great for quantifying and comparing, but to get a real sense of the experience, you need to feel it. Below is a video simulation of how long it takes for georgia.gov to load on a Motorola G phone on a 3G network.

And that site/cost comparison? Well, it turns out that slower page load in Alabama really comes at a cost - their homepage serves up 2,974 KB (2.9MB) and could cost visitors more than $0.19 to load that single page.

Our Goals

It’s great to know that we’re performing well compared to other state portals. We’re doing a lot of things right, because we’ve always tried to build upon and enhance the platform with performance in mind. But our goal is not to beat the page speed of other state sites — our goal is to provide a good user experience. A constituent of Georgia isn’t affected by page loads on portal sites for Alabama, or New York, or California unless they’re doing business with that state. They aren’t our “competitors.” While it helps to know how we stack up, if all we’re doing is comparing against other states, we’ve got our eyes on the wrong prize.

We also need to consider that there are many pieces to the performance puzzle. Both page size and page speed matter, but sometimes for different reasons — and improving one doesn’t always improve the other.

Particularly for mobile devices, our page load speeds are slower than we’d like to see. But most of our pages are serving less than 1MB of data, which tells us we’re doing pretty well. In fact, the agencies who don’t have a rotating image banner on their homepages weigh in at under 0.5MB for the first page load (once a user had loaded the main elements of a site, visits to subsequent pages download much less additional data). When most mobile users have monthly caps on data, that means each carelessly loaded image, JavaScript, or font we serve makes an impact. We want to be respectful of our users, and make sure we serve all of them.

However, we struggle to set a specific number goal for our page load times — I’m not ready to say “1 second load time or bust.” That’s because meeting specific goals can be a challenge on a broad platform, when we’re juggling the needs of many on a code base that contains a lot of interdependencies.

Many of the factors that contribute to a slow load time are out of our hands. We can’t control what each agency content manager is loading on their homepage, for instance. We also can’t control how long it takes for links to external assets — such as Typekit fonts and Google Analytics — take. Then there are other places where performance gain here means functionality loss elsewhere.

So instead of putting a number value on our page speed, our goal is more nebulous and ongoing: Always Be Optimizing. Each month we’re talking through ways we can improve our code to speed up frontend performance or decrease page size across all our sites, whether it’s adjusting how elements load to speed up the perceived load time, or actually cutting image sizes to decrease the amount of data that loads. We’re exploring options, discussing lifts, and prioritizing, just like we would with any other enhancement, until we’ve hit everything we can think to improve.

We’re also going to test performance each month and compare against previous months to see if what we’re doing is working. In fact, we’ve already started doing this. Next, I’ll give you some insight into how that’s working out for us so far.

Related Posts

Related to: 

• CMS