Уже пошел 5й год, как я выпустил Alpha Cache. Писал этот модуль для собственных нужд, не хотелось разбираться с тонкостями настройки готовых модулей, и задача мне казалась интересной.
Последний раз обновлял модуль больше года назад, т.к. особых идей по развитию не было. Но буквально на днях нашел на хабре обзор по кеш-модулям, где были проведены разные сравнительные тесты целой кучи плагинов. Среди них был и мой. Результатами мой Aplha Cache, прямо скажем, не блистал.
Мне стало интересно, как добиваются высокой производительности лидеры тестов, т.к. я, по моему мнению, цеплялся настолько рано в WP, насколько мог, чтобы выдать кеш.
Я даже попробовал выполнить код не в хуке, а прямо при объявлении модуля. Показатели несомненно улучшились, но до лидеров было далеко. Это уже интриговало.
Оказалось, что ключевой момент — это выдать кеш вообще до загрузки WP. Для этого модули встраивали свой код в .htaccess, чтобы переключить mod_rewrite на свой обработчик.
Что нового?
Я пошел проторенным путем, создав перехват инициативы через mod_rewrite. Модуль работает как бы в двух режимах:
- static — когда выполняется выдача кеша без запуска WP,
- interactive — когда условия для быстрой выдачи не подходят, тогда приходится запустить движок, создать/выдать кеш после загрузки WP. Кроме того, сервером может быть и вовсе не Apache, тогда модификация .htaccess не поможет.
Я усовершенствовал и старую схему, отказавшись от хранения данных в базе (ну да :) иначе в новом подходе было и нельзя, ведь к базе мы обращались, используя WP).
Раз уж мы полезли в .htaccess, было бы грешно не реализовать подключение типовых настроек для улучшения в тестах Google PageSpeed Insights. В настройках я назвал это бустерами. Некоторые модули также реализовывали эту фишку.
Новую версию ещё предстоит обкатать, чтобы более точно определиться с настройками для .htaccess и алгоритмом выбора режима кеширования.