Hello dear readers. Probably, you are already tired of the topic of increasing the speed of site loading. But what can I do, I want to outline everything that was understood and done to speed up this blog until the insidious memory wiped out the nuances and important points.

How To Increase Website Loading Speed

Today I want to try to systematize everything that I have already written about speed optimization, as well as add essential points that can slightly reduce the load on the hosting server by using not dynamic, but static Gzip compression.

How you can quickly increase your website loading speed

So, the whole process of speed optimization, in my opinion, should be started with setting Page Speed . With the help of this add-on for Firefox or Chrome, you can comprehensively evaluate the speed of loading pages of your site and get valuable recommendations on how to increase it (you can also familiarize yourself with other useful add-ons.

The first time I ran Page Speed ​​for my blog homepage, I saw this sad picture:

Only 72 points out of 100 possible and a bunch of comments marked in red. True, having fulfilled almost all the recommendations that this plugin gave me, the main page received from it a higher mark of 94 points.

But besides Page Speed, you can very clearly assess the speed of loading a site and see all the objects being loaded in the online services for measuring the speed of loading  – Pingdom and the like.

At first, almost 90 objects (ccs, js, images) were loaded and each of them needed a separate http request. But, having analyzed all downloaded objects using the above online services, as well as following the Page Speed ​​advice, I managed to reduce their number to three dozen, which could not but affect the overall speed:

Well, now let’s recall all the methods in order. And you should start optimization, probably, in the order of displaying problem areas in the Page Speed ​​window, because these will be the most effective and not difficult steps to implement – what is called “cheap and cheerful”.

Therefore, I started, first of all, setting up caching of static objects (ccs, js, images) in the browsers of visitors (i.e. you, my dear readers).

Yes, yes, using the webserver settings, you can control the behavior of the visitors’ browser. In this case, the first tells the second the time during which static objects should be stored in the cache in order not to request them again from the server.

This, at first glance, is an insignificant setting, but it can work wonders in increasing the speed of loading pages of your resource for those visitors who have already visited it once. their browser cache already contains the style and script files, as well as images from your template, which will be the same for all pages.

Unfortunately, the control methods I have described through .htaccess do not always work, due to various reasons (lack of the necessary module, etc.), so you can try to contact your hoster on this issue, because he will also be interested in this, i.e. To. optimal caching settings in user browsers will reduce the load of your resource on its hosting.

The next effective step to increase your loading speed can be to combine external CSS style files or JS scripts.

But I was unable to combine external scripts, probably due to a lack of understanding even of the basics of JavaScript. True, I only had two external files with scripts, so the loss in site loading speed would not be great.

But in addition to combining external CSS styles and scripts (this is done to reduce the total number of loaded objects, which will reduce the number of http requests to the server), these very style and script files can be very efficiently compressed using Gzip (in fact, this is the same Zip, which you actively use on your computer).

It is possible to compress CSS and Js files several times using Gzip, but you can further reduce the size of these files by pre-optimizing their code. 

True, for this you can use special programs that not only remove extra spaces and comments but also try to adjust the CSS properties themselves.

But I still prefer the simple compression that Paige Speed ​​does – the code remains completely readable and even more convenient to use.

By analogy with Css, you will be able to get condensed versions of your external scripts , from which extra spaces and comments will be removed.

After that, applying Gzip to the files of styles and scripts of your resource will lead to an even greater reduction in their size, and hence the download speed. But it was precisely on the compression of Html, Css and Js that I had a number of questions that I tried to solve with relative success.

Static Gzip compression to reduce server load

First, Gzip on the server with its traditional method of activation will be performed in real time, i.e. this is how we implemented dynamic archiving. What does this mean?

The fact is that for each new user who opens the pages of your site, Html, css, and Js files will be archived on the fly again in real-time. As you can imagine, firstly, it will take some time, and secondly, on-the-fly compression will consume additional server processor resources.

My situation with the load of the KtoNaNovenkogo.ru blog is pretty deplorable – I’m balancing on the brink of a foul. Therefore, any opportunity to reduce it, which does not lead to a decrease in the site loading speed, will be very useful.

Static Gzip compression of Html, Css and Js became such a straw, which I decided to grab onto, which is carried out in advance, and ready-made archives are given to users without slowing down the speed and without creating unnecessary load on the hosting processor.

This problem is especially relevant for external scripts and styles (Css and Js), because they practically never change at all, but at the same time they are repeated and purposelessly archived on the fly every time you open a page of your resource. It would be much more logical to roll them up in Gzi in advance, and specify the required order of actions to the webserver.

Given the different perception of .gz files (Gzip archives) by some browsers, there is usually a rather tricky way of renaming archives to regular .CSS style files and scripts.

And there will be lines added to the .htaccess explaining to the web server how to serve these files to different browsers. In general, such a rather convoluted scheme works, and therefore I will describe in more detail all the steps for preparing Gzip archives and give the code for .htaccess.

So, the following steps will have to be done by you for all external styles and scripts that are loaded along with the pages of your site. To avoid data loss in case of an error, be sure to copy all the data to your computer.

So, you will need to download to your computer all external Css and Js files involved in loading pages (after you have merged them, it will not be difficult) and create an archive copy of each of them with the .gz extension. This can be done using the free 7zip program . Next, let me show you with an example, because it is useless to theorize here.

Let’s take my blog’s main stylesheet, style.css, as an example. After I pack it in Gzip using the 7zip program, I will have a style.css.gz archive.

But since some browsers will not want to include a style file with the .gz extension, then we remove the .gz ending from it and get again as a result style.css, but which is actually an archive (are you confused yet?).

But simply replacing the original style.css file on the server (not yet Gzipped) with the archive we just created, but still named style.css, will not be enough.

After all, some browsers still do not support compression (usually these are old versions that are nevertheless still used by users), so next to style.css, which will actually be an archive (remember we removed the .gz extension from it), we need will put the original uncompressed style file.

But we will have to name it differently than style.css. To do this, you can rename it, for example, in this way: style.nogzip.css. Now on the server, in the folder with the WordPress theme, I will have two style files:

1. style.css – archive with stripped .gz extension
2. style.nogzip.css – a normal uncompressed style file that will need to be served to browsers that do not support compression

You will need to do this operation for all external styles and scripts (Css and Js) that are loaded along with the pages of your resource. I had only four of them: the main style one, in which I also added the properties of some WordPress plugins, as well as a script file from the theme folder and two external scripts from the SyntaxHighlighter plugin .

Now, for static compression for external styles and scripts to work, you need to open for editing .htaccess from the root folder of your resource and replace the code responsible for Gzip with the following modified code:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond% {HTTP: Accept-encoding}! Gzip [OR]
 RewriteCond% {HTTP_USER_AGENT} Konqueror
 RewriteRule ^ (. *) \. (Css | js) $ $ 1.nogzip. $ 2 [QSA, L]
</IfModule>
<IfModule mod_headers.c>
 Header append Vary User-Agent
 <FilesMatch. * \. (Js | css) $>
 Header set Content-Encoding: gzip
 Header set Cache-control: private
 </FilesMatch>
 <FilesMatch. * \. Nogzip \. (Js | css) $>
 Header unset Content-Encoding
 </FilesMatch>
</IfModule>

If you used their names other than style.nogzip.css when renaming the original files of styles and scripts, then in the corresponding line of code you will need to replace the mask $ 1.nogzip. $ 2 with your own. In general, that’s all.

Now the server will not compress Css and Js every time on the fly, but will immediately send browsers a pre-compressed copy of you, and in the case of a browser that does not understand Gzip – the original version of a file similar to style.nogzip.css.

On the face of it, there will be a slight increase in the speed of loading the site and a decrease in the load of your resource on hosting. But after a couple of days I had an embarrassment. Apparently the cache of my browser cleared and the look of the WordPress admin area changed dramatically – the styling fell off.

But the problem was quickly resolved by performing the manipulations described above with the style file used in the admin panel. In my case it was colors-classic.css from folder:

/ wp-admin / css

Then I wanted to apply static Gzip compression for Html files, which are also compressed on the fly by the server, creating an additional load. Here I found a pretty simple solution for WordPress. The fact is that I have been using the Hyper Cache caching plugin for a very long time .

In its settings there is an area “Compression”, which, as I initially thought, is responsible for compact placement of cached pages on the hosting hard drive. It seemed to me that archiving cached pages would eat away unnecessary time from the processor and safely turned it off.

But after looking for information on Gzip compression of Html pages a little, I changed my opinion about these compression settings in the Hyper Cache plugin.

It seems that by checking the box “Enable compression”, we thereby enable preliminary compression of cached blog pages using the Gzip algorithm.

I don’t presume to say this one hundred percent, but after activating compression in the Hyper Cache settings, I have been observing a decrease in the load on the server for a long time. In general, it seems that, as always, the chest just opened.

By the way, if your project is built on the basis of Joomla, then for it there are several very good (according to user reviews) components that allow you to use the methods I have described to increase the speed of website loading as much as possible, but at the same time everything will be much easier, because much is done automatically with minimal setup costs.

Optimizing graphics and reducing the number of requests

Also, graphics optimization can have a very significant impact on download speed. As I wrote earlier, you can optimize images in Page Speed . But this will be convenient only in the case of a small number of them.

Personally, I used the PunyPNG online service for batch optimization , which I already wrote about in some detail. You can also use another very popular online service for compressing photos without losing quality from Yahoo.com  – Smush.it. But the degree of photo compression in PunyPNG seemed to me higher, possibly due to the use of more successful scripts.

I copied the folder with the images of my blog to my computer and uploaded them all (in batches of 15, because there is such a limitation in PunyPNG) to this online service, and then downloaded a general archive containing already optimized images from my blog.

In general, after spending half an hour I was able to compress PNG images by about 7 percent on average, and Gif and Jpg by 5 percent.

As a result, the total size of all the images used on my blog has decreased by several megabytes, which will undoubtedly affect both the increase in site loading speed and will slightly reduce the load on the hosting server.

Well, the last, as well as one of the most effective ways to speed up, can be to reduce the number of http requests that will be generated when the pages of your resource are loaded. You can reduce them by reducing the number of objects downloaded along with the web page. We already talked at the beginning of this article about combining external Css and Js files just for this purpose.

But the lion’s share of requests always goes to loading graphics. These can be background images that were mentioned in the style file, or images that are directly specified in the HTML code of the page.

To reduce their number, you need to analyze whether it is necessary to load this or that image along with the page. Thus, I got rid of a couple of dozen unnecessary http requests. The same background images from the template, which are nevertheless necessary for the functioning of your resource, can be combined into so-called CSS sprites . As a result, instead of a dozen requests, you only need to make one.

In general, an increase in the site loading speed will inevitably lead to at least a small, but increase in the load on the hosting, which, with high traffic, can be the last straw. Now, with 5000 thousand visitors per day, the load on the server processor is approaching the maximum allowable.

I have already begun to think about such a radical step, how to make my blog almost static, in the root folder of which regular Html files will lie, and the entire WordPress engine will work in a separate folder. Thus, the load will be minimized.

This can be done in WordPress using the miracle plugin Really Static . True, his version has not yet grown to one, but reviews of his work are extremely positive. In fact, it is a complete analogue of the well-known Maxsite Cache script, which, for example, is used by Mikhail Shakin on his blog.

The price for reducing the load will be the loss of some functionality, but I think that the correct settings for updating the cache (in this case, it will be ordinary Html pages, as on sites at the beginning of this millennium), it will be possible to reduce all these disadvantages to a minimum. In any case, I do not notice any crime in Shakin when I read his blog.

If someone already has experience with the Really Static WordPress plugin, then I would be very grateful if you leave your feedback about it in the comments. Thank you for the attention. The article has quietly come to an end. It’s time to polish it and get it ready for publication.