Google ru pagespeed: обзор PageSpeed Insights от Google

Содержание

Как Pagespeed Insights от Google помогает улучшить скорость загрузки сайта

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

Вы вложились в SEO но до сих пор Google ранжирует ваш сайт в выдаче ниже, чем предполагалось. Что делать?

Google PageSpeed Insights может помочь вам. Как? Читайте в этой статье. 

Предположим у вас есть хорошо настроенный сервер, но производительность вашего сайта оставляет желать лучшего. Задержка ответа сайта занимает секунды и сервер не может обработать более 100 одновременных пользователей. Вы вложились в SEO, но до сих пор чувствуете, что поисковик Google ранжирует ваш сайт в выдаче ниже, чем предполагалось и, о боже, даже не в ТОП 10. Что делать? Как Google PageSpeed Insights может помочь вам? Давайте начнём с основных положений.

Хорошая производительность сайта имеет большое значение. Современный сайт содержит не только статические файлы, но и фронт-энд библиотеки и фрейворки (такие как Bootstrap). И часто посетителю, чтобы увидеть страницу сайта, приходится ждать, пока загрузятся все файлы. И чем дольше загружаются страницы, тем ниже в поиске находится ваш сайт. Об этом много статей написано и мы, Русоникс, проводили собственное

факторов, влияющих на скорость сайтов (Прим. редакции Русоникс).

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

Очень популярный фреймворк для лёгкого создания оптимизированного веб дизайна — это фреймворк Bootstrap. И хотя Bootstrap легко использовать, он требует минимум 2 статических файла для работы. Это значит, что мы получаем удобство пользования за счет потери производительности.

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

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

Вы можете использовать PageSpeed Insights бесплатно со страницы project или следуйте инструкции по установке расширения Google PageSpeed Insights Plesk в вашей панели Plesk

ПОЯСНЕНИЯ К РЕКОМЕНДАЦИЯМ PAGESPEED INSIGHTS


1. Избегайте переадресаций целевой страницы


Переадресации могут вызвать ощутимые задержки, если запрос переадресуется несколько раз на конечный адрес откуда в итоге отсылаются данные клиенту. Каждая переадресация инициирует свою процедуру HTTP запроса-ответа (с возможным поиском DNS и ТСP согласованием), которая может значительно снизить производительность сайта, особенно для мобильных устройств со слабым интернет соединением.

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

Также убедитесь, что настроен правильный редирект в один шаг с http://example.com на https://www.example.com. Люди привыкли набирать короткий адрес вашего домена в адресной строке браузера. Но ваш сайт должен работать только на https (для большей защиты и лучшего рейтинга) и возможно использовать www как субдомен.

Заметки SEO: 301 редирект с HTTP на HTTPS
HTTPS становится важным фактором в ранжировании Google. Поисковый движок отдает предпочтение сайтам, которые используют HTTPS протокол для обеспечения безопасных подключений между двумя конечными объектами — клиентом и сервером. Проверьте возможность активации 301 редиректа на ваших доменах как только вы установили SSL-сертификаты.

Пользователям Plesk поможет расширение Security Advisor для активации бесплатных SSL-сертификатов. И вы можете активировать 301 редирект через опцию «Настройки хостинга» в панели управления.

Говоря о редиректах, Plesk поддерживает из своей коробочной версии 301 редиректы, дружественные к SEO. Т.е. если вы устанавливаете бесплатный SSL сертификат Lets’Encrypt (о том, как его установить из панели Plesk, читайте в этой статье (прим. редакции Русоникс)), то Плеск поможет вам переключиться на безопасный протокол без потери в поисковом рейтинге.

2. Включите сжатие


Всегда отсылайте пользователям контент сжатым с помощью GZIP или Deflate. Эти способы сжатия проверяют может ли быть сжат запрошенный ресурс такой как HTML картинки или JS/CSS файлы. Сжатие уменьшает количество байтов, передаваемых через сеть, до 90%. Это сокращает общее время загрузки всех ресурсов, что приводит к ускорению времени загрузки и лучшему юзабилити. Для сжатия важным является то, что обе стороны (и клиент и сервер) понимают примененный алгоритм сжатия. В так называемых полях HTTP заголовков происходит обмен поддерживаемыми алгоритмами.

Большинство современных браузеров уже поддерживают сжатие по умолчанию. На серверной стороне вы можете использовать специальные модули такие как mod_deflate (в Apache) или ngx_http_gzip_module (в Nginx)

Plesk поддерживает сжатие из коробочной версии
Не переживайте, сервер Plesk уже имеет предустановленные необходимые модули сжатия. Вам лишь необходимо активировать эту опцию вручную для всех доменов где нужно использовать сжатие. Вы можете добавить необходимый код в .htaccess (apache) или web.config (nginx) в корневой директории вашего сайта или прямо в панели Plesk, что ещё проще.

Перейдите в закладку «Сайты и домены» и выберите «Настройки apache и nginx». Если вы используете веб-сервер apache, то вам нужно добавить следующий код в текстовом поле под опцией «Дополнительные директивы apache».

Выберите текстовое поле следующей опции «Дополнительные директивы для HTTPS» если вы используете HTTPS.

Для APACHE:

AddOutputFilterByType DEFLATE text/plain text/html text/xml;
AddOutputFilterByType DEFLATE text/css text/javascript;
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml;
AddOutputFilterByType DEFLATE application/rss+xml;
AddOutputFilterByType DEFLATE application/javascript application/x-javascript

Если вы используете nginx, добавьте следующий код в текстовом поле «Дополнительные директивы nginx»

Для NGINX

gzip on; gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_disable «msie6»;
gzip_types text/plain text/css text/javascript text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss;

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

3. Настройте кеширование браузером


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

Вы можете использовать два поля в заголовке ответа: cache-control и ETag. С помощью Cache-Control вы можете определить как долго браузер может кешировать индивидуальные ответы. ETag создаёт ревалидацию токенов с помощью которых браузер может легко определять изменения файлов.

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

4. Уменьшите время ответа сервера.


PageSpeed Insights выводит это сообщение, когда сервер не отвечает через определённое время (>200ms) . Время ответа обозначает время, которое нужно браузеру для загрузки HTML кода для вывода. На этот параметр может влиять множество причин.

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

Вопрос в том как найти эти «узкие места»? Вы можете использовать расширение New Relic для решения или с помощью тестирования ресурсом Webpagetest где можно увидеть как браузеры отображают страницы и какие файлы замедляют ваш сайт.

5.Уменьшите HTML, CSS&JS


Сервер может уменьшить объём таких ресурсов, как HTML код или JS и CCS файлы, перед отправкой их в браузер.
Это сохранит много байтов данных, что увеличивает скорость загрузки ресурсов. Уменьшение объёма — это процесс оптимизации кода без потери нужной информации, чтобы сайт для посетителя отображался корректно.

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

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

6. Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы


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

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

Также есть смысл объединять все файлы в один файл (1 файл для CSS и JS) для уменьшения количества HTTP запросов. В общем, опредённо следует активировать HTTP/2 на вашем сервере. Новая версия протокола имеет очень положительное влияние на производительность сайта.

7. Оптимизируйте изображения.


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

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

Content-Delivery-Networks (CDN) такие как CloudFlare, могут оптимизировать картинки для вас автоматически.

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

8.Оптимизация видимого контента


Это сообщение выводится аналогично как при ошибке блокирующего контента. PageSpeed Insights выводит его когда для отображения первого экрана страницы, необходимо дополнительное сетевое подключение. Если посетитель загружает эту страницу через медленное интернет подключение (с большими задержками), то дополнительные сетевые запросы создают значительные задержки и ухудшают работу пользователя.

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

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

Google PageSpeed Insights расширение в Плеск
Если вы ещё не делали этого установите расширение в Плеск «Google PageSpeed Insights Plesk » сегодня и улучшите производительность веб-сайта и позиции в поисковой выдаче.

Перевод: Сергей Гордеев (Русоникс)
Оригинал

PageSpeed Insights — Оптимизация (обновление)

Всем привет! Сегодня мы поговорим о сервисе PageSpeed Insights от Google. Это сервис, который позволяет провести анализ сайта и даёт определённые рекомендации по его оптимизации. Когда сервис только появился, это вызвало немалый интерес со стороны разработчиков и SEO-оптимизаторов, ведь по-факту, сам Google даёт рекомендации и указывает, что конкретно нужно изменить или на что стоит обратить внимание, чтобы сайт и работал и загружался быстрее, а соответственно, был более любим поисковыми системами. В своё время я даже делал выпуск по оптимизации вёрстки для того, чтобы ваш проект набирал наибольшее количество баллов в PageSpeed. Там мы творили очень странные вещи по нынешним меркам — от загрузки части CSS в тег style в начале страницы, до более диких вещей, вроде загрузки стилей и ресурсов через JavaScript. И это реально работало. Но работало тогда. Давайте посмотрим, как обстоят дела сейчас, стоит ли колдовать над кодом, или достаточно просто выполнять определённые несложные правила по оптимизации сайта. В этом уроке я дам базовые обязательные рекомендации для любого проекта, актуальные на сегодняшний день и в будущем. Все рекомендации из данного урока отлично реализованы в последнем стартере OptimizedHTML 5, к примеру которого я буду обращаться по-ходу дела.

Поделиться

Твитнуть

Поделиться

Класснуть

Запинить

Полезные материалы

Важное примечание! Google PageSpeed Insights даёт лишь рекомендации по оптимизации страниц, это всего лишь цифры. Они ни в коем случае не должны быть строгим ориентиром и хоть как-то влиять на функционал сайта. Если для достижения лучшего результата PageSpeed Insights вам нужно менять всю структуру проекта, это может быть опасно и отрицательно повлиять на ранжирование сайта в поисковых системах и вот почему. Поисковики, в первую очередь, оценивают удобство сайта для пользователей, поменяв что-то кардинально, вы можете сделать только хуже. Это необходимо объяснять заказчикам, если вы работаете над клиентскими проектами. Результат таких манипуляций может быть непредсказуем, зачастую лучше обойтись базовыми правилами, которые я приведу далее и не стараться получить максимально высокую оценку сервиса, в ущерб пользовательского опыта. Были случаи, когда структура сайта менялась даже незначительно и поисковый трафик безвозвратно падал. Все рекомендации данного урока основаны на достаточно внушительном опыте работы автора с клиентскими проектами.
Оптимизируйте осторожно.

1. Стили и скрипты

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

  • Для оптимизации CSS я использую оптимайзер clean-css в реализации gulp-clean-css в проектах с использование Gulp.
  • Для оптимизации JS я использую модуль uglify-es, как наиболее эффективный, актуальный инструмент в реализации gulp-uglify-es.
  • Конкатенацию можно реализовать любыми доступными инструментами, я предпочитаю обычный gulp-concat.

Не смотря на то, что Google PageSpeed иногда рекомендует загружать и стили и скрипты в конце документа, я рекомендую стили всё-же загружать классическим способом в тег <link>, размещённый в теге <head>, а скрипты в конце документа, перед закрывающим тегом </body>, см. OptimizedHTML 5 — app/index.html.

<!DOCTYPE html>
<html>
<head>
	<meta charset="UTF-8">
	<title>Document</title>
	
	<link rel="stylesheet" href="path/to/styles.min.css">
</head>
<body>
	
	<script src="path/to/scripts. min.js"></script>
</body>
</html>

2. Шрифты

Всё, что касается шрифтов я могу уместить в одной фразе — используйте один формат woff2. Он достаточно легковесный и поддерживается везде, где только можно в настоящее время. Тот-же Google Fonts использует этот формат шрифтов как единственный. Данный момент мы обсуждали в видео-презентации OptimizedHTML 5. Для конвертации и сжатия любого шрифта в woff2 рекомендую использовать сервис Font Squirrel. Это быстрый и эффективный способ получить шрифт в нужном формате.

3. Изображения

Не зависимо от того, какой формат или форматы изображений используются в проекте, самое главное правило — старайтесь не использовать изображения, по своей физической ширине значительно превышающие размер вьюпорта, в котором они находятся. Что это значит. Допустим, вы используете 100% ширину изображения в теге <img> или в другом контейнере, размер которого, например, 700 пикселей (это можно посмотреть в инструментах разработчика любого браузера), а само изображение, загружаемое в контейнер имеет ширину 1000 пикселей. В таком случае, не зависимо от того, насколько хорошо у вас сжато изображение, Google PageSpeed укажет вам на то, что изображение необходимо оптимизировать ещё, хотя на практике это приведёт только к значительной потере качества.

