index.md 9.2KB
title: Three takeaways for web developers after two weeks of painfully slow internet
url: https://medium.com/@zengabor/three-takeaways-for-web-developers-after-two-weeks-of-painfully-slow-internet-9e7f6d47726e
hash_url: e00ae9f67f
When we went to Hungary during the Christmas period last year I bought a 1GB data plan on a prepaid card. However, soon after I went online with my laptop the entire data allowance was used up. Strangely, I wasn’t able to add another data package. Instead, T-Mobile limited my internet access to 32kbps till the end of the month.
Since there was no easy way to fix it and I had nothing critical to do I decided to embrace the situation as an opportunity to understand how it feels to be on a slow network most of the time. I had already started reading the book Responsible Responsive Design at that time anyway so I was curious.
I learned a lot from this first-hand experience. I was mostly using the Twitter client TweetBot and its embedded browser for online reading. I had to be really patient. I learned to make up my mind whether I tap a link or a button, as it was quite expensive: I had to spend the next 1–2 minutes waiting for the web page to load. The psychology of limited internet would be a good topic for another story. Here let’s just concentrate on the key takeaways for makers of web sites, like me.
Here’s the three most important things that I became aware of during this time as a web developer:
1. Some sites never loaded
While most sites worked slowly but otherwise okay, there were some pages that simply never loaded. I couldn’t believe it so I tried many times and left the phone loading for several minutes but all in vain. Nothing appeared on those pages. Unfortunately, I don’t remember which ones but I can’t help thinking that those were single-page JavaScript apps whose loading script wasn’t prepared for these conditions and timed out before the browser could receive something to display. (Good thing I could still use Pocket to store the URL if the topic sounded interesting.)
Takeaway 1: Develop in extra slow emulated mode
It’s critical to test the sites I am making on a very slow network from the beginning. Chrome has an amazing feature for that. If I open the web developer tools (⌥⌘I on a Mac, F12 on Windows) and make sure that “device mode” is turned on (the small phone icon is blue) then I can select the network speed:
I always keep this mode turned on for the site I am working on. I need to feel the pain as soon as possible so that I immediately notice the changes that are bad for performance. Additionally, I like that I can easily disable the cache under the “Network” panel (see screenshot above) without having to purge the browser cache.
2. On some sites the text was invisible for a frustratingly long time
This was annoying. The text was already there but I couldn’t see it until the relevant fonts were downloaded. This problem only occurs on WebKit-based browsers, which means iOS and old Android browsers. WebKit is overly polite and just waits and waits, prudishly hiding the text until the font is downloaded. In contrast, Internet Explorer is so rude it will show the site immediately with the fallback font, exposing me to the flash of unformatted text (FOUT) when the fonts are applied. The pragmatic solution is Chrome, both desktop and Android (as well as Opera which uses the same rendering engine): they hide the text to avoid FOUT but only for a maximum of 3 seconds. It’s a smart trade-off between the two extremes. Fortunately, these browsers cover the majority of the browser population. But there are still users out there with old Androids and iPhones, like me, who are sometimes on a very slow network and don’t have the fonts cached.
Takeaway 2: Web font loading must be controlled
After I’ve done everything Ilya Grigorik says about loading web fonts I created a tiny script called Zenfonts to fix both the “invisible text” problem and the FOUT, without changing the browers’ loading mechanism.
3. Well-designed apps worked wonderfully
I am very grateful for those apps that worked flawlessly under such conditions. The three most prominent being Apple’s own Mail client, Reeder and Pocket. All of them downloaded and stored their items when the network was available and I could access those items even offline. When I marked something as read or starred, all three apps queued these requests until they could send them to the server. I was especially fond of Pocket’s sharing extension which worked lightning fast, even if everything else was unbearable. These three apps never complained that the network timed out. They just worked.
In comparison, FastMail’s app was unusable. I tried it several times but my Inbox never loaded. Their app is probably just a wrapper for the web app. Much easier for the developer but much less value for the user.
Takeaway 3: Design apps for offline & async usage
Design offline-first apps (both native and web apps). When you make a web app, make it offline-first. When you make a native app, don’t settle for a mindless wrapper. Cache content. Queue up outgoing data and actions without blocking the user. Handle conflicts. This makes a huge difference in the usability of the app and can literally open up new markets.
I am so glad this happened. There are different levels of understanding our users, especially those with special requirements. Nothing beats becoming them for a longer period of time.