Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



For any web developer, DevTools provides an irreplaceable aid to debugging code in all common browsers. Both Safari and Firefox offer great solutions in terms of developer tools, however in this post I will be talking about the highlights of the most recent features in my personal favourite browser for coding, Chrome DevTools.
For something that I use day-to-day in my role as a Frontend developer, I unfortunately haven’t been keeping myself up-to-date with the latest features and changes to Chrome DevTools and their latest updates. So in this blog post, I will outline all of the largest DevTools changes over the past year and how this can improve our developer experience.
First of all, I will outline the biggest and most game changing updates to Chrome DevTools in recent times – user flows. We now have a new tab in DevTools called “recorder“. If you can’t see it straight away, make sure you have updated Chrome to the latest version, you can then cmd/ctrl, shift, p on your keyboard to open the command box within DevTools and search for and select “show recorder“. We are now ready to record our first user flow.
To do this, click on ‘start recording’, enter a useful name for the flow that you will be recording and click on the record button. You should then click through the journey of a section of your site, as if you were the user. While this is happening, you will notice each interaction being recorded in our new DevTools panel. When you have finished this journey, click to stop the recording.
We are now ready to replay this recording. We can do this with the ‘replay’ button towards the top of this panel and as an added bonus, we can also simulate a slower, throttled connection using the network drop-down.
But what if we want to add another step to this user journey, will we have to record the whole thing again? Luckily for us, no. Using the three dots beside each step, we can add new steps (e.g. click another interactive element on the page), or even completely remove a step from the journey if necessary.
Now that we are completely happy with our journey, it’s time for the measuring stage. First of all it might be an idea to download our journey in order to share it with others – we can do this by clicking on the export icon. At the moment it’s good to know we can only export this in puppeteer format.
Our recorder tab also has a really useful measurement feature built-in. Click on the ‘measure performance’ button and your performance tab will now populate with an analysis of the performance of your recorded user journey. This will highlight any flaws in your user journey in relation to the Core Web Vitals metrics.
Next up is the new feature that I will definitely be using plenty of times since discovering it. Have you ever been in a situation where there is an issue with your site and you quickly need to determine whether it’s an issue with code changes within your code base, or one of your third parties? Well, gone are the days of individually blocking each of the third-party requests in the network tab. As of Chrome version 106, we can do this as easily as just a tick of a checkbox.
To do this, head to your Chrome settings and click on ‘ignore list’. We now have an option to ‘automatically add known third-party script to ignore list’, so tick that checkbox and you will now be able to re-check your errors in the console. The stack trace will no longer contain any references to 3rd parties, so we can get to the bottom of our errors a lot quicker.
Next, I’ll move onto a language that has been evolving a lot recently – CSS. There have been some fantastic changes for the better to CSS over the past couple of years and luckily for us, the Chrome team at Google has been evolving DevTools alongside these changes to allow for debugging of these new features.
Cascade layers is a recent API added in CSS to help developers define layers of specificity for their styles and overcome the issues that we face when we need to use the !important override. This approach is now compatible in all modern browsers, so to debug in Chrome, just click on the little layers icon in the CSS tab. Then inspect an element that uses Cascade layers to define its style and you will now be able to see which layer it is defined in.
To conclude, DevTools are forever changing and evolving to our debugging needs, as well as the new technologies that are coming up. Therefore, it is a great idea to check in with these changes from time to time to make sure we are always getting the most out of browser debugging tools like DevTools, in order to make our development lives much easier.
Share this
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
3 min read In the previous post, we explored how AI accelerates delivery and compresses the time between change and user impact. As velocity increases, knowing that something has gone wrong before users do becomes a critical capability. But detection is only the beginning. Once alerts fire and dashboards light up, humans still have to interpret what’s happening,
Find out everything you need to know in our new uptime monitoring whitepaper 2021