Debugging WordPress Theme Load Performance with Chrome DevTool

Introduction

In this small article, I’m going to show you how I fix a small performance issue with WordPress theme that we are working on at PixelDima, showing you how to use the Chrome DevTools.

Debugging

As I mentioned on the title I’ll use DevTool on Chrome Canary, you can use the standard Chrome If you want.

I’ll work on a local environment for that you can use Local by Flywheel to setup your WordPress.

Let’s start Profiling and Reload the page to see the performance:

1- Opening DevTools from Chrome’s main menu

Open Chrome DevTools by clicking on the menu at the top right corner, then More Tools > Developer Tools

2 — Go to the Performance tab.

3 — Click on the reload icon.

Looking at The performance profile

Here is the performance profile of page load.

Zoom into the red bar where the large “blocks

As you can see below we can confirm this period of time was slow, the frame took 68.1 ms to execute, and ran at 15 FPS and CPU time 277.66.

A red bar above the FPS is a warning that the frame rate dropped so low that it probably harmed the user’s experience.

To start an investigation the Red bar above the FPS graph. If you click on the record that has a Red triangle on top right-hand you will get more ditties at the Summary tab.

As you can say the children scripting is ticking 45.5 ms, so we must know which activities directly took up the most time in aggregate. DevTool is able to display activities during the selected portion of the recording.

Above you can see that almost practically all of the time was spent executing the two calls e.refrechon vendors.min.js (JS file that contains all the scripts used on the theme ) and Recalculate Style click on e.refrech and you will get:

DevTools takes you to the exact point in code which triggered the event. As the code is minified, you should pretty print it.

I searched for “data-anchor-target" on all JS files on the theme and I found that the file behind the slow is skrollr.js we use it for the parallax images, but in this page, we did not use any parallax images.

The best way to get exactly the code behind the slow frames on a big project is to filter the JS file and go for the custom JS code that we write.

So in order to open the tree, you can hold Option (Mac) or Control+Alt (Windows, Linux) then click. ( Thanks to @ChromeDevTools )

Now after opening the tree activates I searched for main.min.js which contain our custom JS, I opened it and as expected it goes directly into the code that runs the parallax ( where we use Skrollr function ).

In the code, you can see that we are calling Skrollr without any condition which means it's running even if we did not use it. So in order to fix this, we must add a condition that test if the element $(".parallax-background") exists before calling the Skrollr function.

The Result After The Fix

With this small fix, we don’t have the red bar anymore and we manage to save 25 ms ( from 68 ms into 43 ms ) and now run at 23 FPSinstead of 15 FPS with CPU time 247.06 ms.

Sources:

I'm Adel TAHRI, an Algerian Web Designer & Web Developer , I have masters degrees in computer science