Slow WordPress. Let's find out the causes and solutions. - 🏆 Managed Server

BLOG

June 20 2022

Slow WordPress. Let's find out the causes and solutions.

Let's find out the main reasons why WordPress is slow and how to fix them.

Slow WordPress

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.

TTFB process Apache PHP MySQL

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.

html render browser

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.

 

 

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top