PrackHost : Hosting Premium Web LiteSpeed

5 steps to optimize the load of your WordPress

We showed 5 advice to you to optimize WordPress and to improve the speed of load of your Web

Sometimes, our Web of WordPress has too many static archives that cause that the time of load is not most optimal. We can have hosting superquick but we will not take advantage of it if we have a Web that we do not have optimized to the 100%.
These static archives, are the archives that never they change if we in the future make an update of WordPress. We can name some of them: images (.jpg, .png, .gif), archives css of the style sheets (.css), archives Javascript (.js).

It is necessary to optimize the load of WordPress to gain positions in the indexing of Google and to improve our SEO remarkably.

We explained to you with a real example how to improve the speed of load of our WordPress site through several plugins gratuitous.
In this case, we used the Web of a client for his analysis.

IMPORTANT: This tutorial can be applied to any lodging external Web to PrackHost. If your Web is lodged in our servers you must avoid these steps and follow our tutorial to install plugin LiteSpeed Cache.

1. Previous analysis of the speed of our page

Several tools in the market exist that offer a very detailed idea to us of how it loads our website at the moment. We are going away to center for this analysis in 3 gratuitous ones: PageSpeed de Google, GTmetrix and Pingdom.

1,1 PageSpeed Insights

It calculates the speed to us of load of our Web, in addition to giving advice us to improve it. It values the speed of load of our domain for movable devices or desktop computers.

This analysis is available in the URL:

If we analyzed our site of example we see that the speed of load that gives us in a first attempt is of 39/100 for mobiles and 69/100 for computers.

1,2 GTmetrix

In GTmetrix, the analysis is based on the Pagespeed de Google (the same that the previous step) and on the YSlow de Yahoo, another system of measurement.

We observe that the speed that measures is of 63% and 83%. This analysis is available in the URL:

Speed of the initial page in GTmetrix

1,3 Pingdom Website Speed Test

This test is very interesting and is the one that is going to serve to really see the speed to us of load of our Web.

We can analyze it from several points different from the planet: Amsterdam, Dallas, Melbourne, New York and Stockholm. In this case we analyzed it from nearer site with respect to the servant and it gives a result us of 9,29 seconds.

It is a quite high time but we see that the Web serves 264 requests and occupies 1.8Megabyte. This is too much for a Web, nevertheless in this example is being used a slider in the cover with quite heavy photos that causes that the times of load are very high. We are going to see how optimize the load of this wordpress.

This analysis you can use it in:

Speed of the initial page in Pingdom

2. To qualify Compression GZIP in cPanel

We begin our optimization of load of WordPress. As first step, we are going to activate the compression of Gzip in our domain, for it we accede to ours cPanel, we go to the section €œSoftware€ and punctured in €œOptimizing website€, we will enter the options of compression concerning servant.

In the following screen, we marked the option €œTo compress all the content€. Finally we make click in the button €œUpdate configuration€.

To qualify the Gzip compression in cPanel to optimize WordPress

3. To qualify the compression of WordPress

In order to qualify that the archives that we served in our Web are compressed and therefore they take less in loading in the navigators of the visitors we must also qualify the compression in WordPress.

For it, we add to the following lines in ours .htaccess

# BEGIN GZIP <ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/HTML AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/Javascript AddOutputFilterByType DEFLATE AddType application/x-Javascript x-font/otf .otf AddType x-font/ttf .ttf AddType x-font/eot .eot AddType x-font/woff .woff AddType image/x-icon .ico AddType image/png .png </ifmodule> # END GZIP

4. To qualify a Virtual CDN in our domain

We continue with the optimization of our site, for it we are going to qualify the parallel load of static archives.

All the navigators Web, due to the standard HTTP/1.1 of 1,999, offer limitations in the elements that can at the same time unload (.css, .js, .jpg, .png, etc.) the normal thing is that your navigator admits 6 connections at the most simultaneously.

In order to solve this limitation we can qualify subdomains in cPanel that allow us to have more simultaneous connections to lower these static archives to the computer of the visitor in less time, thus generating parallel unloadings of all the archives that compose our site.
Within few dates, with the arrival of standard HTTP/2 this limitation will not exist, but while this happens this method will help us to optimize our WordPress.

In PrackHost we counted already on HTTP/2 in our shared servers and this step would not be necessary.