Данное правило действует и для устройств с HiDPI — дисплеями, но немного по-другому. Например, для Retina или для мониторов с масштабированием интерфейса более 100%. Если мы имеем вьюпорт 700 пикселей на ретине, изображение, загружаемое для таких экранов не должно иметь разрешение свыше 1400 пикселей по ширине, так как масштабирование экрана на ретине 200%. Однако создавать изображения для таких экранов отдельно не обязательно, можно просто проконтролировать, чтобы качество изображения после сжатия было приемлемым, а вьюпорт для предполагаемого 100%-го масштабирования содержал изображение не намного его превышающее.

Если при разработке вы учитываете HiDPI экраны, такие, как Retina и другие с масштабированием свыше 100%, можно использовать атрибут srcset для тегов <img>, чтобы для обычных экранов загружать обычные изображения, а для Retina — увеличенные в 2 раза. Однако на практике я использую это правило и адаптацию для Retina только в своих личных проектах, так как работа с такими изображениями требует технической подготовки. В клиентских проектах, где работают контент-менеджеры, соблюдать эти правила сложно, да и не обязательно. Поэтому я убрал из OptimizedHTML 5 возможность создания изображений @2x формата. В этом нет смысла. Достаточно просто обрезать и сжимать изображения на бэкенде средствами фреймворка или CMS, в пределах разумного, чтобы менеджер, загрузив изображение, весом, например, 8 Мб не затруднил отображение контента на странице.

Почему я написал именно «значительно» превышающих размер вьюпорта — потому, что в условиях разработки Responsive проектов невозможно получить фиксированный размер вьюпорта изображения, в зависимости от экрана или устройства. На малых разрешениях вьюпорт уменьшается, а изображение, соответственно, остаётся неизменным. В таких случаях можно использовать вышеупомянутый атрибут srcset, который будет загружать разные изображения по размеру для разных экранов, но это, по-моему из разряда мракобесия, которое усложняет разработку и поддержку проектов.

Что касается Lazy Load, подгрузки изображений по мере их отображения, данную технику я рекомендую использовать только на тех сайтах, где изображений очень много. Например, в списках товаров или в длинных галереях. Если изображений не много, данная оптимизация хоть и может повлиять на оценку PageSpeed Insights, однако это как мёртвому припарка. Поэтому в контентных, статейных проектах, коммерческих сайтах и визитках данное правило можно опустить и не выполнять отложенную загрузку. Однако если у вас очень много изображений на одной странице — Lazy Load обязателен.

4. Бэкенд

Данный раздел является, на мой взгляд, важнейшим. Вы можете сколько угодно оптимизировать стили, собирать скрипты в кучу, уменьшать изображения до 1 пикселя, однако если у вас тяжёлый и неповоротливый бэкенд, который 5 секунд генерирует содержимое и 2 секунды соединяется с базой, это очень плохо. И плохо даже не столько для оценки PageSpeed, сколько для пользователей и поисковых систем. Это реальная проблема. Если я захожу на сайт и вижу белую страницу более 3-х секунд, просто закрываю вкладку и иду дальше. Зачастую, эта проблема — результат неграмотной разработки, использования множества тяжёлых плагинов, перегруженного бэкенда. Последовательность работы такой городьбы сложно отследить и оптимизировать. Чтобы у вас не случилось таких проблем, разрабатывайте сайты с использованием какой-либо CMS по документации и следуйте рекомендованным разработчиками самой системы правилам.

Не хотел показывать пальцем, пример сам напрашивается. Из опыта, лидером по таким проблемам с бэкендом является WordPress. Ничего не хочу говорить про эту систему плохого, здесь проблема скорее в подавляющем большинстве криворуких разработчиков как плагинов, шаблонов, так и сайтов. При грамотном подходе, ориентируясь на Codex, можно сделать вполне нормальный оптимизированный проект. Однако, на практике, среди готовых проектов такое встречается крайне редко — реализация грамотного подхода при разработке с использованием данной CMS довольно сложная и затратная по времени задача для среднего разработчика, придётся отказаться от множества плагинов сомнительного качества и писать всё самому. Когда ваши задачи выходят за рамки скачивания и кастомизации готовых шаблонов и плагинов, приходит понимание правильной модели разработки, MVC здесь лидер. Я предпочитаю использовать другие системы, которые позволяют контролировать каждый этап разработки — от создания конкретных плагинов, до разработки всего функционала на более низком уровне. В настоящее время лидерами для меня являются Laravel, Opencart и October CMS. Это очень прозрачный MVС у всех систем и возможность контролировать чистоту кода как бэкенда на уровне архитектуры, так и фронтенда, без танцев с бубном.

Однако, использование любой CMS или фреймворка — это сразу минус 5-10 баллов Google PageSpeed, особенно без кеширования, так как на генерацию бэкенда и обращения к базам данных уходит время. Поэтому в своих личных проектах и некоторых клиентских, где не нужен бэкенд, я использую генератор статики Jekyll. Сайт, созданный с использованием Jekyll представляет собой генерацию статических файлов, собранную единожды, например, при написании статьи, добавления другого контента или после внесения каких-либо правок. Лично для меня это по-прежнему самая лучшая, идеальная контентная система, которую я рекомендую всем, кому не нужен бэкенд и требуется молниеносная скорость и эффективность сайта. Сайт WebDesign Master сгенерирован с использованием Jekyll, можете оценить его реальную скорость работы.

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

5. Кеширование сервера

Для всех проектов рекомендую использовать директивы из файла ht.access, который вы найдёте в стартере для вёрстки OptimizedHTML 5. Здесь прописаны, на мой взгляд, самые эффективные настройки сервера для кеширования изображений, стилей, скриптов, шрифтов и других ресурсов. Данный пункт реально добавит вам десятки баллов PageSpeed, без боли.

Если вы используете October CMS, править .htaccess вручную не обязательно — можно, например, использовать плагин Speedy, который сделает эту работу за вас.

6.

Реальная эффективность сайта

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

Мракобесие

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

  1. Использовать async для всех скриптов. Данный параметр может повлиять на оценку, но в реальности все ресурсы загружаются в любом случае. Используйте async только там, где асинхронная загрузка действительно необходима, например, при загрузке виджетов или ресурсов с другого сервера.
  2. Боязнь больших библиотек и плагинов. Можете использовать абсолютно любые библиотеки, вроде jQuery или абсолютно любые плагины, вроде огромного Swiper на ванильном JS. Если все скрипты в одном файле и сжаты — можете быть спокойны. Намного хуже писать свой велосипед плагина из 10-ти строк кода, который работает кое-как и не везде. Это только ухудшит пользовательский опыт или вообще сломает экспириенс, если на данном функционале завязана значительная часть взаимодействия со страницей. Проще говоря: каруселька с товарами не работает, посетитель ушёл, поисковик это отметил, сайт провалился. Нынешние скорости интернета позволяют загружать файлы библиотек и скрипты, содержащие библиотеки довольно быстро. Если бы это было не так, все изображения с сайтов у вас грузились бы по два часа. Ваша библиотека или минифицированный JS-файл — это лишь капля в море в общем потоке загружаемых ресурсов.
  3. Загрузка стилей первого экрана в тег <style>. Знакомая практика для всех, кто занимался оптимизацией страниц. Данный костыль может повлиять на оценку PageSpeed, однако значительно усложнит разработку и поддержку сайта. Использовать или нет — решать вам. Я давно отказался от этого приёма.
  4. Использование WEBP формата изображений с фоллбеком на обычные или без него. Тоже спорный тренд для угоды цифрам PageSpeed. Формат неплох, имеет хорошее сжатие без заметного ущерба качеству. Его можно использовать, если есть желание. Я знаю некоторые студии, в которых практикуется подключение модуля PageSpeed для Nginx. Он отдаёт WEBP только тем браузерам, которые умеют с ним работать. На практике, это лишь усложняет разработку, требует написание фоллбеков и генерацию дополнительных изображений, а в случае работы с какой-либо CMS, вообще лишает всё мероприятие смысла, ведь пользователь или контент-менеджер будет использовать тот формат, который подвернётся. Если вы используете CMS или фреймворк, оптимизируйте и сжимайте популярные типы изображений средствами самой системы на бэкенде. PageSpeed, конечно, заметит возможность ещё большего сжатия изображений, но в этом нет ничего страшного. Это просто рекомендация, выданная машиной на основе анализа, это её работа. Всё должно быть в пределах разумного.
  5. Использование атрибута srcset или тега <picture> для загрузки различных форматов изображений, предназначенных для разных экранов. Данный пункт уже обсудили сегодня в разделе 3 — Изображения. Заморочиться можно, но смысла особого нет.
  6. Спрайты. Довольно популярная методика из 2010-х, которая заключается в объединении изображений или иконок в спрайты с последующим выводом через координаты. Сейчас не имеет никакого смысла, сложна в реализации, далека от контент-менеджеров. Количество запросов к серверу, создаваемое 10-ю иконками или 1 запрос к спрайту ощутимой разницы в реальной оптимизации не дадут, а вот внесение правок, добавление иконок и любые другие изменения требуют дополнительных временных затрат.

Единственной реальной проблемой при оптимизации сайта, которая может повлиять как на скорость загрузки сайта, так и на показатель PageSpeed — это виджеты сторонних сайтов, различные метрики и загрузка ресурсов с CDN. Это виджеты обратной связи, комментариев, групп в социальных сетях, плагины, библиотеки, сервисы статистики и так далее. Они подгружают ресурсы с других серверов и управлять их кешированием или скоростью загрузки невозможно. Могу посоветовать только использовать как можно меньше таких виджетов, не пользоваться шрифтовыми сервисами и прочим, а также, по возможности, загружать скрипты с таких ресурсов, используя атрибут async, загружать виджеты методом отложенной загрузки, если они не находятся на первом экране. Если виджет или ресурс необходим проекту жизненно, его не возможно перенести на рабочий сервер, сделать асинхронную или отложенную загрузку, ничего не остаётся, кроме как смириться с оценкой и не переживать по этому поводу.

Что ж. Как видите, в настоящее время не стоит заниматься мракобесием и выполнять сложные манипуляции со структурой страниц, свойствами тегов и прочим для достижения заветной «соточки», нужно лишь придерживаться базовых правил по сжатию ресурсов, настроить кеширование на сервере и оптимизировать вашу систему управления контентом, если такая возможность есть. Если ваш сайт в зелёной зоне или в топе оранжевой и самое главное, работает достаточно быстро — этого вполне достаточно. А если хочется увеличить посещаемость — лучше подумать о том, чтобы сделать сайт более интересным.

Премиум уроки от WebDesign Master

Другие уроки по теме «Инструменты»

Google: обновление PageSpeed Insights

После 12 ноября Интернет уже не будет прежним — Google кардинально изменил принципы работы PageSpeed Insights (PSI). Главным критерием оценки стала скорость.

Было/стало

В старой версии PageSpeed Insights баллы присуждались сайту за выполнение определенных правил. 95-98 из 100 считались серьезной заявкой на лидерство и получить их можно было за сжатие изображений, оптимизацию CSS, JacaScript и видимого контента и пр.

В обновленном PSI упор делается исключительно на временные характеристики работы сайта, изменилась шкала оценки. Если до ноября 2018 г. нижняя граница зеленой зоны начиналась с 80 баллов, то сейчас поднялась до 90. Для середнячков нижняя граница, наоборот, опустилась с 60 до 50, а несоответствующими требованиям считаются ресурсы в диапазоне 0-49 против старых 0-59 балов. Для наглядности мы сделали таблицу, но сравнивать старую и новую оценки, на самом деле, некорректно — они определяются по разным параметрам.

Оценочная шкала

Зеленая зона

Желтая зона

Красная зона

Старая (качественная/балльная)

Good, 80-100

Medium, 60-79

Low, 0-59

Новая (скоростная)

Fast, 90-100

Average, 50-89

Slow, 0-49

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


Метрики нового PageSpeed Insights

Вернемся к показателям скорости. Их 6:

  1. Время загрузки первого контента. Период до появления на странице первых изображений или текста.
  2. Индекс скорости загрузки. Промежуток, когда страница перестает визуально меняться. Модуль Speedline определяет этот промежуток, проводя покадровую съемку и сравнение данных.
  3. Время загрузки для взаимодействия. По сути это time to interactive — период времени, который требуется для того, чтобы сайт начал отзываться на действия пользователя.
  4. Время загрузки достаточной части контента. Секунды, за которые на странице подгружаются шрифты и появляются основные элементы.
  5. Время окончания работы ЦП. К моменту окончания работы ЦП подгружаются и готовы отвечать на действия пользователя пусть не все, но базовые интерактивные элементы.
  6. Приблизительное время задержки при вводе. Время, за которое страница реагирует на действия посетителя в течение 5 с после загрузки.


У показателей разная значимость. Time to Interactive — ключевой. Estimated Input Latency — наименее важный.

Как теперь оптимизировать сайт под Google

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

Хрусталева Екатерина, Специалист отдела маркетинга Nowmedia

Сервис работает не очень стабильно — идет отладка и обкатка, но первые опыты показали, что на основные параметры скорости негативно влияют:

  • всплывающие окна;
  • интеративные карты, автоматом подгружающиеся при открытии страницы;
  • виджеты ВКонтакте, Facebook, Одноклассников;
  • чаты онлайн-консультантов;
  • подгружающиеся на всей странице, а не на видимой ее части, картинки.

PSI дает рекомендации по улучшению скорости загрузки. Удобно, что сразу прогнозирует экономию времени в секундах.


Пробуем убрать интерактивную мишуру и выигрываем несколько баллов вкупе с приятной прибавкой скорости по основным показателям… Тенденция ясна.

На лицо стремление Google к аскезе. Минимум примочек, ненужных красивостей, отвлекающих деталей. Главное — быстрота и полнота ответа за запрос пользователя.

Запросить коммерческое предложение
на техническую поддержку сайта

Заявка на расчет


Как набрать Google PageSpeed Insights 100 баллов

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

В основном трудности возникают из-за того, что большинство используют различные CMS. А это не HTML страница с 3-мя папками (CSS, IMG, JS) где всё легко найти. На CMS установлено очень много плагинов, которые находятся в отдельных папках. Также сама тема (шаблон) для новичка кажется просто ужасно сложной и он боится вносить любые изменения, чтобы ни в коем случае не навредить сайту.

Прежде чем приступать к основной части статьи, я хочу порекомендовать Вам следующие статьи по оптимизации:

На что влияет скорость загрузки страниц сайта?

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

  • 1. Потеря потенциальных клиентов — все мы постоянно торопимся и не хотим ждать даже лишнюю секунду, потому что информации в интернете достаточно и можно найти другой сайт, который загрузиться намного быстрее.
  • 2. Ухудшение поведенческих факторов — из первого пункта вытекает то, что человек не дожидаясь полной загрузки страницы покидает ее, а это поисковой системой считается как отказ. Чем больше процент отказов, тем, по мнению поисковой системы, менее полезным считается контент и сайт понижается в поисковой выдаче.
  • 3. Проблемы с мобильным трафиком — сейчас большинство для поиска информации в интернете используют мобильные устройства. Скорость интернета в мобильных гаджетах оставляет желать лучшего. Но никто не хочет терять дополнительный трафик на сайт, поэтому необходимо выжать максимум из оптимизации сайта для мобильных устройств как по скорости загрузки, так и по удобству просмотра.
  • 4. Алгоритм mobile-friendly — который Google официально объявил весной 2015 года. Согласно ему страницы, которые корректно отображаются на мобильных устройствах будут ранжироваться выше в результатах мобильного поиска.

Ссылка на сервис — Google PageSpeed Insights

Ускорил ли я свой сайт на 100 баллов по меркам Google PageSpeed Insights?

На изображении выше Вы можете видеть результат. Да, я смог даже из сайта на CMS выжать 100 баллов. Сейчас Вы можете проверить и начать писать в комментариях о том, что у меня нету 100, а лишь 98 баллов. И говорить о том, что плох параметр «Время ответа от сервера». Но в данном цикле статей Вы получите рекомендации как выжать максимум и получить 100 баллов. Главное выполняйте все рекомендации, которые я буду давать в статьях и на видео.

Для каких сайтов и CMS я буду давать решения?

Рекомендации, которые Вы получите по решению той или иной проблемы можно применить абсолютно на любом сайте: будет ли это лендинг на чистом HTML или сайт под управлением CMS.

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

Практика

Предварительно сделайте резервную копию Вашей темы (шаблоны), если Вы используете CMS или резервную копию Вашего лендинга.

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

1 Проблема

Сегодня мы рассмотрим сразу 2 пункта: «Оптимизируйте Javascript» и «Оптимизируйте CSS».

2 Решение

Смотрите видео, чтобы узнать о том, как оптимизировать Javascript и CSS, а также какие нюансы при использовании CMS бывают.

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

Список сервисов для оптимизации JS файлов:

Список сервисов для оптимизации CSS файлов:

Вывод

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

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

Успехов!

С Уважением, Юрий Немец

Как накрутить Google Pagespeed до 100 и найти себе клиентов. АНТИЛАЙФАК | Урок #280

Длительность: 9:10

Как накрутить Google Pagespeed до 100 и найти себе клиентов. АНТИЛАЙФАК | Урок #280


SEO

&nbsp

В новом аудиоподкасте №280 Николай Шмичков рассказал о том, как накрутить Google Pagespeed до 100.

Текстовая версия выступления:

“Всем привет!

Вы на канале Seoquick.

Меня зовут Николай Шмичков.

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

Это пост со страницы Михаила Шакина о том, как накручивают 100 баллов на Google Page Speed.

Эту статью предоставил автор Алексей (фамилии не видно) на сайте vc.ru.

Он до этого рассказывал статью о мифах, что можно подделать Page Speed.

Он рассказывает, что некоторые фрилансеры могут накручивать Page Speed до 100 баллов.

Это действительно правда.

Если клиент хочет Page Speed 100 баллов, а оплатит мало, то делают простой трюк: отдают для робота Google скриншот вашего сайта вместо самого сайта.

Поэтому если вам сделали Page Speed 100 баллов по цене ниже 10000 руб, то 99% случаев это обман.

Технически это делается так: определяется бот page Speed, в Google page Speed insights загружают скрин главной и сайт показывает 100 и 100.

Как узнать, что вас обманывают?

Если скриншот в Google pageSpeed Insights остаётся старым, нужно копаться в коде, чтобы узнать что же вам такого там наворотили.

На сайте дают рекомендации, как обрабатывать в ручном режиме десятки сайтов.

В 98% из 100 сайтов всё было нормально.

На login express сайт 7 из 10 идеальный почти по всем параметрам.

Время загрузки очень быстрое, замер на Web page Test тест ломается – там показывает больше 20 секунд.

На графике загрузки ресурса видно время около 8 секунд.

Если учесть по оценке Яндекс метрики, то замер до 17 секунд, дает тоже хорошие результаты.

Пишут что сайт идеален, что надо включить серверный push.

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

Эту статью Михаила Шакина вы можете посмотреть – я сделаю её репост.

Автор ускорения сделал очень просто, он сделал скрипт, который подсовывает другую версию страницы только для Page Speed, которую можно видеть в lighthouse.

Если бот заходит и видит одну страницу, то на самом деле ему подсовывают другую страницу.

Сам трюк, который можно заметить это 0 элементов структуры DOM, чего у настоящего сайта быть не может. хоть и page Speed говорит, что его надо сократить, но их не должно быть ноль.

У настоящего сайта этот показатель должен быть минимум 1-2.

Фантастические показатели с подставной страницы для Page Speed это фактически то, что вас скорее всего обманывают.

Если сначала подсовывали просто скриншот страницы, то теперь подсовывают просто другую версию страницы.

Чек лист от Алексея, который позволяет проверить такое фейковое ускорение.

Первое.

Если вам ускорили медленный сайт за маленькие деньги и показатель Page Speed больше 90 по мобилке, а логин экспресс показывает ниже 7 баллов, то проверьте вашими хорошими специалистами по ускорению сайта.

Однозначно ищите не фрилансера, а какую-то компанию и закажите аудит полный проверки.

Она делается, конечно же, без всяких Google ботов page Speed.

Сделайте замер внутренней страницы.

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

Как в описанном случае во внутренней странице немножко увидели не то.

Следите за показателями DOM.

Он не должен быть равен нулю.

Это тогда точно не сайт .

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

Смените картинку сайта на проверяемой странице сайта, а на новом экране сделайте замер заново.

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

Если у вас упал трафик в Google, Page Speed поднялся, то у вас скорее всего обманули, а Google это заметил.

Напоследок хотелось бы вас чем-то интересненьким повеселить и удивить.

У меня есть целый сайт, который позволяет накрутить page Speed.

Есть сайт login.express.

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

Способ действительно подойдет, если нет денег на настоящие ускорение, но хочется удивить конкурентов и заставить их потратить кучу денег ускорение сайта.

Допустим для фрилансера, который занимается увеличением Page Speed, но портфолио у него пустое и нужно чем-то похвастаться.

И если на сайте низкая конверсия, но хочется чтобы выглядело всё наоборот.

Они создали сервис, всего одна строчка кода, которая реально позволяет сделать сайт быстрым на 100 баллов по Page Speed insights.

Вставляется строчку в начало индекса сайта PHP, корень сайта, и наслаждаетесь.

Как работает этот код.

Код определяет бота Page Speed по user-agent, а он обязательно содержат Chrome lighthouse.

Только для этого бота он показывает особую страницк вообще без контента.

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

Каждый день скриншот обновляется и на каждой странице сайта будет скриншот, который соответствует этой странице.

В этом и весь функционал.

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

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

После этого они увидят заветную сотню баллов.

На самом деле страница не становится быстрее, обманывается только lighthouse, который Google используют для Page Speed Инсайт.

Так, по факту, Логин Экспресс подготовились к грядущему алгоритму, который вот-вот стрельнет.

Это тоже очень интересно потому что login express – это проект, с которым я столкнулся и возможно их станет больше.

Я думаю этих сервисов станет больше.

Google придётся по-другому вылавливать при помощи других методов, не только при помощи Chrome lighthouse ботов, чтобы выловить реальную скорость загрузки сайта.

А что вы думаете? Задавайте вопросы в комментариях.

Комментарии я буду ждать, например, в телеграм группе, где я стабильно публикую такого рода новости.

Не забывайте про наш youtube-канал.

Каждый четверг у нас выходят вебинары.

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

Буду всех вас рад там видеть.

Не забываем подписываться наши подкасты.

У нас самые лучшие подкасты в рунете по IT.

До новых встреч.”

Чек лист по проверке скорости загрузки сайта

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


Немного теории, Page speed (скорость загрузки) это один из многих факторов ранжирования ПС Яндекс и Google.С каждым годом значение Page speed становится все более значимым для поисковых систем. При долгой загрузке сайта, посетитель скорее всего сразу его покинет, что отрицательно скажется на поведенческих факторах. Низкий показатель поведенческих факторов сразу приведет к просадке в поисковой выдаче. Таким образом скорость важна как пользователям, так и с точки зрения SEO.

Как измеряется скорость и сколько должен загружаться веб-сайт?

Перед тем как рассмотреть основные сервисы проверки, необходимо понять, как поисковая система проверяет загрузку сайта. Для оценки за основу берется показательPageSpeed Insights, который производит имитацию загрузки страниц веб-ресурса на компьютере и мобильном устройстве. PageSpeed Insights анализирует время:

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

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

Основные сервисы для проверки скорости

Google PageSpeed Insights – основной инструмент для анализа скорости от самого Google. Сервис полностью бесплатный и не требует регистрации. Помимо общей оценки загрузки сайта на десктоп и адаптивной версии, Google PageSpeed Insights приводит подробный отчет, какие параметры сайта необходимо исправить и сколько это даст прироста скорости.  


loading.express. В основе этого сервиса находится API Google PageSpeed Insights с разницей геолокации, откуда происходит проверка. Google проверяет сайты с европейских серверов, loading.express использует для анализа данных IP крупных городов России. При использовании общего алгоритма, данные могут отличаться (иногда даже значительно).


Pingdom Tools – онлайн утилита проводящая подробный анализ по 70+ факторам, влияющим на скорость загрузки. Сводный отчет представляется в таблице, где можно увидеть каждый тип обращения к серверу и посмотреть рекомендации по оптимизации скорости конкретного пункта.


Uptrends. Это ещё один зарубежный мульти-ресурс, проводящий мониторинг сайта как по показателям PageSpeed Insights, так и по ряду других метрик. Данные выводятся в таблицах и графиках «без воды».


