We often talk about SEO tools and which is the best, so I think it is worth talking about DevTools , a free suite of analysis tools present in Google Chrome that every SEO should know and use.
In the conferences I participate in and in the various blogs I rarely follow, I rarely hear about the tools available in the browsers and I don’t understand why: there is a world in here and you could talk for days about all the checks that you can perform. This guide wants to make order and clarity on the main functions available in Chrome DevTools, I will try to keep the information updated as the versions of Chrome progress.
Firefox is no exception, it has its developer tools and they are very similar to what we will see, so the guide will be useful even if you are a passionate user of the fox .
- Developer tools
- More tools
- Network conditions
- Performance monitor
- Slide Advanced SEO Tools 2021
Start Developer Tools
Chrome DevTools is a web developer toolset built directly into the Google Chrome browser. DevTools can help you edit pages on the fly and diagnose problems quickly, which ultimately helps you build better websites, faster.
There are many ways to open DevTools as users want to quickly access different parts of the user interface, the quickest method in my opinion is to press f12 . When you want to work with the DOM or CSS, right-click an element on the page and select Inspect to go to the Elements panel . Or press Command + Option + C (Mac) or Control + Shift + C (Windows, Linux, Chrome OS). When you want to open the Console press Command + Option + J (Mac) or Control + Shift + J (Windows, Linux, Chrome OS).
You can also launch the individual tools using the command line that can be activated with CTRL + SHIFT + P. All elements starting with “Panel show…” represent the various tabs that can be activated, you can get help from the auto-complete function.
TLTR: View and edit DOM and CSS
In the DOM tree of the Elements panel, you can perform all DOM related tasks. When you use the inspect element function , the Elements window opens highlighting in the left section the DOM part and, on the right, the CSS rules of the class or id of the selected element.
In this tab you can modify the DOM and CSS in real time and view the final result. Do you want to change the background color to see how it could look? Do you want to add a CSS rule to a class? Here you can do it without having to actually edit your pages.
What is the DOM?
Document Object Model (DOM), literally document object model, is a form of representation of documents structured as an object-oriented model. It is the official W3C standard for the representation of documents structured to be neutral for both language and platform. The DOM is not the native HTML of the page as many believe, it is the final HTML of the web page when all the various scripts have been executed.
Clicking an element of the DOM with the right mouse button you can hide the element (among the various options), or with the left button you can drag an element to move it, for example you can reorder an ul – unsorted-list . By clicking on the smartphone icon at the top left of the DevTools it is possible to enable the Device mode function to emulate navigation from a mobile device , useful for example for testing responsive designs and evaluating layout and mobile user experience. For a developer, I think these functions are basic.
You learn a lot using these tools and the ability to play and change the values at will and in real time is really useful both for debugging and for improving all the elements of the web page (and for learning new things!).
Google Chrome DevTools – Console
- Make sure the code is executed in the right order.
- Inspect the values of the variables at a given time.
Try it yourself, to show a message, enter the command console.log (‘Hello!’) In the console and hit enter.
On large sites, the Console can quickly be flooded with irrelevant messages. Use the console’s left sidebar to reduce noise and focus on messages that matter to you. In the blog you are reading I use console.log to monitor PWA service worker activities, you can open the console and check.
Google Chrome DevTools – Sources
The user interface of the Sources panel consists of 3 parts:
- The File Navigatorpane on the left. Each file required by the page is listed here.
- The code editorpane in the center. After selecting a file in the File Navigator pane, the contents of that file are displayed here.
With Sources developers can debug their scripts thanks to several specific functions such as breackpoints . The breackpoints stop the execution of a script at a precise moment that you define, such as the click on an element. In some cases, breackpoints are more effective than simple console.log since you don’t have to modify the code and customize each console.log command with the variable you want to see.
By selecting a script in the left column, you can view the code in the side pane, edit it and save the new version with a name.
Google Chrome DevTools – Network
TLTR: View and debug network activity.
The Network panel is used to ensure that the resources required to render the HTML page are downloaded as expected. The most common use cases are:
- Make sure the resourcesare actually downloaded.
- Inspect the properties of a single resource, such as HTTP headers, protocol used, content type, size, and so on.
Note: If you’re looking for ideas to improve the loading performance of your pages, don’t start with the Network panel. There are many types of problems that are not related to network activity. I recommend starting with the Audit panel because it offers you targeted suggestions on how to improve your page.
To view the network activity generated by a page you must first reload the page. The Network panel records all network activity in the Network Log which contains the list of all dependencies downloaded from the browser. Each line in the network log represents a resource. By default, resources are listed in chronological order (in order of request). The primary resource is usually the first in the list, the HTML document. The resource below is the latest request. Each column represents information about a resource:
- Status– The HTTP response code, useful for identifying any dependencies that return a 404 error.
- Genre– The type of resource, such as an HTML document, image, pdf, JS, or style sheet.
- Initiator– What caused a resource to be requested, could be the HTML page or a script. Clicking a link in the Initiator column takes you to the source code that caused the request.
- Time– How long it took to fulfill the request.
- Cascade– A graphical representation of the different stages of the request: wait, TTFB and TTLB. Hover over a waterfall to see the details.
By right clicking on a column header you can enable new ones, I usually also want to see the Protocol to analyze which transmission protocol is used by the web server.
Selecting a resource the tool displays specific details such as the HTTP header , download times, response and preview.
Google Chrome DevTools – Network Headers
If you have enabled screenshots (capture screenshots), before the network log you can see the rendering-timeline with the screenshots of the page at every moment of the loading phase. A fast site immediately shows the user the main elements to interact with the page, this small report can make you notice inefficiencies in rendering.
At the top of the Network tab there is a check to disable the Chrome cache and there is also the option for throttling , i.e. the possibility of simulating different network speeds such as 3G or going totally offline to test a PWA.
The Network tab is a powerful tool that allows you to optimize the dependency delivery process: it helps to identify bottlenecks, excessive file download queues, slow files to download and slow servers to respond.
Google Chrome DevTools – Performance
TLTR: Find solutions to improve runtime performance.
Use the Chrome DevTools Performance panel to analyze runtime performance. Runtime performance is the performance of your page when it is running, rather than loading . In terms of the RAIL model , the information provided by this tool is useful for analyzing the response, animation and inactivity phases of the page.
Mobile devices have much less CPU power than desktops and laptops. Whenever you test a page, it uses the CPU Throttling feature to simulate the page’s performance on mobile devices. By selecting 2x slowdown, DevTools throttles your CPU to be 2x slower than usual.
To start recording runtime performance, click Record. DevTools captures performance metrics while the page is running. Wait a few seconds and click Stop. Alternatively you can press the circular arrow (start profiling and reload page) and it will do everything by itself. DevTools stops logging, processes the data, then displays the results. You will be given back a huge amount of data but don’t worry, (almost) everything will make more sense in the short term.
Now that you’ve recorded the page’s performance, you can measure its performance and find the causes of any problems.
First it analyzes the frames per second in the top horizontal bar. The primary metric for measuring the performance of any animation is frames per second (FPS). Users are delighted when the animations run at 60 FPS. Look at the FPS graph, whenever you see a red bar it means that the framerate has dropped so low that it is probably hurting the user experience. In general, the larger the green bar, the higher the FPS.
The CPU diagram is displayed under the FPS diagram. 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 maximized while recording. The CPU should not run at full power for long periods.
By hovering the mouse over the FPS, CPU or NET graphs, DevTools displays a screenshot of the page at that moment. Move the mouse left and right to repeat the recording. This is called scrubbing and is useful for manually analyzing the progression of animations.
On the Summary tab – Summary, DevTools shows a diagram with the activities on the main thread, over time. The x axis represents the registration, over time. Each bar represents an event. A wider bar means the event took longer. The y axis represents the call stack. When you see events stacked on top of each other, it means that higher events caused lower events.
To feel more comfortable with the Performance panel, practice makes perfect. Try profiling your pages and analyzing the results. If you have questions about the results, open a Stack Overflow question tagged with google-chrome-devtools . Include screenshots or links to playable pages if possible. To really master runtime performance, you need to learn how the browser translates HTML, CSS, and JS into pixels on a screen. The best place to start is the rendering performance overview .
Google Chrome DevTools – Memory
TLTR: Memory usage and search for inefficiencies.
The Memory tab provides information on the use of memory by the web page, this analysis is particularly useful for dynamic pages that are constantly updated. Memory can help you understand:
- How much memory your page is currently using.
- Memory usage over time.
- Detached DOM Trees (a common cause of memory leaks) with Snapshot Heap.
- When new memory is allocated in the JS heap.
In the spirit of the RAIL performance model, the focus of your efforts should be on the satisfaction of your users. Memory problems are important because they are often noticeable to users. Users can perceive memory problems in the following ways:
- The performance of a page progressively deteriorates over time. This is likely a symptom of a memory leak. A memory leak occurs when an error on the page causes the page to progressively use more and more memory over time.
- Page performance is consistently negative. This is probably a symptom of memory bloat. Memory swells when a page uses more memory than is needed for optimal page speed.
- The performance of a page lags, lags, or appears to hang frequently. This is likely a symptom of frequent garbage collections . Garbage collection occurs when the browser reclaims memory. The browser decides when to retrieve the memory. During collections, all script execution is paused. Therefore, if the browser frequently garbage collects the scripts will often be blocked.
A memory leak is easy to define. If a site progressively uses more and more memory, you have a loss. But memory bloat situations are harder to pin down. Which limit to respect? When is the page “using too much memory”? There are no fixed values, because different devices and browsers have different capabilities. The same page that works smoothly on a high-end smartphone may crash on a low-end smartphone. The key here is to use the RAIL model and focus on your users. Find out which devices are popular with your users, then test your page on those devices. If the experience is consistently bad, the page may exceed the memory capacities of those devices.
Google Chrome DevTools – Application
TLTR: Inspects all loaded resources, including IndexedDB or Web SQL databases, local and session storage, cookies, application cache, images, fonts, and style sheets.
Use the Application panel dedicated to Progressive Web Apps to inspect, modify and debug the Manifest.json file, the Service Workers and their cache. With this tool you can do many analyzes on PWAs, the most important in my opinion are:
- Use the Manifest pane to:
- inspect the PWA configuration file of the same name,
- activate events Add to Home screen.
- Use the Service Worker pane for a variety of tasks related to this script, such as:
- cancel the registration or update of a service,
- emulate push events,
- log out or stop a service worker.
- View the service worker cache from the Cache Storage pane.
- Unregister a service worker.
- Clear all memory and caches with a single click on the Clear storage tile.
If you are implementing a PWA on your website, Application and Audit are the two most suitable boxes for analysis dedicated to this technology.
Google Chrome DevTools – Security
TLTR: Debugging Mixed Content Issues, Certificate Issues, and more.
Use the Security panel in Chrome DevTools to make sure the HTTPS protocol is implement correctly. This is the main tab for a page’s security inspection and its SSL certificate.
One of the most common problems you can find in this tool is call Non-secure main origins – Insecure page. When the primary source of a page is unencrypte, the Security tab indicates that this page is not secure. This problem occurs when the visite URL was requests over HTTP. To make it secure, you need to request it via HTTPS.
- If you have already set up the HTTPS certificate on your server, all you need to do to fix this is to configure your server to redirect all HTTP requests over HTTPS.
- If you haven’t set up the HTTPS certificate on your server, Let’s Encrypt is a free and relatively simple solution . Alternatively, you might consider hosting your site on a CDN. Most providers of this service also offer certificates, for example with Cloudflare you can activate a basic certificate for free.
Another fairly common problem is that of mixed-content . Mixed content indicates that a page’s primary source is secure, but the page has requested resources from insecure sources, such as a .css file or image. Pages with mix content are only partially protecte because the HTTP content is accessible to sniffers and vulnerable to man-in-the-middle attacks .
So a page in HTTPS that invokes a dependency in HTTP would turn out to be a mixed-content.
Google Chrome DevTools – Audits
TLTR: Check the performance and usability of your pages to find possible improvements.
Audit is the tab that includes an important analysis tool: Lighthouse . Lighthouse is an open source tool develope to help webmasters improve the quality of their web pages. The application runs locally on the client side, so you can scan any page, public or requiring authentication. Lighthouse is set up to perform various checks such as performance, accessibility, PWAs and more.
You can run Lighthouse in Chrome DevTools, from the command line, with PageSpeed Insights , or as a Node. After providing Lighthouse with a URL to check, it performs a series of analyzes on the page and then generates a performance report. All that remains is to use the failed checks as indicators on how to improve on the page. Each audit has a reference document that explains why that specific aspect is important and how to fix it.
By clicking on the three vertical dots at the top right of the DevTools you can view the menu and open the More tools drop- down to have access to further analysis tools.
Google Chrome DevTools – Network conditions
The Network conditions tab allows you to change three important browser settings:
- Disable the Chrome cache. By checking this option the browser will display the contents retrieved from the web and not previously cached.
- You can change the network status (online / offline) and reduce the bandwidth to emulate slower devices and networks.
- User-agent. This feature is very useful, I use it when auditing a website. It allows you to present yourself to the web server with a different user-agent, useful for many purposes: to test dedicated mobile websites (very vintage), to discover cloaking techniques or to verify web servers configured with specific rules for user-agents.
Google Chrome DevTools – Performance monitor
Performance Monitor is a tool that allows you to view various aspects of a page’s load or runtime performance in real time, including:
- CPU usage.
- Layout and style recalculations per second.
If your users report that the app is slow or laggy, check the Performance Monitor tab for helpful clues. The tab shows graphs of CPU usage, JS heap size, and JS event listeners.
The best way to use this tool is to browse the site, scroll pages and use it as if we were a classic user. In parallel we must monitor in real time what happens to the various indicators. Is the CPU working too hard? How are memory is takes up by the various scripts? Which nodes does the displayed page have? How many listeners are active? Knowing these values allows you to solve problems related to the excessive heaviness of the code of web pages.
Google Chrome DevTools – Coverage
To use the component you need to add a link to the Bootstrap stylesheet in the HTML code. This style sheet not only includes the code for the button, it contains the CSS for all Bootstrap components but you are only using one. So your page is downloading a lot of CSS it doesn’t need. This additional CSS is a problem for the following reasons: the additional code slows down the page load and increases the necessary bandwidth.
To start the Coverage analysis press the REC button and reload the page (f5). Once the upload is complete, stop recording. The table on the Coverage tab shows which resources are analyze and the amount of code used within each resource. Click a line to open that resource in the Sources panel and view a line-by-line breakdown of used and unused code.
The basic report shows the following values:
- The URL column is the URL of the resource that was pars.
- The Total Bytes column is the total size of the resource in bytes.
- The not use Bytes column is the number of bytes that have not been use.
- The last unname column is a view of the Total Bytes and Unused Bytes columns. The red section of the slash is unuse bytes. The green section represents the bytes use.
Slide Advanced SEO Tools Bologna 2021
The tools available in Chrome are extremely useful in my daily work but I find that they are little “exploited” by colleagues. I therefore thought it would be useful to bring this topic to an event to show some practical cases.
Below you will find the slides I showed at the Advanced SEO Tools 2021 in Bologna.
Chrome DevTools: the technical basis to better understand SEO from Giovanni Sacheli
For more information on DevTools, refer to the official guide . Wondering what new developer features are offere by the latest version of Chrome? On YouTube you will find an official playlist where Kayce Basques presents the news of each new version of the DevTools.