We explained it to you with an example: if we have in our Web 18 images, the navigating Web of the person who visits to us will unload them in blocks of 6. We suppose that each block of 6 images takes a second in unloading, of this form, when being 3 blocks, the navigator would take 3 seconds in decargarlas and to show them all. If we created 3 subdomains in our lodging, the navigator will lower them in only a second, since he will simultaneously lower to 6 images by subdomain when distributing the load, which will cause that we gain an important time at the time of serving our contents.

Nevertheless, this method has a problem as well and is that there is to count on resolution DNS of the subdomains, since the navigator must make a call to 1+3 domains.

It has, therefore that to generate a limited number of subdomains so that what we won distributing the loads of static archives we do not lose it with a high number of resolutions DNS.

Therefore, we recommended that the number of subdomains to create is from 2 to 4. In the example that we are going to see the tutorial east will be of 3.

In order to create the subdomains in cPanel we will go to the Subdominios Section, and will enter the corresponding section to generate them.

We can use the name that likes us more to create cdn virtual within our own hosting, usually they are used names as cdn, static, img, etc. In our case we are going to use the name cdn1, cdn2 and cdn3.

IMPORTANT: When you introduce the name of the subdomain in the square qualified for it, cPanel will fill up the field automatically €œRoot of Document€. You must modify this parameter and only leave the route in €œpublic_html€ (eliminating €œ/cdn1€)

To qualify a Virtual CDN in our domain

4,1 Modification of the subdomains to CNAME

By defect, cPanel creates the entrances of the subdomains as an entrance To, you will have to modify it and to put it as CNAME. This it you must do from cPanel > Domains > advanced Publisher of zones. Once within this section you will choose the domain and you will realise the following changes:

  • Modification of the entrances, and to change them of A to CNAME, introducing the value
  • Elimination of the entrances, and that have been generated, these entrances do not interest to us.
  • To also eliminate the entrances of,,,,,,,
  • Elimination of the generated TXT entrances, either is not used us for anything. EYE to only eliminate those that belong to the entrances €œcdn€, if we eliminated others we will have problems with the shipment of emails.

Entrances DNS in cPanel to create Virtual CDN

4,2 Modification of .htaccess of our site

Once we have created our 3 subdomains to serve our static contents, we needed to form them so that they do not serve cookies to the visitor since they can slow down the load.

When creating them of way CNAME we made sure that they are not going to serve cookies, but are going to make sure establishing some basic rules in htaccess ours still more hosting.

For it, we will open ours .htaccess by the root of hosting (www) and will add the following lines at the end of the same:

<FilesMatch €œ\. (js|css|jpg|png|JPEG|GIF|xml|json|txt|pdf|mov|avi|otf|woff|ICO|swf) $ " > Header set Break-Control €œmax-age=2592000€ RequestHeader unset Cookie Header unset Cookie Header unset Set Header unset Pragma FileETag None Header unset ETag </FilesMatch>

4.3 Definir only main domain with cookies

In addition, we made sure that only the main domain is going to serve the cookies, and not our subdomains.

For it we opened our configuration file of WordPress (wp-config.php) that is in root of our site and we add the line in the end:

it defines (€˜COOKIE_DOMAIN€™, €˜€™);

Here we must replace €œ€ by our domain. We keep and we closed the file.

We recommended the edition to you of the same with the File manager of cPanel.

5. Plugins de WordPress to optimize the load

Before beginning the optimization of WordPress proper, we must know very clearly our Web slows down if we have many plugins, we must make sure therefore to eliminate plugins that we do not use.

Once we make a four cleaning of these plugins we are going to install plugins that is going to give an extra to us to optimize the load of wordpress.

5,1 Minificar static archives

One of the warnings that do us the PageSpeed de Google and any other optimizer Web is that we try to combine and to minificar archives HTML, css and Javascript to diminish requests realised to our site.

He is very recommendable that the number of static archives of each type does not surpass in number the 5 in each page. That is to say, not to serve more than 5 archives .js and 5 archives .css.

This we only can change it if we published our group of WordPress and ours plugins by hand to combine them some with others. Nevertheless, they exist plugins in WordPress that will help us to this task without having to publish these archives again. >

One of them, the one who we are going to use in this tutorial, is the €œBetter WordPress Minify €œ. This plugin, in addition to combining our static archives, goes to minificarlos, that is to say, to compress them and to optimize them so that they load faster. we installed it in our WordPress as any plugin: Plugins €“ To add plugin €“ Search Plugins, we will introduce €œBetter WordPress Minify€, and we activated it. In the adjustments of plugin, we will qualify the following options:

  • Minificar files JS automatically
  • Minificar files CSS automatically
  • Leave External you case out AT to their original positions
  • It breaks directory: We will form the route here where the cache of the static archives will be stored. We recommend to form a folder I broke. For this we will put the route of ours hosting with the folder €œbreaks in the end€: /home/nombreusuariocpanel/public_html/cache
  • Inable bubble CSS import


