[HTML5]Deep analyzing with Chrome Developer Tools

We use more and more Javascript, animations, and other complex techniques on our web sites. With this comes an increased problem to maintain the code and get a full birds view of what's really going on when your page is loaded. Thankfully we have many tools to aid us with this, like the Developer Tools for Chrome.

Introducing the tools

HTML5, CSS3, heavy use of Javascript, break-points, animations, transitions, and so on. Our need to see inside our code is big to clarify what's going on. We cannot rely only on normal usage testing for slow code on our own super computer at home or at work. Most things will run very smooth on these machines, but few people actually run equivalent systems. And what seems like a small hiccup locally might escalate pretty fast on an older system, or in production when many concurrent users arrive.

To help us, most browsers have their own built-in tools for analysis. Tools that can look inside the computers memory, and analyse the impact of each Javascript function and each CSS-selector. In this article I’m gonna focus on Developer Tools, a set of tools that ships with Chrome and new Opera. No install required!

For this article I only tested the program for Chrome, but it should be identical in newer versions of Opera too. I also further narrowed my scope by focusing on only three main tools of this toolkit, the three I believe kind of got lost in the haystack of good functions and tools, and remain unexplored to a lot of developers.

The tools I’m gonna focus on are called Timeline, Profiler, and Audits. Tools I’ve never used before. Join me in discovering some of their potential.

To open the Developer Tools in Chrome you just press the F12-button on Windows, or right click anything on a web page and select “Inspect element”. Or find the little menu-icon to the right of the address bar and click it, then go to “Tools > Developer Tools”. All of this brings up the Developer Tools program, full of powerful tools and functions.

I bet you recognize it. You’ve most likely inspected your DOM here, changed a few CSS-lines around live, and perhaps checked the Network tool and the Resources tool to dive around after missing files, slow downloads, or odd behaviour. You might’ve even used the Console tool to send Javascript commands to your page. But the other tools might not have gotten more than a simple glance. At least for me that was true, until now.

Tool: Profiles

First out is the Profiles tool. You’ll find all the different tools in the menu at the top of the Developer Tools program. Click the Profiles tab. Here's three choices for recording or collecting some kind of data. I’m gonna explain these in further depth now.

Javascript CPU Profile

The first thing to stumble upon is the Javascript profiler. Select this and click the “Start”-button and a recording is started on everything that happens on the current web page you’re on. So click the Start-button then navigate to your site in the main browser window, keeping the tool in the back. For instance, surf to the main page of labs.enonic.com in another tab (or window) and navigate some of the articles. Then go back to the tool and stop the recording by clicking the “Stop”-button. A full analyze of your Javascript has now been done and a icon with “Profile 1” next to it should appear to the left under the “CPU profiles”-heading. Click it!

Default view is a list of used functions ordered by how long they took to run - longest run on top. You see the name of the function and a list of each time it was called. To the right you see which js-file that contains the source of that function. Click the link to open that row in the Sources-tab (a shame that the DevTools doesn’t un-minimize all those JS-files for you automatically, because always ending up at row one doesn’t help you much). Unfold a function (if there is an unfold arrow there) to see where in the code it has been called, like the “appendChild”.

At the top we have a lot of idle time - “(idle)”. If you click that row, you can exclude it from this list by then clicking the mysterious “X”-icon at the bottom row (the status-row). There are more nice features down here hidden behind the somewhat obscure buttons, so don’t forget about it.

Introduced during summer 2013 is the new Heat map view of the same data you just scrolled through. At the bottom - close to the X-button - we have the text “Heavy (Bottom Up”). Click here and select “Flame chart”.

This will show small colored spikes rising from the bottom. The left edge is the start of your recording, spanning all the way till you ended it. At top we have the timeline overview graph representing the same thing you see on the main area.

Click in the timeline on any interesting part with a lot of spiky graphs and you will get a zoom in on what happened there. You can also easily adjust the left and right edges by dragging, to zoom in and out of this part. I’d suggest you center to a spike you find interesting and adjust the zoom to your liking. Or try marking an area with the left mouse button to zoom in. After this you can further adjust your zoom level by scrolling your scroll wheel on the mouse. This style of navigation works for all timeline-style overviews in this program.

