Causes of a Slow WordPress Site

Causes of a Slow WordPress Site (And How to Fix Them)

The speed at which the website loads is crucial. No one wants slow pages because no one wants to wait for the entire content to load. Every visitor wants to see the content as soon as possible, otherwise goodbye and scarf. Google ranked the speed criterion among the signals that evaluate the quality of the page.

Therefore, as a website operator, you should try to ensure that most pages on your site are fast enough and that their content reaches the visitor as quickly as possible. This means that the page.

 

What is fast loading, and how to measure it?

Google defines an ideal for communicating with the server – it should respond within 200 milliseconds. It can be assumed that the entire page should load and display within one second. Of course, this process is quite individual since each page is compiled from different sources, and it is often necessary to generate data from the database first, which takes quite a long time. In an e-shop, such a time is somewhat unrealistic, but it is already confirmed in simple pages, armed. And how to measure the speed? Never in a browser. This may help us, but external services are used for objective speed measurement, e.g., on the internet.

  • Pingdom Website Speed Test
  • WebPageTest.org
  • Google PageSpeed Insights

If the service offers a choice of where it is measured, select the closest area to the area where you have site visitors or customers. Any European city is enough for the Czech website.

Important: Each page behaves a little differently, so you should measure different types of pages on your website — e.g., cover page, a listing of sections or categories, article detail, etc. You can get slightly different results each time.

In the picture from Stockholm, the article page loads over three seconds, its size is over two megabytes, and the result is average. A small number of requests (73) per server are positive. Everything’s mediocre. So there is an excellent opportunity for improvement: to reduce the amount of data, to reduce the time it is necessary to load.

Often, the browser and its developer tools, which you display with the F12 key, can also help us. But it’s the same information you find using the services above, it’s just more handy (in a web service, you sometimes have to wait for lead tests to take place in front of you), and the quality of your connection distorts it. For example, on the Network tab, you can see what components are loaded on the page, what their total size is, and you’ll see any errors. For a less distorted result, ban cache in the browser — so each request goes directly to the server again. But again, the measurement is subjective – it corresponds to your connection, geopolitics, browser settings.

In the bottom row, you can see that the page sent 260 requests to the server to build it, downloaded almost 31 MB of data, and the entire show lasted over 18 seconds. All this is terrible in one word. This is a food blog where something similar is almost the rule. But such a good and brisk site isn’t supposed to look like that.

 

So what are the brakes, and how to break them?

Here are examples of tracking the factors that are holding the site back. Typically, these are:

  • extended hosting/server response (see an arrow at the top right of the picture, points to a six-second sequence),
  • Too many server requests (260 is a lot),
  • unnecessarily large amounts of data that need to be transferred (e.g., the 31 MB mainly in huge images),
  • old http1 protocol instead of new http/2 (h2), see the box in the image
  • loading external resources (social network boxes, sharing buttons, measurement scripts, fonts – woff2 files pictured).

And how to get rid of these brakes and speed up the web? You need to reduce the amount of data and speed uploading. This is the primary and generally applicable principle.

 

Server Response

The extended hosting response is sometimes because hosting is just slow. The site runs on an old server that is about to retire or is overloaded. Demand better performance after your hosting, i.e., buy a better hosting program and see if you will have new hardware available (e.g., SSD storage instead of classic drives, also for the database).

However, hosting (server) is affected by how much WordPress has to retrieve from the database and somehow prepare for display. In the case of the e-shop, these are already time-consuming operations that can slow down the loading of the page. It also depends on the data structure – the number of categories, labels, or properties of the product hurts speed. Here it is appropriate to analyze the quality of plugins and their contribution.

And for the third time, a poorly written template plays a role here. If it retrieves a lot of data from the database every time you view the page, you can tell. Again, CSS or JavaScript complexity or the amount of data pre-uploaded plays a role— for example, images are read in the background as data stored directly in CSS, not as files. That’s bad technique, at least in this case.

 

Many requests, many data

The source code of the page should bother the server as little as possible to avoid slowing down. Therefore, the same types of data are grouped and then compressed. One of the caching plugins can do this. Typically, it can combine into one and shrink CSS or JS files. Therefore, it is good to set up some such plugin correctly, but only at the end of all acceleration efforts; it should be the last element that “wraps” everything and sends it to the browser.

However, in the case of images, the cache does not help; another technique must occurctiveness. The basic rule for ideas: use the appropriate sizes. Under Media Settings,> choose image dimensions appropriately so that the measures you create match the template requirements and publishing requirements. For example, if preview images with 350 points in width are used in article listings, then the image to be uploaded must be comprehensive (with a tolerance of 20%). It’s inappropriate to load larger images here – you’re burdening the visitor with data they don’t need and won’t use. Still, many websites do, after all, see the picture with an example.

A support technique with good results is image optimization. Of course, you can fine-tune each image manually, i.e., set the appropriate compression rate for it. But luckily, it is possible to use Shortpixel software to optimize images, which can do this automatically. As a result, each loaded image optimizes, i.e., removes unnecessary data and improves compression, with minimal distortion. A professional photographer probably doesn’t appreciate it, but it is a very beneficial tool in illustrative and accompanying images.

 

Go to http/2

Ask hosting to get your website up and running on http/2, which also means HTTPS. Converting a website to HTTPS ensures that the data is transmitted encrypted and cannot be changed on the way from server to browser (and vice versa). This will increase the security of the website and, on the other hand, the speed. Both are among the signals that Google assesses when evaluating pages. Http/2 differs from http/1 in that it allows you to download data in parallel. While previously the server handled requests linearly, one by one, which could have led to a break, http/2 requests are taken simultaneously. That means faster. Combined with the other modifications we describe here, you can achieve rapid acceleration in data transfer.

 

Limit external resources

A frequent break that is a bit hidden is external sources: sharing buttons, Google fonts, Facebook box, and various measurement scripts or online applications like a chatbox. All these elements can slow down the loading of the page. Therefore, it is advisable to load them to the very end, the page is already displayed, and these dynamic components are displayed gradually. Fonts can be converted to local (conversion applications are used) and retrieved in the template from your hosting, sharing buttons can be replaced with a click-through image, etc. It is an individual activity, and not all requirements can be met because they can oppose each other.

 

Measure pages and edit

During regular operation, measure the speed of randomly selected pages and gradually fine-ed everything; you always find a new opportunity. For example, images found, inaccessible scripts or wrong links also slow down the page. Repair, refill, or delete them. Finally, deploy a caching plugin, WP Super Cache, W3C Total Cache, WP Rocket, or another that will benefit your website (this will be useful to test). Also, follow Google Search Console and follow code improvement recommendations.

Leave a Comment

Your email address will not be published. Required fields are marked *