BY CHRIS NEALE
Web browsers have a wide range of tools built-in, and one of the ones that web developers rely on most often is the devtools panel. Accessed with a right click and clicking “Inspect element”, or with the CMD+J keyboard shortcut, devtools is a palette of powerful tools that developers and designers can use to peek under the bonnet of any website.
Different Devtools in Different Browsers
Some also offer some more specialised tools. Chrome has panels for performance for checking the speed code is running at, memory for seeing where the website is using computer memory, security to test the website’s security settings, applications to view what a website is storing in the browser, and audits, which links to the Google Lighthouse website audit tool that checks how well a site works for users.
Chrome is also able to connect to Android devices to offer the same set of tools for testing websites on mobile browsers.
In Apple’s Safari browser the same mobile testing is available for iPhones and iPads.
Mozilla Firefox offers a somewhat different HTML page devtools experience with tools that are designed for testing layouts, especially the new CSS Grid layout system.
One of the most useful tools available is the Performance panel in Chrome devtools. By inspecting a page and then clicking the performance tab in the devtools navigation bar a developer can run a test on a page to work out exactly what calls the website code is making, how often, and which calls are too slow.
To run a performance test you can click the Record button or reload the page to initiate the test from the start of the page download. From there everything the browser is doing, whether it’s automatically happening when code is run and events fire, or something that’s reacting to user input, is recorded along with a screenshot of what the page looked like at regular intervals. Specific user interaction events are also recorded. All this data builds up to a list of every call that the code has made, alongside information about how long it took and what further calls the code made as a result.
When the performance test is stopped all of this performance information is compiled in to a flame chart. The chart looks like an inverted horizontal bar chart, with higher level calls at the top and the calls that they made (eg the stack) underneath. When a call takes a long time or has a potential performance problem the bar is marked with a red flash on the corner. These marked stacks are usually where the performance problems lie.
Navigating the flame chart
By expanding a slow call either by clicking and dragging with the mouse, zooming with the mouse wheel, or navigated the chart with ASDW keys, a developer can zero in on problem areas in the code. It’s often very obvious where the problem is occurring because either there are additional unexpected calls after some work is done which hints at a piece of code failing to check whether it needs to run, or a call being made that takes a long time, which often means the call needs to be moved to a worker or needs to cache the result of complex work using memoization or by storing the result if memoization isn’t possible.
Sometimes the performance flame chart indicates that events in the code are firing too often. If a mouse listener is firing every few milliseconds that represents wasted CPU cycles as the user interface isn’t going to update that often, so that code can be throttled (ignored if it repeated too often) or debounced (made to run less often by waiting to see if it repeats and only running it after the last call). Technically, internally these techniques are actually slowing the application down. By debouncing a call in a website’s code to only run 5ms after the last attempt the user will always have to wait a little while after they interact with a page, but by reducing the number of calls that are made the code can run more easily which leads to much better overall performance.
Using the performance chart in Chrome can lead to significantly better user experiences in a web application.
Improving over time
One useful feature of the performance tool is to be able to save a performance test as a JSON object. Once it’s been saved it can be loaded in devtools again for further analysis later. This means developers can perform performance tests as a web application is being built, and test to see how changes affect the performance metrics. By comparing performance before and after small tweaks are made to the code it is possible to iterate the settings a website uses until it’s optimal state has been found.
Furthermore, as the performance test output is saved as in open JSON format, developers can create their own tools to use the performance data in reports and automatic optimisation tools, and perhaps even machine learning or AI.
We help teams across the UK deliver successful digital projects. If you’d like to have a conversation with us, we’ll put the kettle on.