We recently passed the one-year anniversary of Hurricane Helene and its devastating impact on Western North Carolina. As a web developer, I am thinking again about my experience with the mobile web on the day after the storm.
We recently passed the one-year anniversary of Hurricane Helene and its devastating impact on Western North Carolina. When the storm hit, causing widespread flooding, it wasn’t just the power that was knocked out for weeks due to all the downed trees. Many cell towers were damaged, leaving people with little to no access to life-saving emergency information.
As a web developer, I am thinking again about my experience with the mobile web on the day after the storm, and the following week. I remember trying in vain to find out info about the storm damage and road closures—watching loaders spin and spin on blank pages until they timed out trying to load. Once in a while, pages would finally load or partially load, and I could actually click a second or third link. We had a tiny bit of service but not much. At one point we drove down our main street to find service; eventually finding cars congregating in a closed fast-food parking lot, where there were a few bars of service!
When I was able to load some government and emergency sites, problems with loading speed and website content became very apparent. We tried to find out the situation with the highways on the government site that tracks road closures. I wasn’t able to view the big slow loading interactive map and got a pop-up with an API failure message. I wish the main closures had been listed more simply, so I could have seen that the highway was completely closed by a landslide.
Other emergency sites I was able to reach had excessive media being loaded like image sliders. At one point, I was linked to an emergency site by a recently updated banner, navigated there, and then clicked an emergency message there that looped me back to the original site I was on. Some time after the storm hit, the local county site put up a message that they were displaying a “faster loading” experience. Which begs the question of why sites like this are not fast loading to begin with.
The best bulleted list I’ve ever read
With a developing disaster situation, obviously not all information can be perfect. During the outages, many people got information from the local radio station’s ongoing broadcasts. The best information I received came from an unlikely place: a simple bulleted list in a daily email newsletter from our local state representative. Every day that newsletter listed food and water, power and gas, shelter locations, road and cell service updates, etc.
I was struck by how something as simple as text content could have such a big impact.
In having the best information provided in a simple newsletter list, I found myself wishing for faster loading and more direct websites. Especially ones with this sort of info. At that time, even a plain text site with barely any styles or images would have been better.
Simply going back to the basics can make the web a better place
Outside of the storm situation, we need to talk about loading speed and performance. For many years now, loading speed has been more important than ever because most web traffic is on mobile devices. That’s nothing new. Yet the web is still filled with a lot of bloat. We have free browser tools to test speed, performance, and slow connection speeds. And we have lightweight architectures or frameworks to choose from.
Is it necessary to have 5MB+ of loaded network assets and over 100 network requests to view a simple brochure-style site?
Why do I still need to download a 10MB PDF for most restaurants, when that could be headings and paragraph text on a webpage that is easy for the restaurant to edit?
Does a WordPress site really need 40 or more plugins?
Why isn’t page speed discussed and tested earlier in the design and development process? Why does this not seem like a big concern to a lot of businesses?
Limited connectivity isn’t something that only happens during natural disasters. It can happen all the time in our daily lives. In more rural areas around me, service is already pretty spotty. In the past, while working outdoors in an area without Wi-Fi, I’ve found myself struggling to load or even find instruction manuals or how-to guides from various product manufacturers.
We deserve better from not just our government websites, but our local utilities, banks, and healthcare providers. Some are better than others. Out of curiosity, I ran a Google Page Speed Insights scan on one government site that had given me trouble, and received performance scores that were 40 out of 100 and 26 out of 100.
We deserve better not just in terms of performance, but with content, information architecture, and basic functionality.
A local county has a PDF to explain how to use a part of the website, including what parts of it don’t work and need to be sent manually. At one point, it displayed a message that the software was only working in Microsoft Edge and not Chrome. The last couple times I used my dental insurance website, it was completely not mobile responsive, requiring the old-school pinch zoom to even get to anything on the page. And the provider search was barely usable and hard to find. This is shocking to see for multi-billion and multi-million dollar companies.
These are times when we need to go back to basics when building for the web. For a baseline level of page speed, we can avoid too many scripts, giant media assets on key pages, and holding up the page from loading. We can build things so the JavaScript bundles are not excessively large. Going beyond basics, there’s a lot that can be optimized for the “first contentful paint” and reducing the time before the page can be interacted with (these are part of page speed scans).
Just using Semantic HTML and the correct native elements, we also can set a baseline for better accessibility. And make sure interactive elements can be reached with a keyboard and screen readers have a good sense of what things are on the page. Making websites responsive for mobile devices is not optional, and devs have had the CSS tools and experience to do this for over a decade. Information architecture and content is important to plan and revisit. What content are you really trying to provide and how do you get to it?
To find areas like these that need improvement, it might just take a conversation with your users and developers. They already know and are experiencing the pain points. The information your user needs the most could just be a simple paragraph or a bulleted list.
