<shortdiv />

Being a better A11Y It’s almost impossible to think of the world without the web. Compared to other inventions of yore, the web is the single most powerful medium of communication. Through its promise of openness, freedom and independence, the web levelled the playing field. It gave everyone the chance to transcend the limitations of their physical condition regardless of their level of ability. In spite of this promise of inclusivity, the web’s potential as a “global community” was never truly realized.

This week, I focused on the many aspects of PWAs and their role in making the web experience more streamlined across browsers and devices. Inherent to PWAs is the concept of progressive enhancement. To the untrained eye, progressive enhancement might seem akin to the concept of “it works without JavaScript”. While this is kinda sorta true (a well built PWA should work with JS turned off 🤞🏾), progressive enhancement is more about using web technologies in a so-called “layered” fashion.

In the latest stable build of Chrome, came support for desktop progressive web apps (PWAs). Similar to mobile PWAs, desktop PWAs allow users to install apps onto a device’s home screen for quick and easy access. In addition to this, they allow web apps leverage to the numerous capabilities of modern web APIs like authentication, payments and so on, without having to worry about potential security vulnerabilities. After all, a desktop PWA is basically a web browser running in its own app window context.

Push notifications are a simple way in which web applications can interact with users to provide them with timely updates and customized content. When integrated with service workers, push notifications allow web applications a more active and engaging experience that was previously reserved for mobile applications. Technically speaking, this feature is possible thanks to the Push API. The Push API is what allows web applications to receive messages from the server, regardless of whether an application or a user agent is active.

Service workers are an important player in the PWA game. Not only are they handy for keeping applications functional while offline, they are also instrumental when it comes to improving overall page load time. Working with a service worker however can be a little tricky. Because they are run in the background of a page (outside of a page’s render cycle) and are registered only once, service workers don’t always work as expected.

Offline storage is the linchpin of progressive enhancement. Under a low or unreliable network connection, the app is not dependent on a successful response from the server to be operational. Instead, it reads and writes data from a local in browser database while in offline mode. There are several ways to serve data offline. Picking the right option for your PWA ultimately depends on the type of data you’re intending to store and how big it is.

Network connectivity is a single point of failure when it comes to user experience on the web. By nature of the web’s reliance on the network, the web fails when the network b0rks. Inadvertently as developers, this means that we’re always at the mercy of network connectivity. When faced with a slow or failed network connection, there is no way for us to help websites gracefully fail. While connectivity is an issue for most mobile web applications because of the reliance on the network, native mobile apps are able to deliver an offline user experience that is on par with an online one.

Last week, we identified the trend that a large and growing number of users are accessing the web via mobile devices. With this trend in mind, we covered various strategies to building websites that load fast and seamlessly without discriminating based on a user’s bandwidth and/or connectivity. From a performance standpoint, lightning fast websites translate to lower bounce rates and an overall more satisfactory user experience. In spite of this, however, the performance of a webpage, no matter how amazing, plays only a partial role when it comes to user engagement.

Content compression is one of the simplest and most effective means to improving webpage performance. A smaller file size means lighter page load and faster download speeds, which translates to lightning fast page renders. For some, if not most of us developers, content compression is a black box that we don’t have to give much though to. Compression mechanisms automagically work by default in browsers and servers. And if you’re loading pages via a CDN like Netlify, chances are you will never have to think about compression since they compress your files for you ✨ .

This week, we focused on web performance and discussed the many strategies to improving our websites to optimize for a fast user experience. Some of these strategies involved “forcing the browsers hand” or coercing it into downloading resources in a specified order and time—hello preload and async/defer. Historically, the browser exercised full control over how and when resources were downloaded in order to paint pixels to the screen. It would make requests as they came, one at a time and block rendering while it waited on resources it needed from the server.