How I increased my site render speed by 65% using Chrome dev tools
I’ve just used Chrome Canary’s developer tools to optimise my site, making the homepage render 65% faster. Check out the summary pie chart of the before and after:
The pie charts above show a breakdown of the events occurring for the first 1.80s of my site loading. I've gone with 1.80s because the site previously had events running up until around that point. Here's the main outcomes of this blog:
- all the page events (Loading, Scripting, Rendering, Painting, Other) have been cut significantly by making modifications to my page that were affecting the critical rendering path of the browser.
- the original events made up 527.1ms of the 1.80s , and the optimized events only take 186ms, a 65% decrease
- dev tools timeline feature is a great tool to help identify jank provided you have an understanding of the browser's critical rendering path
Timelines: before and after
Before going into the details, here is the timeline for before - look where dotted red line cuts off at 1800ms:
And here is the timeline after the optimisations were made, look where the final dotted red line is now in comparison to the one above:
Frames per second analysis
Chrome developer tools allows you to assess the frames per second (fps) of a site, highlighting areas of janky page loading with red labels for you to optimise.
These page jank indicators are shown where the fps are over 10 fps. This is because most devices have screen refresh rates of 60 times per second, so each frame we show needs to be created in under 16ms as we need to render 60 frames every 1000ms. Additionally, because of other work the browser has to do, we only have 10-12 fps to play with.
You can see this in the image below:
Checking for page jank
To optimise this jankiness, I started off by zooming into the the first section with the red indicator. That's the part taking 68.2ms and running at 15 fps - which is around 5 fps too slow, so is just about noticeable to a user. Below is a close up of the section:
Now I'll walk you through the analysis of the above timeline screenshot. Looking at the entire section between the two grey dotted lines, starting from the purple bars on the left, we see the following sequence happen:
- the styles get recalculated (the first purple bar)
- the layout event gets is run (the second long purple bar)
- paint events take place (the small green bars).
After that, something a bit strange happens - more HTML is parsed (the blue bar), causing and the entire cycle of styles, layout and paint to happen again.
Drilling into the timeline
Clicking on that second round of HTML parsing outlined above presents the pie chart below, indicating that some scripting is occurring which is evidently delaying the browser:
The script is not marked as async either, so because the browser doesn’t know if the script is going to make changes to the DOM, it has to wait for the entire script to be loaded to find out.
What was the script for?
The script was actually loading this github activity image into the DOM. Whilst it’s something cool, it was making the page janky, so before optimising it, I’m going to remove it:
In addition to this, I also removed a script at the end of the body linking out to jQuery, and an @import from the CSS file. Overall these small tweaks have greatly improved the rendering of my site, but that's not where it stops.
There are still many optimsations I must make to improve the pageload of my site. These include:
- optimising images
- removal parser-blocking CSS
I'll cover these in a later post.