Here I am, almost 2 years later, realizing I have learned more about performance in the last couple of weeks than I had ever imagined. Up to this point in my career I have mainly focused on performance and how it relates to the backend of web applications. As I start a new chapter in my life, I have come to realize frontend performance has come along way from stitching together files and minifying everything.
For anyone interested in a deep dive I recommend you checkout web.dev. Although most people thing of Google as a search engine, the developers there have done an outstanding job documenting various metrics calculations as well as the steps develops should be taking to ensure web applications score as best as possible several key areas (Core Web Vitals). Now, this is not to say they are just sitting there pointing there finger saying “you need to do some arbitrary thing to ensure some academic computation looks good” but they show various techniques they have used to improve performance and metrics scores.
Core Web Vitals
Unless you have been developing websites in a cave somewhere, Core Web Vitals (CWV) is something you have probably seen at least once in the last couple of months. Why is that? CWV consists of the metrics Google has determined to be the most important when it comes to not only speed, but perceived speed of a web application. The metrics included in CWV are Cumulative Layout Shift (CLS), First Input Delay (FID), and Largest Contentful Paint (LCP). The linked pages do a much better job explaining these metrics than I can and I recommend you read the docs. CLS is the amount of space your content shifts during page load, FID tracks how long it takes before a user can interact with your site (e.g. click a link) and LCP shows how long it took for the largest content block (text, image, video, etc) to finish loading.
In addition to explaining the metrics, the documentation also provides demonstrations of what is measured and offers suggestions on how to fix common issues.
But that’s not all
In addition to the core metrics there are loads of others, such as Speed Index (SI), First Contentful Paint (FCP), Total Blocking Time (TBT), Time to Interactive (TTI), and Time to First Byte (TTFB).
TTFB gets a lot of attention because it tracks how long it takes from when a request is sent to when the first byte of a response is returned from the server. If you have a slow connection, a slow server, or if your application is doing a lot of work before sending information to the browser, the result is a high TTFB. No amount of processing power on the user’s end is going to make your site load faster if it takes your server 3 seconds to respond.
As a backend developer, TTFB has been the only metric I have really given any thought because I felt it was my job to ensure my application returned data as fast as possible. Only after diving into performance feet first (OK, I was pushed) did I realize it was actually a small piece of the puzzle. In addition to faster backend code, TTFB can usually be improved with caching and CDNs, however, that’s not all you can do. Deferring non-essential scripts/css as well as the old standby of minifying and stitching your JS/CSS files can go a long way.
Now what?
Hopefully I have at least made you aware of the fact there is more web performance than just smaller files and less round trips to the server. In addition to the web.dev site I mentioned there are loads of resources available for those wishing to dive deeper (or find those “solutions” I mentioned) I recommend watching several (or all) of Google’s 2020 Dev Summit, and the Website Performance Optimization course on Udacity. The dev tools used in the course are a bit outdated and have been moved around in newer versions of Chrome but the content is still really valuable.
Time permitting, I may add more about this topic as I dive deeper. Performance is a topic I have always been fascinated with and now I have seen how deep the rabbit hole can go I am seeing just how little I knew about optimizations on the frontend.