You've successfully subscribed to WorldRemit Technology Blog
Great! Next, complete checkout for full access to WorldRemit Technology Blog
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.
(S)ite (E)lements (O)ptimization matters

(S)ite (E)lements (O)ptimization matters

. 3 min read

| Image by NeONBRAND via Unsplash

As Healthy Systems Poland team, we are involved in tasks from many different areas. In this blog post, we would like to write about our cooperation with the Search Engine Optimization team, which has led not only to a major improvement of SEO metrics, but also to a significant performance boost.

At the beginning of August, we were asked by the SEO team to investigate the root cause of Cumulative Layout Shifts. We've been told that the number of affected URLs had increased dramatically in the previous month, possibly as a result of several recently released changes, and we needed to resolve the issue quickly as it had a negative impact not only on our performance metrics, but especially on the users who could observe unexpected jumps of the content of our pages.

We started the investigation by checking all previously released tickets, but unfortunately we couldn't find anything that could have an impact on CLS. That's why we moved to the Lighthouse, which is the built-in dev tool that measures performance of the sites and gives additional information about issues and elements to improve. The generated results showed that our images in the HTML document didn't have specified "width" and "height" attributes, which allows browsers to create properly sized placeholders for them before loading them. This means that our images had always 0px x 0px dimensions before loading, and after loading, when stretched to the correct dimensions, they caused layout shifts.

However, that wasn't the only thing we discovered. By checking the performance metrics and the page loading behavior, we realized that the fonts were processed twice and the whole site rendering operation looked like this:

  • render site received from the server
  • load the fonts and repaint the fonts
  • render content from the client with old fonts
  • repaint client with new font

In the meantime, we received an incident stating that the Country Landing Page on mobiles was broken and it needed to be urgently fixed.

Country Landing Page rendering issue

We connected both cases and discovered that the issue could be due to differences between data served from the server and the client. For this reason, the hydrate method from the React library which we were using was not working efficiently. In general, this library expects the data to be equal in both cases so it can just to do its job which is to attach the events. In our scenario, it had to additionally re-render the whole content to make it equal with the client and only after this part attach the events. To solve this problem, we decided to use a render method which allows us to avoid the very first "check/compare differences" step.

Using this simple optimisation, we were able to remove the bug occurring on mobile devices and improve the performance statistics twice.

Before:

PageSpeed Insights results with the usage of hydrate method

After:

PageSpeed Insights results with the usage of render method

However, even though those changes didn't improve CLS metrics, we still had in mind that we could introduce the above mentioned dimensions to all images on the site, and so did! The results were shocking. We were able to reduce the metrics from 0.49 (previous screenshot) to 0.05. Excellent!

Reduced Cumulative Layout Shifts metrics


As you can see, in our day-to-day work, it's often worth being open and observe a wider range than is expected of us. Here, thanks to some discoveries, by removing a few flaws from the code and introducing some simple optimizations, we were able to make significant improvements.