Плагин для ускорения wordpress pagespeed ninja: инструкция и описание

Тестирование плагина Pagespeed Ninja

Сделал несколько сравнительных тестов на сайте wp-best.ru.

Стоит заметить, что сайт на легкой теме Astra, обслуживается оптимизированным centmimod стеком, подключены cloudflare и оптимизация изображений в jetpack. Скорость высокая, поэтому сложно оценить потенциальный прирост. Но можно проверить свои ожидания, и в целом работоспособность сайта.

Тесты проведены на вкладке Audit в браузере Google Chrome.

С включенным Pagespeed Ninja

Одного теста, конечно, мало. По-хорошему надо тестировать большее количество страниц, применять разный набор опций, понимать как они устроены и где их лучше использовать.

В целом, мне плагин понравился. Буду продолжать тестировать в разных условиях.

Есть еще один положительный момент — здоровая конкуренция. Это позволяет схожим продуктам быстрее развиваться и улучшаться.

Напишите ваши впечатления, если плагин Pagespeed Ninja у вас уже установлен. Если только собираетесь устанавливать, не знаете какую опцию выбрать или возникает ошибка, напишите вопрос в комментарии — постараюсь помочь.

Apache

Модуль для apache называется mod_pagespeed и может распространяться как пакет.

Установка

Установка модуля немного различается для различных систем. Рассмотрим 2 варианта.

CentOS

Устанавливаем пакеты at и wget:

yum install at wget

Затем необходимо скачать установочный пакет:

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_x86_64.rpm

* в данном примере мы загрузим пакет для 64-битной системы. Для 32-х нужно использовать ссылку https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.rpm.

После можно ставить сам модуль:

rpm -Uvh mod-pagespeed-*.rpm

Перезапускаем Apache:

systemctl restart httpd

Ubuntu

Загружаем установочный пакет:

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb

Устанавливаем скачанный пакет командой:

dpkg -i mod-pagespeed-*.deb

После установки модуля, необходимо перезагрузить apache:

systemctl restart apache2

Настройка

а) если используем CentOS:

vi /etc/httpd/conf.d/pagespeed.conf

б) если используем Ubuntu:

vi /etc/apache2/mods-enabled/pagespeed.conf

Данный файл хорошо документирован комментариями. Приведем некоторые примеры для настроек.

1. Для отключения модуля находим:

ModPagespeed on

и меняем на:

ModPagespeed off

2. Для указания конкретного каталога хранения кэша меняем опцию для:

ModPagespeedFileCachePath         «/var/cache/mod_pagespeed/»

3. Путь хранения логов:

ModPagespeedLogDir       «/var/log/pagespeed»

Для применения настроек не забываем перезапустить apache:

systemctl restart {apache2,httpd}

* данная команда отработает как на CentOS, так и Ubuntu.

Доступ к веб-интерфесу

Веб-интерфейс модуля позволяет увидеть статистику его работы, а также получить сведения о текущих настройках. По умолчанию, доступ к нему разрешен только с локального сервера. Для того, чтобы разрешить подключение с определенной сети открываем файл:

vi /etc/httpd/conf.d/pagespeed.conf

Находим настройку:

<Location /pagespeed_admin>
    Order allow,deny
    Allow from localhost
    Allow from 127.0.0.1
    SetHandler pagespeed_admin
</Location>

И добавляем в нее доступ (Allow from …) — в итоге мы получим, примерно, следующее:

<Location /pagespeed_admin>
    Order allow,deny
    Allow from localhost
    Allow from 127.0.0.1
    Allow from 192.168.1.5
    Allow from 192.168.0.0/24
    SetHandler pagespeed_admin
</Location>

* в данном примере мы добавили разрешение использовать веб-интерфейс для узла 192.168.1.5 и всей подсети 192.168.0.0/24.

Перезапускаем сервис:

systemctl restart {apache2,httpd}

