DEV Community

loading...
Cover image for The web should be F.I.R.E

The web should be F.I.R.E

Tsowa Babangida
Web developer with a passion for inclusive and performant experiences on the web #webperf #webdev
Updated on ・5 min read

BACKGROUND

As a user on the web, when you visit a website, you expect it to:

  • load as fast as possible and display relevant information properly without distractions.
  • be easy to interact with.
  • load properly with whatever network conditions you're working with.
  • give you another reason to come back.

Hence, any website or web application that falls short of the aforementioned points is considered unattractive to its user and can have diverse effects on different fronts. From a business point of view and whatnot.

Having a presence on the web allows your clients to easily find you, drives traffic towards your business, improves client relations and ultimately increases revenue. But not just any presence. You need "good" presence to drive those sales up and retain users. To do this, a website or web application should be:

  • Fast, (F)
  • Integrated, (I)
  • Reliable and (R)
  • Engaging (E)

The characteristics of an awesome website or web application.

🔥🔥🔥🔥🔥🔥🔥🔥🔥

HOW DO I MAKE IT FIRE?

Glad you asked this question. Let's take each of the characteristics one at a time, shall we.

THE WEB SHOULD BE FAST (F)

Users hate it when the website does not load fast, responds slowly to their input or takes them a relatively long time to get to what they need. So, a fast presence on the web is highly essential.

HOW DO I DO THIS?

GOOGLE explains to us the "RAIL" model that can be used to improve performance. With the goal of helping designers and developers improve user experience.

The RAIL model is a performance model that breaks the lifecycle of a website or web application into four aspects, namely:

  • Response: Response to user input should be fast so that the user does not lose interest in performing a task.
  • Animations: Animations such as visual animations (loading indicators), dragging and scrolling should be smooth.
  • Idle: Maximise the use of idle time to load and display non-critical data or information.
  • Load: Deliver fully interactive content to the user as fast as possible (ideally, content should be available under 5 seconds).

To measure your website's RAIL performance, you can use the following tools:

These tools help you summarise where your application is doing good or not in terms of performance by measuring several performance metrics (Explained in a later post).

Knowing where your application is doing badly can help you strategise on how to fix performance issues. And to make a website or an application fast, you can:

  • Optimise critical rendering path,
  • Optimise loading performance,
  • Use next-gen image formats e.g WebP,
  • Optimise rendering performance e.t.c.

All of which, I will try and explain in a later post.

Another is the APP SHELL ARCHITECTURE primarily used to build Progressive Web Apps (PWAs) that are reliable and load instantly on the user's screen.

An Application Shell is the minimum HTML, CSS and JavaScript required to load a user interface. Caching the app shell using a service worker can ensure instant loads and good performance when the user opens the app while dynamic content is loaded via JavaScript.

If you plan to build a Progressive Web App(PWA) or a Single Page Application (SPA), using the app shell architecture is the way to go.

THE WEB SHOULD BE INTEGRATED (I)

The user's experience on the web should feel as close as possible to what the user is used to. And in most cases, it is their device(s).

HOW DO I DO THIS?

To make the experience integrated, delivering your website or application as a Progressive Web App(PWA) is the most commonly used approach out there. Companies such as Twitter, Instagram, UBER and Forbes use PWAs to deliver fast and integrated experiences to their users.

If you want to go a step further, you use new-generation web APIs like the Payment Request API and the Credential Management API to give your user a more native-like experience on the web.

THE WEB SHOULD BE RELIABLE (R)

Not all your users are going to have the latest 5G phones and access to fast network connections. As a matter of fact, a large percentage of the world population does not have access to 4G connections using 3G or sometimes 2G connectivity on the internet. So a website designed and developed with that in mind and can be accessed with even the slowest of network connections at least once is considered reliable.

HOW DO I DO THIS?

Luckily, there are tools available to help with that like the Service Worker and Browser Cache APIs.

With Service Workers and the Browser Cache API, you can store and retrieve network responses to allow your application retrieve data and resources even when the user is offline.

THE WEB SHOULD BE ENGAGING (E)

Engagement goes beyond functionality and makes the user's experience delightful by making it easier for the user to do what needs to be done.

HOW DO I DO THIS?

To give the user an engaging experience, you can make use of the Web Push & Notifications API so that your application is always up-to-date and re-engages the user through push notifications.

But at the end of the day, the easiest way to do this is to design beautiful user interfaces and experiences.

CONCLUSION

Making a website FIRE can seem like a daunting task after reading this post. But, it isn't so. In summary to make your website or application fast, integrated, reliable and engaging, it is as simple as:

  • Designing beautiful user experiences,
  • Using Lighthouse to audit your website.
  • Following suggestions by Lighthouse on how to improve performance such as using next-gen image formats etc.
  • Using service workers and other APIs (where necessary) to make it engaging for the user, feel as close to the user's device as possible and reliable for user's in poorly connected areas.

In the next post, we'll be diving into the world of USER-CENTRIC PERFORMANCE METRICS and what they stand for when working with tools such as Lighthouse.

Discussion (0)