In this last part, I’m giving you a bullet list of every step I take when going for runtime discoveries. Two days ago we established two types of perf audits and said that one can focus on either loadtime or runtime. Today let’s see an actionable list of steps that you can take on your website right now.
First, a quick reminder: in a runtime discovery you focus on those metrics that can tell you if your website runs smoothly enough. The aim is to answer the questions: Does it respond quickly upon interaction? Is scrolling acceptable? Etc..
However, runtime audits can be very different from case to case. Typically, I focus on scrolling lag and heavy animations smoothness. The right thing to do would be to record small interactions on the timeline and see the how long frames are. Then to try to identify the cause of long frames by digging in the callbacks and the render process. It is a pretty accurate, yet slow and painful process, so I like to start by looking for common issues. It is faster and typically ends up solving most performance problems.
I like to start by looking for common issues. It is faster and typically ends up solving most performance problems.
Here is a brief list of what I usually watch out for:
From there, it is pretty much a matter of what the main activity of the site in question is. Improving runtime performance is an exercise of asking he right questions for the site at hand:
I’ll be honest, there is no concrete secret recipe when it comes to crafting a great experience on the Web. If I had to find some guidelines I’ll say this: you need to empathize with the users and try as hard as possible to let their journey be flawless, while exploiting the idle time (e.g — while the user is reading, or thinking) to lazy load functionalities and content. Try not to lock the main thread for long at once, and may the force be with you.
I read each and every comment, contribute to the conversation with your thoughts!