Открываем веб-интерфейс по адресу http://<IP-адрес сервера>/pagespeed_admin — мы должны увидеть страницу Pagespeed Admin.

Сократить время ответа сервера

Есть такой термин — Time To First Byte. Так называют интервал времени до получения после отправки запроса со стороны посетителя самого первого байта.

Согласно рекомендациям Google, этот показатель не должен быть больше 200 мс. В идеальном варианте — не более 50 мс. Чем меньше такой показатель, тем более быстро начнется загрузка страницы браузером.

Необходимо проверить TTFB? В таком случае используйте PageSpeed Insights. После завершения инструментом анализа проверить информацию можно в блоке под названием «Сократите время от сервера».

Часто такие проблемы возникают, если используется плохой или недостаточно мощный сервер. В таком случае он может давать долгий ответ. Или, как вариант, — сервер расположен далеко территориально.

Eliminate Render-blocking JavaScript and CSS

The next thing on the list was Eliminate render-blocking JavaScript and CSS in above-the-fold content. When I selected to optimize the CSS settings using the Speed Booster Pack plugin it solved this issue on the first try. However, I had deleted that plugin when I didn’t see enough improvement in the score. I had a dramatic improvement with WP Performance Score Booster, so I decided to install a minifying plugin by the same author.

WP Super Minify

This free plugin will compress JavaScript and CSS. You can choose what to compress, but to compression is supposed to work on install. Installing it actually dropped the score back to 85 and the message to eliminate render-blocking JavaScript and CSS in above-the-fold content was still there. After several attempts to make improvements I decided to delete this plugin.

PageSpeed Score with WP Super Minify = 85/100 (actually reduced)

Better WordPress Minify

This free plugin has several good options to minify your JavaScript and CSS. I installed it and went through the settings. After running it, it still had suggestions to minify JavaScript, CSS, and HTML, but they were lower in the priority list. It had fixed the largest issues and increased my score by 1 point.

PageSpeed Score with Better WordPress Minify = 86/100

I still had 6 blocking scripts that caused delays in page-loading: 2 blocking JavaScript resources and 2 blocking CSS resources. This was giving me the message to eliminate render-blocking JavaScript and CSS in above-the-fold content. I decided to look for a plugin that moves files from the header to the footer.

Autoptimize

This plugin is supposed to compress and move files such as styles and scripts from the header to the footer. It will also minify the HTML, making it as lightweight as possible.

I went through all of the settings, but my score was still 87 at best and I was still getting the message to eliminate render-blocking JavaScript and CSS in above-the-fold content. This one fixes both of the JavaScript issues and two of the CSS issues. One of the remaining issues was an Autoptimize file. The other was Google fonts.

PageSpeed Score with Autoptimize = 87/100

Out of curiosity I turned on the Speed Booster Pack again and the page speed score went up to 90/100.

PageSpeed Score with Speed Booster Pack = 90/100

I still had 2 blocking CSS files. Suggestions were:

• Defer
• Asynchronously load

I tried several plugins but could not find one to fix the issue.

Async JS and CSS

This free plugin will load your JavaScript and CSS asynchronously. The only adjustment I made was to move all CSS to the footer. It did not move the two files.

At this point, server response time was higher on the list, so I moved on.

Поверка работы модуля

После того, как мы установили и применили модуль, необходимо убедиться, что он используется при работе сайта. Можно сделать это несколькими методами.

1. Браузер Google Chrome

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

Нам необходимо посмотреть заголовки при ответе и убедиться, что среди них есть X-Mod-Pagespeed. Для этого запускаем браузер и кликаем F12, чтобы вызвать панель разработчика. Переходим на любой сайт на нашем сервере. В панели разработчика переходим в Network — кликаем по любому загруженному элементу в списке слева — Headers — если наш сервер настроен верно, мы увидим заголовок X-Mod-Pagespeed и версию модуля:

2. Командная строка Linux

Также мы можем выполнить проверку на сервере с помощью curl. Для этого вводим команду:

curl -I -p http://localhost

Мы должны получить что-то на подбие:

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Date: Fri, 03 Jul 2020 09:45:20 GMTX-Page-Speed: 1.13.35.2-0
Cache-Control: max-age=0, no-cache

3. Используем Google PageSpeed Insights

Переходим на страницу PageSpeed Insights и вводим адрес сайта — нажимаем Анализировать:

Ждем результатов и на основе их принимаем решение для оптимальных настроек модуля pagespeed.

Рекомендации Google Page Speed Insights

Кроме подробного отчета о производительности веб-ресурса, сервис предлагает и различные варианты для ее улучшения. Например, сайт Amazon.com получил следующие предложения по оптимизации.

Использование кеша браузера. Практичный и полезный совет по применению заголовков кеширования для хранения копий статических файлов (не меняются от одного поискового запроса к другому) в браузере пользователя.

Возможна ситуация, когда в списке ссылок присутствует ресурс, веб-хостинг которого реализован на стороннем сайте, что делает невозможным выполнение данной рекомендации.

Удаление JavaScript, блокирующего рендеринг. По возможности организуйте выполнение интерактивных сценариев веб-страниц в футере сайта (footer – нижняя часть) или сделайте асинхронную загрузку шапки и JavaScript. Также часть кода можно перенести в основную HTML-разметку

Здесь важно участие профессионала, чтобы не нарушить корректную работу функционала сайта. Эта рекомендация не подходит для ресурсов, использующих готовый шаблон WordPress.

Оптимизация Cascading Style Sheet. Существует возможность разделения CSS-кода для приоритетной выгрузки стилей оформления первого экрана в шапку сайта и добавления остальных каскадных таблиц в футер. Здесь также нужно участие верстальщика, чтобы избежать будущих проблем в работе сайта.

Сжатие изображений. Эффективным способом увеличения скорости загрузки сайта является оптимизация размера картинок и фотографий. Для этого можно использовать редактор Adobe Photoshop или специализированные онлайн-сервисы: Compressor.io, TinyPNG, Optimizilla, Web Resizer. Рекомендуемая ширина изображения в формате jpeg, gif или png – 400–600 пикселей при весе 35–75 Кб.

Бесплатный инструмент Google Page Speed Insights отличается быстродействием, простотой применения, детальным анализом производительности сайта и практичными рекомендациями по повышению скорости загрузки. Используя этот сервис, вы сможете улучшить конверсию своего веб-ресурса и избежать ситуации с уходом пользователя по причине затянутого рендеринга или длительной выгрузки изображений.

Начало ускорения

Оптимизация WordPress начинается с теста скорости. Тут все довольно просто, есть такие инструменты, как PageSpeed Insights от Google, также Pingdom Tools, GTmetrix. Рекомендую использовать все, они покажут, какие слабости есть у сайта. Ниже скриншоты тестов. Вроде все неплохо, за исключением гугловского инструмента. К сожалению, вы запросто можете оказаться в ситуации, что от вас требуют высоких результатов в данном тесте, не понимая даже, что он собой представляет. Конечно, можно улучшить сильнее, но тогда пострадает дизайн. В целом, в мобильной версии у меня от 60 до 64, в ПК от 87 до 93. Когда как. Но в основном проблема заключается в партнерках, счетчиках и частично с файлами js и css. В общем, многое исправить будет нелегко, да и не нужно.

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

Могу с уверенностью сказать, что в мобильной версии высокие результаты часто идут во вред пользователям. Отложенная загрузка всего и вся и чуть ли не голая HTML-страница — единственный путь к заветной сотне. В общем, PSI немного отстал от жизни, голый HTML давно почил в небытие. И да, разработчиками инструмента является не Google, а другая компания, так что не ждите от него идеальных результатов, он не замеряет скорость, а ищет потенциально-слабые места в сайте.

Итак, в первую очередь отключаем плагины кэширования. Они будут серьезно мешать в процессе работы. Сжатие тоже рекомендую отключить на уровне хостинга. Если в файле .htaccess прописаны методы cache и сжатия, комментируем их. Теперь поехали. Пришло время разобраться, как ускорить WordPress.

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

Кстати, специально для тех, кто решит протестировать мой сайт, публикую результаты теста без использования рекламы от Яндекс.

Тест сайта без рекламы

А на скриншоте ниже наглядно демонстрирую, что реклама творит со скоростью сайта. К сожалению, это так. Кстати, Adsense меньше замедляет сайт.

Тест сайта с рекламой

Так что, если у вас на сайте реклама, то скорость будет на порядок ниже. И ничего с этим поделать не сможете.

Оптимизация сайта по PageSpeed: что нужно делать?

Согласитесь, задача по оптимизации кода JavaScript способна поставить в тупик как простого сайтовладельца, так и SEO-шника. Везунчиками можно считать тех, чьи сайты собраны на CMS WordPress – для этой платформы есть плагины на все случаи жизни.

Я как раз из числа таких везунчиков, поэтому знаю плагины, с помощью которых можно массово пожать картинки и настроить Lazy-Loading. Однако их я не использую, поскольку нашёл более красивое решение – плагин Autoptimize.

Autoptimize – настоящий бальзам на раны тех, кто устал видеть сайт в красной зоне PageSpeed. Один-единственный плагин позволяет настроить Lazy-Loading, оптимизировать JS, CSS и код HTML, конвертировать картинки в WebP и включает в себя еще много полезных «плюшек» – например, Try-Catch обертывание для исправления ошибок JS. Optimizer настраивается действительно гибко – можно, например, некоторые скрипты добавить в список исключений, чтобы программа их не жала и не объединяла с другими.

Autoptimize эффективен. Я могу это подтвердить результатами замеров до и после активации плагина.

ДО

ПОСЛЕ

Однако плагин я ставил не только ради самоуспокоения и красивой картинки

Я также хотел докопаться до истины, стоит ли обращать внимание на PageSpeed или это пузомерка-«пустышка». Поэтому я поставил простой эксперимент

Плагины для увеличения оценки PageSpeed Insights

Для WordPress написаны десятки плагинов, ориентированные на увеличение скорости загрузки разным типом способов: включение gzip сжатия, задание сроков хранения статических ресурсов, сжатие кода (минификация html, js, css), сборка js и css в файлы и откладывание их загрузки, асинхронная загрузка, оптимизация изображений, ленивая загрузка (изображения, iframe, video), динамическое кэширование (генерация статических страниц), оптимизация загрузки шрифтов, отключение лишнего функционала и т.д.

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

В моей услуге по ускорению сайтов на WordPress я работал с десятками сайтов разной сложности, содержания и способов наполнения. Я выделил наиболее общие проблемы с возможными путями их решения.

Уменьшение времени ответа сервера. Обычно достигается включением динамического кэширования (WP Super Cache, Cache Enabler и др.).

Оптимизация кода (минификация, сборка, откладывание). Я использую для этих целей популярный плагин Autoptimize. Есть другие плагины, имеющие аналогичный функционал — WP Rocket, Pagespeed Ninja, WP Fastest Cache.

Безопасность и легкость этого процесса зависит от слоёв кода сайта. Если повезет — оптимизацию удастся выполнить в несколько кликов. Но в реальности очень часто возникают ошибки и требуются технические навыки для их поиска и исключения.

Оптимизация кода позволяет сократить вес страниц, снять блокировку ресурсов, которые препятствуют отображению (частично, за исключением jquery и основного файла стилей), и сократить количество запросов (обычно в 1,5 — 2 раза)

Оптимизация изображений. Я использую плагин Ewww Image Optimizer, как один из наиболее актуальных, популярных и проверенных, и его бесплатного функционала вполне достаточно. Некоторые особо крупные изображения лучше сжимать вручную.

В принципе, любой плагин подойдет и пользоваться ими просто.

Вместо максимальных настроек сжатия имеет смысл сочетать с технологией ленивой загрузки.

Ленивая загрузка. Позволит очень существенно сократить вес страницы. Многие плагины поддерживают включение ленивой загрузки изображений (практически все вышеперечисленные). Но нередко появляются ошибки в визуальном отображении, и появляется необходимость исключать оптимизацию изображений в некоторых блоках.

Но продвинутые настройки ленивой загрузки есть не во всех плагинах. Сюда также можно добавить ленивую загрузку видео (youtube) и iframe (вставки карт), — эти скрипты очень увесистые, — если удастся их отложить, будет значительный прирост.

Внешние скрипты, чаты и виджеты. С ними обычно основная беда скорости загрузки., потому что вы не можете вмешаться в ход их выполнения, и оптимизировать загружаемые ими ресурсы.

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

window.addEventListener('scroll', () => {
        
        setTimeout(() => {

        }, 1000)
    }
});

Такая оптимизация потребует определенного уровня знаний и навыков.

Поэтому, увы, достижение высокой оценки PageSpeed Insights одними лишь плагинами для WordPress, зачастую задача невыполнимая.

Что за PageSpeed такой?

Один мой знакомый SEO-шник настолько верил в «силу» аналитических способностей PageSpeed, что отказывался вести работу над сайтом дальше, пока программисты не довели бы его до желтой зоны. Настолько его впечатлил анонс нового фактора ранжирования Google под названием «Speed Update» – скорости загрузки сайта на мобильных устройствах. Он считал, что с плохим баллом по PageSpeed чуда однозначно не случится, и доводил программистов до исступления изнуряющими ТЗ. Те же доводили владельца бизнеса до обморока кошмарными счетами за работы. В итоге этого парня уволили. Это к слову об Икаре и совершенстве.

Ждешь 2-3 минуты – и готово! Speed Test завершен, ты убеждаешься, что твой сайт, по мнению Google – «улитка».

Проверить на Page Speed можно любой сайт – и это бесплатно!

Какие рекомендации дает сервис от Гугл?

К чести сервиса, он не оставляет тебя удрученного и без поддержки. Пэйджспид даёт подробные рекомендации по поводу того, что сделать, чтобы улучшить показатели.

Каждый из пунктов можно еще развернуть, чтобы получить точные данные – например, о том, какие картинки замедляют загрузку.

Залипнуть можно не на один час! Я же вкратце перечислю типичные рекомендации:

• Отложить загрузку скрытых изображений. Здесь речь о технологии Lazy Loading.
• Использовать современные форматы изображений. Сервис советует отказаться от PNG и JPG в пользу экзотических форматов – вроде WebP.
• Устранить ресурсы, блокирующие отображение страницы. Речь об излишних JS и CSS.
• Настроить эффективную кодировку изображений. Если перевести на русский – сжать картинки.
• Сократить время хранения кэша. Если кэш хранится долго, то при повторном посещении страница будет загружаться медленно.
• Уменьшить влияние стороннего кода. То есть по максимуму выбросить различные счетчики, оставить только Analytics, который (опять же по данным PageSpeed, который в некоторых вопросам может быть – хм, хм – необъективен) почти не замедляет сайт, в отличие от «Метрики».

PageSpeed Insights измеряет отдельно версии сайтов для мобильных и для компьютеров. И если десктопные довести хотя бы до жёлтой зоны реально, то с мобильными версиями у большинства – катастрофа.

Операция «Ускорить WordPress»

Существует множество факторов, которые влияют на скорость загрузки сайта: число и размер объектов на страницах, время ответа сервера, ненужные редиректы и многое другое.

