Пришло время для актуализации информации и полного обновления статьи с учётом полученного опыта, потому, размещаю новую версию, актуальную для 2024 года. По крайней мере, приведённые здесь способы до сих пор работают. После выхода новых версий WordPress я проверяю все приведённые методы, и если потребуется, вношу изменения в данный мануал.
Ускорение сайта на WordPress — задача довольно сложная и нетривиальная, например, если требуются хорошие результаты для PageSpeed Insights. Причин для возникновения сложностей довольно много:
Еще куча всякой мелочёвки, которою рассмотрим в процессе. Итак, пора перейти к делу. В данной статье мы рассмотрим ускорение для ПК, а также оптимизацию WordPress для мобильной версии сайта. Кстати, рекомендую не концентрироваться только на PageSpeed Insights, лучше замерять с помощью GTmetrix или Pingdom Tools.
Начало ускорения
Оптимизация WordPress начинается с теста скорости. Тут все довольно просто, есть такие инструменты, как PageSpeed Insights от Google, также Pingdom Tools, GTmetrix. Рекомендую использовать все, они покажут, какие слабости есть у сайта. Но это только рекомендации, реальная скорость сайта рассчитывается иначе, например, в этой статье рассказываю об этом.
К сожалению, вы запросто можете оказаться в ситуации, что от вас требуют высоких результатов в данном тесте, не понимая даже, что он собой представляет. Конечно, можно улучшить сильнее, но тогда пострадает дизайн. В целом, в мобильной версии у меня от 60 до 64, в ПК от 87 до 93. Когда как. Но в основном проблема заключается в партнерках, рекламе, счетчиках и частично с файлами js и css. В общем, многое исправить будет нелегко, да и не нужно. А на некоторые вещи вроде рекламы вы повлиять вообще не сможете.
Неоднократно наблюдал, что «зеленые» сайты грузятся визуально долго, а «желтые» прогружаются заметно быстрее. Так что относитесь к результатам инструмента с некоторой долей скептицизма.
Могу с уверенностью сказать, что в мобильной версии высокие результаты часто идут во вред пользователям. Отложенная загрузка всего и вся и чуть ли не голая HTML-страница — единственный путь к заветной сотне. И да, разработчиками инструмента является не Google, а другая компания, так что не ждите от него идеальных результатов, он не замеряет скорость, а ищет потенциально-слабые места в сайте.
Итак, в первую очередь отключаем плагины кэширования. Они будут серьезно мешать в процессе работы. Сжатие тоже рекомендую отключить на уровне хостинга. Если в файле .htaccess прописаны методы cache и сжатия, комментируем их. Теперь поехали. Пришло время разобраться, как ускорить WordPress.
И небольшое предостережение. Не старайтесь добиться самых высоких результатов. Иногда полезнее пожертвовать производительностью, но сделать красивый сайт и дать пользователям необходимое, чем размещать голую страницу без красивых шрифтов и с минимумом изображений. Делайте все в меру, не гонитесь за цифрами.
Кстати, специально для тех, кто решит протестировать мой сайт, публикую результаты теста без использования рекламы от Яндекс.
А на скриншоте ниже наглядно демонстрирую, что реклама творит со скоростью сайта. К сожалению, это так. Кстати, Adsense меньше замедляет сайт, но, например, для российских и белорусских сайтов от этой платформы мало толку.
Так что, если у вас на сайте реклама, то скорость будет на порядок ниже. И ничего с этим поделать не сможете.
Ускорение WordPress без плагинов
В первую очередь стоит настроить все, что возможно, без плагинов, дальше все это придется дополнить кешированием и прочими веселыми элементами. Для начала определимся с выбором хостинга.
Хостинг
Раньше я держал сайт на Fozzy, но сейчас решил переехать на Beget, это самый шустрый хостинг из всех, что я пробовал. По крайней мере претензий к данному хостингу нет. Так что рекомендую.
Вот, например, сводная таблица тестирования разных хостингов:
Тест
| Хостинг | ||||
|---|---|---|---|---|---|
PS Insight Mobile | 28 | 26 | 26 | 21 | 29 |
PS Insight PC | 72 | 65 | 71 | 71 | 73 |
GTmetrix Perfomance | 62 | 61 | 65 | 60 | 66 |
P-Tools | 63 | 64 | 65 | 61 | 65 |
Скорость загрузки страниц | |||||
LCP | 2,6 сек. | 2,7 сек. | 2,5 сек. | 2,8 сек. | 2,5 сек. |
TBT | 2,01 сек. | 2,16 сек. | 1,97 сек. | 2,24 сек. | 1,92 сек. |
Стоимость за месяц | 329 р. | 5 $. | 279 р. | 279 р. | 320 р. |
К выбору хостинга стоит отнестись серьёзно. Простые сайты размещал на Reg.ru, вполне хватало. Конечно, ходят легенды о том, какой хостинг плохой. Но на деле он такой же как все. Но есть несколько но:
- Он довольно дорогой по меркам хостинг-провайдеров.
- Здесь выделяется не особо много CP. Хоть и не стоит хостинг выбирать по этому параметру, но в данном случае и по оборудованию они не превосходят аналоги.
В общем, вот пара скриншотов для сравнения.
Честно говоря не впечатляет. Одни и те же сайты у меня шустрее работают на Бегет.
Также было время, когда использовал Макхост, но оттуда тоже в итоге ушёл.
У Рег.ру: https://www.reg.ru/hosting/ я беру тариф Host-0, на сайты с большой посещаемостью тарифы повыше. На первое время «нуля» хватит. Ежемесячная оплата — 329 рублей. Стоит заметить, что многие хают хостинг от Рег, рассказывают про мифические проблемы, но у меня никаких проблем практически не возникало. А те, что были, быстро разрешались поддержкой. И да, здесь есть ISP Manager. Очень люблю данную панель управления. Веб-сервер используется Apache+Nginx, что дает неплохую скорость. Если решитесь брать, то держите промокод на скидку: 8404-F30B-D292-4306
Есть еще один интересный хостинг: https://fozzy.com/. Fozzy интересен тем, что использует веб-сервер LiteSpeed. Соответственно, это отличное кеширование, шустрое реагирование на запросы. Данный хостинг способен обеспечить максимальную производительность на ресурсах с большим количеством повторных посещений. В общем, если рассчитываете, что к вам будут возвращаться люди, то он быстрее любой другой связки. Но для новых посетителей Apache+Nginx будет пошустрее. Из панелей есть cPanel, ISP и DirectAdmin. Все вполне удобны. Цена за месяц на тариф «5 быстрых сайтов» — 5 долларов, короче, самый дешевый вариант. Если решите, что вам данный хостинг подходит больше, то вот промокод на скидку: 0f42e170-1599-4410-8934-83f003aa61df
Кстати, когда-то сидел на McHost, но в итоге я с Макхоста переехал на Fozzy. Производительность чуток получше оказалась, а цена на 50 рублей ниже. К тому же панель DirectAdmin мне больше нравится, чем самописная панель на Макхост. А с Макхоста переехал в итоге на Бегет, так на нём и остался.
У Макхост за 249 рублей я покупал тариф Мак-10. Это 12,5% мощности ядра (очень абстрактно, учитывая, что не указано, что у них за процессоры в оборудовании), 300 000 файлов. В целом, Макхост мне показался не идеальным, но интересным. Единственное, по чему скучаю, — ISP Manager, очень нравится данная панель, но здесь она платная — 290 рублей в месяц. Вроде недорого, но жаба душит. В общем, решил от данного хостинга отказаться.
Ладно, с хостингом определились, на самом деле выбирайте любой наиболее удобный, где есть поддержка последних версий PHP, Apache+Nginx в качестве веб-сервера или LSAPI. Не обязательно выбирать то, что предложил я. По крайней мере, наиболее шустрый вариант для первоначальной загрузки — Apache + Nginx. А вот если есть постоянные посетители (причем много), то эффективней окажется LSAPI, ибо он значительно ужимает байты при повторной загрузке и лучше подходит для формирования статического кеша. В любом случае, чистый Apache проигрывает обоим вариантам.
Настройка .htaccess
Сначала необходимо активировать сжатие. Это позволит сократить количество передаваемых данных. Причем многократно. Отвечает за это модуль Apache mod_deflate. В корне сайта должен располагаться файл .htaccess. В него и внесем изменения. Возьмите за правило: пользовательский код можно вносить только после # END WordPress, то, что находится в WP-блоке, CMS может затереть при обновлении.
Итак, добавляем следующее содержимое:
# сжатие text, html, javascript, css, xml:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css text/javascript text/xml text/plain image/x-icon image/svg+xml application/rss+xml application/javascript application/x-javascript application/xml application/xhtml+xml application/x-font application/x-font-truetype application/x-font-ttf application/x-font-otf application/x-font-opentype application/vnd.ms-fontobject font/ttf font/otf font/opentype
# Совместимость с устаревшими браузерами
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>Это директивы для активации gzip-сжатия при ответе сервера. Также есть директива DeflateCompressionLevel отвечает за степень компрессии по шкале от 1 до 9. Чем выше уровень, тем сильнее нагрузка на процессор как сервера, так и клиента. Но сейчас любой компьютер или смартфон, даже слабенький, справится с задачей, так что можно не переживать и ставить высокий уровень. В .htaccess нельзя данную переменную размещать. Только в конфигурации Apache. Так что уточняйте у хостера степень компрессии, если что, просите выставить уровень повыше.
Теперь необходимо включить кеширование на уровне браузера. Для примера выкладываю код с секундами, часами и даже месяцами, выбирайте удобную единицу измерения. Итак, будем редактировать модуль mod_expires.c, внося изменения в тот же файл .htaccess, добавляем эти строки после тех, что были выше.
# кеш браузера: разрешаем истечение срока
<ifModule mod_expires.c>
ExpiresActive On
#по умолчанию кеш в 5 секунд
ExpiresDefault "access plus 120 minutes"
# Включаем кэширование изображений и флэш на месяц
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType image/jpeg "access plus 4 weeks"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/gif "access plus 43829 minutes"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
# Включаем кэширование css, javascript и текстовых файлов на одиннадцать часов
ExpiresByType text/css "access plus 11 hours"
ExpiresByType text/javascript "access plus 11 hours"
ExpiresByType application/javascript "access plus 11 hours"
ExpiresByType application/x-javascript "access plus 11 hours"
# Включаем кэширование html и htm файлов на 2 часа
ExpiresByType text/html "access plus 120 minutes"
# Включаем кэширование xml файлов на десять минут
ExpiresByType application/xhtml+xml "access plus 600 seconds"
# Нестандартные шрифты сайта
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
</ifModule>Отлично, кеширование на уровне браузера задано. Учтите, если у вас нет форм обратной связи, то все значения, где у меня стоит по 11 часов, можете заменить на более продолжительный срок. Просто некоторые плагины могут негативно реагировать на длительное кеширование. Например, Caldera Forms, где токен рассчитан на 12 часов, соответственно, токен тоже кешируется и закешированная страница с формой обратной связи попросту не срабатывает спустя этот срок. У плагина Contact Form 7 такой проблемы нет.
Версия PHP и обновление WP
Хотя в требованиях версия указана не ниже 7.4, но лучше для WordPress использовать последнюю версию PHP. Если какие-то плагины не работают, например, давно не обновлялись, то лучше найти «свежие» аналоги. По сети гуляет множество тестов, которые наглядно демонстрируют, насколько выше производительность у последней версии. Между 7.4 и 8.1 разница будет 2-3% по PSI. Тоже неплохо. Мы сейчас бьёмся за каждый процентик. У меня есть обзор сравнения PHP 7.4 и 8.0 для WordPress.
Потому лучше обновить WP и плагины. Если есть серьезно устаревшие, которые давно не актуализировались, то заменить на другие. Но учтите, существуют плагины, которые не обновлялись по несколько лет, а с кодом у них все в порядке. Смотрите внимательнее. Кстати, актуальная версия WordPress работает стабильнее и шустрее, чем предыдущая ветка, потому рекомендую не откладывать переход. Если у вас версия 4 с копейками, то самое время задуматься о переходе на 5.9.x. Чем дольше ждете, тем сложнее будет обновиться. Особенно при выходе 6-ой версии, с четвёрки на неё будет трудно перейти.
Контент
Не все обращают внимание на данную сторону оптимизации, а она крайне важна. Контент имеет определенный вес. Изображения, разные файлы, видеозаписи, текст в конце концов. И если видео можно загрузить на Youtube и выдавать оттуда, а разные файлы не будут ничего весить до запроса пользователя к ним, то изображения вызывают большую проблему.
Сколько раз наблюдал несжатые картинки с весом более мегабайта. Когда таких накопится критическая масса, то страница может весить под 15 МБ. Итак, что рекомендуется делать:
- Заранее сжимать изображения.
- По возможности конвертировать их в WebP. Например, с помощью плагина WebP Express.
- Не использовать изображения с большим разрешением, если в этом нет необходимости.
- Не загружать на страницы видеоконтент. По крайней мере, нужно сделать так, чтобы загрузка видеоконтента начиналась только по запросу пользователя, а не вместе с загрузкой страницы.
- Сделать отложенную загрузку изображений.
Так что, позаботьтесь, чтобы на страницах не было ничего «тяжеловесного», особенно изображений. И дополнительно рекомендую воспользоваться функциями ленивой загрузки (Lazy Load), кликайте по ссылке, там все подробно описано.
CDN
Сеть доставки контента. Фактически, весь статический контент размещается на сторонних серверах, а посетителю выдается из наиболее близкой к нему точки. Можно отправлять посредством CDN:
- Статические файлы: HTML, JS, CSS.
- Изображения, видеоконтент.
- Разнообразные файлы, например, текстовые, PDF.
Система проста: ваш контент дублируется на множество разных серверов и при запросе к сайту, все ресурсы выдаются пользователю с наиболее близкого по местонахождению. Значительно сокращает пинг, но удовольствие недешевое. Подойдет только крупным площадкам, способным окупать такие затраты (если в CDN вообще будет смысл), а также организациям, желающим плотно застолбить регионы. Если желает двигаться по Европе и США, то вам подойдёт бесплатный CDN от Fozzy или Cloudflare.
Ускорение сайта WordPress на уровне Back-end
Теперь пришло время улучшить работу WP, для этого понадобятся минимальные знания, ибо я предоставлю готовые решения, способные значительно упростить жизнь. Начнем, конечно же, не с самого простого.
Выбор темы
Это ключевой момент. На самом деле движок WordPress довольно-таки шустрый. Его ругают за то, что из «коробки» ничего нет, но я считаю это правильным. Такой подход дает большую вариативность последующей кастомизации. Поставил плагин для SEO какой нужно, добавил функционал, который необходим именно для целевого проекта.
Но не только плагины грузят сайт. Частенько, основным фактором нагрузки становится тема. Стандартные темы WP практически не содержат в себе ничего лишнего, соответственно, не требуют колоссальных ресурсов для генерации страниц. Но ведь функционал данных тем может показаться недостаточным?
И тогда начинается поиск. Рекомендую следующее. По возможности не брать темы с большим количеством скриптов, где все элементы построены на AJAX. Да, они выглядят красиво, но чтобы обеспечить широкий функционал, могут быть подключены сотни разнообразных скриптов, которые будут с трудом грузиться. Да и подход к SEO при использовании AJAX несколько сложнее.
Чем чище тема, тем лучше. Обращайте внимание при выборе платных премиальных тем. Часто разработчики стараются удовлетворить максимально широкие потребности конечного потребителя, так что в них будет понапихано всего и побольше. Например, Avada, JupiterX. Там будут конструкторы тем, разнообразные функции для поддержки встроенных слайдеров, некоторые вообще не будут работать без тяжеловесных плагинов.
Лично предпочитаю брать темы из официального репозитория. Простые, без излишеств и слишком широкого функционала. Все, что нужно будет добавить, решу с помощью плагинов или собственного кода. Конечно, для данного блога взял тему Breek с ThemeForest, если интересно, то на сайте есть обзор данной темы, но она оказалась легковесной и с хорошей документацией. Так что можно искать и платные.
Плагины
Существует распространенная болезнь среди новичков в WP – плагинобоязнь. Все стараются накодить самостоятельно. Даже когда в этом нет необходимости. С одной стороны правильно, лишних инструментов стоит избегать. Многие популярные плагины включают в себя множество излишеств, становятся очень тяжелыми.
Если нужна только одна функция и плагина под нее нет, то тогда есть смысл создать нужный код самому. На самом деле, не важно, куда внесете код. В виде плагина или в functions.php он будет требовать одинаковое количество ресурсов. Перебарщивать с плагинами тоже не стоит. Чем их больше, тем больше ресурсов потребуется на работу, что может заметно замедлить сайт.
Но возьмите за правило:
- Тот код, что влияет на тему, например, дизайн, стили, файлы темы, вносите в файлы дочереней темы. Предварительно дочернюю тему создайте.
- То, что не относится к функционалу темы, лучше вносите в кастомный плагин. Например, счётчики, функционал для асинхронной и отложенной загрузки, всякие SEO-фишки или API. Можете почитать о том, как создать собственный плагин.
Но использовать можно, если они закрывают ваши потребности. Не бойтесь плагинов, но по возможности урезайте их количество. Чтобы ускорить сайт, уберите лишние. Ищите замены, в которых функционал консолидирован. Тестируйте, пробуйте альтернативы.
Оптимизация JS и CSS
Скрипты, порой, основная часть нагрузки на сайт. Каждый скрипт генерирует запросы, имеет определенный вес, соответственно, притормаживает сайт. Многие рекомендуют объединить скрипты в один файл и построить зависимости для него. Это очень сложный метод, способный впоследствии принести массу проблем.
В отдельно файле придется самостоятельно обновлять код, а после обновлений плагинов и темы все зависимости будут слетать и их придется строить заново. В общем, муторный метод. Поговорим лучше о тех, что более просты в реализации и не требуют огромных затрат времени на поддержку.
Отложенная и асинхронная загрузка JS
Самый простой вариант ускорить сайт WordPress — сделать загрузку скриптов более динамичной. Для этого отличным решением станет отложенная и асинхронная загрузка. Если раньше я обходился простым универсальным кодом, то со временем задача усложнилась и пришлось принять волевое решение и распределить скрипты ручками.
Как правильно все это настроить я рассказал в отдельной статье. Рекомендую ознакомиться, ведь там размести наиболее правильные с точки зрения WordPress методы оптимизации. Кликайте по заголовку.
Оптимизация CSS
В данном случае все несколько сложнее, чем с JS, для данной задачи лучше использовать плагины, о которых рассказал по ссылке. Но тут все сводится к объединению и минификации файлов стилей. Есть, конечно, и кастомные решения, но в отличии от скриптов, решение с помощью плагина получается гораздо более эффективным.
Оптимизация HTML
Все тоже сводится к минификации и удалению некоторых тегов и атрибутов. Задачу также целесообразнее доверить специальным плагинам, ведь прописать все необходимые алгоритмы довольно трудоемко. По ссылке в заголовке о CSS есть информация об этом.
Перенос скриптов в подвал
Да, убрать скрипты из head и перенести в подвал тоже можно. Достаточно добавить в файл functions.php или кастомный плагин такой код:
if(!is_admin()){
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);
}Фактически все скрипты, расположенные в разделе head будут отключены и подключатся заново в разделе footer. Ничего сложного. Но не всегда это хорошо влияет на сайт. Используйте с осторожностью.
Плагины для ускорения WordPress
Этим «исчадиям ада» решил посвятить отдельную статью. Там много сложных настроек, к которым стоит ответственно относиться, потому, переходите по ссылке в заголовке и вникайте. Функционал попросту огромен, лично я использовал PageSpeed Ninja, но он плохо работал с PHP 7.4, а с 8.0 вообще не работал, так что поставил вместо него Autoptimize. Он оказался стабильнее, а также сейчас показывает результаты даже получше.
Полетели!
Как видите, методы для ускорения сайта на WordPress есть, главное, грамотно их использовать и не перебарщивать. Будем надеяться, что зайдя к вам на сайт, я моментально получу страницу, а не буду ожидать пол часа, пока подгрузится все.
Спасибо, варианты многие уже видел, но главное работает.
Спасибо за ответ, постараюсь в ближайшее время актуализировать информацию.
>Спасибо за ответ, постараюсь в ближайшее время актуализировать информацию
Жду с нетерпением!
Советую w.tools как дополнение к хостингу. Свой CDN, кешируют как статику так и динамику, полный охват РФ\СНГ, сервера в 31 стране. Сайт реально ускорился.
Не знаю насчет w.tools, может реально хорош, но если сайт коммерческий, то в CDN реально есть смысл, помогает быстрее отображать сайт и снизить количество запросов к основному хостингу.
Здравствуйте! Спасибо за подробную информацию! У меня вопрос: код для файла .htaccess нужно использовать отдельно или можно в сочетании с плагином кэширования?
Здравствуйте, обычно плагины кеширования создают отдельный .htaccess в папке wp-content, свои директивы лучше вносить в тот файл, что находится в корне сайта. В принципе, все то, что не реализуется посредством плагина кеширования (например, если нет сжатия), можно без проблем вносить в .htaccess.
Что-то ваш сайт имеет слабые покзатели в том же gtmetrix. Как-то слабенько вы оптимизировали свой сайт
Реклама, вся проблема в ней. Кстати, вот скриншот с отключенными рекламаными вставками:
Он способен наглядно продемонстрировать, что реклама от Яндекс творит с сайтом. Кто хочет сравнения, посмотрите на скриншот, а потом делайте тест этого сайта. Adsence замедляет на порядок меньше.
Спасибо за ответ! А что думаете насчет сайта https://ktonanovenkogo.ru/?
У них правда нет рекламы от Яндекса, но меня интересует другое — как они смогли спрятать счетчики? В коде их нет, но я уверен, что они там есть, как-то выводят они их нестандартно. Но в коде скрипта нет и поэтому в метриках результаты очень красивые. Как это можно реализовать?
Да, под PageSpeed его заточили хорошо. Скорее всего используют отсроченную загрузку счётчиков. В коде они точно есть. С рекламой от AdSense (которую использует владелец Ktonanovenkogo у меня примерно такие же результаты по PageSpeed. С рекламой от Яндекс скачет. То «красно-жёлтая» зона, то «желто-зелёная». Сейчас замерил: 53 и 97. В общем, если желаете на сайт рекламу, по возможности лучше использовать AdSense. Но я использую рекламу от поисковой системы, которая приносит больше трафика, так эффективнее.
Вот, собственно, счётчики в коде. Всё есть.
Вот результаты по GTmetrix выглядят не так интересно.
В целом, нормальные результаты для крупной площадки. То, что результаты по GTmetrix и для мобильной версии сайта не идеальные, не мешает ему сидеть в топах по многим запросам. Моему блогу до уровня этой площадки очень и очень далеко.
Самое рабочее на мой взгляд это оптимизация HTML, CSS, перенос скриптов в подвал ну и отключение ненужных плагинов, остальное не значительно на скорость влияет. На днях просто на время отключил рекламу на сайте (скорость для мобильных аж в 2 раза улучшилась), поэкспериментировать повысятся ли позиции статей в поисковиках или нет, если кто проводил такой эксперимент, напишите! Ну и сайт приложу, оцените, кто что думает, может рекомендации дадите effect-dieta.ru
Здравствуйте, тут, в принципе, нет чего-то более или менее важного. Результат получается только от комплекса мер. И если есть техническая возможность использовать что-либо, то лучше это сделать.
В плане скорости с вашим сайтом всё отлично, по крайней мере, даже при имитации слабенького процессора с медленным интернетом, страницы отрисовывает быстро. И добавлю, «скорость» по PageSpeed Insight не учитывается при расчёте позиций. Показатели скорости основываются на данных реальных посетителей. Рассказывал об этом в данной статье: https://workinnet.ru/page-speed-and-seo/. И это заявления представителей Google, ссылку на оригинал в той статье тоже оставил.
Спасибо, просто анализируя сайты-конкуренты, с примерно таким же количеством статей и т.д., то посещаемость у моего крайне низкая, почти все там наладил, видимо надо над улучшением контента работать(
Вам следует поработать над SEO, пересобрать семантическое ядро, использовать его в статьях. К тому же по вашим запросам сидят серьёзные конкуренты. Обратите внимание, что некоторые конкуренты, которые находятся выше вас, используют видеовставки примеров упражнений, вам тоже стоит взять такой метод на заметку, он будет уместно смотреться на вашем сайте, да и канал на YouTube — неплохой источник монетизации по вашей тематике. Банально, взять запрос «тренировка спины», под который ориентирована первая запись вашего блога, вы увидите пару видео с Youtube, а также на первом месте Lifehakers, который выигрывает не только за счёт качества контента.
В таком случае вам стоит расширить контент, а также выкладывать видеопримеры выполнения упражнений. В таком случае сможете использовать сильные стороны обоих каналов привлечения трафика.
Также попробуйте готовить контент под низкочастотные запросы. Например, «тренировка спины в домашних условиях с помощью резинок». Может показаться, что это неэффективны источник трафика, но даже когда работал с сайтами, у которых было по 2 десятка тысяч посетителей в сутки, то 80% запросов посетителей — низкочастотные. Да, контента понадобится много, но эффективность такого контента, а также вовлечение аудитории, будут гораздо выше, чем при работе под высоко и среднечастотные запросы.
Конечно, полноценный аудит вашего сайта не проводил, но так, дал навскидку парочку полезных советов. Даже высокое качество контента не гарантирует попадание в топ, там слишком много факторов, которые учитываются ПС. Попробуйте поработать на низкочастотники, это реально эффективней. Конечно, это не значит, что под каждое упражнение нужна отдельная статья, но свой подзаголовок пригодится. Например, h3: тренировка широчайших мышц спины, h4: «название упражнений». А ориентироваться посетитель сможет из оглавления. Это расширит семантическое ядро, а также позволит крупной статье ранжироваться не только по среднечастотным, но и низкочастотным запросам. Конечно, подробное объяснение всех факторов, которые нужны для подготовки качественного контента, в пределах комментария не привести.
Спасибо большое, взял на заметку, в некоторых статьях есть и фотографии и видео с моего Youtube канала, в целом неплохо отклик этих статей в поисковиках, буду дорабатывать!;-)
Не за что, успехов вам в этом нелёгком деле)
Добрый день
Можно ли править .htaccess через дочернюю тему? Не айс, если каждый раз при обновлении его переписывать, верно?
Здравствуйте, .htaccess к дочерней теме никакого отношения не имеет, он должен лежать в корневой папке сайта, так как по сути он является «инструкцией» для веб-сервера Apache, так что у вас должен лежать файл в корне сайта, главное, между #Begin WordPress и #End WordPress ничего не добавляйте. Либо перед этими надписями, либо после.
Ага! Спасибо за подробный и оперативный ответ )
#DeflateCompressionLevel 8 //не указывать, спросите степень у хостера
«В .htaccess нельзя данную переменную размещать. Только в конфигурации Apache» — так эта строка вообще нужна или нет? Спросить и записать в комментарий для памяти?
Подскажите пож этот момент подробнее, остальное у вас предельно чётко вроде )
Здравствуйте, лучше, наверное, этот момент вообще удалить, просто степень компрессии определяет конфигурация Apache, потому следует уточнять у хостера, какую они указали, чем выше, тем больше нагрузка на ПК посетителя и сервер, но современные мощности позволяют это даже не заметить, ощутимые проблемы со сжатием могут возникнуть на каком-нибудь пеньке 2000-го года. На современных ПК и ноутах — нет, даже у смартфонов проблем не будет.
Но не переживайте, можете вставлять код как есть.
# — это обозначение комментария в .htaccess, так что данный код ни на что не повлияет, работать попросту не будет.
P. S. Если использовали предложенные методы для асинхронной или отложенной загрузки, то статью немного обновил, добавил туда менее «костыльный» метод для смены тега скриптов, работает лучше и стабильнее. Рекомендую использовать именно метод для асинхронной загрузки, так как он не блокирует работу потока. Расположил в самом начале статьи.
Спасибо. Для совсем начинающего этот момент был непонятен.
Просто наполнил сайт, теперь занялся скоростью — там совсем плохо: 5-7 по PageSpeed и это без рекламы, только с метриками. Поэтому сейчас повыкидываю все лишние комментарии и пустые строки из css, а заодно и в .htaccess и тп
У вас удобная свежая пошаговая статья. Решил начать по ней. Потом вероятно откажусь от каруселей картинок и прожму их плагином.
По поводу конструкторов мнения разные, кто-то уверяет, что Гутенберг единственное решение, кто-то, что Elementor не хуже. Вручную пока нереально. Оставлю Элементор. Еще рекомендуют удалять старые версии постов.
Если не поможет кардинально, придётся заменить тему Сидней наверное на Астру и переделать весь сайт. Благо всего 50 страниц пока.
Поддерживайте пож статью актуальной — очень удобная и надеюсь полезная )
Elementor сильно жрёт скорость, минимум пунктов 10 от PSI и пунктов 5 на GTmetrix отъедает, но обычно даже больше. И это наблюдал на огромном количестве сайтов. Лучше от него отказаться. Замена темы, если не используете Elementor, — дело пары кликов, конечно, иногда приходится вручную подправить стили, но это уже дело второе.
А вы бы какую связку Тема+Конструктор для начинающего посоветовали? Сайт коммерческий, продажа доступа к онлайн-курсам в записи, пользователь начинающий. Нужен симпатичный сайт без изысков.
Зависит от того, используете WooCommerce (или другой плагин для электронной коммерции) или нет. В целом, на Gutenberg можно строить страницы не хуже, чем на Elementor и WPBackery. Есть ещё и классический редактор, который был до 5-ой версии WP, но там немного сложнее, ибо внешний вид блоков придётся сначала самостоятельно прописывать в CSS, учитывая медиазапросы, а это муторно бывает.
Да, использую Woo в связке с Memberlux.
Похоже придётся пересаживаться на другую тему всё-таки. К сожалению в сети среди рекламы не найти реальную информацию по скорости тем и конструкторов. Например в частности встречается утверждение, что Гутенберг оказывается медленнее Элементора. Из скоростных часто называют Beaver Builder и Page Builder by SiteOrigin.
А по темам из самых быстрых — ту же Астру постоянно.
Вот и вопрос, то ли не менять ничего и потом уже отдать в полную переделку на своем коде. Толи переделать, пока не сильно запущено на быструю тему с быстрым конструктором.
Лучше переделать сразу, несмотря на все заявления об обратной совместимости того же Elementor c Гутенбергом, когда отключаешь конструктор, на страницах получается полнейшая дичь. Проверял на собственном опыте, причём сравнительно недавно. Астра — медленная тема. Для Woo лучше бы взял: Easy Storefront, Storefront, Esfahan (использовать без Elementor), Short, а также, если желаете сделать красивую посадочную страницу, можете попробовать тему Mesmerize. В целом, даже Asta без Elementor, будет ничем не хуже, чем предложенные варианты.
Отписываюсь по шагам вашей инструкции ) Тесты 1. GT 2. G 3. Pingdom 4. WebPageTest.
Плагины ускорения отключены. Работает Cloudflare, на нем включено сжатие и Rocket Loader
1. Изменение в .htaccess — изменение по тестам — 0, 0, 0 , 0 все примерно ноль, где-то даже хуже. В пределах погрешностей
2. php и плагины уже на пределе актуальности и были
3. Картинки уже вполне оптимально подготовлены. Потом попробую ещё ужать до минимума
Дальше пока рано. Сначала сделаю Gzip-сжатие, которое рекомендуют везде, но не у вас на почему-то. Потом Lazy load и асинхронную загрузку и перенесу скрипты в подвал. И в конце PageSpeed Ninja по вашей рекомендации попробую, может ещё какие-то плагины
извините про Gzip-сжатие — затупил )
Ничего страшного, это, скорее, моя оплошность, я там чёрным по белому не указал, что это директивы для gzip, исправлюсь)
Директивы в начале статьи рекомендовал, просто не указал, что это именно gzip. Проблема может быть в том, что на некоторых админ-панелях, например, ISPmanager, нужно включать сжатие средствами самой панели (на cPanel, вроде бы, тоже, не помню уже). Так же эти директивы могут не сработать, если ваш веб-сервер, к примеру, php-fpm. Но для Apache точно сработает.
Из плагинов ускорения рекомендую PageSpeed Ninja, сейчас его обновили, работает отлично, не крашит сайт, как Autoptimize, по настройкам плагина на сайте тоже есть статья. Даёт хорошую прибавку к скорости. И ещё по поводу тем, что Astra, что Sydney — очень тормознутые темы, лучше поискать другие.
Отписываюсь по результатам:
1. Gzip через .htaccess — результат +0
2. Сжатие на сервере через ISPmanager -8 – hрезультат 0 (CentOS6 веб-сервер: Nginx и Apache HTTP Server Version 2.2)
3. Нашёл большие картинки в png, ужатие дало +1 пункт (png нужно из-за возможности прозрачности. Пока не нашёл как её обеспечить в .Webp)
4. Убрал лишние комментарии и пустые строки из functions.php дочерней темы +0
5. Отложенная и асинхронная загрузка JS +2 пункта
6. Перенос скриптов в подвал +9 = 17
7. Замена всех картинок на webp с помощью Webp express +3=20 (непонятно как будет с бесплатным CDN от Cloudflare)
8. PageSpeed Ninja +10 = 27 — по мобильным
9. Включаю обратно плагины Jetpack – 0. Autooptimaze – удален, WP-Optimize – с отключенными оптимизаторами уронил на 3 пункта, удалён.
10. Минут через 30 после PageSpeed Ninja -> отключение AMP for WP дало ошибку в тестерах — The page returned an error: 500 Internal Server Error. Повторное включение ничего не изменило. Но страницы открываются и шустро.
11. Отключение PageSpeed Ninja — тесты пошли, скорость упала. Возвращаю PageSpeed Ninja постепенно подключая функции. Gzip – даёт ощутимый прирост скорости. Вопрос по пп. 1 и 2 – а надо ли было тогда Gzip через .htaccess и через сервер?
12. В раздел Решение проблем-Manage Javascript URLs – заблокировал скрипты на которые грешил Google тест – скорости не добавило
13. Слетели некоторые фоновые изображения в Хроме только – надо копаться
Итого поднято с 5 до 27 для мобильных и до 54 на компах
1, 2 и 11. Через PageSpeed Ninja Gzip-компрессия включается не только через .htaccess. К тому же она может не сильно влиять на конечный результат. Если у вас ISP, то сжатие через .htaccess не особо нужно.
3. Webp поддерживает прозрачность, но со старыми версиями Photoshop не работает, а также поддерживается ещё не всеми браузерами.
4. Комментарии — доли секунды, особо не решает.
5. Какой вариант для асинхронной или отложенной загрузки выбрали?
6. Перенос скриптов в подвал — вещь опасная, посмотрите на разных браузерах, как сайт работает.
7. Ничего сказать не могу, не пробовал это.
8. Конфиг с безопасными настройками сброшу.
9. Жутьпак, несмотря на свои обещания об ускорении, убивает скорость сайта.
10. У меня с AMP PSN работает нормально.
13. Скорее всего из-за PSN, может слишком жёсткий конфиг сделали.
Вот адекватный конфиг для PSN: https://workinnet.ru/pagespeed-ninja/#Moj_konfig_dla_PageSpeed_Ninja
И если несложно, скиньте ссылку на сайт, посмотрю, в чём может быть проблема, может ещё что подскажу.
И ещё: Метрика может отжирать скорость очень сильно, попробуйте её отключить и проверить скорость.
Отключение метрики дало: с ней 26/59 моб/ПК, без нее 25/54 — ничего в общем
Странно конечно. Метрика на самом деле сильно нагружает сайт. Но тут скорость очень низкая. Знаю, конечно, что Woo сильно нагружает сайт, да и Elementor тоже, но тут просадка по скорости очень сильная. Какой у вас хостинг, если не секрет?
у reg ru хостинг.
Woo задействуется во внутренней части сайта в момент продажи. То, что важно, что тестирую — это по сути набор лендингов на одном сайте, там Woo не задействован.
Для эксперимента деактивировал Элементор — изменения по PageSpeed Insights не было заметно! На удивление. Замена темы на Астру домашнюю страницу ускорила чуть ли не вдвое, остальные — затормозила. Ох….
Woo действует на весь сайт, он увеличивает количество записей в БД, а также количество запросов к серверу, причём независимо от того, страница товаров это или нет.
Но у вас реально что-то странное происходит, но не глядя причину сказать не могу. Reg.ru, конечно, не идеальный хостинг, но работает нормально, так что на него грешить не буду.
Тогда получается так:
— выкину из .htaccess все ускорение gzip, и оставлю в Ninja и ISP
— Webp прозрачность научился добывать, но осталась проблема загрузки на WP, который категорически не позволяет, поэтому приходится использовать костыль WebP Express — который в общем неплох, снимает необходимость готовить картинки — жмёт на лету и ещё вроде раздаёт под разные браузеры картинки, которые те поддерживают
— асинхронную использовал
— скрипты в подвале дали хороший прирост. Из заметного — на долю секунду в шапке появляется текст, меню вроде, исчезает, потом появляется через секунду уже оформлено стилями
— вроде все восстановилось, когда кэш браузера почистил, наверное зря на Ниндзю грешил, прошёлся по всем настройкам аккуратно — работает норм, но надо понаблюдать
В открытый эфир сайт не хочу светить, можно в где-то ещё. Кстати в поле при комментарии могу — не засветится? )
Если вам интересно, то можно придумать такой проект: я под вашим руководством переделываю сайт, а вы публикуете результаты.
Для таких же новичков, как и я, думаю, будет очень интересно и полезно.
Ну, в WP так и задумано, что не предложено изначально, делается плагином, так что для WebP — разумный вариант. И сайт проверьте GTmetrix, он более информативен, в отличие от PSI.
Если асинхронная загрузка не даёт прироста, то, возможно, что-то блокирует отрисовку некоторых скриптов. Нужно будет смотреть. Можете вот с этой статьёй ознакомиться, там рассказываю о способах проверить реальную скорость сайта: https://workinnet.ru/page-speed-and-seo/
А ссылку на ваш сайт могу просто вручную удалить, но посмотреть и потестить всё-таки нужно.
О вашей идее стоит подумать, но тогда придётся все шаги протоколировать, а это точно засветит ваш проект на публику.
Асинхронная загрузка как раз дала прирост. 2 пункта по PageSpeed Insights. Для меня тогда — уже радость ))
*********
Думаю всё-таки сменить тему — посоветуете быструю и адаптивную из бесплатных?
И может тогда остаться на Элементоре… Они обещали прирост скорости в последних версиях — и эксперимент с отключением показал, что замедление 1-7 пунктов по моб, и 0-15 пунктов на ПК (по разным страницам). Будет ли Гутендерг лучше?
Cloudflare бесплатной версии у вас?
Рекомендую отключить Cloudflare, заодно Rocket Loader, потом протестировать сайт повторно. Бесплатная версия данного сервиса мало того, что не подходит для продвижения по России, так ещё и замедляет сайт. После этих манипуляций вычистите кэш в PageSpeed Ninja (в разделе «решение проблем»). Проверьте сайт снова. Там 15 странных ошибок на сайте, и, как мне кажется, связаны они с CDN.
Ещё отключите предзагрузку. У вас гифка от прелодера грузится последней, соответственно, блокирует время до первого взаимодействия.
На Gutenberg можно сделать неплохой сайт, форматирование блоками, колонки и прочие фишки, свойственные Elementor, там тоже доступны. У вас проблема явно не в конструкторе, попробуйте сделать то, что посоветовал выше. Если не прокатит, то придётся смотреть, откуда повылезали ошибки и править это дело.
Cloudflare бесплатный, подключил под планируемый будущий большой поток обращения за видео-контентом ) Потестить. У них вроде сервера в Москве и Киеве.
2. Отключение Rocket и сжатия Auto Minify ничего не дало. Пауза CF (в настройках Пауза на странице Overview, на страничке DNS не показывает отключение, но наверное так и должно быть) — не дало изменений
3. С прелоадером – умаялся. Был уверен, что он где-то настраивался. Дежа вю. Он встроен в тему. Убрал добавлением CSS.
4. Пока экспериментировал слетели меню и полезли непрошеные сайдбары, слетели меню. Надо восстанавливать. Но сделал как вы рекомендовали. Результаты: было 24/55, стало 22/52. Погрешности в общем
Надо все-таки тему менять.
1. Насколько помню, у бесплатной версии не все серваки доступны и серьёзные ограничения по пропускной способности. Лучше попробовать обрубить. С видео лучшая тактика — загрузка на YouTube и добавление на сайт в виде вставки.
2. Auto Minify от Cloudflare используете?
3. Скрывать CSS бесполезно, но всё равно будет подгружаться, что на графике загрузки видно до сих пор. Всё так же блокирует отрисовку.
Ошибки никуда не пропали, вы их можете увидеть в режиме разработчика браузера (нажмите F12).
1. Я отключил Cloudflare вчера, когда написал. Пока и стоит отключен. Должны направлять напрямую на сайт.
2. Ютуб не подходит, т.к. платный контент. Нужна максимальная защита в т.ч. от скачивания
3. Auto Minify также отключил вчера. И РокетЛоадер. Их отдельно и сам Cloudflare на паузу
4. Угу (( Нашёл как убрать с CSS вроде через дочерний functions
Сделано. Cloudflare и прелоадер полностью отключены
1. Отдаёт до сих пор с c0.wp.com. DNS обновили у регистратора?
2. Понял, но для таких вещей подойдут только платные тарифы, на первых порах лучше раздавать с вашего сервера, у Reg.ru вроде ограничений на это нет.
4. Нет, через CSS не годится, всё равно будет грузиться, только не отображаться. CSS не может заблокировать чего-либо, видимо, придётся менять тему либо копаться у неё во «внутренностях».
1. Да нет, DNS не менял, включил только «Pause Cloudflare on site» по идее это только должно использовать их DNS, ничего более. Но если надо, то перепишу
2. Да, так и решил
3. Техподдержка темы уверила,. что add_action(‘init’, ‘sydney_remove_preloader’); function sydney_remove_preloader() {remove_action(‘sydney_before_site’, ‘sydney_preloader’); } Именно удалит прелоадер. Но попробую покопаться в коде…. готово, закомментил функцию прелоадера в материнской теме.
Вот.
Переписать DNS обратно на reg.ru-шные ? Cloudflare говорит, что у них всё на паузе стоит.
Возможно, но DNS там от Cloudflare стоит и раздаётся с c0.wp.com, а не непосредственно с адреса самого сайта. Ошибки также никуда не делись, и проблемы в работе могут заключаться в них. Посмотрите сами в режиме разработчика, именно файлы ядра сбоят.
К сожалению не смогу ничего понять в ошибках. Не разбираюсь.
DNS поменяю, посмотрим как скажется на скорости.
Возможно проблемы в настройках Ninja. Попробую поставить ваши безопасные.
Потом буду тогда менять тему.
Отлично, действуйте, если что, отпишитесь.
Сделал. DNS уже переписали. PageSpeed_Ninja в безопасных настройках. Прелоадер удалён из темы.
Скорость осталась та же. 24/50 по PSI.
Пока из всех экспериментов прирост дали замена темы (45/87) и немного отключение Элементора (30/55). Редактор всё-таки нужен, может и его стоит оставить, не факт, что Гутенберг, меньше сбудет тормозить. Верно?
Кстати, вполне возможно, что c0.wp.com — последствия JetPack. Скорее всего так и есть. Нужно посмотреть, что ЖутьПак творит, а пока что тоже отключите плагин, ибо ошибки никуда не делись. В идеале, вам сейчас нужно посмотреть все плагины и что с ними происходит. Может отправлю вам на почту свои контакты? Комменты — не самое удобное место для переписки. Нужно найти причины ошибок, а тут уже, скорее всего, проще будет самому покопаться.
c0.wp.com было до переписи DNS-ов, должно уже полностью исчезнуть. DNS уже обновлены везде вроде. Больше пол суток прошло.
Джетпак сейчас отключен.
Контакты — конечно.
Спасибо!
До связи )
Всё, контакты отправил на эту почту. Тогда до связи)
PageSpeed Ninja включала, не заметила сильного прироста. Вернулась к WP-Optimize
Да, результаты от сайта к сайту будут разниться, нет универсального плагина, каждому своя «сборка».
Здравствуйте! Скажите, пожалуйста как ускорить именно мобильную загрузку сайта? Изображения сжала, плагин кэширования настроила, лишних плагинов нет. Есть Elementor, да. После проведенных работ показатели GTMetrix улучшились с 24до 60%, скорость загрузки уменьшилась с 6.4 до 2.2сек. Но при проверке через Page Speed для мобильной версии по-прежнему выдает 22-24, т.е. улучшений нет. Я понимаю что Page Speed не лучший сервис, но клиент ориентируется именно на него.
Здравствуйте, было бы, конечно, удобнее, если бы вы указали конкретный сайт, сомневаюсь, что вы разрабатываете для клиента сайт агентства. Но даже на вашем сайте отрисовку мобильной версии очень сильно тормозят API VK и Facebook, а так нужно внимательно смотреть. Навскидку могу сказать много причин. Попробуйте плагин PageSpeed Ninja поставить, может с него чуть-чуть выиграете. Также держите инструкцию по настройке плагина.
Здравствуйте.
Скажите, если поставить плагин PageSpeed Ninja то в ручную можно это ничего не вносить, это как замена плагину? Я смотрю там вроде одно и тоже
Кстати, если заменить метрику яндекса на liveinternet то 10-15 баллов прибавляется сразу. Смотрю многие из старых сайтов на liveinternet остаются, видимо что-то знают
Здравствуйте!
Pagespeed ninja имеет ограниченные директивы для htaccess, так что лучше продублировать в корневом каталоге, хуже не будет. Метрика нужна для продвижения в Яндекс, Analytics для продвижения в Google, сайты без данных счётчиков продвигаются немного хуже, так как поисковые системы не могут учитывать поведенческие факторы, так что лучше их ставить.
Ninja уже год не обновлялся, аминь!
Я сервер сменил на более мощный теперь всё летает без всяких плагинов. Про хостинги вообще можно забыть, там никакие танцы с бубном не помогут
То, что не обновлялся, не значит, что не работает. Плагин до сих пор работает, в том числе и с последними версиями WP. Разве что с PHP 8 не тестировал, нужно будет посмотреть как-нибудь. Одним сервером не обойтись, такие вещи, как кеширование, минификация и сжатие, на базовом уровне в WP не реализованы, а без них сайт будет работать медленно, так что лучше это сделать.