Is Laravel overrated

WordPress Performance - probably the best guide on the web

At least if I have my way! In a nutshell, anyone who runs a WordPress site with a few users per day quickly realizes that WordPress is easy quickly becomes very slow. Everyone knows the solution to the problem - activate the caching plugin and it is faster directly. But anyone who deals with it a little more also knows that one is still working do a lot more can. However, this again depends on how great your own technical understanding is. In the linked below English-language instructions you can simply find extremely good and successful step-by-step instructions, which really (almost) anything is possible.

Notes on WordPress optimization

Some additions to the respective chapters can be found in this section. In places the instructions above should have been a bit more detailed, but you don't want to complain.

Use a good basis (theme framework)

On Themeforest and Co. you get Avada, Enfold, Divi and Co. these days. thrown afterwards for little money. All themes are "multipurpose", you can implement a wide variety of layouts with them. Some even have their own layout and content builders integrated, others even have their own caching solutions. What many simply forget: every function, every query, every call of a hook makes such a "script" slow. And as a rule, such themes have to have thousands of queries in order to put together the case that the user has put together in the backend. Anyone who generally opts for such a theme simply cannot expect to get great speed values ​​from the start. In the end, the bitter thing is that 10 out of 100 functions are used, but 60 are also loaded.

The article even recommends the thesis framework as a basis. I would go further and say that frameworks should also be avoided - the less the better.

Use caching

Here, too, there is really little to say. There are some good caching plugins out there that one can use. If need be, I use W3 Total Cache and only the Page Caching module there. You generally have to test here. It can happen that a caching plugin slows down your site. The typical case is the usually uncached WordPress backend. If you are using W3TC and have activated the Object Cacher, the backend is slow in many cases. What I want to say: test, test, test and double-check! The egg-laying woolly milk sow does not exist here either.

Who one own server with Nginx operates, he can take a look at FastCGI Caching. For WordPress there is the appropriate plugin "Nginx Helper". If you then put the caching directory on the main memory, you have an incredibly good and faster alternative to all normal caching solutions. Key-value caching solutions á la Redis or Memcached are also recommended at this point and should be considered if possible.