PR-CY. Отечественный сервис, предлагающий платную подписку на свои инструменты поисковой SEO оптимизации. В данном случае мы рассматриваем функцию проверки скорости, которая бесплатна и доступна без регистрации. Отчет формируется сразу на странице и содержит подробное описание (простым и понятным языком), что проверил сервис и какие изменения необходимо сделать на сайте.


Sitespeed. Внешне этот сервис ничем не отличается от аналогов, однако при ближайшем рассмотрении у него открывается ощутимый плюс. Sitespeed проводит проверку с разных IP (как российских, так и зарубежных), выводя общий отчет, учитывающий разные сервера.


Следите за скорость загрузка своего ресурса и не забывайте об ускоренной версии сайтов Яндекс Турбо и Google APM, о которой мы подробно рассказывали в отдельной статье. 

Битрикс — Inline CSS, Preloading, Preconnect для ускорения загрузки и увеличения баллов PageSpeed


Inline CSS, Preloading, Preconnect для ускорения загрузки сайта — это решение для 1с-Битрикс, ускоряющее отображение сайта на всех типах  устройств пользователей и  положительно влияющее на баллы, скорость и параметры загрузки сайта в Google  PageSpeed Insights.

Механизм решения основан на снятии блокировки загрузки страницы  CSS-стилями в шапке сайта без изменения файлов вашего сайта и искажения  отображения. Дополнительно в решении есть функционал preconnect  (предсоединения), preloading (предзагрузки) и возможность проставлять  свойство font-display для шрифтов на лету.

В терминологии сервиса PageSpeed Insight решение устраняет проблемы:

Механизм работы решения основан на снятии блокировки загрузки страницы стилями это позволяет значительно ускорить отображение страницы на экране пользователя. С использованием загрузки css инлайн-кодом, страница может быть отображена значительно раньше полной загрузки и отработки Javascript. Особенно четко эффект заметен на мобильных устройствах.

Увеличение баллов в PageSpeed является не самоцелью, а последствием ускорения отображения страницы за счёт работы модуля.


Простая установка и настройка
Модуль работает «На лету», исходные файлы не редактируются
Работа модуля полностью безопасна
Обрабатываемые CSS-стили оптимизируются
Поддерживается работа с Google Fonts
Поддерживаются внешние таблицы стилей
▷  Ускоряет работу сайта у реальных пользователей, а не только в PageSpeed Insight
▷  Умеет удалять стандартный шрифт Open Sans, подключаемый из ядра битрикса
Обрабатываемый модулем CSS оптимизируется — удаляются комментарии, переносы, лишние пробелы и прочие, не несущие ценности, символы
  ✔  Корректно работает на пк, смартфоне и планшете
  ✔  Поддерживает механизм многосайтовости
  ✔  Одинаково хорошо работает с кодировками UTF-8 и Windows-1251
  ✔  Использует стабильные события и работает на большинстве версий 1с-Битрикс
  ✔  Поддерживает композитный и автокомпозитный режим

Для дополнительного ускорения отображения сайта и увеличения рейтинга скорости по Google Pagespeed Вам будут полезны:

— Модуль «Отложенная загрузка картинок, видео и фоновых изображений», решающий проблему «Отложите загрузку изображений» — смотреть карточку решения

— Модуль «Оптимизация и сжатие HTML + CSS», уменьшающий вес отдаваемых html-страниц — смотреть карточку решения

Правда о подсчете очков 100/100

Google PageSpeed ​​Insights, без сомнения, полезный инструмент для веб-мастеров, разработчиков и владельцев сайтов всех типов. Однако мы заметили, что многие люди часами поглощены оптимизацией своих сайтов, чтобы попытаться получить 100/100 баллов в этом тесте.

По правде говоря, Google PageSpeed ​​Insights не предназначен для использования и не является стоящим делом. Когда вы сосредоточитесь на выполнении рекомендаций платформы, а не на цифре в верхней части страницы, вы получите гораздо больше преимуществ для своего сайта.

Этот пост представляет собой исчерпывающее руководство по использованию Google PageSpeed ​​Insights с максимальной выгодой. Мы расскажем, как Google использует вашу оценку, а также как учитывать полученные вами рекомендации.

Приступим!

Введение в Google PageSpeed ​​Insights

Если вы еще не знакомы с Google PageSpeed ​​Insights, это инструмент, используемый для тестирования производительности веб-сайтов. Вы можете ввести любой URL-адрес и проанализировать его:

Google PageSpeed ​​Insights

Затем Google дает тестируемому веб-сайту общую оценку из 100 на основе нескольких рекомендаций по оптимизации производительности:

Оценка Google PageSpeed ​​Insights

Наряду с этим результатом вы также увидите несколько рекомендаций от Google о том, как улучшить вашу производительность (и, следовательно, ваш рейтинг PageSpeed ​​Insights):

Рекомендации Google PageSpeed ​​Insights

По состоянию на 2018 год оценки PageSpeed ​​Insights рассчитываются с помощью Lighthouse, автоматизированного инструмента Google с открытым исходным кодом для улучшения общего качества веб-страниц. Эта платформа может оценивать всевозможные факторы, включая производительность, доступность, прогрессивные веб-приложения и многое другое.

Чтобы увидеть комплексную оценку вашего сайта Lighthouse, вы можете использовать инструмент Google Measure:

Инструмент аудита Google Webmasters Measure

В дополнение к аудиту производительности, подобному тому, который проводится в Google PageSpeed ​​Insights, вы получите оценку доступности, передовых методов и поисковой оптимизации (SEO).

Правда о рейтинге 100/100 в Google PageSpeed ​​Insights

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

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

В отличие от PageSpeed ​​Insights, Pingdom Tools позволяет тестировать производительность вашего сайта из разных мест:

Результаты теста скорости Pingdom Tools

Вы также можете запускать тесты на таких платформах, как GTmetrix (который объединяет ваши результаты из PageSpeed ​​Insights и YSlow) и WebPageTest.Скорее всего, ваши результаты по этим различным инструментам не будут точно совпадать, что показывает, насколько произвольными могут быть эти числа.

Что действительно важно, так это фактическая скорость вашего сайта . Для сравнения: мы видели сайты со средним временем загрузки менее 500 миллисекунд (что очень быстро!), Которые не имеют оценки 100/100 на PageSpeed ​​Insights.

Другой фактор, который должен влиять на ваш подход к оптимизации скорости, — это воспринимаемая производительность вашего сайта.Посетителей не волнует, какой у вас рейтинг в Google PageSpeed ​​Insights. Они просто хотят иметь возможность просматривать ваш контент как можно быстрее.

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

Как Google использует PageSpeed ​​Insights

Помимо влияния на пользовательский опыт (UX) вашего сайта, производительность также играет роль в SEO.Учитывая, что PageSpeed ​​Insights управляется крупнейшей и самой популярной поисковой системой в мире, само собой разумеется, что ваш результат может иметь некоторое влияние на рейтинг вашей страницы результатов поисковой системы (SERP) (по крайней мере, в самом Google).

Реальность такова, что Google действительно использует PageSpeed ​​Insights для определения рейтинга — своего рода. Скорость сайта — это простой и понятный фактор ранжирования. Результаты вашего теста производительности могут дать вам довольно хорошее представление о том, где вы стоите на этом фронте.

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

С учетом сказанного, вы все равно можете использовать результаты PageSpeed ​​Insights для улучшения вашего SEO. Например, с 2018 года скорость мобильной страницы была фактором ранжирования для Google. Вы заметите, что ваш тест производительности предоставляет данные как для настольной, так и для мобильной версии вашего сайта:

Вкладка для мобильных устройств в Google PageSpeed ​​Insights

Поскольку более 73 процентов пользователей мобильного Интернета утверждают, что сталкивались с сайтом, который слишком долго загружается, информация на вкладке Google PageSpeed ​​Insights Mobile бесценна.Использование приведенных здесь рекомендаций по сокращению времени загрузки на смартфонах и других устройствах должно дать вам конкурентное преимущество.

Рекомендации Google PageSpeed ​​Insights (24 способа повышения производительности)

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

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

Есть также две диаграммы, которые показывают, где попадают ваши средние значения First Contentful Paint (FCP) и First Input Delay (FID):

Данные поля Google PageSpeed ​​Insights

На изображении выше FCP нашего сайта примерно такой же, как у 45 процентов сайтов в 75-м процентиле, а наш FID примерно такой же, как 9 процентов из 95-го процентиля.

Лабораторные данные показывают конкретные данные для моделируемой загрузки страницы:

Данные лаборатории Google PageSpeed ​​Insights

Вы заметите, что наши полевые данные и лабораторные данные не полностью совпадают.Это совершенно нормально. Lab Data создается при фиксированных условиях, а Field Data использует фактические скорости загрузки, собранные с течением времени.

Если рассматривать их вместе, Field Data и Lab Data должны дать вам представление о фактическом времени загрузки вашего сайта. Как мы упоминали ранее, это даже более важно, чем ваш общий показатель PageSpeed, поэтому вам стоит обращать внимание на эти числа.

После того, как вы обдумали эту информацию, пора приступить к повышению производительности вашего сайта с помощью рекомендаций Google PageSpeed.

1. Устранение ресурсов, блокирующих рендеринг

Одной из наиболее распространенных рекомендаций Google PageSpeed ​​Insights является устранение ресурсов, блокирующих отображение:

Рекомендация по устранению блокировки ресурсов рендеринга

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

Подробнее об этой проблеме можно узнать из нашего руководства по устранению скриптов, блокирующих рендеринг. Что касается Google, вам следует рассмотреть два решения:

  • Если у вас мало JavaScript или CSS, вы можете встроить их, чтобы избавиться от этого предупреждения. Этот процесс относится к включению вашего JavaScript и / или CSS в ваш HTML-файл. Вы можете сделать это с помощью такого плагина, как Autoptimize. Однако это действительно только для очень маленьких сайтов. На большинстве сайтов WordPress достаточно JavaScript, поэтому этот метод может действительно замедлить работу.
  • Другой вариант — отложить выполнение JavaScript. Этот атрибут загружает ваш файл JavaScript во время синтаксического анализа HTML, но выполняет его только после завершения синтаксического анализа. Кроме того, скрипты с этим атрибутом выполняются в порядке появления на странице.

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

2. Избегайте цепочки критических запросов

Концепция объединения критических запросов связана с критическим путем отрисовки (CRP) и тем, как браузеры загружают ваши страницы.Определенные элементы, такие как JavaScript и CSS, которые мы обсуждали выше, должны быть полностью загружены, прежде чем ваша страница станет видимой.

В рамках этого предложения Google PageSpeed ​​Insights покажет вам цепочки запросов на анализируемой странице:

Рекомендация избегать цепочки критических запросов

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

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

  • Устранение ресурсов, блокирующих рендеринг
  • Откладывание закадровых изображений
  • Минимизация CSS и JavaScript

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

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

3. Сохраняйте низкое количество запросов и малые размеры передачи

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

Как и рекомендация Избегайте цепочки критических запросов , эта рекомендация не приводит к «успешному выполнению» или «неудаче». Вместо этого вы просто увидите список с количеством сделанных запросов и их размером:

Сохраняйте низкое количество запросов и рекомендуем небольшой объем переводов

Не существует идеального количества запросов или максимального размера, о котором следует помнить.Вместо этого Google рекомендует вам установить эти стандарты для себя, создав бюджет производительности. Это набор определенных целей, которые могут быть связаны с такими аспектами, как:

  • Максимальный размер изображения
  • Количество используемых веб-шрифтов
  • Сколько внешних ресурсов вы звоните на номер
  • Размер скриптов и фреймворков

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

4. Сократите CSS
Файлы CSS

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

Сокращение CSS — это процесс сжатия файлов путем удаления ненужных символов, пробелов и дубликатов. Google рекомендует эту практику, поскольку она уменьшает размеры ваших файлов CSS и, следовательно, может улучшить скорость загрузки:

Минимизировать рекомендацию CSS

Мы рекомендуем использовать такой плагин, как Autoptimize или WP Rocket, для минимизации ваших файлов CSS.

5. Минимизируйте JavaScript

Так же, как вы можете уменьшить размер файла CSS с помощью минификации, то же самое относится и к вашим файлам JavaScript:

Минимизировать рекомендацию JavaScript

Autoptimize или WP Rocket также могут справиться с этой задачей для вашего сайта WordPress.

6. Удалите неиспользуемый CSS

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

Вот почему Google рекомендует удалить все неиспользуемые CSS:

