Debugging WordPress Theme Load Performance with Chrome DevTool
Tags: devtools, wordpress, debugging, chrome
Published: 2019-03-24 09:04:49

---
title: Debugging WordPress Theme Load Performance with Chrome DevTool
published: true
description: 
tags: Devtools, WordPress, Debugging, Chrome
---

### 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](https://pixeldima.com/), showing you how to use the Chrome DevTools.

![](https://thepracticaldev.s3.amazonaws.com/i/nkahlkptpuaqnne567a6.png)

### Debugging

As I mentioned on the title I’ll use DevTool on [Chrome
Canary](https://www.google.com/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](https://localbyflywheel.com/) 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*

![](https://thepracticaldev.s3.amazonaws.com/i/1dkfrk8sq5kwnxvw0ewb.png)

2 — Go to the **Performance** tab.

3 — Click on the **reload** icon.

![](https://thepracticaldev.s3.amazonaws.com/i/5fo3yfq77yeax33dddid.png)

### Looking at The performance profile

Here is the performance profile of page load.

![](https://thepracticaldev.s3.amazonaws.com/i/y15fsvtsf8zh040rt5zx.png)

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`.

![](https://thepracticaldev.s3.amazonaws.com/i/tyxmo2q1o7u0tq6m3v64.png)

> *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**.

![](https://thepracticaldev.s3.amazonaws.com/i/dtjdftl25ok0780zajlq.png)

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.

![](https://thepracticaldev.s3.amazonaws.com/i/2duz4aefx3ivq9omvn5w.png)

Above you can see that almost practically all of the time was spent executing
the two calls `e.refrech`on `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:

![](https://thepracticaldev.s3.amazonaws.com/i/gmqx2yrnlal1xp45xmdg.png)

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

![](https://thepracticaldev.s3.amazonaws.com/i/npqr4jo024hsiwry0lzw.png)

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.

![](https://thepracticaldev.s3.amazonaws.com/i/oethcq7qiqy6exqknmpq.png)

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 )

{% twitter 928340118091395077 %}

![](https://thepracticaldev.s3.amazonaws.com/i/a5nyxjiboh36qyguak71.png)

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* ).

![](https://thepracticaldev.s3.amazonaws.com/i/5e5895cvrwwvvqcd07j0.png)

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

![](https://thepracticaldev.s3.amazonaws.com/i/3dai9ri5xpw43jv5ipnt.png)

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 FPS`instead of `15 FPS`
with CPU time `247.06 ms`.

### Sources:

* [https://moderndevtools.com/lessons/11](https://moderndevtools.com/lessons/11)
* [https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference)