Meet Surge, a brand new page caching plugin for WordPress. It’s extremely fast and has no configuration screens. There is no learning curve, the plugin works just by activating it.
Surge stores cache files on the filesystem, leveraging the Linux kernel page cache for efficient in-memory caching and invalidation. In various load tests, Surge has shown to easily handle 1000-2500 requests per second at 100 concurrent, on a cheap single-core virtual server with only 1 GB of memory. That’s over 70x faster than a stock WordPress install with a default theme and no plugins.
Surge is free and open source, available under the GPL.
Another Caching Plugin
As many of you know I’ve been working on a CLI tool called Sail these past few months, and one of the features many customers have been asking for is caching.
I agree, a WordPress site can not be considered production-ready without a page caching layer, so I’ve been on the lookout for a good fit for Sail. I’ve probably tried every single page caching plugin for WordPress, and unfortunately none of the available options were a great fit.
The biggest blocker for me was the configuration, screen after screen after screen, the amount of hoops I had to jump through just to get things working. And sure, there are on-screen guides and wizards, video tutorials, hundreds of documentation articles, but all I wanted was a page caching plugin, not a rocket (no pun intended).
I had to roll my own.
The first draft of Surge was created a few months ago during a live stream, and since then, it’s been polished and battle-tested on various small and large WordPress projects in production. It’s in good shape, and will soon ship with Sail by default.
Installing Surge
If you already use a page caching plugin, you’ll have to deactivate it first. If you’re hosting with a managed WordPress host, you might already have a built-in caching solution and may not need an additional plugin (ask your host).
Otherwise, you can install Surge using WP-CLI:
wp plugin install --activate surgeOr using the WordPress Dashboard, in Plugins – Add New – Search for “surge”, then hit Install. After the installation is successful, hit Activate to enable caching.
Surge will automatically invalidate cached entries on various different events, so you shouldn’t have to worry about that. There’s no “clear cache” button and you shouldn’t really need one. However, if for whatever reason, you absolutely need to clear the page cache, just toggle the plugin off and on.
If you like Surge, consider rating it on WordPress.org, and if you have any questions, or come across any problems with the plugin, feel free to reach out via the support forums, or Twitter.
Many congrats on launching Surge.
Will ask my team at Cloudways to test and write about it.
Thanks Saad, let me know if you bump into any issues!
Приветствую.
А почему кеш-версии страниц хранятся в “нечеловекопонятных”, в смысле названий, папках и файлах?
Я так понимаю, вычисляется какой-то хеш адреса страницы для формирования названия файла/папки, где хранится копия страницы. По сравнению с другими плагинами кеширования, где структура хранения кеша совпадает с урл-ом, по типу /wp-content/cache/domain.com/category/post/index.html или подобного – я вижу для себя большой недостаток – В .htaccess , например, нельзя прописать правило для отдачи кеш-версии в обход index.php , т.е. вместо того, чтобы вообще не вызывать php обработчик при обращении к кешированной странице, один раз он таки вызывается, при тысяче обращений – тысяча вызовов?
Возможно я поспешил и что-то не так понял, тогда сори.
Спасибо за комментарий!
Вы все правильно поняли. Surge не хранит файлы кэша в открытом виде, так как содержимое одного и того же адреса может изменятся, в зависимости от данных запроса. Например если в запросе присутствуют параметры ?sort=asc или ?search=term, то это все тот же /domain.com/index.html
Также в Surge есть возможность задавать вариации кэширования в зависимости, например, от наличия определенного куки, или User-Agent, или заголовка гео-локации от вашей CDN и других факторов.
Содержимое может не только изменяться в зависимости от этих параметров, но и содержать конфиденциальные данные. Поэтому мы не только задаем трудго-угадываемые названия ключей, но и обеспеичваем безопасность содержимого, путем хранения их в .php файлах (а не .html) и имея функцию exit(); в самом начале.
Конечно это не сравнится по скорости с выдачей напрямую .html файлов через Apache/Nginx, но если вы хотите получить максимум, то рекомендуем fastcgi_cache/proxy_cache, или эквивалент в Apache, тогда вы будете обходить стороной PHP, и результаты будут близки к выдачи статических .html файлов.
спасибо за ответ, теперь идея понятна. мой вопрос был основан в основном на том, что для разных друзей/клиентов, использую плагины кеширования на шаред хостингах, что не позволяет лезть в конфигурацию дальше чем “редактирование .htaccess”, и там отдача html напрямую действительно спасает