Подпишитесь на информационный бюллетень

Мы увеличили наш трафик на 1187% с помощью WordPress.


Мы покажем вам, как это сделать.

Присоединяйтесь к более чем 20 000 других людей, которые получают нашу еженедельную рассылку с инсайдерскими советами по WordPress!

Удалить неиспользуемые рекомендации CSS

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

7. Минимизируйте работу с основной резьбой

«Основной поток» — это основной элемент браузера пользователя, который отвечает за преобразование кода в веб-страницу, с которой посетители могут взаимодействовать. Он анализирует и выполняет HTML, CSS и JavaScript. Кроме того, он отвечает за взаимодействие с пользователем.

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

Google PageSpeed ​​помечает страницы, которым требуется больше четырех секунд для завершения работы основного потока, и представляет пригодную для использования веб-страницу:

Рекомендация минимизировать работу основного потока

Некоторые методы, используемые для сокращения работы основного потока, уже были описаны в других разделах этого сообщения, в том числе:

  • Уменьшение кода
  • Удаление неиспользуемого кода
  • Реализация кэширования

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

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

8. Сократите время выполнения JavaScript

Выполнение JavaScript часто является наиболее важным фактором, влияющим на работу основного потока. В PageSpeed ​​Insights есть отдельная рекомендация, чтобы предупредить вас, если эта задача оказывает значительное влияние на производительность вашего сайта:

Рекомендация по сокращению времени выполнения JavaScript

Методы, предложенные выше для сокращения работы основного потока, также должны устранить это предупреждение в ваших результатах PageSpeed.

9. Сократите время отклика сервера (TTFB)

Время до первого байта (TTFB) — это показатель того, сколько времени требуется браузеру для получения первого байта данных обратно с сервера вашего сайта после выполнения запроса. Хотя это не то же самое, что и общая скорость вашего сайта, низкий TTFB, по понятным причинам, хорошо сказывается на производительности вашего сайта.

Таким образом, сокращение времени ответа сервера входит в число рекомендаций Google PageSpeed ​​Insights. Если вам удается достичь низкого значения TTFB, вы увидите это сообщение под заголовком Пройден аудит :

Низкое время ответа сервера сообщение

Есть несколько факторов, которые могут повлиять на ваш TTFB.Некоторые стратегии для его снижения включают:

  • Выбор качественного провайдера веб-хостинга, ориентированного на скорость
  • Использование легких тем и плагинов
  • Уменьшение количества плагинов, установленных на вашем сайте
  • Использование сети доставки контента (CDN)
  • Реализация кеширования браузера
  • Выбор надежного поставщика системы доменных имен (DNS)

Наш пост на TTFB — отличный ресурс для более подробной информации об оптимизации в этой области.

10. Правильный размер изображений

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

Рекомендация правильного размера изображений

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

Чтобы исправить это, вы можете либо загружать изображения подходящего размера, либо использовать «адаптивные изображения».Это предполагает создание изображений разного размера для разных устройств.

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

Например, предположим, что у вас есть изображение заголовка, и вы хотите сделать его адаптивным. Вы можете загрузить три его версии с шириной 800, 480 и 320 пикселей.Затем вы примените атрибут srcset , например:

    

Атрибут srcset указывает различные доступные файлы, а атрибут sizes сообщает браузерам, какой из них следует использовать в зависимости от текущего размера экрана.

11. Отложить закадровые изображения

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

Меньшая загрузка до того, как страница станет видимой, означает лучшую производительность, поэтому Google рекомендует этот метод:

Рекомендация отложить закадровые изображения

Существует несколько плагинов WordPress, созданных специально для отложенной загрузки, включая a3 Lazy Load и Lazy Load от WP Rocket. Различные плагины для оптимизации изображений и производительности, такие как Autoptimize, также имеют функции отложенной загрузки. Ознакомьтесь с нашим полным руководством по отложенной загрузке изображений и видео в WordPress.

12. Эффективное кодирование изображений

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

Рекомендации по эффективному кодированию изображений

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

Другие рекомендации, которые влияют на то, «пройдете» вы или «не пройдете» проверку Эффективное кодирование изображений :

  • Показ изображений с правильным размером
  • Реализация отложенной загрузки (откладывание закадровых изображений)
  • Преобразование изображений в форматы файлов следующего поколения, такие как WebP
  • Использование видеоформатов для анимированного содержимого, например GIF

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

13. Показывать изображения в форматах следующего поколения

Некоторые форматы файлов изображений загружаются быстрее других. К сожалению, это не обычные форматы PNG или JPEG . WebP Изображения становятся новым стандартом, и Google PageSpeed ​​сообщит вам, если ваши изображения не соответствуют ему:

Рекомендация по показу изображений в форматах следующего поколения

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

14. Используйте видеоформаты для анимированного содержимого

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

К сожалению, за эти преимущества приходится платить. GIF-файлы требуют загрузки, поэтому PageSpeed ​​Insights рекомендует вместо этого использовать видеоконтент:

Использовать видеоформаты для анимированного содержимого Рекомендация

К сожалению, преобразование GIF в видеоформат — не самый простой процесс.Во-первых, вам нужно решить, какой тип видео вы хотите использовать:

  • MP4: Создает файлы немного большего размера, но совместим с большинством основных браузеров.
  • WebM: Наиболее оптимизированный видеоформат, хотя он имеет ограниченную совместимость с браузером.

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

Инструмент преобразования формата файлов FFmpeg для видео и аудио

Затем откройте интерфейс командной строки и выполните следующую команду:

  ffmpeg -i input.gif output.mp4  

Это преобразует GIF с именем файла input.gif в видео MP4 с именем файла output.mp4 . Однако изменение формата — это только начало. Теперь вам нужно встроить полученное видео на свой сайт WordPress таким образом, чтобы оно выглядело как анимированный GIF.

Встраивание видеоконтента в анимацию

Как вы, наверное, заметили, если раньше видели GIF, они немного отличаются от обычных видео. Обычно они запускаются автоматически и запускаются в цикле, и они всегда без звука. Встраивание нового файла MP4 или WebM на сайт WordPress не приведет к появлению этих функций.

Однако вы, , можете воссоздать их с помощью очень простого кода. Загрузите свое видео в медиатеку, а затем добавьте следующее на страницу или сообщение, в которое вы хотите добавить свой GIF:

  <цикл автовоспроизведения видео приглушен, воспроизведение в режиме онлайн>

  

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

15. Убедитесь, что текст остается видимым во время загрузки веб-шрифта

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

Убедитесь, что текст остается видимым во время загрузки веб-шрифта. Рекомендация

Google рекомендует решить эту проблему, применив директиву Font Display API swap в вашем стиле @ font-face .Для этого войдите в свою таблицу стилей ( style.css ) и добавьте следующее после атрибута src в поле @ font-face :

font-display: swap

Вы можете узнать больше об оптимизации веб-шрифтов в нашей публикации « Как изменить шрифты в WordPress » и в нашем подробном руководстве по размещению локальных шрифтов.

16. Включить сжатие текста

Google PageSpeed ​​Insights ‘ Включить сжатие текста Рекомендация относится к использованию сжатия GZIP:

Включить рекомендацию по сжатию текста

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

Первый — установить плагин с функцией сжатия GZIP. WP Rocket — жизнеспособное решение, если вы готовы за него платить.

Вы также можете сжать текст вручную. Это включает в себя редактирование файла .htaccess , что может быть рискованным, поэтому убедитесь, что у вас есть последняя резервная копия.

Большинство сайтов WordPress работают на серверах Apache. Код для включения сжатия GZIP выглядит так:

  
  # Сжатие HTML, CSS, JavaScript, текста, XML и шрифтов
  AddOutputFilterByType DEFLATE application / javascript
  AddOutputFilterByType DEFLATE application / rss + xml
  AddOutputFilterByType DEFLATE application / vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application / x-font
  AddOutputFilterByType DEFLATE application / x-font-opentype
  AddOutputFilterByType DEFLATE application / x-font-otf
  AddOutputFilterByType DEFLATE application / x-font-truetype
  AddOutputFilterByType DEFLATE application / x-font-ttf
  AddOutputFilterByType DEFLATE application / x-javascript
  AddOutputFilterByType DEFLATE application / xhtml + xml
  AddOutputFilterByType DEFLATE application / xml
  AddOutputFilterByType DEFLATE font / opentype
  AddOutputFilterByType DEFLATE font / otf
  AddOutputFilterByType DEFLATE font / ttf
  AddOutputFilterByType DEFLATE изображение / svg + xml
  AddOutputFilterByType DEFLATE изображение / значок x
  AddOutputFilterByType DEFLATE text / css
  AddOutputFilterByType DEFLATE text / html
  AddOutputFilterByType DEFLATE текст / javascript
  AddOutputFilterByType DEFLATE текст / простой
  AddOutputFilterByType DEFLATE текст / xml

  # Удалить ошибки браузера (требуется только для действительно старых браузеров)
  BrowserMatch ^ Mozilla / 4 gzip-only-text / html
  BrowserMatch ^ Mozilla / 4 \. 0 [678] без gzip
  BrowserMatch \ bMSIE! No-gzip! Gzip-only-text / html
  Добавление заголовка Варьируется User-Agent
  

Вы должны добавить его после #END в файле .htaccess . Если у вас есть сайт WordPress на сервере Nginx, вам следует вместо этого добавить следующий код в файл nginx.conf :

  36 gzip on;
37 gzip_disable "MSIE [1-6] \. (?!. * SV1)";
38 gzip_vary on;
39 gzip_types текст / простой текст / текст css / приложение javascript / приложение javascript / x-javascript;  

Если вы хотите проверить сжатие текста на своем сайте, мы рекомендуем использовать такой инструмент, как GiftOfSpeed:

GiftOfSpeed ​​GZIP проверка сжатия

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

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

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

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

Если Google считает, что для вашей страницы может быть полезен этот метод, вы увидите предложение Preconnect to required origins :

Предварительное подключение к требуемому источнику, рекомендация

Есть несколько способов реализовать эту стратегию оптимизации. Если вам удобно редактировать файлы темы WordPress, вы можете добавить тег ссылки в файл header.php . Вот пример:

    

В этом случае тег сообщает браузерам, что им необходимо как можно быстрее установить соединение с example. com . Google PageSpeed ​​Insights перечислит все соответствующие ресурсы, для которых вы должны добавить теги ссылок с атрибутами предварительного подключения.

Другой вариант — использовать плагин для достижения того же эффекта. Perfmatters включает в себя функцию предварительного подключения (отказ от ответственности: я один из основателей Perfmatters). WP Rocket и Pre * Party Resource Hints включают аналогичные функции.

18. Запросы ключа предварительной загрузки

Подобно рекомендации Preconnect to required origins , следование этому предложению позволяет минимизировать количество запросов, которые браузеры должны отправлять на сервер вашего сайта. Однако вместо подключения к сторонним ресурсам Preload key requests относится к загрузке критически важных ресурсов на ваш собственный сервер:

Рекомендация по запросам ключей предварительной загрузки

Реализация этой техники также очень похожа на предыдущую рекомендацию. Вы можете добавить теги ссылок, определяющие ресурсы, перечисленные в PageSpeed ​​Insights, в свой файл header.php :

    

Вы также можете включить этот тег, используя Perfmatters, WP Rocket или Pre * Party Resource Hints.

19. Избегайте множественной переадресации страниц

Редиректы используются, когда вы хотите, чтобы один URL указывал на другой. Они обычно используются, когда вы перемещаете или удаляете страницу на своем сайте. Хотя в общем случае нет ничего плохого в использовании переадресации, они вызывают дополнительные задержки во времени загрузки.

Если на вашем сайте слишком много перенаправлений, вы можете увидеть эту рекомендацию в Google PageSpeed ​​Insights:

Избегайте переадресации нескольких страниц, рекомендация

Единственное, что вы можете сделать в ответ на эту рекомендацию, — это убедиться, что вы используете переадресацию только тогда, когда это абсолютно необходимо. Вы можете узнать больше о процессе их создания в нашей публикации « WordPress Redirect — Best Practices for Better Performance ».

20. Обслуживайте статические активы с помощью эффективной политики кэширования

Если вы какое-то время использовали Google PageSpeed ​​Insights, возможно, вам лучше известна эта рекомендация как предупреждение Leverage кэширования в браузере .В версии 5 он теперь помечен как «Обслуживать статические активы с эффективной политикой кеширования» :

Статические ресурсы сервера с рекомендациями по эффективной политике кэширования

