This is part 9 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, we talked all about total bytes transferred and page composition. The page composition report is incredibly important because there is such a strong correlation between page size and performance. Simply, if you want your site to perform better, make it smaller. Personally, I don’t like deploying pages that are bigger than 500,000 bytes unless there is a very compelling reason. There hardly ever is…
This article
This article, we’re going to talk about the page checklist report. The easiest way to describe this page is that it’s a collection of important stuff that just doesn’t really fit anywhere else. Everything on here is important and it’s all valuable, it was just really hard to figure out where to put it. So I created a checklist.
For the most part, I only look here when sites perform really poorly or when I’ve seen front end code so bad that I’m genuinely worried about the overall quality of the project. If I have quality concerns, I look here and usually get a wall of X. With better architected sites, I’m not surprised to see a few Xs, but I expect to see mostly checkmarks.
The checklist answers some very basic questions:
Is the page served over https? If not, that’s a problem both from a user privacy and from a search marketing perspective. Do you know that you can get a free SSL certificate from Let’s Encrypt? There’s no excuse to run a site over http only. Go out and change that right now.
Is the viewport properly configured? If not, your site is likely not delivering the best experience to people with different sized devices. If you get an X here, check your site on a desktop computer, phone and a tablet. Do you see any problems?
Does this page avoid too many redirects? Redirects hurt interactivity and lead directly to lag. Why give your users a browser that looks unresponsive?
Are images displayed with the correct aspect ratio? If not, you’re showing some users badly stretched and distorted images. That might be your brand, but if not, is that really the first impression you want to give a potential client?
Do all your images have height and weight attributes set? If not, your site will experience a lot of layout shift as images are downloaded and processed by your users' browsers. This is one of the easiest and fastest ways you can improve your score in cumulative layout shift!
Is text visible while your webfonts load? I’m going to share an unpopular opinion but I hate webfonts. They are big files you make every user download and cache when they all have perfectly good fonts available on their machines. I want to remove this one entirely and replace it with:
Does your page load webfonts?
But that will come in a future iteration. I’ve simply seen too many websites that perform poorly on the first, acquisition load because a designer got too cute with fonts. We have to stop this trend in its tracks.
The second two questions are definitely getting phased out in a future iteration because I’m working on incorporating them into the data I show on the page composition report. For now, the questions are:
Does this page use link rel=preload to speed up fetching resources requested later on in page load?
and
Does this page use rel=preconnect to establish an earlier connection to important third party resources?
I don’t actually like those questions and they really don’t belong. Instead, I want to tailor the page composition reports so it focuses on critical resources and the critical resource path. Then I want to incorporate those two concepts as recommendations to shorten the critical resource path. Unfortunately, that’s a future iteration and this is my marketing/documentation week.
As you can see, these are really basic things that I think every professional web developer should just deliver today. However, it’s remarkable how often sites with red scores on their scores pages have a wall of Xs on their page checklists. That correlation is so strong that I could start the SiteImp process with a checklist and simply stop if they get 6 or more Xs. When sites get 6 or more Xs, they invariably score below 50 in performance and best practices. And they usually have such severe architectural problems that the kinds of really quick site wide fixes that SiteImp is so good at uncovering won’t even work.
This checklist is kind of like a canary in the coal mine. If you get a lot of checkmarks, you can ignore it. If you don’t, it’s time to seriously consider whether you can work with your current site or whether it’s time to cut your losses and move on.
Next article
In the next article, I’m going to look at the page tasks report. When a browser processes a page, it has to perform all the tasks in its main thread before the page is fully ready for the user. This report shows all the tasks that have to be executed on the browser’s main thread.