Как я пытался сократить время открытия сайта: почему я отключил плагин Jetpack

Вступление

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

Начало эксперимента сократить время открытия сайта

Для начала, делаю полную резервную копию сайта. Она всегда к месту. Для анализа нагрузок на сервер со стороны установленных плагинов ставлю и активирую плагин P3 (Plugin Performance Profiler). Все ссылки внизу статьи. На 27-01-2020 этот плагин не поддерживается более 3-х лет, используйте другие инструменты проверок.

P3 (Plugin Performance Profiler)

  • Если плагин P3 использовался на сайте ранее, удалите все истории сканирования, на вкладке History, в настройках плагина;
  • На вкладке P3, включаю сканирование сайта плагином P3, кнопкой «Scan Now». Использую режим автоматического сканирования «Auto Scan»;
  • Жду результатов, долго жду, сканирование затянулось;
  • По диаграмме результатов вижу, что плагин Jetpack самый тяжелый из всех установленных плагинов. Именно тут меня посещает мысль, что Jetpack основная причина «тормозов» сайта.

P3 (Plugin Performance Profiler) анализ сайта

Иду дальше. Раздражение большим временем загрузки сайта зашкаливает и чтобы добить себя, ставлю скрипт в Footer чтобы посмотреть время ответа сервера (о нём я писал тут). Вижу неутешительную картинку: время ответа сервера 1,7-2,3 сек, а должно быть менее 200мс по рекомендации Google.

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

Анализирую сайт на Webpagetest по точке проверки: Европа. Это значит, что контрольная точка проверки будет в Европе и запрос будут посылать и получать из Дата-центра в Амстердаме. То есть будет моделироваться ситуация, что пользователь сидит в Амстердаме. Амстердам не Москва, но ближе ничего нет.

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

Вижу такую картинку.

  • Общее время загрузки: 12,823 сек;
  • Ответ сервера: 0,870 сек;
  • Время до начала прорисовки: 3,414 сек;
  • Загрузка до DOM: 12,177.

WebPagetest Test Result проверки сайта

По таблице Request Details, вижу детали анализа. Тормозят сайт или дольше всего загружаются:

  • Файлы (скрипты) Яндекс метрика,
  • Скрипты Google Analytics,
  • Статистика JetPack (WordPress),
  • Форма подписки mailMunch.

таблица Request Details

Также вижу, что основные файлы JetPack, загружаются быстро, в рамках 45-50 мс, каждый, правда, их много.

Также вижу, что дольше всего грузятся: картинки превью и фотогалереи расположенные на странице. Обще время: около 5 секунд. Это очень много. При этом я все картинки оптимизирую до загрузки на сайт программой Caesium и на сайте сжимаю фото плагином WP Smush.

Что делаю для исправления

  • Убираю с сайта плагин статистики Google;
  • Отключаю в настройках плагина статистику JetPack;
  • Убираю из виджетов сайта картинки, которые были в отчете Request Details, были выделены, как тяжелые.
  • Отключаю все плагины кеширования. У меня стояла двойка Autoptimizer и WP Fastest Cache. Почему? Есть подозрение, что они у меня работают наоборот.
  • Очищаю папку cache вручную по FTP.

Следующий шаг: Отключаю плагин JetPack, с чего собственно началось. Опять делаю замер скорости, после очистки кэш браузера. Вижу, полное время загрузки сайта 9,161 сек. Сократить время открытия сайта удалось, но не принципиально.

Google (PageSpeed Insights)

Меняю сервис проверки скорости сайта и иду в проверку скорости на Google (PageSpeed Insights). Замер дает такой результат: 64/100, мобильный сайт и  74/100 обычный. Опять плохо. Продолжаю чистку сайта, делая контрольные замеры скорости.

Google (PageSpeed Insights)

  • Отключаю всю рекламу на сайте;
  • Нашел коды статистики вставленные плагином «Tracking Code Manager». Убираю коды статистики и отключаю этот плагин;
  • Отключаю плагины, которые использую лишь для анализа и проверок сайта. В частности отключаю плагины «WP Smush», сжатие картинок и «Broken Links» для поиска битых ссылок.
  • Очищаю базу данных сайта плагином «Optimize Database after Deleting Revisions», после очистки плагин отключаю.