У этого предложения есть несколько слоев, которые нам нужно проработать. Во-первых, что означает «кеширование». Короче говоря, это процесс, при котором браузеры сохраняют копии ваших страниц, чтобы их можно было быстрее загружать при будущих посещениях.

Чаще всего сайты WordPress реализуют кеширование с помощью плагинов. WP Rocket и W3 Total Cache — популярные варианты. Однако некоторые хостинг-провайдеры, в том числе мы здесь, в Kinsta, включают кэширование через свои серверы. Обязательно проверьте и посмотрите, так ли это на вашем хосте, прежде чем устанавливать плагин кеширования.

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

В идеале вы хотите, чтобы этот период времени был больше, чем меньше.Если вы очищаете свой сайт из кеша браузера каждые пару часов, это в первую очередь лишает смысла использование этого метода. Вы можете оптимизировать срок действия кэша, используя заголовки Cache-Control и Expires .

Добавление заголовков Cache-Control

Используйте следующий код для добавления заголовков Cache-Control в Nginx:

  расположение ~ * \. (Js | css | png | jpg | jpeg | gif | svg | ico) $ {
 истекает 30 дней;
 add_header Cache-Control «общедоступный, без преобразования»;
}  

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

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

  
Заголовочный набор Cache-Control "max-age = 84600, общедоступный"
  

Добавьте этот код перед #BEGIN WordPress или после #END WordPress . В этом примере период истечения срока действия кэша установлен на 84 600 секунд.

Добавление заголовков Expires

Заголовки Cache-Control сейчас в значительной степени стали стандартом. Однако есть некоторые инструменты (включая GTMetrix), которые все еще проверяют заголовки Expires .

Вы можете добавить их на сервер Nginx, включив в свой серверный блок следующее:

  расположение ~ * \.  (Jpg | jpeg | gif | png | svg) $ {
        истекает 365 дней;
    }

    расположение ~ * \. (pdf | css | html | js | swf) $ {
        истекает 2d;
    }  

Вы должны установить разное время истечения срока действия в зависимости от типа файлов.Серверы Apache дадут те же результаты, если вы добавите этот код в свой файл .htaccess :

  ## ИСКЛЮЧАЕТ КЭШЕР ЗАГОЛОВКИ ##

ExpiresActive On
ExpiresByType image / jpg «доступ на 1 год»
ExpiresByType image / jpeg "доступ на 1 год"
ExpiresByType image / gif "доступ на 1 год"
ExpiresByType image / png "доступ на 1 год"
ExpiresByType image / svg "доступ на 1 год"
ExpiresByType text / css "доступ на 1 месяц"
Приложение ExpiresByType / pdf "доступ на 1 месяц"
Приложение ExpiresByType / javascript "доступ 1 месяц"
Приложение ExpiresByType / x-javascript "доступ на 1 месяц"
Приложение ExpiresByType / x-shockwave-flash "доступ 1 месяц"
ExpiresByType изображение / значок x "доступ на 1 год"
ExpiresDefault "доступ 2 дня"

## СРОК КЭШЕНИЯ ЗАГОЛОВКИ ##  

Еще раз, вы должны добавить этот код либо перед #BEGIN WordPress , либо после #END WordPress .

Эффективное кэширование Google Analytics

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

Этот сценарий появится в списке ресурсов, требующих вашего внимания, в разделе «Обслуживать статические ресурсы с эффективной политикой кэширования» .Поскольку он принадлежит третьей стороне, вы не можете изменить срок его действия с помощью заголовков Cache-Control или Expires .

Если это единственный сценарий, указанный в этой рекомендации, вы все равно можете пройти аудит:

Пройден эффективный аудит политики кеширования

Однако, как мы отмечали в этом посте, ваша оценка PageSpeed ​​имеет меньшее значение, чем ваша фактическая и предполагаемая производительность. Чтобы эффективно обслуживать этот ресурс, вы можете рассмотреть возможность локального размещения Google Analytics.

Плагины

, такие как Complete Analytics Optimization Suite (CAOS) и Perfmatters, позволят вам сделать это. Вы можете узнать больше о процессе в нашем полном руководстве по этому предложению PageSpeed.

21. Снижение воздействия стороннего кода

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

Тем не менее, в некоторых случаях лучшим решением для потребностей вашего сайта является включение стороннего скрипта. Google Analytics — отличный тому пример. Другие включают:

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

Уменьшить влияние рекомендаций стороннего кода

Для более эффективной загрузки стороннего кода вы можете воспользоваться одним из методов, которые мы уже упоминали в этом посте:

  • Отложить загрузку JavaScript
  • Используйте теги ссылок с атрибутами preconnect
  • Сторонние скрипты с самостоятельным размещением (как мы описали выше для Google Analytics)

Эти методы должны минимизировать влияние на производительность вашего сайта.

22. Избегайте огромной сетевой полезной нагрузки

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

Избегайте огромной полезной нагрузки сети Рекомендация

Google рекомендует, чтобы общий размер байта не превышал 1600 КБ. Методы, наиболее часто используемые для достижения этой цели, можно найти в этом посте, в том числе:

  • Отложенные CSS, JavaScript и изображения в нижней части страницы
  • Минифицирующий код
  • Сжатие файлов изображений
  • Использование формата WebP для изображений
  • Реализация кэширования

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

23. Пользовательские временные метки и меры

Эта рекомендация актуальна, только если вы используете User Timing API. Этот инструмент создает временные метки, чтобы помочь вам оценить производительность вашего JavaScript. Если вы настроили API для своего сайта, вы увидите свои оценки и меры под этим заголовком в PageSpeed ​​Insights:

.

User Timing отмечает и рекомендации по измерениям

Как видите, это еще одно предложение от Google, которое не дает результатов «сдано» или «не выполнено».PageSpeed ​​Insights просто делает эту информацию легко доступной, поэтому вы можете использовать ее для оценки областей, которые могут потребовать оптимизации.

Если вы заинтересованы во внедрении User Timing API на свой сайт WordPress, вы можете узнать больше в руководстве Mozilla по этой теме.

24. Избегайте чрезмерного размера объектной модели документа (DOM)

Проще говоря, DOM — это то, как браузеры превращают HTML в объекты. Он включает использование древовидной структуры, состоящей из отдельных узлов, каждый из которых представляет объект.Естественно, чем больше размер модели DOM вашей страницы, тем дольше она загружается.

Если ваша страница превышает определенные стандарты в отношении размера DOM, будет рекомендовано уменьшить количество узлов, а также сложность вашего стиля CSS:

Избегайте чрезмерных рекомендаций по размеру DOM

Распространенным виновником, если вы «не прошли» аудит в PageSpeed ​​Insights, является ваша тема WordPress. Тяжелые темы часто добавляют в DOM большие объемы элементов, а также могут включать замысловатые стили, замедляющие работу вашего сайта.В этом случае вам может потребоваться переключить тему.

Вы пытаетесь набрать 100 из 100 баллов на #Google PageSpeed? Вот совет: не зацикливайтесь на своем счете и сосредоточьтесь на том, что действительно влияет на загрузку вашей страницы! 🚀📊Нажмите, чтобы написать твит

Сводка

Google PageSpeed ​​Insights должен быть основным продуктом в вашем наборе инструментов для веб-мастеров. Однако зацикливание на своем счете и одержимость достижением желанных 100/100, вероятно, не лучший вариант использования вашего времени. Это может отвлечь вас от других важных задач, которые могут дать более значительные преимущества.

В этом посте мы рассмотрели, каким образом ваш показатель Google PageSpeed ​​Score имеет и не имеет значения. Мы также поделились некоторыми краткими рекомендациями по использованию рекомендаций платформы на вашем сайте WordPress с целью повышения его производительности.

У вас есть вопросы о Google PageSpeed ​​Insights или оптимизации производительности вашего сайта? Спросите в разделе комментариев ниже!


Если вам понравилась эта статья, то вам понравится хостинговая платформа Kinsta WordPress.Ускорьте свой сайт и получите круглосуточную поддержку от нашей опытной команды WordPress. Наша инфраструктура на базе Google Cloud ориентирована на автоматическое масштабирование, производительность и безопасность. Позвольте нам показать вам разницу Kinsta! Ознакомьтесь с нашими тарифами

Вот почему у New York Times только 52 балла PageSpeed ​​Insights

Последнее обновление 21.10.2020

Некоторые из крупнейших и наиболее успешных сайтов WordPress по всему миру, такие как Wall Street Journal или People Magazine, очень плохо работают в PageSpeed ​​Insights от Google.И это несмотря на то, что их бизнес-модель зависит от хорошей производительности. На примере New York Times я объясню, почему вы можете пренебречь показателем оптимизации PageSpeed ​​и какие конкретные преимущества может получить ваш бизнес WP от этих знаний.

Обновление: Google изменил свой инструмент PageSpeed ​​Insights в ноябре 2018 года. С тех пор данные анализа основаны на инструменте с открытым исходным кодом Lighthouse. Новый PageSpeed ​​Insights включает в оценку еще больше факторов, поэтому многие веб-сайты демонстрируют худшие результаты в новой оценке PSI, чем раньше.Это также относится к нашему тематическому исследованию — веб-сайту WordPress NYTimes: его рейтинг PSI для настольных компьютеров теперь 46, а для мобильных устройств — 21. Более подробную информацию о новом PageSpeed ​​Insights можно найти в видео #SEODRIVEN, которое вы также можете найти в конце этой статьи.

Что общего у веб-сайтов Forbes, Time Magazine, New Yorker, Wall Street Journal, People Magazine и Harvard Business Review? Все это крупные издания с охватом в миллион долларов и соответствующими продажами в Интернете.И все они работают на WordPress!

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

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

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

Пример Financial Times также показывает, что производительность окупается. В 2016 году они проверили, как задержка времени загрузки от одной до пяти секунд влияет на поведение читателей. Результат: чем медленнее сайт, тем меньше статей читают посетители. Результат: снижение доходов от рекламы и количество выполненных подписок. Неудивительно, что оптимизация времени загрузки была главным приоритетом, когда примерно шесть месяцев спустя веб-сайт Financial Times был обновлен.

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


За исключением двух, все протестированные публикации достигли хорошей оценки мобильной оптимизации (80–100). Но с настольными компьютерами все выглядит совсем иначе: оценки PageSpeed ​​у NY Times, HBR и People Magazine «низкие», оценки WSJ, Forbes и Time Magazine только «средние», и только житель Нью-Йорка попадает в хороший район.

Что это за «плохие результаты»?

Теперь анализ использования ресурсов вашего сайта стал еще проще с нашим интегрированным сервером мониторинга.

PageSpeed-Score не имеет ничего общего со скоростью загрузки

Многие считают, что оценка (эл.грамм. 60/100) на сайте PageSpeed ​​Insight указывает скорость загрузки страницы. Название инструмента подсказывает это. Только: «PageSpeed» и «Page Speed» в этом случае не одно и то же. Показатель оптимизации, который в конечном итоге выбрасывает инструмент, не зависит от времени загрузки страницы.

Прочтите правильно: Google PageSpeed ​​Insights оценивает баллов, а не баллов за время загрузки.

Вместо этого он проверяет, реализовал ли оператор сайта определенные меры, которые считаются «передовой практикой» в оптимизации производительности.Затем выполнение этих мер оценивается по шкале от 0 до 100.

Второй миф, который не утихает: хороший показатель PageSpeed ​​улучшает ваш рейтинг в Google. Однако это не так. Да, скорость сайта влияет на рейтинг. Но оценка, которую выдает инструмент, не учитывается Google (тем более, что она все равно не коррелирует со скоростью). Поэтому, когда дело касается SEO, можно в значительной степени игнорировать оценку Google PSI.

Единый вход: войдите в свой сервер WP одним щелчком мыши прямо с панели управления RAIDBOXES.

Кроме того, время загрузки страницы не имеет отношения к ранжированию, то есть время, в течение которого сайт должен быть на полностью для загрузки. Вместо этого Google включает значение Time To First Byte (TTFB) в качестве фактора. Это время, которое проходит до тех пор, пока браузер не получит первый ответ от сервера после HTTP-запроса. Как правило, это вопрос миллисекунд.

Корреляция между TTFB и рейтингом могла быть доказана уже в 2013 году (соответствующие статьи MOZ можно найти здесь и здесь).С другой стороны, Гэри Илес — уважаемый в сообществе аналитик веб-тенденций в Google — публично объявил через Twitter, что не следует слишком беспокоиться о времени загрузки страницы. нужно.

Пример использования: оценка PageSpeed ​​Insights по версии New York Times

Давайте внимательнее посмотрим на New York Times в качестве примера. Он набрал 84 балла PageSpeed ​​Insights для мобильных устройств («хорошо») и для настольных компьютеров — 52 балла («низкий»).Что лучше PageSpeed ​​Insights для сокращения времени загрузки? Согласно Google, настольная версия могла бы выиграть от следующих мер, среди прочего:

Удалите ресурсы JavaScript и CSS, которые блокируют рендеринг в содержимом «над сгибом» (отображается без прокрутки)

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

И когда ресурсы CSS загружаются в конце, весь сайт строится полностью без дизайна — неприятный пользовательский интерфейс. Конечно, теоретически можно было бы отфильтровать CSS, необходимый для содержимого «над сгибом», и добавить его вверху, а затем загрузить остальную часть таблицы стилей внизу.Однако впоследствии это практически невозможно, эту хитрость придется учитывать при разработке. Это также требует значительных усилий для разработчика и в конечном итоге улучшает только оценку скорости страницы, но не фактическое время загрузки страницы. Так что, вероятно, лучше вложить усилия в другое место.

Использовать кеширование браузера

Сначала звучит нормально. Но если вы посмотрите на предложения о том, что еще можно кэшировать, вы найдете элементы, которые не размещены на самом сайте NY Times.Например, файлы, размещенные в Google Analytics или Facebook и включенные в NY Times для мониторинга. Нью-Йорк Таймс не имеет никакого влияния на конфигурацию кеша этих элементов — так что предложение напрасно.

Google также критикует использование сети доставки контента (CDN) — сети серверов, распределенных по всему миру, но связанных друг с другом. От этого особенно выигрывают международные пользователи. CDN в основном выгоден с точки зрения производительности, поскольку время ответа сервера значительно сокращается, а контент может доставляться намного быстрее.А с такой актуальной публикацией, как New York Times, вы можете предположить, что читатели во всем мире захотят получить доступ к контенту и не ждать долго.

Оптимизировать изображения

Большая часть изображений, которые PageSpeed ​​Insights предлагает оптимизировать, будут меньше всего на несколько килобайт из-за сжатия, в некоторых случаях только байтов. Конечно, сжатие изображений — важный фактор для оптимизации производительности. Однако при такой небольшой экономии маловероятно, что это значительно улучшит время загрузки.

Уменьшить JavaScript

Всего здесь можно сэкономить почти 72 килобайта. Еще неизвестно, имеет ли это принципиальное значение для такой огромной газеты, как New York Times.

Уменьшить HTML

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

Некоторые меры, предлагаемые инструментом, скорее всего, будут просто неэкономичными, а другие принесут только такие незначительные изменения, что их не стоит использовать.Отрезвляющий вывод состоит в том, что PageSpeed ​​Insight генерирует всевозможные предложения по улучшению. Но не все из них приводят к значительному улучшению показателей NY Times. В противном случае можно было бы предположить, что они уже внедрены — ведь производительность здесь напрямую влияет на успешность бизнес-модели.

PageSpeed ​​Insights-Score остается проблемой клиентов

В профессиональном мире полное несоответствие между оценкой PageSpeed ​​и скоростью загрузки привело к горячим спорам.В конце концов, инструмент доступен неспециалистам, которые могут не знать об этом несоответствии. Сообщения уважаемых гуру интернет-маркетинга, подобные этой, в которых говорится о том, что оценка PageSpeed ​​100, эквивалентная быстрой загрузке, вызывают дополнительную путаницу.

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

Хотя оценка PageSpeed ​​Insights может улучшиться, если вы уменьшите размеры изображений и HTML на несколько КБ. Однако для повышения производительности используются меры, которые инструмент PageSpeed ​​Insights вообще не предлагает. Оптимизация профессиональной деятельности — это, в конечном счете, больше, чем просто ориентация на одну ключевую фигуру. Об этом также свидетельствует перезапуск Financial Times: для более масштабных усилий по оптимизации обычно требуется комплексный редизайн сайта.

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

Хотите протестировать RAIDBOXES бесплатно и без обязательств?
Позвольте нам перенести ваш сайт за вас в течение двух рабочих дней!

Аргументы в пользу реальной оптимизации производительности

Неуверенность в оценке PageSpeed ​​Insights предлагает хорошую возможность, особенно для дизайнерских агентств: потому что, если вы поймете связь между скоростью загрузки и бизнесом и будете знать, как ее использовать, вы выделитесь среди конкурентов.Конкретные цифры и тематические исследования, такие как пример NY Times, помогут вам убедить существующих и потенциальных клиентов:

  • В 2006 году Amazon провела A / B-тесты, которые показали, что задержка скорости загрузки в 100 миллисекунд означает потерю дохода примерно на 1 процент в год, или, другими словами, 1,6 миллиарда долларов.
  • Исследования показывают, что за последние годы средняя продолжительность концентрации внимания пользователей снизилась с 12 до 8 секунд. Итак, как только веб-сайт загружается в течение пяти секунд, остается только три, чтобы убедить пользователя в содержании.(Достоверность этих данных обсуждается, но вы в безопасности, если предполагаете, что пользователи тратят меньше времени на ваш контент, а не больше).
  • Скорость загрузки очень важна для бизнеса, особенно для мобильных сайтов. В электронной коммерции время загрузки оказывает фундаментальное влияние на продажи: если сайт работает слишком медленно, более половины клиентов предпочитают оставлять свои деньги в другом месте. 53 процента пользователей отказываются от помощи, если сайт загружается на мобильный телефон дольше трех секунд.И за каждую секунду, когда мобильный сайт загружается дольше, оператор сайта теряет 20 процентов конверсий. И мобильный трафик нельзя игнорировать: среднее время, проведенное в Интернете через мобильные устройства, уже составляет около 87 минут, а смартфон превосходит ноутбук как самое распространенное интернет-устройство.
Как сделать заставить ваших клиентов игнорировать оценку PageSpeed ​​Insights

Так как же помочь своим клиентам получить рейтинг Google PageSpeed ​​Insightsright и придать инструменту меньшее значение? Вот краткое изложение наиболее важных аргументов:

  • Оценка PageSpeed ​​не имеет ничего общего со скоростью загрузки , но оценивает, были ли реализованы определенные меры, которые обычно рекомендуются.Не все эти меры имеют смысл. Вы можете предложить своим клиентам детально их проверить и реализовать те, которые считаете полезными.
  • Оценка PageSpeed ​​не имеет отношения к SEO. Для ранжирования включено время до первого байта (TTFB), а не полное время загрузки. Вы можете измерить это значение, например, с помощью инструмента Webpagetest tool. Как правильно анализировать реальное время загрузки страницы с помощью Webpagetest, мы объясним в нашей электронной книге.
  • Инструмент PageSpeed ​​Insights проверяет только «общедоступные» факторы. Например, инструмент не может видеть, как работает база данных (и это хорошо по соображениям безопасности). С аккуратной базой данных, простой темой, которая не отправляет слишком много HTTP-запросов на сервер и как можно меньшим количеством подключаемых модулей, время загрузки значительно увеличится. Однако эти факторы не принимаются во внимание PageSpeed ​​Insights. Так что действительно эффективные сайты WordPress по-прежнему получают плохие оценки.
  • PageSpeed ​​Insights не включает все меры по оптимизации производительности.Расскажите своим клиентам о важности хорошего хостера, который работает с HTTP / 2 и последней версией PHP. Если хостинг не работает, вы можете оптимизировать сайт сколько угодно, время загрузки принципиально не изменится.

Сосредоточиться только на счете PageSpeed ​​- все равно что взять лошадь на гонку Формулы 1. Даже если вы покрасите шубу своей лошади в красный цвет и выбрите на боку логотип Ferrari, вы не обогнаете гоночные автомобили.

Заключительные мысли

У

Forbes, Time Magazine или New York Times могут быть не самые привлекательные веб-сайты, но они являются одними из самых успешных сайтов WordPress в мире.Это связано с тем, что дизайн, функциональность и скорость работают вместе, чтобы создать гармоничный общий опыт.

Однако оценка PageSpeed ​​Insights этого не отражает. Разработчикам регулярно приходится объяснять обеспокоенным клиентам, что на их веб-сайте , а не , исчезают в глубине результатов поиска, если вердикт инструмента «плохой». Время загрузки сайта зависит от многих факторов, и многие из них не отражаются упрощенными инструментами, такими как Google PageSpeed ​​Insights.

Настоящее измерение времени зарядки никогда не должно отсутствовать!

При работе с Google PageSpeed ​​Insights по причинам, указанным выше, рекомендуется критически изучить предложения на предмет их экономической эффективности и сравнить результаты теста с другими значениями (например, с результатами Webpagetest или Pingdom).

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

В нижней строке инструмент указывает некоторые стандартные меры (сжатие изображений, использование SSL и / или HTTP / 2, настройка кеширования и т. Д.). Однако для удобства пользователей дизайн сайтов оптимизирован по времени загрузки. отображение (которое инструмент PageSpeed ​​не измеряет) и оптимизация UX имеют особое значение.

Вы когда-нибудь сталкивались с плохой оценкой PageSpeed? Или вам известно о тревожных запросах клиентов по этому поводу? Оставьте мне комментарий со своим опытом и советами.

Новый PageSpeed ​​Insights

Загружая видео, вы принимаете политику конфиденциальности YouTube.
Подробнее

Загрузка видео

Всегда разблокировать YouTube

PGlmcmFtZSBzcmM9Imh0dHBzOi8vd3d3LnlvdXR1YmUtbm9jb29raWUuY29tL2VtYmVkL3drLUJIV1h2WHN3IiBhbGxvd2Z1bGxzY3JlZW49ImFsbG93ZnVsbHNjcmVlbiIgd2lkdGg9IjU2MCIgaGVpZ2h0PSIzMTUiIGZyYW1lYm9yZGVyPSIwIj48L2lmcmFtZT4 =

Делаем шрифты Google быстрее⚡.Если вы используете Google Fonts на своем веб-сайте… | Сиа Карамалегос | Clio + Calliope

https://sia.codes/posts/making-google-fonts-faster/

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

  1. Пропустить часть времени задержки для загрузки шрифтов из Google Fonts
  2. Самостоятельно разместить шрифты для более быстрой скорости и большего контроля над FOIT и FOUT
  3. Сделайте то же, что и # 2, но быстрее с помощью классного инструмента

Google Fonts размещается в довольно быстрой и надежной сети доставки контента (CDN), так почему мы можем рассмотреть возможность размещения на нашей собственной CDN?

Давайте сделаем шаг назад и посмотрим, что происходит, когда вы запрашиваете у Google Fonts с помощью стандартного , скопированного с их веб-сайта:

Вы заметили, что ссылка предназначена для таблицы стилей, а не для файла шрифта? Если мы загрузим href ссылки в наш браузер, мы увидим, что Google Fonts загружает таблицу стилей из объявлений @ font-face для всех стилей шрифтов, которые мы запрашивали в каждом доступном наборе символов.К счастью, не все из них используются по умолчанию.

Затем каждое объявление @ font-face сообщает браузеру использовать локальную версию шрифта, если таковая имеется, перед попыткой загрузки файла с fonts.gstatic.com:

Итак, в чем проблема?

https://sia.codes/posts/making-google-fonts-faster/

Во-первых, у нас есть как минимум 2 отдельных запроса к разным хостам — сначала для таблицы стилей на fonts.googleapis.com, а затем для уникальный URL-адрес для каждого шрифта, размещенного в fonts.gstatic.com. Это делает невозможным использование мультиплексирования HTTP / 2 или подсказок ресурсов.

Вы можете спросить себя: «Почему я не могу просто использовать прямую ссылку на шрифт?» Шрифты Google обновляются часто, поэтому вы можете довольно быстро попытаться загрузить шрифт по ссылке, которая больше не существует. 🤦🏾

Вторая проблема, с которой мы сталкиваемся при использовании Google Fonts, заключается в том, что мы не можем контролировать мигание невидимого текста (FOIT) и мигание нестилизованного текста (FOUT) во время загрузки шрифтов.Установка свойства font-display в @ font-face даст нам этот элемент управления, но он определен в таблице стилей Google Fonts.

FOIT в действии — обратите внимание на отсутствующий текст навигационной панели на снимке экрана киноленты (уменьшено до замедления 3G).

