If you thought website performance issues were limited to the stuffy corporate server rooms, think again. Only a few hours ago, Washington’s new health insurance exchange site, HealthCare.gov, ground down to a halt. Thousands of site visitors were either unable to load pages, unable to create accounts, or experienced severe crashes. Quite the bitter pill to swallow, since heated debates surrounding American health insurance have been swirling for the better part of a decade.

By 2pm today, the Department of Health and Human Services (HHS) issued a notice that read: “The system is down at the moment. We’re working to resolve the issue as soon as possible. Please try again later.” Faced with loading times upwards of 20 minutes, server-side technicians tried to limit the problem by changing up landing pages and providing alternate links for generic insurance inquiries. This is surprising because HHS had modeled the site to limit incoming traffic, much in the same way Gmail’s first hours were invitation-only.

How much proved to be too much for this government-created site that had already anticipated high volume? 4.7 million unique visits over 24 hours, which translates to roughly 196,000 visitors an hour, 3300 visitors a minute, and 54 visitors each second. When you think about it, that’s not even that many – Google processes over 34,000 searchers per second 86,400 times a day.

There’s an important lesson to be gleaned from this fiasco – no one is immune to lackluster website performance, not even governments. Clearly, HHS knew beforehand that the launch of HealthCare.gov would likely result in delayed site speed, yet they also completely understimated how unprepared the site was to handle the actual influx of visitors.

Yet a quick look at HealthCare.gov doesn’t reveal any glaring performance no-nos. If anything, the poor performance probably has more to do with the HHS’s servers rather than the actual site design. So, instead of bashing HealthCare.gov, we’re going to go over a few of the things that they did right. In fact, if these considerations weren’t already in place, the site would have performed way worse than it did:

1. Avoiding Text-Heavy Images

You’ve seen them plenty of times before – headers, footers, and banners that are basically glorified slogans or catchphrases that just litter a company site, as if some graphic designer had been given the keys to the universe and decided web performance was no longer something he had to worry about. Yes, these images slow down performance. HHS doesn’t have any of them on any of their pages, as far as we can tell, so that’s one checkoff.

2. Avoiding Images, Period

The landing page may make you think otherwise, but the HealthCare.gov site doesn’t actually feature that many images. In fact, the only image is the single one on the landing page. All the other pages are fairly text-heavy and image-sparse, which is exactly how a good, lean site should be. A few embedded videos here and there certainly could slow things down, but due to the nature of the site it’s easy to see why these sorts of explainer videos are necessary. Another checkmark.

3. Splitting Longer Readings Into Separate Sections

Government sites are notorious for being relics of the ancient world. They’re usually overly text-heavy, as if someone were trying to cram as many tiny words as possible onto each and every page. Thankfully, HealthCare.gov is obviously a product of 21st century design. Each section, from “Individuals & Families” to “Small Businesses”, is split up into bite-sized offerings with lots of white space. This helps distribute traffic across the server and frees up processing speed. Simple considerations like these make huge differences for site visitors.