Верх страницы
Обложка к записи Оптимизация WordPress путём кэширования переводов
Время для прочтения: 0 мин. 15 сек.

Оптимизация WordPress путём кэширования переводов

API интернационализации i18n в WordPress реализован очень неэффективено.

Хотя файлы перевода и хранятся в форматах PO / MO и могут быть распаршены обычным gettext, но по факту WordPress использует свою собственную реализацию gettext под названием POMO, полностью написанную на PHP.

Это связано с тем, что модуль PHP gettext по умолчанию не встроен в PHP, поэтому на многих серверах его просто не будет.

Поскольку реализация gettext на чистом PHP в несколько раз медленнее, чем реализация на основе модуля, было предпринято несколько попыток для поддержки реализации на основе модулей.

Но ни одна из них не была добавлена в ядро WordPress, так как оказалось, что существуют серьезные различия между нативной/модульной реализацией и библиотекой POMO, включенной в WordPress.

Откуда берутся тормоза?

Каждая тема, плагин и само ядро загружают свои скомпилированные языковые пакеты при помощи функции load_plugin_textdomain, которые анализируются и загружаются в память. Эти операции занимают совсем немного времени.

Но поскольку скомпилированные языковые пакеты являются двоичными файлами, то преобразование их в массивы PHP связаны с с огромным количеством битовых и байтовых операций, которые сводят на нет использование компиляции пакетов.

Более того, выше указанные процессы происходят во время загрузки всех активных плагинов, поэтому ядро подтягивает абсолютно все строки в память, которые могут ему понадобиться в будущем. А, как известно, ленивой загрузки ядром не предусмотрено.

Плюс ко всему, разработчики не делают различий между строками для фронтенда и бэкенда, при этом реально для текущей страницы необходимо всего 1-10% от этих строк.

Как с этим бороться

Многие разработчики пытались бороться с этой проблемой при помощи кэширования декомпилировнных данных переводов в менее ресурсоёмких форматах: серилизация PHP или JSON, которые являются нативными и работают намного быстрее, чем библиотека POMO.

Все эти попытки давали прирост примерно в 20-30%, что уже совсем неплохо.

Так родилась библиотека pomodoro, название которой происходит от слияние двух слов POMO и d’Oro – золотой кэшер для POMO.

Для ее использования достаточно скопировать файл pomodoro.php из официального репозитория проекта на GitHub в папку вкраплений (необходимых плагинов) /wp-content/mu-plugins/ на вашем сервере. И плагин сразу начнёт работать.

Возможные проблемы

  • Отсутствие opcache. Без него работать будет на 50% медленнее
  • Использование pomodoro вместе с плагином Loco Translate может привести к непредвиденным результатам в некоторых редких случаях.
  • Папка временных файлов на сервере может быть защищиена от чтения/записи или закрыта через open_basedir.
  • В очень редких случаях (один на миллион, когда кончается дисковое пространство) при возникновении фатальных ошибок весь сайт падает с синтаксической ошибкой.

Ссылки

Автор: Кобзарёв Михаил

Русский разработчик с 20-ти летним стажем. Работаю с PHP, ООП, JavaScript, Git, WordPress, Битрикс, Joomla, Drupal, Opencart, DLE, Laravel, Moonshine, SuiteCRM.

Оптимизирую сайты под Google Page Speed, настраиваю импорты для больших магазинов на WooCommerce + WP All Import. Пишу плагины на заказ. Все мои услуги.

Веду блог о разработке, дайджест в телеграмме и в ВК.

Вы всегда можете нанять меня.

Комментарии
Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Предыдущая запись
Следующая запись

Давайте дружить
в Telegram

Авторский блог вашего покорного слуги в Telegram про web, программирование, алгоритмы, инструменты разработчика, WordPress, Joomla, Opencart, Laravel, Moonshine, фильмы и сериалы