Chrome DevTools

The Chrome DevTools are a set of web authoring and debugging tools built into Google Chrome. We can use the DevTools to iterate, debug, and profile the site.

Open DevTools

Right-click a page element and select Inspect, or click F12 (windows).

We can choose the proper dock size (highlighted) to decide where the panel is attached to the page to be inspected.

Discover DevTools

Elements panel

View and change the CSS rules applied to any selected element in the Styles pane. To edit a name or value, click on it, make your changes, and press Tab or Enter to save the change.
View and edit a selected element's box model in the Computed pane.

View any changes made to your page locally in the Sources panel.

Example:

Before	After

When increasing the value of padding-top and padding-bottom, data density becomes larger.

In Styles panel, click the file you have modified, which will take you to the Source panel. Right click on Local modifications, you can see the when and where you modified the file. Clicking revert will undo all the changes to the file.

Other tips

Styles associated with a selector that matches the element.
User agent stylesheets are clearly labelled, and are often overridden by the CSS on your web page.
Rules that have been overridden by cascading rules are shown with strikethrough text.
Inherited styles are displayed as a group under the "Inherited from <NODE>" header. Click the DOM node in the header to navigate to its position in the DOM tree view.
Grey colored entries are rules that are not defined but instead computed at runtime.

Console panel

Log diagnostic information during development or interact with the JavaScript on the page.

Sources panel

Debug your JavaScript using breakpoints or connect your local files via Workspaces to use DevTools as a code editor.

Example to debug JS in Chrome Devtools:

Click on "Add Number1 and Number2", we find it returns incorrect result
In Sources→ Event Listener Breakpoints→ Check "click" under "mouse". When check the click checkbox, you set up an event-based breakpoint on all click events. When any node is clicked, and that node has a click handler, DevTools automatically pauses on the first line of that node's click handler.
Like in other programming IDE, click Step into next function call to step through the execution of the onClick() function, one line at a time. Click Step over next function call . DevTools executes function without stepping into it.
Set another breakpoint. As the below shows, click on the beginning at line 32, which sets an breakpoint (highlighted in blue). Click resume script execution , the script continues executing until it reaches the line of code you placed the breakpoint on.
Look at the lines of code in updateLabel() that have already executed. DevTools prints out the values of addend1, addend2, and sum.
Use "Watch" to check the variable values. Click Add Expression and enter what you want to check. For example, type "sum", "typeof sum" and press enter.
Now we know that the cause of the bug is data type. To verify it, in the Console, type parseInt(addend1) + parseInt(addend2). Press Enter. DevTools evaluates the statement and prints out 6, which is the expected result.
We can edit JavaScript code directly within the DevTools UI to fix this issue. Change the code and save. This time we get correct result.

Keep in mind that this workflow only applies a fix to the code that is running in your browser. It won't fix the code for all users that run your page. To do that, you need to fix the code that's running on the servers that serve your page.

Network panel

Example: learn how to use the Chrome DevTools Network panel to understand why a page loads slowly.

In DevTools, click the Network tab.
Enable Capture Screenshots , which turns blue when enabled. DevTools captures screenshots during the page load.

Check the Disable Cache checkbox. When this checkbox is enabled, DevTools doesn't serve any resources from the cache. This more accurately emulates what first-time users experience when they view your page.

From the dropdown menu that currently says No Throttling, select Regular 2G. DevTools throttles the network connection to simulate a regular 2G experience. This is how mobile users experience your site in places with poor connections. This is a worst-case setup. If you can get your page loading fast on this setup, it'll be fast for all your users!
Screenshots show that the page takes more than 10 seconds to load completely. Note the value for DOMContentLoaded, on the bottom of the Network panel. You should see a value of at least 4 seconds.
Click main.js to investigate that request further. DevTools shows a set of new tabs that provide more information about this request.
Click the Preview tab to view the request's source code. You can see that the script just hangs for 4000ms.

Solution: By marking this script with the async attribute and moving it to the bottom of the document's <body>, the page can load without waiting for the script.

Code change:

Before

After
Double-click on the top-left screenshot. The time below the screenshot indicates when the screenshot was taken. The screenshot takes multiple seconds to load. That means it's probably too large of a file.
Hover over the Waterfall for the logo-1024px.png request. The request spends most of its time downloading the image. This confirms that the image is too large. Convert format of the logo will reduce its size.
The Requests table (highlighted in blue in above pic) displays the following columns by default:
- Name. The filename of, or an identifier for, the resource.
- Status. The HTTP status code.
- Type. The MIME type of the requested resource.
- Initiator. The following objects or processes can initiate requests:
  - Parser. Chrome's HTML parser.
  - Redirect. An HTTP redirect.
  - Script. A JavaScript function.
  - Other. Some other process or action, such as navigating to a page via a link or entering a URL in the address bar.
- Size. The combined size of the response headers plus the response body, as delivered by the server.
- Time. The total duration, from the start of the request to the receipt of the final byte in the response.
- Waterfall. A visual breakdown of each request's activity.

Other tips

