Скорость загрузки html wordpress

Ускорение загрузки сайта на WordPress

Сегодня я расскажу как правильно ускорить загрузку сайта на WordPress. Это статья отлично подойдет для новичков. Никаких специальных знаний не потребуется.

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

Я покажу два равнозначных варианта технической оптимизации сайта – бесплатный и платный. Расскажу про достоинства и недостатки каждого метода и помогу выбрать.

Ну а сейчас заваривай себе побольше чаю ☕, запасайся печеньками и усаживайся поудобнее. Мы начинаем…

Шаг #1. Оцениваем текущую скорость загрузки

Перед тем, как начинать нашу магию, нужно зафиксировать текущие показатели сайта. Для этого переходим в Google PageSpeed Insights, вставляем ссылку на любую страницу нашего сайта и нажимаем «Анализировать». Гугл загрузит нашу страницу, проанализирует и выдаст результат.

Вот так выглядит стандартный отчет Google PageSpeed:

Google отдельно оценивает загрузку страницы на мобильных устройствах (1) и компьютерах (2). Внизу – ключевые показатели (3) из которых складывается общая оценка (4).

Ключевые показатели по которым Google оценивает твой сайт называются Core Web Vitals. Подробнее про них ты сможешь прочитать в отдельной статье.

Если промотаешь отчет выше, ты можешь посмотреть средние показатели скорости загрузки страницы за последние 28 дней, которую Google собирает через браузеры своих пользователей.

В конце отчета ты можешь найти рекомендации по оптимизации, которые Google считает важными. На них пока не смотрим. К ним мы вернемся посже.

Скорость загрузки можно также проверить локально на своем компьютере с помощью инструмента litehouse, который встроен в Chrome.

Для этого нажимаем ctr+shift+I или Меню –> Дополнительные инструменты –> Инструменты разработчика. Внизу откроется панелька с инструментами разработчика.

Переходим на вкладку litehouse выбираем мобильную или десктопную версию, ставим галочку Perfomance и нажимаем Generate Report.

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

Теперь, когда мы зафиксировали текущие показатели сайта, можно переходить к оптимизации сайта.

Шаг #2. Чек-лист правильной оптимизации сайта

Вот мой стандартный чек-лист технической оптимизации сайта

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

Дальше будет немного теории, чтобы у тебя сложилось общее понимание чем мы будем заниматься. Но если ты хочешь поскорее перейти к практике, можешь перепрыгнуть этот раздел и сразу перейти к Шагу #3. Выбор кэширующего плагина.

Кэширование на сервере и в браузере

На какие метрики влияет: TTB (time to firs bite)

Кэширование – это один из самых эффективных способов оптимизировать скорость загрузки.

Упрощенная схема кэширования выглядит вот так:

Темно-синие стрелки – это стандартная схема работы сайта. Пользователь делает запрос на сервер. На сервере отрабатывает php-скрипт, который делает SQL-запрос к базе данных, в которой хранится текст страницы и вся сопутствующая информация. После того как сервер получает ответ от базы данных, он собирает html-страницу, которую отправляет пользователю.

Зеленые пунктирные стрелки – это работа кэширования. Предположим, мы подключили кэширующий плагин. Теперь, перед тем как отправить html-страницу пользователю, сервер дополнительно сохраняет ее в отдельное хранилище которое называется кэш. Если эту страницу запросят еще раз, сервер сначала проверит ее в кэше. Если страница в кэше есть, браузер просто отправит ее, вместо того, чтобы создавать страницу заново. Так работает серверное кэширование.

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

Конвертация картинок в webp

На какие метрики влияет: Speed Index

Теперь переходим к картинкам. Для примера возьмем среднестатистическую неоптимизированную страницу и проверим ее через https://gtmetrix.com/. В разделе Page Details мы можем посмотреть из чего она состоит.

Все картинки на странице весят больше мегабайта (!), что составляет 33.8% от общего размера страницы. Что с этим можно поделать? Первое и самое необходимое – пережать все картинки из jpg и png в современный формат webp.

Например, если конвертировать в webp все картинки из примера выше, то их суммарный вес будет всего 300 Кб вместо изначальных 1.15 МБ. Это всего лишь 25% от первоначального объема.

Ленивая загрузка картинок и айфреймов

На какие метрики влияет: Speed Index

Но это еще не все. Загрузка каждой картинки – это одно обращение к серверу. Если мы еще раз вернемся к примеру выше, мы увидим, что для загрузки всех картинок браузеру потребовалось сделать целых 89 обращений к серверу. В процентном соотношении это 34.4% процента от всех запросов, которые сделала страница. Каждый лишний запрос – это дополнительная потеря времени.

Как можно уменьшить количество запросов? Самое лучшее средство – ленивая загрузка (lazy loading). Это значит, что при загрузки страницы с сервера скачаються только картинки, которые находятся в первом экране. Остальные картинки будут загружаться по мере того, как пользователь скролит страницу вниз. Т.е. контент загружаеться только в том случае, если он действительно нужен пользователю в данный конкретный момент.

То же самое относиться к видео и другим интерактивным вставкам на странице.

Создание критических стилей для каждой страницы в отдельности

