Debugging WordPress Theme Load Performance with Chrome DevTool

Adel Tahri — Sun, 24 Mar 2019 09:04:49 +0000

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 )

// Detect dark theme var iframe = document.getElementById('tweet-928340118091395077-624'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=928340118091395077&theme=dark" }

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.

DEV Community: Adel Tahri

Debugging WordPress Theme Load Performance with Chrome DevTool

Introduction

Debugging

Looking at The performance profile

The Result After The Fix

Sources: