performance

This article is not an introduction to neither Xdebug, Local by Flywheel nor PhpStorm, but shows you how you can get started with debugging and profiling your WordPress sites in PhpStorm when using Local by Flywheel as a local development environment. You should already know what Xdebug is before reading this article. This is how you get started with Xdebug in Local by Flywheel.{{ double-space-with-newline }}

With HTTP/2 push you can effectively send a web page’s assets to the client before the client even knows about them. Here’s how you can HTTP/2 push WordPress assets to your first-time visitors.{{ double-space-with-newline }}

WordPress translations are compiled from human-readable PO-files into machine optimized MO-files, but still takes a lot of overhead to load. If you only could cache the translation load time, you would save a lot of page load time. We can easily cut 90% of our WordPress translations loading time.

Generating the menus in WordPress is quite resource intensive. Sites with few visitors and few menu items might not notice this much. But if you have a large amount of menu items, like in a mega menu, in combination with a lot of visitors the menu generation can be a real hog on your server’s CPUs. Let’s see if we can improve the speed with a little WordPress menu cache trickery.

For 20 years or so, there has been the debate over whether you should use www or not in your web site’s canonical hostname. So should you use www or not?

OK, so you might have been at a WordCamp listening to talks or reading a few blog posts and you get that you should really get your WordPress site speed optimized. Starting all over isn’t either tempting nor something you have the time for. Don’t despair, you’ll get a long way by installing 5 plugins.

Now that you have secured Nginx with HTTPS and enabled SPDY enabled HTTP/2, it’s time to improve both the security and the performance of the server.

TL;DR: Varnish lacks support for SSL and SPDY. Nginx handles it just fine, and has very fast cache with either memcache or disk storage (ramdisk). Both can serve stale cache if your backend is down. But Nginx can not write to the memcache storage directly, it has to be done by the application. Also, Nginx can not purge the cache itself, without you compiling your own package.