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.
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.
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. Continue reading “«Slap-on» speed optimization of your WordPress site”
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.