Table of contents of the article:
The importance of the speed of a website is now undisputed, especially after the advent of Google Core Web Vitals, who have eloquently confirmed that a site's speed is a ranking factor.
With this awareness it would be misleading, inappropriate, inappropriate and counterproductive not to dwell on such an important issue, capable of decreeing the failure of your site (and of your person), or a profitable and rewarding business capable of guaranteeing you a comfortable lifestyle. it is satisfying.
Let's be serious, if you're on the front page and have a fast and snappy site, you'll be doing business. On the other hand, if your site is slow and not positioned, your site will only be a cost, an expense, a liability and not a money machine.
Having said and clarified the concept above, let's ask ourselves if we really have the faintest idea of what it means to have a fast site. Most of the professionals who today talking about speed do not have the faintest idea of what they are telling their customers and even themselves.
We do not want to be presumptuous, but more and more often we see hosters and systems engineers dealing only with their branch, as well as developers and developers completely disinterested in the systems implications on the final result.
In other contexts, and other articles that you find online instead we limit ourselves to recommending one WordPress hosting rather than the other, often with embarrassing conflicts of interest such as fake reviews and undeclared commissions.
For our part, it is enough to know that WordPress was slow before the advent of Core Web Vitals, and WordPress is slow even after them. We simply had metrics that allowed even the common man to understand what is good and what is not good.
However, this desire to simplify, with a trivial score, did not allow us to easily understand what is fast and what is slow in a WordPress site, and therefore we find ourselves professionals who have not understood anything about how to optimize a website and about how you must necessarily lend to the Server component, if you want to start well and finish better.
We speak for obvious commercial reasons of slow WordPress, but it is clear that the theoretical concepts that we are going to express are applicable and adaptable to any other CMS or server side language.
Slow WordPress. Understanding the problem by breaking it down
It has always been useless in life to start from solving a problem without first having understood its origin and causes. In this article we want to separate the problem by talking about the speed of HTML page generation and the speed that the browser uses in reassembling the resources it sees indicated in the HTML page.
A bit like saying that to make an exotic culinary dish, we must first order the ingredients, wait for them to be delivered to us, and then only then start with the elaboration of the recipe that will produce the exotic dish ready and finished to taste.
Server-side and TTFB issues.
It is easy to understand that if the realization of an elaborate recipe takes half an hour, but looking for the ingredients and bringing them to the kitchen would occupy us half a morning, the time of realization of the dish is equivalent to the time it took us to find and buy. the ingredients added to the time required for making the recipe.
Sometimes in short, the recovery time of the server-side HTML can be much longer than the time it takes the browser to download the resources and put them back together just like a puzzle.
The problem with retrieving HTML is what is technically measured in the value of Time To First Byte.
This value that we have extensively discussed in the article of which you can find the link above, is the one that can be briefly defined with server speed, influenced by non-performing PHP code, slow queries to the MySQL database, and inefficiency of everything built on top of this PHP + MySQL architecture.
Whether it may be a plugin, a theme, a function, a code snippet, the problem for what is made in PHP and MySQL will always be searchable in PHP and MySQL. Whether they are plugins, themes, functions, pieces of code, we know this, which we wanted to abstract architectural concepts with organizational superstructures, but at the server side level, at the PHP interpreter level nothing changes, it is not known if what is running is a module, a plugin, a theme or other. PHP code is PHP code, MySQL query is MySQL query.
End of speeches, end of various amenities and of the "IT philosophy", useful only to fatten the consultants' fees and decrease the portfolios of customers and clients.
These problems must obviously be identified and profiled with debugging and profiling, the use of slow query logs in the debugging of slow queries, etc ... etc ...
The use of high-performance, efficient, low-latency and high-throughput hardware is certainly an adjuvant added value in achieving the intended objectives, that is to have a processing time as low as possible.
A query that takes 100ms instead of 200ms is a double performing query, which at the end of the generation chain of the HTML page to be returned to the browser will allow us to have a site that is maybe twice as fast, or maybe not, but certainly faster.
Let's not talk about plugins? Let's not talk about the 10 secrets to speed up WordPress?
How to speed up WordPress in 10 tricks?
There are no miraculous "plugins", there are no secret "ways", instead there are skills and approaches as well as combinations of procedures and tasks that improve every aspect of your software stack and server.
We are now humanly tired of seeing "lists" of things written by people who have never installed a linux distribution in their life, who have never written code in C language or who do not know how the TCP / IP protocol works, perhaps proposing the separation of application server and DB server, perhaps with a gigabit connection.
We are tired of being scammed by people who have sites of the local delicatessen in their portfolio, and that perhaps in reaching the fateful 90 score on Google PageSpeed Mobile, compromised the correct functioning of the Facebook pixel and the tracking of campaigns, perhaps not caring about the TTFB and extremely high DNS latency.
Certainly you will come across individuals who will also significantly improve speed and TTFB using Cache plugins such as WordPress SuperCache, W3 Total Cache or commercial plugins such as WP Rocket for example and demonstration in hand, you will also feel fully satisfied.
Few would go further than these plugins, not being competent systems engineers. Go to recompile the kernel with the right tuning values at the TCP / IP level, the right support at the webserver level such as the support of BBR TCP , the support of the Brotli compression: 0-RTT with Early data support, And a server-side static cache such as Varnish Cache able to work very well even with traffic coming from social networks.
Therefore you will probably get a good result but not the best, and considering the increasingly fierce competition to position yourself in the first results it makes no sense to resort to half measures.
Client side issues, browser side issues and HTML rendering
Now that we have the HTML of the page we want to view, we need to start downloading the resources contained in it. Let's imagine that this HTML page is a long classic Homepage, with hundreds of resources and images, some of which in the header, some in the initial slideshow, some in the central body of the text and many others in the final footer.
Which one should start uploading right away? Obviously the ones we will see first and therefore, the parts inherent to the header and the menu, the slideshow and only subsequently the image elements of the content that we are going to read (perhaps) or of the footer, assuming that we are interested in continuing the complete reading up to to get to the footer.
This is where approaches such as Critical CSS, lazy loading of resources, removal of CSS and unused JS come into play, as well as ensuring the best possible weight for resources, as well as an important efficiency on the network and networking side, aspects these are extensively covered in the section of Core Web Vitals.
These aspects should normally be seen by developers who, however, are often unable to solve the problems described above on the server side and therefore the best recipe is to unite competent developers and systems engineers in solving the speed problems of the site.
Always be wary of the classic approaches "Install a plugin, make 3 clicks and you're done". This is not how it works and you risk doing more damage than anything else, or at least thinking you have done well and then not realizing that maybe the traffic coming from Facebook or Instagram or Google campaigns cuts your cache like a red-hot iron. in a stick of butter and the user's bad navigation values are sent to Google which uses them to generate and compile reports on CRUX data of Core Web Vitals which will be judged insufficient and therefore you will be penalized or at least not rewarded.
Conclusions
If you have a slow WordPress site and you want to speed it up, you must necessarily achieve the two objectives indicated above: have a server that returns HTML in the order of 200 - 300ms maximum; that this HTML and related resources such as JS and CSS are structured in such a way as to have the minimum of information necessary to render the page, the minimum of space occupied (effective compression), and that the markup is designed with the aim of immediately downloading the resources that we need to show first (e.g. Critical CSS).
Satisfying both requirements will give you an important advantage both in terms of user usability and therefore User Experience, as well as advantages in terms of SEO since the speed of a site is now an indexing factor.