Прежде чем приступить к ускорению своего ресурса, Ник Лерой решил понять, с чем предстоит работать. Так как сайт построен на CMS WordPress, были проанализированы следующие области:

• хостинг,
• тема,
• плагины,
• изображения,
• ресурсы.

На основе проверки был составлен список того, что можно улучшить. Затем Ник приступил к внедрению изменений.

Проблема: хостинг и TTFB

Первое, что бросалось в глаза при поверхностном анализе — большое время до получения первого байта после отправки запроса со стороны клиента (Time To First Byte или TTFB) для всех страниц сайта: от 1,5 до 2 секунд. И это было просто время, которое необходимо для первоначального соединения со страницей без ее загрузки.

Помимо этого были и другие проблемы, связанные с хостингом: отсутствие HTTP/2 setup/configured (проблему можно было бы исправить, используя CDN), отсутствие кеширования и т.п. Общий хостинг на Hostgator не способствовал достижению цели увеличения скорости загрузки сайта.

Решение: смена хостинг-провайдера

В качестве альтернативы существующему хостингу были выбраны два провайдера: FlyWheel и Kinsta. Оба провайдера:

В итоге было решено остановиться на хостинге FlyWheel. Этот провайдер был немного дешевле и предоставлял локальные решения для разработки новых сайтов на WordPress.

После некоторых раздумий Ник Лерой решил создать новый сайт NickLeRoy.com. И вот, почему.

Проблема: оптимизация тем, плагинов, изображений, ресурсов

Даже с лучшим хостинг-провайдером сайт может медленно загружаться. На это бывает несколько причин.

Тема WordPress

Тема, которая изначально использовалась на сайте Ника, была куплена у сторонних разработчиков. Часто такие темы поставляются в комплекте с кучей различных функций. Имеют компоновщик страниц, плагины для слайд-шоу, несколько библиотек JavaScript, библиотеки шрифтов и многое другое. Нередко такие темы используют CSS и JavaScript, чтобы удовлетворять потребностям аудитории.

В результате многие темы содержат большое количество ненужного функционала.

Плагины

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

Изображения

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

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

Ресурсы

Многие проблемы медленной загрузки сайтов связаны с ресурсами на страницах, в значительной степени с CSS и JavaScript. Если правильно выбрать тему и плагины, многие сложности отпадут сами собой. Ведь чем легче тема и эффективнее плагины, тем меньше владельцам сайтов нужно думать об оптимизации ресурсов.

На сайте NickLeRoy.com использовалось большое количество ресурсов, даже там, где они не были необходимы. Шрифты, javascript-файлы для ненужных функций, CSS для стилей и эффектов и многое другое, от чего можно было бы избавиться.

Решение: создание нового сайта

Оценив состояние ресурса, стало понятно, что без внесения существенных изменений в тему и плагины оптимизировать производительность сайта не удастся. Даже смена хостинга не помогла бы сделать сайт быстрым. Нужно было решить проблемы с темой, плагинами, ресурсами и изображениями.

Тогда Ник принял решение перезапустить сайт с нуля на новом хостинге. Для этого была проделана следующая работа:

• чистая установка WordPress на Local by Flywheel с чистой базой данных и кодом,
• установка облегченной темы,
• установка конструктора страниц Elementor, чтобы сайт выглядел так же, как изначально, но загружался быстрее,
• перестройка всего сайта,
• оптимизация изображений с помощью imageOptim. Для этого все картинки были загружены в папку wp-content/uploads, пропущены через сервис imageOptim, и выложены обратно на сайт. Суммарное сжатие составило около 90% по сравнению с исходным размером файлов,
• установка Autoptimize и Async Javascript, что позволило объединить JS и CSS и уменьшить / удалить блокировку рендеринга.

После реализации описанных выше действий сайт был перемещен из локальной среды разработки в промежуточную. Затем специалисты настроили SSL и HTTP/2 и после тестирования обновили DNS.