Infoxicator.com

Help! My website performance sucks!

Published

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.

Conclusion

In case you haven’t noticed the screenshot above is of the new fully React facebook.com 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

The case against DRY, Micro-Frontends edition.

“Don’t Repeat Yourself” How does a modular architectural approach affect the DRY principle?

How I translated my Next.js Blog

English is my second language and before I was proficient, I always found it really difficult to find tech resources in my own language. That’s why I decided to translate my blog and make all my content available in Spanish. Internationalization with Next.js Next.js has made Internationalization (i18n) a breeze with one of the most[…]

Rules of Micro-Frontends

This is an opinionated list of best practices when designing applications that follow the Micro-frontend pattern