Before end-users interact with your website in a browser, they need to wait for a number of things to happen: initialization (DNS resolution, TCP connection, proxy, and SSL negotiation), server rendering, data transfer, and page rendering in the browser.
Blackfire helps you improve the performance of server rendering, but what about the other parts of the equation?
Websites and many mobile applications rely on the same underlying technologies like HTTP, DNS, SSL, etc. But for mobile applications, the latency, the bandwidth, and the limited amount of resources on phones make everything more challenging. Speed matters, even on mobile — and perhaps especially on mobile.
Improving server performance is made simpler as you know everything about your infrastructure: the number of servers, their CPU, memory, bandwidth, location, and more. Client performance is much harder as users can have very different setups: location, bandwidth, computer power, internet connectivity, etc. These constraints all influence a user’s experience and they are all out of your control.
This chapter is a quick overview of the tools you can use to understand and improve your application’s frontend performance.
Improving the time it takes for a webpage to be usable by a user starts with HTTP optimizations. A quick overview is given by Google’s timeline:
If you want to learn more about how a browser handles HTTP and possible optimizations, read Page Weight Doesn’t Matter.
The Google Chrome Network tab also summarizes HTTP interactions with the user quite nicely:
The “High-Performance browser network” book is a great resource for an in-depth analysis of network performance.
To get a quick overview of the browser performance of your application, use Google PageSpeed Insights. This tool does indeed give you great insights.
When the Google Chrome Team introduced the RAIL model, Paul Irish started with this great advice:
There’s no shortage of performance advice, is there? The elephant in the room is the fact that it’s challenging to interpret: Everything comes with caveats and disclaimers, and sometimes one piece of advice can seem to actively contradict another. Phrases like “The DOM is slow” or “Always use CSS animations” make for great headlines, but the truth is often far more nuanced.
RAIL is a model that helps you avoid performance issues by setting general performance goals. RAIL stands for:
If you want to dive more in RAIL, watch the “Dev Tools: State of the Union” talk.
Let’s see how these goals can be observed and improved.
When a user interacts with a page by clicking a button or submitting a form, you can either load a new page or asynchronously load data to render a React component or populate an Angular scope.
For any interface change, 100ms is the performance goal you should target after the user triggers it from the interface. If not, you should use a loader, a progress bar, or anything that will help the user understand that the action has been taken into account.
Animations are exceptionally smooth for end users at 60 frames per second. That gives you 16ms per frame.
16ms is even too much according to this article:
Each of those frames has a budget of just over 16ms (1 second / 60 = 16.66ms). In reality, however, the browser has housekeeping work to do, so all of your work needs to be completed inside 10ms. When you fail to meet this budget the frame rate drops, and the content judders on screen. This is often referred to as jank, and it negatively impacts the user’s experience.
You can spot janks in your pages by having a look at the “Timeline” tab of the Google Chrome developer toolbar; janks are reported with a red corner:
You can also read this very nice tutorial explaining how to build a Pokemon application.
Google Chrome timeline is a great tool that you can use to record a page display process as a series of screenshots:
If you want to test your website from a different location than yours, or with another browser, use webpagetest.org. This tool provides a lot of metrics to help you better understand what is happening during browsing load time and let you compare different selections of locations, browsers, etc.
Stylesheets are probably one of the most difficult parts of a website to optimize. Here is a quick overview of some optimization techniques:
Google Chrome developer tools provide an “Audit” tab that helps diagnose some CSS issues:
You should start looking at two interesting technologies that could help making your application blazing fast: Google AMP and the Service Workers API.
Google AMP for accelerated mobile pages is a project that should provide a way to write web applications in HTML/JS using components that will be rendered fast. You can test the technology on the project website.
This blog post is an interesting read about instant loading web page using the application shell architecture and service workers.
Like for unit tests, you need to keep an eye on the frontend performance in an automated way. There are quite a few tools that you can use: