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, 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, 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?
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.
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.
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, 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!