Page tasks report

This is part 10 of An introduction to SiteImp Reports, an 11 part series about SiteImp audits, designed to help you learn more about your new SiteImp report. If you would like to follow along, you can download it here. (Note - it will open in a new tab.)

Last article

Last article, I wrote about the page checklist report. The page checklist report is ultimately a collection of important stuff that didn’t fit anywhere else. But the more I’ve worked with SiteImp audits, I’ve come to realize that the page checklist report is like a canary in a coal mine. It asks questions about the real basics that any competent web developer should provide by default. Invariably, when sites perform really poorly, they also fail most of the checks on the page checklist.

Sometimes when you have that many problems, it’s time to move on. There’s no shame in rebuilding your website because your current can never be up to task. If anything, it takes good judgement to know when it’s going to be more expensive to fix something than it is to start over.

This article

This article, I’m going to start talking about how browsers render pages.

When a browser starts loading a page, its rendering engine starts a renderer process. Do rendering engines have a person (or maybe a committee?) called “Renderest”? Or was that title rendered obsolete by technology?

I’m sorry.

That renderer process triggers threads. The exact details depend on the browser and the technologies used to build individual pages. But in general, you will always have more than two threads active in every browser process.

There is the main thread or the UI thread. The browser process' main thread updates the user interface. It parses HTML and CSS, evaluates scripts, and renders content within the style and layout the designer intended.

There is a UI thread. At the browser level, the UI thread handles networking and interprocess communications (IPC) requests.

Then there are a variety of other threads. In the good old days, we used to just call these worker threads but times have changed and so have browsers. Many browsers collect data on their users so they undoubtedbly have tracking threads. Browsers are too different and serve too many different purposes for different users and the companies that make them. So I’m uncomfortable defining these other threads. You may run into them, especially if you develop single page applications (SPAs) on a team with people who know Typescript and one javascript Framework but who never bothered to gain really solid javascript fundamentals. When you do, frankly, I feel very sorry for you and you’re not possibly getting paid enough.

The page tasks report is about the browser’s main thread. How many things have to be parsed, processed and evaluated and how long does it take?

The best way to describe this report is that like the page checklist report, it’s really a canary in the coal mine. I hope that you never get any value out of it, because if you do, it usually means that your site is going to be really messy.

Here is a page tasks report from that SiteImp audit that I ran on January 9. This one shows the tasks on siteimp.com, my home page.

As you can see, when a mobile browser loads siteimp.com, it runs 198 tasks in a little under 164 milliseconds. Only 8 of the 198 tasks take between 10 and 100 milliseconds to run. Those are really good results and so I don’t use this page at all.

On the other hand, if you start running into thousands of tasks that take seconds to execute, you really need to flip to page composition reports and the site recommendations report. Chances are good that reducing unused CSS and javascript, reducing network requests and reducing size transferred are all amongst your most pressing site wide requirements.

In the field, I see this happen in Wordpress sites with > 15 plugins active. When I look at site wide recommendations, it will all be about removing unused CSS and javascript. Then when I look into page composition, I’ll see that they’re downloading > 6 scripts and stylesheets. As I dig deeper, I’ll find that their plugins all inject their own dependencies in different ways, so I’ll usually find that every page downloads multiple versions of Bootstrap and jQuery.

Then, if I dig into the php error log, I’ll find lots of PHP warnings from depracated functions. With a little more digging, I’ll find that a third of the plugins were never updated beyond PHP 5.

So, in the field, when I uncover major problems in the page tasks report, it usually means that the site has really deep problems. At this point, it’s usually cheaper to start over than to start removing and replacing plugins while simultaneously working on a child theme. It’s possible to save sites like this but it’s a heck of a lot of work, and if they’ve been using old versions of PHP, there’s always the danger that you’re just polishing up a well hacked and fully owned website.

To conclude, I hope that you never get any utility out of this report and that it only shows you really good things. Let’s all hope that 2022 is a year full of sub 500 millisecond total task times!

Next article

Next article, I’ll conclude the series with a look at SiteImp’s page metrics reports. These reports contain a whole lot of numbers that SiteImp observes and collects during its testing process. They’re most useful when you run a report, make changes and want to truly quantify what has changed. It’s especially helpful when things that help cumulative layout shift end up adding to first input delay!