When you’ve zoom in enough you’ll see actual function names on each block in a “flame”. The spikes are horizontally line out in the order they got called. Stacked on top of each other are functions that called each other. So a bottom one called one - or more - that’s on top of it, and they in turn called others and so on. A new function call will never be wider than it’s “parent” and that’s why the blocks gets narrower as we go upwards. If a function calls three other functions, and one of them took double the amount of time, then this will be indicated by the width of each of these three blocks, with the slower being much wider than the others.

Hover any colored box here for a popup at the top where you can see total time it took in milliseconds, URL to the js-file, and things like that. Click to open this file in the Sources-tab of DevTools scrolled to the definition of that function. However this doesn’t work on all the blocks.

What you want to look for in the flame graph is mostly the width of the blocks. Wide blocks are functions that take a long time to finish. Tall stacks of blocks aren’t bad, but they of course mean that a lot of functions are depending on each other. If that is bad or not depends on your overall architecture.

TIP: If you want you can activate an even more fine grained profiling resolution in the DevTools. If you hit the cog wheel in the bottom right of DevTools you can enable “High resolution CPU profiling” that enables graphs down to tenth of a millisecond! This does take a lot more resources, so use it wisely.

Take Heap Snapshot

Heading back to the Profiles start page, this option takes an instant picture of your browser memory. You don’t record anything so this is an instant fun thing. In here you find all Javascript functions currently active on this webpage, and you see how much memory they occupy, and how many objects they contain. The size of this file is large. It’s all the Javascript objects that can be seen by this page.

TIP: You should remember to delete snapshots when done, or they will be reloaded the next time you open DevTools.

In the bottom of screen you can switch out the selected view-option “Summary” to “Containment”. Now you’ll get a overview of open windows. One will says “Window / labs.enonic.com/”-something. Fold that out to see all functions loaded, like Modernizer, jQuery, and Google Analytics.

Modernizer takes up about 72 kB in Retained Size. This is 2% of all open objects, but almost 20% of just this window. That’s a lot! If you hover “Modernizr” you’ll see all properties on this object. This can be done on all objects and classes for a quick overview.

Read more about Heap profiling at Google as I won’t dig any deeper than this.

Tool: Timeline

Open the Timeline tab and you will see an empty timeline at the top, along with three different choices to the left: Events, Frames, Memory. These are all different views of the same data. This data is something you must record yourself while you test a website. When you start a recording all the data will be presented to you as it happens, and this is data like events fired, timers, layout of the page, painting of areas of the page, etc. So if you use a lot of Javascript and animations this tool is very helpful.

To use the Timeline we need to start a recording. This is done with the almost hidden little gray full circle at the bottom of your screen. Clicking this button will start a recording (why they made the UI this unintuitive in this tool beats me). If you now start clicking around on articles, and try triggering Javascript events, the DevTools window will fill up with data. Just play around for a few seconds until you have some data and then go back to DevTools and click the same button (that now is red) to stop the recording.

Events view

First of we have the “Events”-view. This will show along the timeline each event that happened, grouped by colors symbolizing the type of event (explanations of the colors are shown at the bottom of the screen). Use the timeline to narrow the data in the main window of the program, just like the timeline worked on the Profiles tool.

In the data under the timeline you see a waterfall of events. This helps you see what happens on your page and what Javascript-files that are triggered for each function. You also spot big “Paint”-events, where parts of - or the entire - page gets re-painted because of styles being changed by Javascript or events like hover or click. Keeping these repaint areas as small as possible is something that will result in a smoother page browsing experience.

This is in now way scientifically done by me, but when I compared a few events like “Paint setup” and “Paint” I noticed that the former is normally very fast no matter how big the area to repaint is, but the latter increase very much in time as the area increases. Painting an entire page took in my test two seconds, while repainting a small 300 by 300 pixel area just took about 200 ms. These values will of course be heavily influenced by how powerful computer you have, and the current running environment.

