No doubt if you spent any time around us technical types you have heard mention of this thing called technical debt often camel cased to TechDebt. There are already countless articles that explain what TechDebt is and often times managers equate the cost of TechDebt in terms of lost dev hours.
The typical conversation usually boils down to: “If we do not pay down the debt now when it is a minimal cost it will cascade into a larger cost displacing the big revenue generating project you’ve got on the road map.” Of course management tends to follow the path of delay paying until it is absolutely necessary.
The problem is that not all TechDebt is created equal. For instance there is the routine server maintenance versus application and code stack patching and upgrades versus critical security updates. The latter in my experience tends to be the easiest to receive management buy-in. Simply stating if we put this security update off our risk of a breach or catastrophic public incident will rise X% (usually a huge number).
In the WordPress world the typical form of TechDebt falls into the patch and software update category. More often than not these are routine core, plugin and theme updates. There are also the critical security patches that take the same form but carry an air of urgency especially since WordPress had reach the point of critical mass. The latest numbers hold that nearly 28% of all website run on some version of WordPress. So with 1 in 3 web sites running on this software security update need to be taken seriously.
Page load time is a huge factor affecting your sites value in the attention based economy.
There’s another form of TechDebt that those of us who run software development team experience. It the kind from hidden bugs. These bug are usually missed as many developers test and ship code with display errors turned off in PHP. The problem is that these errors are like cancer or diabetes. They are the silent killers of web sites.
The above image is the output of an undefined variable notice grabbed from xdebug. If you are not running xdebug on you dev PHP stack you will want to change that immediately. While the normal display errors is useful even in it’s simplest form xdebug adds the stack trace and nothing scream ‘Fix Me, NOW!’ like a bright orange error notice. In addition you can integrate xdebug into IDEs like PHPStorm and system performance profilers to really take a deep dive into application execution performance. However that is NOT the focus of this discussion.
So the notice above is not critical in the sense that it will stop your site from loading completely the infamous White Screen of Death (i.e., WSOD). In fact PHP (and WordPress) will happily continue chugging along like the little engine that could, ignoring the notices and warnings but there is a cost. Most developers overlook the fact that even though you’ve set the site up in production mode to suppress errors and warnings they are still there under the hood eating away at the foundation of your site.
That’s right they cost you page load and assembly time. To make matters worse with some caching systems these issues can remain hidden until the day they metastasize into a WSOD. To illustrate examine this page load analysis from GTMetrix of a page with the error noted above but hidden from view. Keep in mind that these tests are on a raw system with no local system caching.
As you can see the load time is not great. While the page suffers from many other problems the fully loaded time is pretty egregious however that’s not the worst I’ve seen. Let’s examine the page load timings.
The timings start off pretty good 96ms TTFB but they quickly slide down hill from there. So it should be obvious that we need to fix this. The patch itself is rather easy, the offending vars had no default value. All it took was to add $section = ”; to the top of the method. Now let’s take a look at the post patch results.
As you can see the page size stayed exactly the same and a few more requests to external services fired but nothing major. However the fully loaded page time dropped significantly. While a 3.5s fully loaded time is not the end of the story as we certainly can optimize more it is a huge improvement. Let’s look over the page load timings for this page post patch.
So the TTFB increased slightly, but the first paint dropped significantly meaning the user experience has vastly improved over the previous. In fact our DOM complete time is nearly half of the time it took the prepatch version of this page to reach it’s first paint. If we has not fixed this the user most likely would have bounced but this time.
As developers it is up to us to ensure that the code we produce does not leave an impalatable remnant of carelessness. Just because you can not see the errors they are still there and PHP must still analyze the code and decide how to handle it and it will affect page load times.