However, it is always importantthat you take a close look at your own system! What should / must be cached and what not? Where dynamics are not needed (articles, pages, categories, start page, ...) and where are they simply necessary (Ajax calls, special plugins (product comparisons with session handling, ...).
Especially for complex customer projects I often see that some caching plugin is simply activated and one then wonders why it has become slower or why it does not work properly at all.


Even if CDN is being sold as the next big thing, it's worth it only reallywhen you have an extremely large number of visitors and they may come from different corners of the world. Then it is worthwhile to host assets on servers in their vicinity and deliver them from there. Anyone who has a few 1000 visitors a day should not expect a significantly higher performance boost from using CDN.

However, it is always worthwhile to host frequently used libraries externally - jQuery from Google CDN or the web fonts from Google, but also Bootstrap from MaxCDN, should be mentioned here. Most of your visitors will already have these libraries in their browser cache because some other site has already uploaded them there.

Optimize database

You can also do it, but thanks to indices, you can hardly expect any big leaps in performance here. It looks different if you have REALLY MANY articles written per day and thereby hundreds or thousands of revisions etc. are saved. I personally always set the interval between saving revisions to 120 seconds and allow a maximum of 3 revisions.

Optimize images

Clearly - the smaller the better. However, you should make sure that you do not lose quality. Nowadays, the subject of images on websites is very complex. I just mention them right new srcset and sizes attributes of the img tag, with which you can control a lot. If you invest a little time here, you can always deliver the right size of the picture to your visitors in optimal quality.

I am using the EWWW Image Optimizer. For static images, I mostly use JpegMini or. TinyPNG.

Gzip compression

Everyone should activate. In the best case, you deactivate the gzip compression on the PHP side (php.ini) and use the faster variant via Apache or Nginx.

Reduce the number of WordPress plugins

Unfortunately, I think this topic is neglected too often. WordPress operators tend to do this dozens of plugins to involve - without meaning or understanding. If you analyze these plugins you can see that some of these plugins are so incredibly bad and slow that it borders on illegality. Use the tried and tested big name plugins and do without unknown things.
Generally it is advisable Functions that smaller plugins (Social buttons, ... e.g.), more likely to be programmed directly into the theme. That is usually more efficient. In the article linked above, P3 (Plugin Performance Profiler) or the paid WP Performance Profiler is recommended. I had rather bad experience with P3 - rough data, partly incorrect or not meaningful. Much better is "Query Monitor„.

And if you still have problems with the identification of slow plugins and theme parts, you should perhaps commission someone with a thorough analysis. PHP offers great tools here, such as "XDebug"Whose use, however, is aimed at PHP developers and the tech-savvy.

Optimize web font performance

It has become established that huge amounts of web fonts can be obtained from the Google server. Here should be you look firstwhether this is generally necessary. There is great stuff there, so I use that too. Still, I take a look at what exactly I want to use: size 300 and 700 as well as Bold. In such a case I ONLY integrate these web fonts and do not use 500, 500 bold, 500 condensed etc. pp.
That saves a lot of loading time!
The general tips on the topic in the article are very worth reading.

Lazyloading of images, videos and disqus

This is also a super important theme. Images and other things that are displayed at the end of the page do not have to be loaded directly by the visitor. Here I use, for example, "Unveil". This is an incredibly small JS library that only loads the images in the viewport directly and then reloads everything that appears when you scroll down. I was able to reduce the initial size of from 600 KB to 250 KB.

The subject of Disqus is such a thing in general. I do without something like that because it is the Page extremely slowed down - great and useful or not. For me personally, for example, the WP Disquz comment system is completely sufficient! However, if you want or have to use Disqus, lazy loading of the part is practically mandatory! The visitor will thank you!

Shrink and merge JS and CSS files

Downsizing is practically compulsory, it always saves a few KB. Merging has always been the standard, but in the age of HTTP / 2.0 this is becoming less and less important, so it should not be overrated and not blind tools like Google Page Insights consequences!

For minifying I use either W3TC in manual mode or autopimize - a combination is often also possible. Theme CSS / JS should generally be made smaller by default. At this point, every good developer should use tools such as gulp, grunt or a good IDE with appropriate functions. For me, it's Netbeans that's about SASS minified everything directly. Great thing!

In the case of HTML shrinking, however, you have to be careful, as it is often in Source code comments that you must NOT delete. Simple Minify plugins do that, however.

If you fumble around here, move JS files in the source code and reduce this and that, you should then check extremely thoroughlywhether your own website works! Is everything loading? Can the user vote normally? Many sites simply activate plugins here, if they have great Insights values, the site simply does not work properly - unfortunately these are often the little things that nobody thinks about. If in doubt: let the professionals do the work!

Reduce HTTP requests

You can do it, but in most cases not really solvablebecause it is about topics such as ad servers or advertising scripts. The only thing that helps here is to expand - but that is not possible for most of them because they are dependent on advertising income. The deactivation of Emoji or Gravater can be done, see the article. With the "Query Monitor" plug-in you can also find out generally which external requests are being fired by plugins and themes. There are a few things that can be optimized away from time to time.

Deactivate hotlinking

Can be done, does not have to be. Whose pictures are of course linked thousands of times elsewhere, should give some thought here. The delivery of static content is rarely really a problem for me so little with performance to do. It looks different when it comes to the site with millions of hits a day.

Deactivate pingbacks and trackbacks

When you don't need it, then you should deactivate it - generally you can lock the xmlrpc.php (htaccess!) if you don't need it. This even protects against DOS attacks and potential security holes.

Define image dimensions

You should be extremely careful here! We live in times of "Responsiveness". The Google Insights Tool may see a problem here, but in real life it really isn't. I refer again to the srcset and size attributes of img. In the case of static images, such as logos, an image can be generated for each breakpoint in the appropriate size and delivered via CSS and background-image (). This also saves a few KB for the respective device if you do it right.

Slow admin-ajax.php "optimize"

Optimization is also worthwhile here, but you shouldn't expect too much either. The file is used excessively by various plugins and can quickly become a performance killer. However, you do not notice that much of it, as it is usually carried out asynchronously and at intervals. All in all, with many requests, this will at some point also be noticeable in normal requests and page views.

Optimize MySQL database

The article mentions the Perl tool "mysqltuner", which I also use. However, access to the server is necessary here, so this measure is aimed at technology freaks. Anyone who handles relatively large amounts of data (CSV import in the backend into the DB, for example) can definitely get a lot out of this. The “mysqlprimer” tool is also recommended at this point. MySQL can also be monitored in the console with "mytop". This is especially interesting when you have slow queries. In this context, however, the MySQL slowlog can also be activated directly.

Choose a good hoster

Simple and easy - if you choose a forest and meadow host to save 2 euros a month, you have to reckon with the fact that there is not enough budget to take care of all servers well really good hardware to put. Good hosters are, all-inclusive or Domain Factory.

To the complete article with all details on

How I handle it - brief insight

My pages are generally open current servers with NGinx. I have my own highly optimized themes, which I then like to program myself - I sometimes sit down for 10 to 20 hours. The nice thing is that it then unique is and super fast. In addition, I can go with modern ones right away PHP 7 compatible syntax use what ensures future security.

When developing, JS and CSS files are automatically merged. Plugin assets are only compressed with Autooptimize and, if the server only has HTTP / 1.1, also merged. At enabled HTTP / 2.0 or SPDY the files remain separate and are only reduced in size.

I don't use a caching plugin. For this I use the Fast CGI Cacher from Nginxwhose caching directory is located directly in RAM, which makes the pages extremely fast. It doesn't get any better than that. I program my own really important projects on the basis of frameworks without WordPress anyway - this is how I ensure good code quality and fast execution.

In general I try to forego plugins. There is a maximum of 10 and these are only relatively large and well-known plugins. I usually program important functions directly into the theme. Is hosted on small vServer instances on or on larger jiffy boxes, everywhere I put everything on my own and look after it!

Also: Since I only use large and well-known plugins, I have the great advantage that they usually compatible with PHP7.0 are. I now use that by default. The speed advantage is scary! I also forego looking at the Google Insight Tools - a lot of that is basically out of date. It is a shame, however, that so many people blindly follow what Google simply writes there. A lot is really good and recommendable, but not everything and above all you have to see it in context.

The results can always be seen in general - the latter two even work completely without caching:

Optimize WordPress sites really well not a trivial matter, even if the existence of countless plugins and tutorials gives this appearance. Not every measure is wise in every context. If you Advice on performance optimization Need your site - WordPress or something else - then do not hesitate and just get in touch.

Google Pagespeed Insights Tool: Be Careful

A few times now I have mentioned this extremely popular tool from Google. There is currently a huge amount of money to be made optimizing websites. The goal: the closer the value to 100, the better. In my own projects, I always set myself the goal of 100/100 for fun and achieved it. But as I said - you have to Tips always see Google in context!

What can be good on an HTTP / 1.1 server is already wrong on an HTTP / 2.0 server. Google gives bad points for pages that use CDN (where it makes sense), and the use of CDN in these cases often ensures very good loading times. The constant complaint that you can save a few KB when compressing images is also funny.
If you test such optimizations on an HTTP / 2.0 server, you always have to be aware that tools such as Pingdom cannot currently handle HTTP / 2.0. In general, one should be extremely careful when benchmarking. It has to be fast for the user and not for any computer program.

But what should I write more than others have already written. Worth reading:
HTTP2 will mean a change in how we should build websites. The best practices of HTTP1 are harmful in a HTTP2 world.
WP Rocket:Why you Shouldn't Care About Google PageSpeed ​​Insights