Is your website slow? Does it use a lot of resources to do what others seem to handle effortlessly? Don’t know where to start fixing it?
Optimising a website is a creative exercise, but it also requires a process to identify issues. I will outline the steps I use to identify, analyse and fix performance issues.
The examples in this article will be geared towards WordPress and the specific stack I’m used to. The methods used will be applicable in any technology stack.
Remember: premature optimisation is the root of all evil. Identification and analysis is an important step. You should not be ‘fixing’ any code before you are sure it’s causing performance issues.
The performance and efficiency of a website is important.
An optimized website improves conversion, lowers hosting costs, provides a great user experience and is good for the environment.
The opposite happens on a non-optimised website. Conversion rates go down, you are adding and scaling servers constantly and probably waste CPU time and energy on efficient calculations.
To get started with identifying performance issues you need the following:
A trigger can be a lot of things:
The first objective is to find a trigger that is as specific as possible.
Like in regular debugging, we are limiting the scope of things we are looking at. Through deductive reasoning we narrow the trigger down.
This might look something like the following:
Your trigger is ‘perfect’ when you can explain the slowness of a situation purely on the trigger and no external elements cause unexpected results.
In static process control, a distinction is made on common and special causes.
Common causes explain the normal variation and should produce a repeatable distribution over time.
Special causes can always be assigned a source of the variation. An external influence is affecting some outcomes.
In determining the perfect trigger, you want to eliminate all special causes for delay.
Example: Element Z is expected to cause the issue.
The above analysis shows that there is an unexplained factor in the XY combination elements.
The process is probably resource constrained. This causes everything to be queued. This is a very hard to debug situation.
Resource constraints appear in several forms:
Use ‘theory of constraints’ analysis to identify which parts of a program are using the most of available resources.
These problems often only occur in production environments.
Anything happening outside of the browser is considered a server side issue. This includes crons, API calls, command line calls, etc.
To determine if the server is slow, open the network tab of your browser and check out the server response time. Anything >1.5 seconds is worth exploring further.
To identify frontend issues: use the time to interactive and First contentful Paint indicators. Subtract the server response time. Any time remaining I would consider it to be caused by ‘frontend’. If this is >1.5 seconds, consider exploring the frontend performance further.
We should now have a good idea where and when the performance issue is occuring. It’s time to explore why the issue occurs.
There are a lot of tools available to help identify bottlenecks. The type of issue we are investigating, and the environment we have available may limit the effective toolset.
|Phase||Finding||SQL Slow log,
PHP Slow log,
Profiling xDebug (free), blackfire (paid),
|Understanding||PHPSpy||Profiling xDebug (free), blackfire (paid),
SQL Explain statements,
The main tool I use for finding frontend issues is Lighthouse.
At this time we should have identified a probable performance issue. Let’s start fixing it! This might be as easy as disabling/replacing a plugin, or rewriting entire data structures.
Just like regular coding, there is not one solution to fixing these issues. Instead there are some common patterns and best practices you can use as a starting point, and have to get creative from there.