Chrome Developer Tools is a developer tool, especially those that are in the first place, i.e. using the same web application interface, they use daily. I suspect that the vast majority of readers already know the basic functionality of this tool. You know for sure what the Console tab is, you know that you change HTML and CSS when something is testifying, that you are following the Network tab, etc.
But did you do anything outside of that? If you haven’t done it now, we suggest you read the first part of our blog post first.
One of the most important elements of Developer Tools. There you must have clicked at least once if you were checking why your site was slow to load. It is very likely that through this tab you were checking the response from the server or the request you are sending to the server. But did you go beyond that?
Let’s just look at what part is:
Dio 1 -contains two essential components
- In the first component, you can simulate how content is loaded for a page, e.g. if you check the Disable cache option you will see how the page loads when the cache is disabled. You will notice that the page load will be slower in this case. This is usually the first time your page is loaded, ie. the first time a user enters your site. The next time it will usually load faster. You can also change the internet flow, click on Online, and you can see various options for setting the Internet flow that will be used to load the page.
- In the other component, you can choose which files you want to see in the list that contains Part 3. In the Filter section, you can enter the name of the file you are looking for or even a regular expression (eg I want all files with png extension). To the right, by clicking on one of the options (XHR, Img, CSS, etc.) you can select which file type you want to display in section 3.
Dio 2 – contains a diagram showing how resources on the page are loaded, in what order, how long it takes to load, and more. The horizontal axis shows the time in ms that the resource is loading
Dio 3 – contains all the resources needed to view the page. Part 1 describes how you can filter the view of these resources. Resources can be media files, Html pages, JSON response, etc.
Dio 4 – contains the time it takes for the resource to appear on the page. When you click on one of the resources mentioned in Part 3, you will see details of that resource on the right. By default, you will be presented with the Headers tab. In this blog post, this tab will not be analyzed as it is assumed that the readers of this blog know well what is in it. Also, we will not analyze either Preview or Response (they only contain responses from the server). The tab we will turn to Timing. If you look closely at the image above, you will see that the total load time of the selected resource is about 830ms. What counts at that time? As you can see, the total loading time is affected by multiple items, each of which is defined with color. What if I told you that each of those colors meant something?
See the following image (downloaded from the link)
Dio 5 – contains information about the number of resources loaded, how heavy your application is (how much memory it takes), how long it took to load all the content on the page (note that this is an initial load because we shut down the cache). Are you aware that the more requests you have, the more often that the resource will intrude on Queuing (noted above that the browser, this applies to Chrome, accepts up to 6 concurrent TCP connections, which means that all others will be hosted in a queue) leading to slower page reads? Here’s one of the reasons why JS bundling is done, or CSS bundling.
Did you know that at one point, Google estimated that it had 20% less traffic, i.e. fewer searches because the page load decreased in only half a second? How to prevent this from happening to you, and how you can control make sure your site is fast enough, you will see that in this and subsequent sections of this post.
After selecting the options that interest you and clicking Run audits after a few seconds you will receive a complete detail report for the page you are testing. You can run this on any page, and see the pros and cons of the page itself. You can find various variations of websites on the internet that allow you to test your site, one of which is https://www.webpagetest.org/. Problems that usually occur: gzip is not checked on the server, image compression is not activated, a cache is not well set up, etc. It’s always good to keep your site ranked as well as possible, but just as often it’s not possible to bring everything down to over 95%. If you test and Facebook yourself you will see that their performance is not nearly as good as you might think.
Do you know what’s going on with the JS code and what does the browser do with it? The following picture shows a pretty rough picture of what a browser does with JS code
How can we calculate how long it takes to execute a piece of code?
performance.mark('start'); // Do some work... performance.mark('end'); performance.measure('Our Measurement', 'start', 'end'); performance.getEntriesByType('measure');
As this is not a blog post about JS, we will not focus on this part of the code, it is only important to state that using this code you can easily check the performance of your function.
Now let’s take a look at how the Performace tab can help us in detecting page performance issues. If you open the Performace tab, you will see a white screen instructing you to click on a small circle to start recording the site’s performance. After you’ve done that (don’t shoot for more than 3 seconds), let’s see what happens in the following picture
In this section, you can monitor the behavior of your site, how memory is being filled, which JS code is causing problems (slowing down page loading). The key role of this tab is to detect which part of the code is causing the problem (pictured with a red flag). Also, as you can see from the picture, you can keep track of how the site looks at specific time intervals. For more details, read the official Google documentation: link
Memory and Profiling
If you want to see which part of the code fills your memory, then use the Memory tab and profiling.
As with the Performance tab, it is first necessary to record the memory (small circle). Preferably, the recording takes about 15-20 seconds to get the right picture of the memory. In this tab, you can easily detect which part of the code is filling your memory (eg you put in a string, and you forgot to stop adding elements, in which case the memory is constantly full). The difference between Shallow and Retained size is that Shallow size represents memory that will be free if you delete only that variable (where some data is stored), and Retained size refers to memory that can be free if you remove the variable that binds to Shallow size and all variables that just depend on it. It is always Retained size> Shallow size. If you want to know more about this tab, read the official Google article: link.
As you have seen, Chrome Develop Tools is one of the very powerful tools that can help any web developer drastically help with everyday tasks. Thank you for coming up with this sentence 🙂
Good luck programming, I wish you a few bugs and as many interesting projects as possible.