EXPERIMENTAL: There is an option in the following eyelash, options outposts, the call €œInable friendly Minify urls€, that shortens urls generated in the combination of static archives (the other options outposts will allow us to have one to improve load but we will need to have contracted a real CDN, reason why this tutorial we are going them to avoid).

This option we have proven and gives it some problems and worse results reason why you will have testearla before leaving activated it as definitive.

IMPORTANT: This plugin is not compatible with all the subjects of WordPress, reason why you will have to deactivate it if you see that the group is disturbed when unifying the archives .css and .js.

So that it works correctly, we will have to add some lines at the end of ours .htaccess by the root of hosting. These lines you can see if kitchen mhelps them in the connection €œShow rewrite rules for Apache€.

In this example, we have put the following that the system shows to us:

# BEGIN BWP Minify Rules # BEGIN BWP Minify Headers <Files €œ*.js.gz " > ForceType application/x-Javascript </Files> <Files €œ*.css.gz " > ForceType text/css </Files> <IfModule mod_mime.c> AddEncoding gzip .gz AddCharset utf-8 .js .css </IfModule> <IfModule mod_deflate.c>    <IfModule mod_setenvif.c>    SetEnvIfNoCase Request_URI €œ\ .gz$€ no-gzip    </IfModule> </IfModule> <IfModule mod_headers.c> Header set Break-Control €œpublic, max-age=86400€ Header set Vary €œAccept-Encoding€ Header unset ETag </IfModule> # END BWP Minify Headers <IfModule mod_rewrite.c> RewriteEngine On RewriteCond % \ {HTTP: Accept-Encoding} gzip RewriteRule. * - [E=ZIP_EXT: .gz] RewriteCond % \ {HTTP: Break-Control}! \ not-breaks RewriteCond % {HTTP: If-Modified-Since}! \ not-breaks RewriteCond % {REQUEST_FILENAME} % \ {ENV: ZIP_EXT} - f RewriteRule (. *) $1% \ {ENV: ZIP_EXT} [L] RewriteRule ^minify-b (\ d+) - ([a-zA-Z0-9-_.] +) \. (css|js) $ /index.php? blog=$1&min_group=$2&min_type=$3 [L] </IfModule> # END BWP Minify Rules

Once activated plugin, if we observed the source code of our site before and later we see that the number of combined static archives has been reduced to the being.


If they do not appear, test first a to clean the cache of your navigator and repeats the test. (If you want that these lines do not appear in your source code to hide that you use Super Breaks, deshabilita this option from the Debug eyelash of plugin, the option €œBreaks Messages Status €œ.)

We are going to now analyze the loads in Pagespeed Insights, GTmetrix and Pingdom to see if we have improved.

6,1 PageSpeed Insights

We repeat the test in the Web of Google and see that now it leaves to us much more favorable: €“ From 39 to 63 in mobiles. €“ from 69 to 83 for desktop computers.

6,2 GTmetrix

We visit the Web of GTmetrix and we see that the change is impressive. We have happened from 63% to 90%.

Plugin of Lazy Load makes here its function and the slider of the cover not it load of the first reason why also long ago faster test.

To optimize load of wordpress in GTmetrix

6,3 Pingdom Website Speed Test

The last test the one of Pingdom is clearest, we have reduced the load of the Web until the quarter! The requests also have lowered of the 264 of the initial test to 33 of now.

To optimize load of wordpress in Pingdom

7. Conclusions

Sometimes we saturated our unnecessary sites of WordPress with plugins and groups that load too many static archives without optimizing.

Our advice always is to eliminate plugins that we do not use and that we do not install plugins to install. If we want to testear some, to eliminate it if we are not going it to use finally.

If you have a Web in production that contains heavy archives as which we have seen in this example, we advised to you that you follow the recommendations of this tutorial to improve the load of your Web.

Without needing having to alter the static archives of the group and plugins, we will be able to optimize the load of WordPress and will win in visits, speed and positioning.

Published in ,
Transformation for PrackHost


Hosting specialized in Joomla! , Wordpress, Prestashop and Moodle. Services of hosting in the cloud. Dedicated servers VPS and.