CLS: Changing the perspective (Vol.3)
Prologue
This is the third instalment in the series where we talk about what worked for us and what didn’t in our attempts to solve the problem of layout shifts in Housing.com.
Previous Chapter:
We tried a lot of approaches, from adding loaders to inserting placeholders for places where content isn’t available, each approach addressed few use cases but introduced problems which kept us at our toes.
The idea we talked about in the previous instalment, degraded the quality of our website as the approach increased the probability of listing page being heavy with placeholders rather than being rich with content.
After brainstorming through a lot of ideas, one idea managed to tick all the boxes.
What if we provide alternate streams of data or a set of widgets as a fallback to places where content isn’t available?
Categorising Content
We segregated the UI elements on our SERP (search and results page) into the following categories:
- Listing Cards
- Banners / Ads / Widgets
- Extra Cards
Let’s try to understand all of their use cases,
Clubbing Content
Listing Cards are our primary source of information and serving all of the content through these cards is of utmost importance, hence the chances of layout shifts arising from these cards is quite low.
Our focus was now on the remaining component types.
From our past exercises we have known that the best way to avoid any layout shift is via components which always render. Streamlining those components becomes a task as :
- These widgets/components are developed and maintained by different teams
- Each widget/component has a different objective
Hence, a carousel was introduced which clubbed multiple banners of same dimensions. If there was a banner which didn’t match the dimensions, either a new carousel was setup or the dimensions of the banner were changed.
Since, most of the banners were inside carousels adhering to their specified height and width, the probability of incurring a layout shift reduced dramatically.
This left us with components which didn’t fit this use case, so we decided to merge them with another workflow that was in the works.
Prioritising Content
We have already established that components which request their data client side are prone to layout shifts as there’s always a case where data isn’t available. This brings us to the statement we had referred to earlier:
What if we provide alternate streams of data or a set of components as a fallback to places where content isn’t available?
This idea alone enabled us to see the search page through a different perspective.
The basic idea was that all secondary cards (extra cards) were provided with list of components that had less stringent data requirements with each passing component hereby reducing the probability of encountering an empty dataset as well.
A queue was developed containing a list of components. As all of the components are client side rendered, a loader is shown to the user whenever the data is requested. If the component has no data, the list is dequeued and the process starts over for the next component in queue and for the user the loader is still visible!
There was a slight increase in the time for sections to be visible but only for the cases where there’s data unavailability.
The last item in every queue has a functional/promotional component which in principle doesn’t have any data requirements attached to it and hence is always rendered!
So, we gracefully tackled our problem, solved layout shifts for our listing page and at the same time didn’t reduce the quality of our listings!
The journey doesn’t end here though, there’s still few more things to sort out…
