How to open dev-tools<\/h2>\n
First of all, navigate in Chrome to the page you want to test. Press Command+Option+I (Mac) or Control+Shift+I (Windows and Linux). You will see the dev tools panel open. Click on the \u2018network\u2019 tab, this is where the magic happens.<\/p>\n
Emulate your users<\/h2>\n
When testing a website, it is important to replicate the connection and device your users use. Dev tools has some nice options for that. You can choose your connection by clicking on \u2018online\u2019, now you can switch to a 2G mobile connection for example. By clicking on the device icon you can switch between most common devices, with desktop being the default option. Bonus tip: click on the camera icon to see a filmstrip. This will visualize how fast your content is visible for your users. Remember: it is more important that a user is able to read and scan a website as fast as possible than it is to interact with a page.<\/p>\n
![\"\"](\"https:\/\/wp-rocket.me\/wp-content\/uploads\/1\/network-panel-1024x427.png\")
<\/p>\n
To cache or not to cache<\/h2>\n
It is useful to toggle the \u2018Disable cache\u2019 box. This will give us the load time of the page without any browser caching, and therefore giving us better insights on where to improve. Caching is not always possible for all pages.<\/p>\n
It is always possible to right click in the Dev tools pane to clear browser cookies and browser cache.<\/p>\n
Which metric to focus on?<\/h2>\n
Before we do our first test it is important to explain the most important metric Dev tools will show you: load. The time for \u2018load\u2019 indicates when the page is ready and available on your screen, including all the other assets that the page needs to load such as images, CSS and scripts.<\/p>\n
Waterfall<\/h2>\n
You are now on the page you want to test and the Network tab is opened in Dev Tool. Do a reload (instructions are visible in the dev tools pane). Chrome will generate a waterfall chart for you. You will see the results rolling in with different assets being timed and visualized in a waterfall chart. Now we know exactly how this page is loaded by the browser.<\/p>\n
![\"\"](\"https:\/\/wp-rocket.me\/wp-content\/uploads\/1\/waterfall-webpagetest.png\")
<\/p>\n
Finding the culprits<\/h2>\n
First, let\u2019s see what time we have for \u2018load\u2019. Note this number and let\u2019s see if we can improve this. By checking and fixing the items below we should be able to shave some time off the current load time.<\/p>\n
Render blocking scripts<\/h3>\n
Before a browser is able to tell what is needed to display on the page, it will need to parse all the scripts the page loads. So, if you put a javascript file in the header of a page the browser has to read all the code in this file before it decides what to render on the page. These scripts delay the moment when a user sees something of your website on his\/her screen. To reduce bounce rate<\/a> it is very important to show something on the screen as early as possible.<\/p>\n You can find render blocking scripts by looking at the blue line indicating the \u2018DOMContentLoaded\u2019. Scripts that are loaded before this line are probably render blocking<\/a>. You can investigate them by clicking on that script and checking the Preview tab. Try to make these scripts asynchronous, move them near the closing body tag (WPRocket can do this for you) or get rid of them completely. Google has written an excellent article on Render Blocking<\/a> vs Asynchronous JavaScript.<\/p>\n All assets that are downloaded from a server come with a status code. These status codes tell a lot. A status code of 200 means \u2018OK\u2019. You want all your assets to have a status code of 200.<\/p>\n You can find suspicious status codes by sorting the assets in your network tab based on the column Status. Skip the 200\u2019s and focus on the other ones.<\/p>\n Status codes that you want to fix are mostly:<\/p>\n Please check httpstatuses<\/a> for the complete list.<\/p>\n It will come as no surprise that large requests are bad. They are slow and use up a lot of bandwidth (especially for users with bandwidth limited mobile phone subscriptions). Sort on the column `Size` to find the largest assets.<\/p>\n Most of the times these large assets will be images or video files. Make sure the image dimensions fit the dimensions of how you use them within your site and save them with an amount of compression that makes them still OK to look at. A service like Imagify<\/a> will compress these images even further while still looking good.<\/p>\n Large requests are often slow, but a slow requests does not mean it is always large. Hence it is a good idea to also sort on the column `Time`. Slow requests are often external scripts for tracking<\/a> or specific functionality. You can see in the column Initiator what asset requested this asset to be downloaded. Also use the Preview tab to check the contents of the asset if you are unsure on what it is. External scripts are very hard to optimize. If they slow your site down too much consider another supplier.<\/p>\nSuspicious status codes<\/h3>\n
\n
Large requests<\/h3>\n
Slow requests<\/h3>\n