We recently celebrated the one-year anniversary of Hurricane Helene and its devastating impact on Western North Carolina. As a web developer, I’m thinking again about my experience with the mobile web the day after the storm.
We recently celebrated the one-year anniversary of Hurricane Helene and its devastating impact on Western North Carolina. When the storm hit, causing massive flooding, it wasn’t just power that was out for weeks with all the trees downed. Many cell towers were damaged, leaving people with little or no access to life-saving emergency information.
As a web developer, I’m thinking again about my experience with the mobile web the day after the storm and the week after. I remember trying in vain to get information about storm damage and road closures – watching loaders go back and forth over blank pages until it was time to try to load. Sometimes, pages would eventually load or partially load, and I could actually click on the second or third link. We had a little service but not much. At one point we walked down our main road to find service; Eventually a bunch of cars were found 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 status of highways on the government site, which keeps track of road closures. I wasn’t able to view the large slow loading interactive map and got a pop-up with an API failure message. I wish the major closures had been listed more simply, then I could have seen that the highway was completely closed due to landslides.
Other emergency sites I was able to access had heavily loaded media, like image sliders. At one point, I was linked to an emergency site by a recently updated banner, navigated there, and then clicked on an emergency message there that redirected me back to the original site I was on. Shortly after the storm, the local county site posted a message that they were experiencing a “fast loading” experience. Which raises the question why such sites do not load fast in the beginning.
Best bulleted list I’ve ever read
With a developing disaster situation, obviously not all information may be accurate. During the outage, many people received information from the local radio station’s ongoing broadcast. The best information I found came from an unexpected place: a simple bulleted list in our local state representative’s daily email newsletter. Every day that newsletter listed food and water, electricity and gas, shelter locations, road and cell service updates, etc.
I was amazed to see how something as simple as text could make such a big impact.
After providing the best information in a simple newsletter list, I found myself wishing for faster loading and more direct websites. Especially those who have this kind of information. At that time, a plain text site with barely any style or images would have been better.
Simply going back to basics can make the web a better place
Besides storm conditions, we need to talk about loading speed and performance. For several years now, loading speed has become more important than ever as the majority of web traffic occurs on mobile devices. This is not a new thing. Yet the web is still full of a lot of crap. 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 just to view a simple brochure-style site?
-
Why do I still need to download a 10MB PDF for most restaurants, when that can be a headline 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 was page speed not discussed and tested earlier in the design and development process? Why doesn’t this seem to be a big concern for many businesses?
Limited connectivity is not something that only happens during natural disasters. This can happen all the time in our daily lives. In the more rural areas around me, service is already pretty bad. In the past, when working outside in an area with no Wi-Fi, I had difficulty loading or even finding instruction manuals or how-to guides from various product manufacturers.
We deserve better, not only from our government websites, but also from our local utilities, banks and healthcare providers. Some are better than others. Out of curiosity, I ran a Google Page Speed Insights scan on a government site I had trouble with, and got performance scores that were 40 out of 100 and 26 out of 100.
We deserve better, not only in terms of performance, but also in terms of content, information architecture and basic functionality.
One local county has a PDF to explain how to use a portion of the website, including which parts of it don’t work and need to be sent in manually. At one point, it displayed a message that the software was only working in Microsoft Edge, not Chrome. The last few times I used my dental insurance website, it was not completely mobile responsive, requiring an old school pinch zoom to get 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.
This is the time when we need to go back to basics when building the web. For a basic level of page speed, we can avoid too many scripts, huge media assets on key pages, and blocking the page from loading. We can make things so that JavaScript bundles don’t get excessively large. Going beyond the basics, there is a lot that can be optimized to “paint content first” and reduce the time it takes to interact with a page (these are part of the page speed scan).
By using semantic HTML and the right root elements, we can also set a baseline for better accessibility. And make sure that interactive elements are accessible from the keyboard and that screen readers have a good understanding of what’s on the page. Making websites responsive for mobile devices is not optional, and developers have had the CSS tools and experience to do so for over a decade. Information structure and content are important for planning and reviewing. What exactly is the content you are trying to provide and how do you achieve it?
Finding areas that need improvement may require conversations with your users and developers. They already know and experience the pain points. The information your user needs most may be just a simple paragraph or bulleted list.
<a href