Help! My website performance sucks!

cover image

We all have been there!

After spending hours creating your beloved masterpiece, you finally push your code to production just to find the dreaded lighthouse performance results. What did I do wrong? did I put too much CSS in my javascript?

Here is why I think we are obsessed with numbers rather than the actual performance than makes the user expierience better:

Focus on improving performance rather than aiming for the holy grail number.

Scrolling through Twitter you often find screenshots of 100% green scores. Also big SEO companies showing off their results at a conference bragging about their perfect 100% score (after disabling most of the website’s functionality) just to score less than 56% weeks or months later.

Take action and follow the recommendations to improve the performance, comparing results before and after applying the changes. On occasions, results may vary even without changing anything, however, you would be surprised how simple tweaks like properly sizing your images go a long way.

Not all websites are made equal

Static rendered websites are fast! very fast! Tools like Gatsby are an awesome way to create blazingly fast websites. The main reason is that usually there isn’t a server involved and all the required HTML and assets are stored on a fast Content Delivery Network (CDN) close to the users requesting the pages; no time wasted getting the data, computing, rendering, etc. That works perfectly for small-scale websites and blogs that can be generated at build time, however, if you need a large web application, a static site generator might not be the right solution for you. In those scenarios, many more variables come into play, and close attention should be paid to server-side rendering performance (Which is just a fancy name for traditionally built web applications, remember PHP anyone?), keeping payload sizes small (using code-splitting for example) and removing unused CSS.

Your website is only as fast as your backend

One of the main metrics returned by Lighthouse is the Time to First Byte (TTFB) this is the time it takes from when the request is made from the browser to the data being returned by the webserver. For Server side rendered applications, this includes making all the required database/API calls to fetch the data, transform it, and then spit the resulting HTML back to the client. Most improvements in this category depend on the type of application and web server you use, for example, a React server-side rendered application performance can be improved applying caching strategies and streamingNeedless to say, the performance and resilience of the web server handling the requests will determine any meaningful improvements in TTFB.


In case you haven’t noticed the screenshot above is of the new fully React and yes, one of the websites visited by millions every day scores a humble 11%; so don’t be discouraged, improving performance is a constant battle, and of course, the only and most important score is the ability for your users to navigate your site quickly and securely.

Recent Posts

Is React going anywhere?

Earlier this year I had an interesting conversation with a CTO of a price comparison website (e-commerce) and he mentioned that they are moving away from React. “Wait, what?”… was my Reaction (pun 👊 intended)… please tell me more! “Yeah, it is not working for us, we are moving away for performance reasons, e-commerce is[…]

React Router 6 Deferred Fetch

React Router 6 introduced the “deferred” API that allows you to “await” for critical data and “defer” optional data when calling your loaders.

React Router 6.4 Code-Splitting

Single Page Applications that are unable to migrate can benefit from all of the goodies 🎁 that Remix provides.