Наконец, хотя это случается редко, если Google Fonts не работает, мы не получим наши шрифты. Если наш собственный CDN не работает, то, по крайней мере, мы постоянно ничего не доставляем нашим пользователям, верно? 🤷🏻️

Единственное базовое улучшение производительности, которое мы можем сделать с помощью хостинга Google Fonts, — это активизировать поиск DNS, подтверждение TCP и согласование TLS для шрифтов.gstatic.com с предварительным подключением:

Почему? Если вы не разогреете соединение, браузер будет ждать, пока он не увидит файлы шрифтов вызова CSS, прежде чем он начнет работу DNS / TCP / TLS:

Загрузка шрифтов Google без предварительного подключения

Это напрасная трата времени, потому что мы ЗНАЕМ, что нам обязательно понадобится для запроса ресурсов с fonts.gstatic.com. Добавляя предварительное подключение, мы можем выполнить DNS / TCP / TLS до того, как сокет понадобится, тем самым продвинув эту ветвь водопада:

Загрузка шрифтов Google с предварительным подключением к шрифтам.gstatic.com

Было бы еще лучше, если бы у нас был полный контроль над нашими файлами шрифтов, загрузкой и свойствами CSS. К счастью, Марио Ранфтл создал google-webfonts-helper, который помогает нам в этом! Это замечательный инструмент для предоставления нам файлов шрифтов и объявлений шрифтов на основе выбранных вами шрифтов, кодировок, стилей и поддержки браузера.

https://sia.codes/posts/making-google-fonts-faster/

Шаг 1. Используйте google-webfonts-helper, чтобы загрузить наши шрифты и предоставить базовые объявления шрифтов CSS.

Сначала выберите Google нужный шрифт с левой боковой панели.Введите в поле поиска отфильтрованный список (красная стрелка), затем щелкните свой шрифт (синяя стрелка):

Шаг 1: Выберите шрифт.

Затем выберите наборы символов и стили. Помните, что большее количество стилей означает больше для загрузки клиентом:

Выберите наборы символов и стили (вес и стиль).

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

Open Sans поддерживает намного больше наборов символов, включая кириллицу, греческий, вьетнамский и расширенные наборы.

Ваш окончательный выбор — какие браузеры вы хотите поддерживать. «Современные браузеры» предоставят вам форматы WOFF и WOFF2, а «Лучшая поддержка» также предоставит вам TTF, EOT и SVG. В нашем случае мы решили разместить только WOFF и WOFF2, выбрав системные шрифты в качестве резервных для старых браузеров. Работайте со своей командой дизайнеров, чтобы выбрать лучший вариант для вас.

Выберите «Лучшая поддержка» для всех форматов файлов или «Современные браузеры» только для WOFF и WOFF2.

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

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

https://sia.codes/posts/making-google-fonts-faster/

Шаг 2. Загрузка оптимизации

До сих пор мы переехали только туда, где мы размещаем файлы, с серверов Google на наши. Это хорошо, но недостаточно.Мы хотим, чтобы наши файлы шрифтов начали загружаться сразу, а не после анализа CSS и создания CSSOM.

Мы можем сделать это с помощью предварительной загрузки Подсказка ресурса :

Предварительная загрузка — это декларативная выборка, позволяющая заставить браузер делать запрос ресурса без блокировки события загрузки документа.

— из «Предварительная загрузка, предварительная выборка и приоритеты в Chrome» Адди Османи

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

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

В свой HTML-файл добавьте подсказки ресурсов для всех файлов шрифтов WOFF2, которые вам нужны для текущей страницы:

Давайте разберем нашу предварительную загрузку element:

  • rel = "preload" сообщает браузеру, что декларативно получить ресурс, но не «выполнить» его (наш CSS будет использовать очередь).
  • as = "font" сообщает браузеру, что он будет загружать, чтобы он мог установить соответствующий приоритет. Без него браузер установил бы низкий приоритет по умолчанию.
  • type = "font / woff2 сообщает браузеру тип файла, чтобы он загружал ресурс только в том случае, если он поддерживает этот тип файла.
  • crossorigin требуется, потому что шрифты выбираются с использованием анонимного режима CORS.

Итак Как у нас получилось? Давайте посмотрим на выступление до и после.Используя webpagetest.org в простом режиме (Moto G4, Chrome, медленный 3G), наш индекс скорости составил 4,147 с при использовании только предварительного подключения и 3,388 с при использовании собственного хостинга и предварительной загрузки. Каскады для каждого из них показывают, как мы экономим время, играя с задержкой:

Загрузка из Google с предварительным подключением к fonts.gstatic.com Самостоятельный хостинг шрифтов и использование предварительной загрузки

Шаг 3: Исправьте FOIT и FOUT (необязательно)

https: // sia.codes/posts/making-google-fonts-faster/

Разные люди по-разному относятся к FOIT (вспышка невидимого текста) и FOUT (вспышка нестилизованного текста).По большей части мы предпочитаем отображать текст как можно быстрее, даже если это означает неприятный переход к нашему предпочтительному шрифту после его загрузки. Для контента с сильным брендом вы можете не использовать FOIT, а не показывать небрендовые шрифты.

Если вас устраивает FOUT или мигание нестилизованного текста, то мы можем исправить FOIT, добавив font-display: swap; в наши объявления @ font-face .

Проверьте все варианты отображения шрифтов на этой забавной игровой площадке Glitch от Моники Динкулеску.

Так что, если вы не хотите проходить все эти шаги? Пакет subfont npm сделает это в дополнение к динамическому разделению ваших шрифтов при сборке. На настройку уходит больше времени, но попробовать стоит.

Вы поклонник Гэтсби? Для этого есть даже плагин подшрифтов.

https://sia.codes/posts/making-google-fonts-faster/

Размещение статических ресурсов в сети CDN.

Google Fonts предлагает только быструю и надежную сеть доставки контента (CDN).Вы также должны разместить свои статические ресурсы в CDN для более быстрой доставки пользователям в разных регионах. Мы используем AWS S3 plus Cloudfront, сервис CDN, предлагаемый Amazon, но существует множество вариантов.

Размер и популярные шрифты

В некоторых из моих тестов для веб-сайта нашей компании я заметил меньшие размеры файлов шрифтов для некоторых шрифтов, размещенных в Google. Моя теория заключается в том, что это связано с вариантами оптимизации Google:

Google Fonts поддерживает 30+ оптимизированных вариантов для каждого шрифта и автоматически определяет и предоставляет оптимальный вариант для каждой платформы и браузера.

— из Web Font Optimization by Ilya Grigorik

Кроме того, очень популярные шрифты, такие как Open Sans и Roboto, вероятно, будут существовать в кэше ваших пользователей. Надеюсь, в одном из будущих постов я смогу изучить данные HTTPArchive и дать вам представление о том, какие шрифты наиболее популярны.

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

Хотите увидеть весь пример кода и результаты производительности? Вот репо.

Как исправить блокировку рендеринга JavaScript и CSS в WordPress

Вы хотите избавиться от JavaScript и CSS, блокирующих рендеринг, в WordPress?

Если вы протестируете свой веб-сайт с помощью Google PageSpeed ​​insights, вы, скорее всего, увидите предложение по устранению скриптов, блокирующих отображение, и CSS. Однако он не предоставляет никаких подробностей о том, как это сделать на вашем сайте WordPress.

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

Что такое JavaScript и CSS с блокировкой рендеринга?

Блокировка рендеринга JavaScript и CSS — это файлы, которые не позволяют веб-сайту отображать веб-страницу перед загрузкой этих файлов.

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

Браузер пользователя должен будет загрузить эти сценарии и CSS перед загрузкой остальной части HTML на странице.Это означает, что пользователям с более медленным подключением придется подождать еще несколько миллисекунд, чтобы увидеть страницу.

Эти скрипты и таблицы стилей называются JavaScript и CSS, блокирующими рендеринг.

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

Что такое показатель Google PageSpeed?

Google PageSpeed ​​Insights — это инструмент для проверки скорости веб-сайтов, созданный Google, чтобы помочь владельцам веб-сайтов оптимизировать и тестировать свои веб-сайты.Этот инструмент проверяет ваш сайт на соответствие рекомендациям Google по скорости и предлагает предложения по сокращению времени загрузки страницы вашего сайта.

Показывает оценку, основанную на количестве правил, которым соответствует ваш сайт. Большинство веб-сайтов получают где-то 50-70. Тем не менее, некоторые владельцы веб-сайтов вынуждены набрать 100 баллов (максимальная оценка, которую может получить страница).

Вам действительно нужен идеальный показатель Google PageSpeed ​​«100»?

Цель Google PageSpeed ​​insights — предоставить вам рекомендации по повышению скорости и производительности вашего веб-сайта.Вы не обязаны строго соблюдать эти правила.

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

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

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

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

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

Сказав это, давайте посмотрим, что вы можете сделать, чтобы исправить блокирующие рендеринг JavaScript и CSS в WordPress.

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

1. Исправьте скрипты блокировки рендеринга и CSS с помощью WP Rocket

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

Во-первых, вам необходимо установить и активировать плагин WP Rocket.Для получения дополнительной информации см. Наше пошаговое руководство по установке плагина WordPress.

WP Rocket работает «из коробки» и включит кеширование с оптимальными настройками для вашего сайта. Вы можете узнать больше об этом в нашем полном руководстве о том, как правильно установить и настроить WP Rocket в WordPress.

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

Для этого вам необходимо посетить страницу «Настройки » »WP Rocket , а затем переключиться на вкладку« Оптимизация файлов ». Отсюда перейдите к разделу «Файлы CSS» и установите флажки рядом с параметрами «Сократить CSS», «Объединить файлы CSS» и «Оптимизировать доставку CSS».

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

Затем вам нужно перейти в раздел файлов JavaScript. Отсюда вы можете проверить все варианты для максимального повышения производительности.

Вы можете минимизировать и комбинировать файлы JavaScript, как вы это делали для CSS.

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

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

Затем прокрутите немного вниз и установите флажки рядом с параметрами «Загрузить отложенный JavaScript» и «Безопасный режим для jQuery».

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

Не забудьте нажать кнопку «Сохранить изменения», чтобы сохранить настройки.

После этого вы также можете очистить кеш в WP Rocket перед повторным тестированием своего сайта с помощью Google Page Speed ​​Insights.

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

2. Исправьте сценарии блокировки рендеринга и CSS с помощью функции автоматической оптимизации

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

Первое, что вам нужно сделать, это установить и активировать плагин Autoptimize. Для получения дополнительной информации см. Наше пошаговое руководство по установке плагина WordPress.

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

Во-первых, вам нужно установить флажок рядом с опцией «Оптимизировать код JavaScript» в блоке «Параметры JavaScript».Убедитесь, что опция «Агрегировать JS-файлы» не отмечена.

Затем прокрутите вниз до поля «Параметры CSS» и установите флажок «Оптимизировать код CSS». Убедитесь, что опция «Агрегировать CSS-файлы» не отмечена.

Теперь вы можете нажать кнопку «Сохранить изменения и очистить кеш», чтобы сохранить свои настройки.

Протестируйте свой веб-сайт с помощью инструмента Page Speed ​​Insights. На нашем демонстрационном сайте мы смогли исправить проблему с блокировкой рендеринга с помощью этих основных настроек.

Если скрипты, блокирующие рендеринг, по-прежнему существуют, вам необходимо вернуться на страницу настроек плагина и просмотреть параметры как для JavaScript, так и для CSS.

Например, вы можете разрешить плагину включать встроенный JS и удалять сценарии, которые исключены по умолчанию, например, seal.js или jquery.js.

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

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

Как это работает?

Autoptimize объединяет все поставленные в очередь JavaScript и CSS. После этого он создает миниатюрные файлы CSS и JavaScripts и передает кэшированные копии на ваш сайт как асинхронные или отложенные.

Это позволяет исправить проблему со скриптами и стилями, блокирующими рендеринг. Однако имейте в виду, что это также может повлиять на производительность или внешний вид вашего веб-сайта.

Устранение неполадок

В зависимости от того, как плагины и ваша тема WordPress используют JavaScript и CSS, может быть довольно сложно полностью исправить все проблемы JavaScript и CSS, блокирующие отображение.

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

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

Однако может быть довольно сложно определить, какой код CSS вам нужно будет отображать над содержимым сгиба.

Мы надеемся, что эта статья помогла вам узнать, как исправить JavaScript и CSS, блокирующие отображение в WordPress.

Leave a Reply