Modern profiling and speed improvements in the browser

[jducoeur]

(Only interesting to programmers, and this time really only interesting to folks who actually build front end pages. But really interesting for those of us who do that.)

Okay, I'm probably late to the party here, and the serious front-end people already knew about it, but last week Otto Chrons (one of my fellow Scala.js geeks) happened to point to an article that mentioned Chrome's current Performance tab. So I took a look, and found it downright revelatory. That turned into the focus of this weekend's Querki release.

If you have Chrome, go check it out: Inspect a page, go to the Performance tab, and reload the page. Poof, you are presented with a wonderland of data. Here is a representative image from Querki, behind the cut tag. (Ignore the nonsensical function names -- that's because the code has all been optimized.)

At the top, it shows a summary of what the CPU was doing while you reloaded. This makes it starkly obvious when the page is just sitting there, waiting for stuff from the network. Below that is a sort of icicle view of exactly what happened when, with each task broken into sub-tasks, and sub-sub-tasks, and sub-sub-sub... you get the idea.

Honestly, it smacked me across the face: it turned out that one reason Querki's page load was so slow nowadays was that it was taking over two seconds to parse a bloody text file, because I hadn't optimized the parser properly. An hour or two of hacking on that, and I'd reduced it by over 80%. Check.

Then there is all that downtime: basically, it would completely lay out the basic page, then go fetch the big scripts, and only once those fed in did it start to process. This led to me reading into the new Preload tag. This is very new (as in, it's been around for about a year), and only supported on Chrome and Opera, so it's not a panacea -- but it does help a lot of the market. Basically, it lets you say "I am going to need this resource soon, so start loading it Right Now". If it's supported by the browser, and you have enough network connections, it starts fetching it in parallel, so the scripts can start to execute as soon as things are ready for them. That seems to shave another second or so off of load time.

Overall, it's a huge win, and the result is that Querki's initial page load is now down from averaging about 6-7 seconds on the desktop to sometimes getting as low as 2 seconds under optimal circumstances. (Among other things, this means that navigating to your index and then over to another Space is much faster than it had been.)

I haven't managed to fix everything yet: there turns out to be another fetch that is sometimes causing delays, which Preload doesn't seem to work on. (Basically, because it's an AJAX request.) That's going to need a serious rewrite, I think. But I hadn't even realized it was a concern until getting whapped upside the head by the Performance tab.

So to summarize: if you're building webpages, Chrome's Performance tab is your friend. It's dense, but chock-full of useful information to help you understand exactly what's taking how long at load time...

Comments

[drwex]

That was really useful even to me as a non-programmer.