By default, DevTools shows the Overview pane. Click Hide overview to hide it.
By default, DevTools uses small rows in the Requests pane. Click Use large request rows to use large rows, instead.
By default, DevTools shows the Filters pane. Click Filter to hide it.
Save a request as HAR with content:
1. Right-click the row containing the request in the Requests table.
2. Select Save as HAR with Content.
Copy requests to the clipboard. Under the Name column of the Requests table, right-click a request, hover over Copy, and select one of the options you want to copy.
Add or remove request columns: right-click the header of the Requests table and select an option to hide or show it. Currently displayed options have checkmarks next to them.

Performance panel

Improve the runtime performance of your page by recording and exploring the various events that happen during the lifecycle of a site.

Runtime performance is how your page performs when it is running, as opposed to loading. Next teaches how to use the Chrome DevTools Performance panel to analyze runtime performance. In terms of the RAIL model, the skills are useful for analyzing the Response, Animation, and Idle phases of your page.

In DevTools, click Record . DevTools captures performance metrics as the page runs.
Wait a few seconds.
Click Stop. DevTools stops recording, processes the data, then displays the results on the Performance panel.
Recording of the page's performance:
Look at the FPS chart.
Whenever you see a red bar above FPS (Frames Per Second, the main metric for measuring the performance of any animation, Users are happy when animations run at 60 FPS), it means that the framerate dropped so low that it's probably harming the user experience. In general, the higher the green bar, the higher the FPS.
Below the FPS chart you see the CPU chart.
The colors in the CPU chart correspond to the colors in the Summary tab, at the bottom of the Performance panel. The fact that the CPU chart is full of color means that the CPU was maxed out during the recording. Whenever you see the CPU maxed out for long periods, it's a cue to find ways to do less work.
Hover your mouse over the FPS, CPU, or NET charts. DevTools shows a screenshot of the page at that point in time. Move your mouse left and right to replay the recording. This is called scrubbing, and it's useful for manually analyzing the progression of animations.
In the Frames section, hover your mouse over one of the green squares. DevTools shows you the FPS for that particular frame. Each frame is probably well below the target of 60 FPS.
Another handy tool is the FPS meter, which provides real-time estimates for FPS as the page runs.
- Press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux) to open the Command Menu.
- Start typing Rendering in the Command Menu and select Show Rendering.
- In the Rendering tab, enable FPS Meter. A new overlay appears in the viewport.
Note the summary tab. When no events are selected, this tab shows you a breakdown of activity. The page spent most of its time rendering. Since performance is the art of doing less work, your goal is to reduce the amount of time spent doing rendering work.
Expand the Main section. DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time. Each bar represents an event. A wider bar means that event took longer.
Zoom in on a single Animation Frame Fired event by clicking, holding, and dragging your mouse over the Overview, which is the section that includes the FPS, CPU, and NET charts. The Main section and Summary tab only display information for the selected portion of the recording.
Note the red triangle in the top-right of the Animation Frame Fired event. A red triangle is a warning that there may be an issue related to this event.
Click the Animation Frame Fired event. The Summary tab now shows you information about that event. Note the reveal link. Clicking that causes DevTools to highlight the event that initiated the Animation Frame Fired event. Also note the app.js:94 link. Clicking that jumps you to the relevant line in the source code.
Under the app.update event, there's a bunch of purple events. If they were wider, it looks as though each one might have a red triangle on it. Click one of the purple Layout events now. DevTools provides more information about the event in the Summary tab. Indeed, there's a warning about forced reflows (layout).
In the Summary tab, click the app.js:70 link under Layout Forced. DevTools takes you to the line of code that forced the layout.
qa

Memory panel

Learn how to use Chrome and DevTools to find memory issues that affect page performance, including memory leaks, memory bloat, and frequent garbage collections.

memory leaks

In object-oriented programming, a memory leak may happen when an object is stored in memory but cannot be accessed by the running code.

Memory leak occurs when programmers create a memory in heap and forget to delete it.

Memory issues are important because they are often perceivable by users. Users can perceive memory issues in the following ways:

A page's performance gets progressively worse over time. This is possibly a symptom of a memory leak. A memory leak is when a bug in the page causes the page to progressively use more and more memory over time.
A page's performance is consistently bad. This is possibly a symptom of memory bloat. Memory bloat is when a page uses more memory than is necessary for optimal page speed.
A page's performance is delayed or appears to pause frequently. This is possibly a symptom of frequent garbage collections. Garbage collection is when the browser reclaims memory. The browser decides when this happens. During collections, all script execution is paused. So if the browser is garbage collecting a lot, script execution is going to get paused a lot.

Monitor memory use in realtime with the Chrome Task Manager:

Press Shift+Esc or go to the Chrome main menu and select More tools > Task manager to open the Task Manager.
Right-click on the table header of the Task Manager and enable JavaScript memory.
- The Memory column represents native memory. DOM nodes are stored in native memory. If this value is increasing, DOM nodes are getting created.
- The JavaScript Memory column represents the JS heap. This column contains two values. The value you're interested in is the live number (the number in parentheses). The live number represents how much memory the reachable objects on your page are using. If this number is increasing, either new objects are being created, or the existing objects are growing.

REF

https://developers.google.com/web/tools/chrome-devtools/