Hovering any event on the left will popup more information about it. There you’ll get information on milliseconds used, and many other type-specific details.

Frames view

If you select the view “Frames” at the top we will see the same data, but grouped together in frames instead. A very tall block is a point of interest, because that indicates a very low Frames Per Second (FPS) value, something you’ll notice as choppy movements on the page. Use this view to find areas where too many things happen at the same time, resulting in a bad user experience.

If you hover the header of any column (right beneath the timeline where it says number of milliseconds) you’ll see the amount of time each different type of event took, as well as the total time taken. You’ll also see the FPS value here. Low values are not good.

Try looking for frames that are really big containing a lot of different animations and calculations meaning it will play out slow for the end user. Hover any “Recalculate Style” to see a count of how many objects got affected by the style changes. This is also a value you would prefer to keep low.

Memory view

This view focuses on memory used by the page. The timeline shows how this usage is affected over time, and if you zoom in on it, which events got fired.

On the Memory view you get another area at the bottom of the screen. In this window you’ll get a interesting count of number of DOM-nodes and Event Listeners. These are both values that you should try and keep an eye on as very high values can slow down your web page when users browse it.

Overall the entire Timeline tool is very huge and I will not cover more than these basic things in this article. But do check out Google’s article about the Timeline feature to learn more if you’re interested.

Tool: Audits

Audits are best explained as a website optimization suggestion tool built into DevTools, just like Yslowfrom Yahoo or Page Speed from Google.

At the main page of this tool you should check the checkboxes “Network Utilization” and “Web Page Performance”, change the radio button to the second choice (“Reload Page and Audit on Load”), then press the Run-button.

Each time this is done a new result will be saved and listed to the left, so that you easily can compare and test your changes to each other. This is particularly useful when wanting to see your different code improvements over time.

When viewing a result we get the main area split up by a horizontal rule between Network-related improvements in the upper part, and Web page-performance tips in the bottom part. On each row we get a simple summary that can be expanded. After each summary a number will indicate the number of affected objects. The colored icon to the left of the text are either red or yellow. Green lights doesn’t show up because that’s things that was done good performance-wise. Red lights are the first thing to focus on because the red indicates you could improve your performance the most here. You should fold these out to get further information and help on how to solve them. Often a few small steps will greatly improve your website performance.

For instance, expanding “Enable gzip compression” will list all the files that could be compressed, with an approximate data save value next to it, and a link to that file. If this would mean a lot of work for you this would be something to skip, as we see the save is extremely small. In the case of Gzip compression, Enonic now got you covered by compressing static resources by default as of Enonic 4.7.5.

I don’t really know why they put the “Specify image dimensions” up in the Network-area as that is a Web Page performance optimization. Maybe it’s because that would use the fetched resources in a better way.

Moving on to the other half of this view we find only one or a few things to improve. The one we’re gonna look at is “Remove unused CSS rules”, especially since we get numbers as high as 85% on this one! Opening this will show each stylesheet and a percentage on how many of their rules that are not used on the current page. You want to keep the numbers as low as possible, but then again the rules can’t always be used everywhere because they can be meant for different pages and templates only.

On our Labs site we see that "prettify.css" is loaded but none of its style rules are ever used. And from "bootstrap.css" we only use a very low amount of rules. Expanding each file will list all the rules that are not used on the current page. I wouldn’t mind a feature that only listed the style rules that you do use, then I could move all of them to the main CSS-file instead and throw away the "bootstrap.css" for one less http-request.

Sometimes during development you forget what you created the other month, and you easily recreate and duplicate styles. Not to say when we one year later upgrade a website and add styles to new modules. Keeping an eye on this particular count is never bad. However the impact unused style rules have on performance is not that big, but if you do happen to have thousands of rows of CSS, spread over many files, then this is something you should pay attention to. At the very least this will make your site more maintainable and updates a bit easier to implement later.

I hope this introduced some new features and tools of Developer Tools for you, or explained some that you never really used. Happy coding!