Опять делаю замеры на PageSpeed Insights. Сервис «ругается», но меньше: 67/100 и 78/100.

В завершении, хочу сжать картинки вручную

  • По FTP иду в картинки сайта (каталог wp-uploads).
  • Копирую картинки последнего месяца на комп.
  • Использую программу «Caesium», сжимаю все картинки и возвращаю на сайт.

Опять замер скорости на Webpagetest:

  • Время до прорисовки: 10,438, полная загрузка 11,918.
время открытия сайта
Контроль, как удалось сократить время открытия сайта

Другие проверки:

  • Смотрю результаты скрипта в футере: 26.26MB | MySQL:102 | 0,282sec.
  • PageSpeed Insights: 80/100 и 86/100.

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

сократить время открытия сайта
сократить время открытия сайта удалось, но не идеально

Лучше чем было, но не идеально. На сегодня всё, пора делать выводы. Замечаю, в PageSpeed Insights внизу анализа строка: «скачать оптимизированные изображения, файлы JS, CSS этой страницы». Что-то новенькое. Скачиваю архив и заменяю файлы, которые сервис оптимизировал для меня. Результат улучшается.

Выводы

Все «танцы» со временем загрузки, дают простой вывод. Если вам нужен быстрый сайт нужно:

  • Минимально использовать фото на сайте;
  • Сжимать фото перед загрузкой на сайт, например, программой Caesium.
  • Плагины сжатия фото показывают не идеальный вариант;
  • Не использовать рекламу;
  • Сократить количество плагинов до минимума, а лучше не использовать вовсе.

Итог

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

Отсюда вывод: Тяжелые плагины WordPress принципиально не влияют на скорость загрузки сайта.

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

Кстати, на JetPack есть модуль Photon, который должен ускорять загрузку картинок. Я этого не заметил.

27-01-2020: За время жизни статьи плагин JetPack сильно изменился. В бесплатной версии добавлены 4-функции ускорения сайта, появилось много интересного функционала. Я JetPack продолжаю использовать, а для ускорения сайта ставлю один из плагинов кеширования: Comet Cache или WP Speed of Light. Для сервера Fozzy  плагин LiteSpeed Cache. Плагины Autoptimize, WP Fastest Cache и WP Super Cache перестал использовать. От плагина  W3 Total Cache из-за сложности настроек, не могу получить хороший результат.

Полезные ссылки статьи

  • JetPack плагин: https://ru.wordpress.org/plugins/jetpack/
  • P3 (Plugin Performance Profiler) плагин: https://ru.wordpress.org/plugins/p3-profiler/
  • PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=ru
  • Webpagetest сервис анализа скорости сайта: https://www.Webpagetest.org/
  • Caesium программа сжатия фото: https://saerasoft.com/caesium/
  • WP Smush плагин сжатия фото: https://ru.wordpress.org/plugins/wp-smushit/
  • Broken Links плагин поиска битых ссылок: https://ru.wordpress.org/plugins/broken-link-checker/
  • Autoptimize плагин оптимизации: https://ru.wordpress.org/plugins/autoptimize/
  • Optimize Database after Deleting Revisions плагин оптимизации базы данных: https://ru.wordpress.org/plugins/rvg-optimize-database/
  • WP Fastest Cache плагин кэширования: https://ru.wordpress.org/plugins/wp-fastest-cache/

©www.wordpress-abc.ru

Статьи по теме

3 комментария для “Как я пытался сократить время открытия сайта: почему я отключил плагин Jetpack”

  1. Спасибо за комментарий. Упустил блокировку ресурса Webpagetest.com. Согласен, теперь правильный адрес Webpagetest.org. Весь функционал ресурса сохранён.

  2. Вот тоже бьюсь над ускорением ВП. Делал сайт на Elementor – тот еще тяжелый и переполненный код.
    У меня еще стоит подключка к CDN. В общем, результаты пока не особо радуют.
    В своем эксперименте ты не упомянул про хостинг – а это тоже определенный % скорости и он очень даже может влиять.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.