One request, one response

Tom Slutsky

February 29, 2024

min read

Serving super-performing widgets to hundreds of millions of users a month is not easy. This simple approach can help you do it.

In the world of widget development, efficiency is crucial. At Loox, widgets are our bread and butter, so to be more efficient, we've embraced a new approach: 'One Request, One Response.' This method is tailored for embedded widgets, recognizing their unique requirements separate from full-scale web applications. Learn about the strategies behind this approach, designed to minimize network overhead and enhance widget performance.

First and foremost, It's essential to understand that your widgets play a supporting role rather than taking center stage. Despite their attractiveness and usefulness, users are not specifically searching for or bookmarking widgets. Instead, they’re integrated into a webpage to fulfill a particular purpose and provide assistance within that specific context.

This is a very important realization and it has significant implications.

We will start by talking about how resource management works on the web.
Let's say we have a simple static webpage (a dynamic page is just a static page that was generated on demand and not preemptively) that welcomes everyone with a good morning or a good night greeting according to the time:

1// main.js
2
3const date = new Date();
4if(date.getHours() > 16) {
5	const body = document.querySelector('body');
6	body.classList.add('night');
7	body.innerText = "Good night! 🌙"
8}
9
10// index.html
11
12<!DOCTYPE html>
13<html>
14	<head>
15		<link rel="stylesheet" href="./styles.css"></link>
16	</head>
17	<body>
18		Good morning! 🌞
19		<script src="./main.js"></script>
20	</body>
21</html>
22
23
24// style.css
25
26body {
27	background-color: yellow;
28}
29
30body.night {
31	background-color: black;
32	color: white;
33}

Now let's analyze what is happening here:
First, a user will hit our URL and be served with an HTML document. Only then will the browser start parsing the document and as it goes along, ask for more resources, hence, the CSS document and then the Javascript document.

As you can see in the diagram, even though our app is tiny, it is pretty chatty! 3 requests are going from our browser to the server, and each is blocking the rendering until it resolves. That means that until the request for the CSS file is resolved our app is not styled, and even after that it is not responsive until the request for the Javascript file is resolved.
When considering that network requests are most likely the slowest part of the rendering lifecycle, we can come to the conclusion that this pattern might not be ideal.

Now zoom out for a second. We were talking about rendering an entire app, which means:

We have full control of the assets we send and can pull different levers to manipulate the experience to our liking.
Clients hitting our app are intentional about visiting our app and will probably tolerate a few milliseconds of delay in its loading.

However, when talking about rendering an embedded widget, it is just not the case.
Our widget is already at the bottom of the rendering queue. We might have little control over the resource management, if at all and our widget might be requested very late in the rendering flow, way after most of the app was already rendered.

In addition, not only that clients are not visiting our app intentionally, but they are probably not even aware of our "existence" as a separate app.
The only one who knows this is the embedding app owner and they want to provide a great experience for their users, regardless of those limitations.

What can we do about it?

Under these conditions, we still want to provide a great experience. We can't beat the speed of light, but we can do some things to minimize our loading time and leverage the fact that we are rendering a widget and not an entire app.

Inject critical styles early (if possible)

If we have the option, we should try to inject our most critical styles as early as possible. That means we will look for ways to add those styles to the document even before our widget is requested.Most times we can have a way to take part in the app's resource loading.

When this is impossible we can explicitly guide (or ask) the app's developers to add our styles in the app's <blog-code-tag>head<blog-code-tag> element.

This should help us avoid flashes of unstyled content and some layout shifts.

Inlining resources

We're dealing with network calls that are dragging their feet, causing delays.

Our goal: dodge these calls.

The strategy: Inlining.

It’s not the usual route, but it’s effective for embedding styles and Javascript without extra network chatter.

Style tags

We place <blog-code-tag>style<blog-code-tag> tags directly in the HTML. This approach is quick and efficient, especially for essential styles. It ensures immediate availability of styles, cutting down on the time waiting for external CSS to load

Inline styles

We use the <blog-code-tag>style<blog-code-tag> attribute for direct application to HTML elements. It's a focused method, suitable for unique, element-specific styling. However, it's best used sparingly to avoid cluttered HTML.

Script tags

We embed small, critical JavaScript snippets using <blog-code-tag>script<blog-code-tag> tags in the HTML. This reduces external requests. For larger scripts, external loading with defer or async attributes is recommended to prevent blocking the page's rendering.

For example, we can change our simple example from above and reduce all subsequent network calls:

1<!DOCTYPE html>
2<html>
3<head>
4    <style>
5        body {
6            background-color: yellow;
7        }
8
9        body.night {
10            background-color: black;
11            color: white;
12        }
13    </style>
14</head>
15<body>
16    <script>
17        const date = new Date();
18        if (date.getHours() > 16) {
19            document.body.classList.add('night');
20            document.body.innerText = "Good night! 🌙";
21        } else {
22            document.body.innerText = "Good morning! 🌞";
23        }
24    </script>
25</body>
26</html>

Inlining data

In the embedded widgets domain, where minimizing network calls is crucial, an effective technique is to inline serialized JSON data directly into the HTML. Instead of relying on subsequent API calls to fetch dynamic data, we serialize the necessary information and embed it within the widget's HTML structure. This approach not only reduces the need for additional network requests but also accelerates the widget's rendering process.

For instance, imagine a weather widget that fetches real-time data to display current conditions. Instead of sending a follow-up API call after the initial widget load, we can serialize and embed the essential weather data directly into the HTML. This ensures that the widget presents up-to-date information without introducing delays from external requests.

Inlining serialized JSON data proves particularly beneficial when dealing with small to moderate-sized datasets, striking a balance between reducing dependencies and optimizing load times. By adopting this practice, embedded widgets can offer a seamless user experience with minimal reliance on external APIs, aligning perfectly with the efficiency goals of widget development.

Fewer dependencies

It might be obvious to most but limiting our use of dependencies can have a huge impact on our use case.
When considering dependencies, we have to way to consume them, either via another module (an additional network call) or inlining it (larger document size).
It's tradeoffs all the way down.
Yes, we will not write our own interactive date picker if we don't have to. But we will also not add a dependency only to find out if a number is even or odd.

Conclusion

In conclusion, the paradigm of "One request, one response" emerges as a guiding principle in the world of embedded widgets. Unlike standalone web applications, widgets necessitate an approach focused on efficiency and unintrusiveness within the hosting application's environment. The crucial realization that a widget plays a supporting role rather than taking center stage shapes the strategies employed.

Our exploration reveals that strategies like inlining critical styles, scripts, and data, and limited use of dependencies, can significantly improve the widget's performance and user experience. By embedding styles and scripts directly into HTML, we sidestep additional network requests, ensuring faster load times and immediate responsiveness. Moreover, being selective about dependencies helps maintain a lean and efficient widget, avoiding unnecessary bloat.

Tom Slutsky

Senior Full Stack Engineer. Way too tall cook and wall climber. Happen to write code when being asked to.

Join our team!

Explore open positions