На какие метрики влияет: FCP (first contentfull paint), LCP (lagest contentfull paint)

Следующий шаг – оптимизация стилей. На нашей тестовой странице они занимают почетное 3-е место по весу (521 КБ или 14.8% от общего веса страницы). Казалось бы не так уж и много.

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

Лучше всего это видно в том же gtmetrix.com в разделе Speed Visualization.

Красная стрелочка – это как раз то самое время, которое уходит на загрузку стилей. И оно существенно удлиняет отрисовку контента, т.е. и портит нам метрики FCP и LCP, что сказывается на общей оценке загрузки сайта.

Как с этим бороться? Казалось бы, логично перенести все стили в самый низ страницы, чтобы они загружались в последнюю очередь. В этом случае мы получим, эффект «flash of unstyled content», т.е. когда пользователь сначала увидит просто текст страницы на белом фоне, и только через некоторое время, когда подгрузятся стили, текст будет стилизован.

Такой трюк действительно поможет нам подтянуть FCP, но при этом обрушит другую метрику – CLS (Cumulative Layout Shift), которая отражает общее смещение всех элементов страницы при загрузке.

Единственный выход из такого положения – разбить все стили на две части. Первая часть называется критические стили. Это оформление для верней части страницы, которая будет показана пользователю в первую очередь. Критические стили встраиваются непосредственно в html-код страницы.

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

Объединение минификация и асинхронная загрузка стилей

На какие метрики влияет: FCP (first contentfull paint), LCP (lagest contentfull paint)

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

Объединение минификация и асинхронная загрузка скриптов

На какие метрики влияет: FCP (first contentfull paint), LCP (lagest contentfull paint), TTI (Time to Interactive)

Со скриптами все еще сложнее.

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

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

Что нужно сделать? Для всех скриптов нужно прописать атрибут defer. В этом случае они будут загружаться в фоновом режиме и выполняться когда страница будет загружена и первый экран отрисован. Их также можно минифицировать и собрать в отдельный файл, чтобы сэкономить запросы к серверу.

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

Асинхронная загрузка шрифтов

На какие метрики влияет: FCP (first contentfull paint), LCP (lagest contentfull paint)

Шрифты это тоже довольно тяжелые файлы, которые нужно скачать с сервера Google Fonts. Это может привести к проблеме, которая называется мелькание невидимого текста (flash of invisible text или FOIT), когда документ уже отрендерился, а шрифты еще не подгрузились. Для того, чтобы это не происходило, нужно временно показывать один из системных шрифтов. Для этого нужно прописать свойство «font-display: swap» внутри правила @font-face.

Если ты загружаешь шрифты с CDN Google, то нужно добавить параметр &display=swap к ссылке на шрифт.

https://fonts.googleapis.com/css?family=Roboto:400&display=swap

Шаг #3. Выбираем кэширующий плагин

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

Я выбрал несколько самых популярных кэширующих плагинов и сравнил их характеристики.

Источник

Увеличение скорости загрузки сайта для CMS WordPress

Часто бывает, что купленная или полученная бесплатно готовая тема не набирает большой процент в проверке Google PageSpeed. В хроме встроен инструмент LightHouse для проверки сайта, который позволяет проверять не опубликованные сайты на домашнем сервере.

Основные ошибки, возникающие при проверке:

1. Eliminate render-blocking resources. Решением служит необходимость переноса css и js из секции head вниз секции body.

Это можно сделать при помощи платных или бесплатных плагинов, а также кодом:

function footer_enqueue_scripts() < remove_action('wp_head','wp_print_scripts'); remove_action('wp_head','wp_print_head_scripts',9); remove_action('wp_head','wp_enqueue_scripts',1); add_action('wp_footer','wp_print_scripts',5); add_action('wp_footer','wp_enqueue_scripts',5); add_action('wp_footer','wp_print_head_scripts',5); >add_action('after_setup_theme','footer_enqueue_scripts'); if ( !is_admin() )

Для удобства я создал отдельный файл wp-content/themes/storefront2/speed/functions.php

и разместил этот код в нем, а в wp-content/themes/storefront2/functions.php добавил его подключение:

include_once(get_parent_theme_file_path().'/speed/functions.php');

Перезапустив отчет заново, мы видим, как изменилось набранное число и убралась ошибка.

2. Preload key requests. В моем случае — это подключение шрифта. Решаю добавлением в head.php с атрибутом rel=»preload»

3. Добавление белого экрана и прелодера, пока не загрузились скрипты внизу страницы:

.preload-body < position: fixed; width: 100%; height: 100%; background-color: #fff; z-index: 9999; text-align: center; >.preload-body img

Также добавляю в footer.php выключение экрана прелодера

jQuery(document).ready(function() < jQuery('.preload-body').hide(); >); 

4. Remove unused CSS и Remove unused JavaScript. Для решения этой проблемы я порекомендую бесплатный плагин Autoptimize. С вот такими настройками.

В результате проблема может не уйти до конца, но позволит существенно ускорить отдачу сайта, с небольшими затратами.

Конечно хорошим решением было бы выкусить все css и js из плагинов и тем и упаковать при помощи gulp, но не всегда есть целесообразность применения данного решения.

Источник