В поисковой системе Google — скорость загрузки важный фактор ранжирования документов в системе сильно коррелирует с позициями сайта (следует также учесть релевантность документа интенту запроса).
Важным инструментом при проведении технической оптимизации сайтов под Google — считать 2 инструмента: «Проверка оптимизации для мобильных» и «PageSpeed Insights».
Скорость загрузки и мобильная адаптация — то, что сильно влияет на поведенческие характеристики сайта, восприятие информации.
PageSpeed Insights
С помощью Гугл пейдж спид инсайт — можно проверить, насколько хорошо оптимизирован сайт с точки зрения загрузки клиентской части.
Проверяется оптимизация, как для мобильных устройств, так и для компьютеров.
После завершения проверки Google дает основные рекомендации в отчетах:
- Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы;
- Оптимизируйте загрузку видимого контента;
- Используйте кеш браузера;
- Включите сжатие;
- Не используйте переадресацию с целевой страницы;
- Оптимизируйте изображения;
- Сократите CSS;
- Сократите HTML;
- Сократите JavaScript;
- Сократите время ответа сервера.
Рассмотрим каждый пункт отдельно чуть позже.
Проверка оптимизации для мобильных устройств
Про этот инструмент расскажем немного вскользь…
Основная цель инструмента — показать, насколько эффективно отображается сайт на мобильных устройствах. Показывает, оптимизирована страница или нет.
Если возникают «Проблемы при загрузке страницы» — можно посмотреть подробнее что не так.
Чаще всего в этом блоке присутствуют ошибки с жалобами на то, что роботу Googlebot заблокирован доступ в файле robots.txt. Если это скрипты или файлы счетчиков, систем статистики — внешние хосты, то ничего предпринимать не надо.
А если это внутренние ресурсы, влияющие на отображение, заблокированы в robots.txt — то рекомендую их открыть для индексации. Их можно увидеть в отчете «Заблокированные ресурсы», чаще всего это скрипты, стили и картинки.
Еще особенность такого второго инструмента, то, что отображаются ошибки JS в блоке «Консоль JavaScript» — их мы тоже исправляем при наличии такой возможности.
PageSpeed Insights — 100% из 100% — миф, за которым не стоит гнаться…
Это вполне реально, если убрать счетчики, скрипты социальных сетей и другие внешние неоптимизированные ресурсы. Только стоит ли оно того?
Я выгружал по крону свой скрипт, который брал внешние скрипты, сжимал и сохранял к себе на сервер. Далее подключал кэшируемые скрипты себе на сайт. Трюк работает:
Поделюсь кодом этого PHP-скрипта костыля:
<?php
function downloadJs($file_url,$save_to)
{$content=file_get_contents($file_url);
// удаляем комментарии, пробелы, пустые строки в коде:
$content=preg_replace("#(;|{|}|=|:|,|<|>|+||) *#i", "\1",$content);
$content=preg_replace("# *(;|{|}|=|:|,|<|>|+||)#i", "\1",$content);
$content=preg_replace("#++new#i", "+ +new",$content);
$content=preg_replace("#(;|{|}|t|s)//.*#i", "\1",$content);
$content = preg_replace('#(r|n)//.*#i','',$content);
$content = preg_replace("#s*?r?ns*?(?=rn|n)#i","",$content);
file_put_contents($save_to,$content);}
downloadJs('https://mc.yandex.ru/metrika/watch.js', realpath("./metrika") . '/watch.js');
downloadJs('https://mc.yandex.ru/metrika/tag.js', realpath("./metrika") . '/tag.js');
downloadJs('https://top-fwz1.mail.ru/js/code.js', realpath("./js") . '/code.js');
downloadJs('https://st.top100.ru/top100/top100.js', realpath("./top100") . '/top100.js');
downloadJs('https://www.google-analytics.com/analytics.js', realpath("./js") . '/analytics.js');
downloadJs('https://vk.com/js/api/openapi.js', realpath("./js/api") . '/openapi.js');
// Указываем URL, затем папку от корня сайта и имя файла с расширением.
// Проверьте, чтобы на папке были права на запись 777/755
?>
Кладем этот скрипт в корень сайта и настраиваем крон, к примеру, раз в 3 дня. Если будут изменения в скриптах — они учтутся в локальной копии на нашем сайте.
Такой небольшой хак — результат 99%.
Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы
Переместите все CSS-стили и JavaScript-файлы в самый низ сайта, после контента.
Оптимизируйте загрузку видимого контента
Используйте следующие методы оптимизации:
Атрибуты для подключаемых скриптов:
- onload=»async» — для первоочередных ресурсов, без которых сайт будет некорректно работать, это позволит загружать страницы асинхронно. Рекомендуется для: jquery, lazyload;
- async — для скриптов, которые могут загружаться асинхронно и не особо влияют на функционал сайта. Рекомендуется для: скриптов социальных сетей, кнопок поделиться, скриптов, не влияющих на отдельные части сайта.
- defer — применяйте для скриптов, которые должны включиться после рендеринга страниц и сильно зависимы от выше стоящих скриптов jquery, lazyload…
Функции для встроенных скриптов:
$(document).ready(function(){
Встроенный скрипт с отложенным выполнением, который выполняется тогда, когда документ загружен. Подобен атрибуту defer.
});
Используйте кеш браузера
Настроить кеширование браузером можно через корневой файл .htaccess на веб-сервере.
Expires
Более простой вариант кеширования страниц с помощью браузеров.
Пример кода:
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 60 seconds"
ExpiresByType text/html "access plus 3600 seconds"
ExpiresByType text/php "access plus 3600 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 604800 seconds"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType font/truetype "access plus 1 year"
ExpiresByType font/opentype "access plus 1 year"
ExpiresByType application/x-font-woff "access plus 1 year"
ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
ExpiresByType video/ogg "access plus 1 year"
ExpiresByType audio/ogg "access plus 1 year"
ExpiresByType audio/mp3 "access plus 1 year"
ExpiresByType video/mp4 "access p.
0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/rss+xml "access plus 3600 seconds"
ExpiresByType application/json "access plus 0 seconds"
</IfModule>Cache-Control
Метод позволяет получить больше контроля над процессом кэширования страниц браузерами. Можно совмещать с Expires.
Пример:
<filesMatch ".(ico|jpg|jpeg|png|svg|gif|swf|ogg|ogv|svgz|eot|otf|woff|mp4|ttf|rss|atom|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|js|css)$">
Header set Cache-Control "max-age=31622400, public"
</filesMatch>
<FilesMatch ".(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</FilesMatch>
<filesMatch ".(x?html?|php)$">
Header set Cache-Control "max-age=60, private, must-revalidate"
</filesMatch>Включите сжатие
Включаем gzip-сжатие — необходимо убедиться, что сервер поддерживает такую технологию.
Пример. Вначале прописываем DEFLATE:
<FilesMatch ".(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
AddOutputFilterByType DEFLATE text/html text/css text/javascript text/plain text/xml text/x-component
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml application/json application/x-javascript application/javascript application/rss+xml application/atom+xml application/vnd.ms-fontobject application/x-font-ttf
AddOutputFilterByType DEFLATE image/svg+xml font/opentype
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary
Далее, gzip:
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_update_static No
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl|xml)$
mod_gzip_item_exclude file .(jpg|png|gif)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^application/x-httpd-php
mod_gzip_item_include mime ^application/xml
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_include mime ^text/html$
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_maximum_file_size 100000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_inmem_size 100000
</IfModule>
И активируем сжатие:
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)s*,?s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
</IfModule>
</IfModule>Не используйте переадресацию с целевой страницы
К примеру, если ваш сайт перенаправляет на поддомен «m.» при использовании мобильных устройств, то такому сайту понижают баллы. А если сайт имеет несколько перенаправлений — то он не годиться для мобильных пользователей. Пример:
site.ru => www.site.ru => m.site.ruИспользуйте адаптивную верстку страниц и избегайте цепочек перенаправлений — это позволит повысить эффективность сайта в эпоху Mobile-First Indexing.
Оптимизируйте изображения
Тут важным пунктом играет вес используемых изображений — чем больше вес, тем больше загрузка страниц.
Пути и варианты решений:
- Производить автоматический ресайз картинок под отображаемые размеры изображения (обрезка до нужных пропорций);
- Автоматически сжимать изображения без их потери качества, либо оптимизировать вручную каждую картинку с помощью сервиса tinypng;
- Указывать ширину и высоту изображений с помощью атрибутов width и height;
- Обрабатывать тяжёлые фото в Photoshop — снижаем разрешение до 72 пикселей на дюйм;
- Объединить все небольшие иконки в один файл — для их вывода использовать CSS-спрайты;
- Использовать отложенную загрузку изображений, к примеру, с помощью плагина LazyLoad. Минус в том, что картинки не индексируются по этим специальным атрибутам, поэтому лучше применять для всех второстепенных графических элементов.
Внимание! При замене файлов картинок на предложенные оптимизированные от Google может снизиться качество их отображения. Поэтому лучше их файлы не использовать — применяйте вышеуказанные приемы оптимизации.
Сократите CSS
Лучшим вариантов будет просто скачать оптимизированные файлы, которые предлагает сам Google, либо получить сжатые файлы через GTMetrix. Еще как вариант: использовать приведенный мною выше скрипт — редактировать несжатый файл, а получать на выходе оптимизированный css-файл.
Сократите HTML
К примеру, для ModX Revo и написал плагин «miniHTML»:
<?php
$output = &$modx->resource->_output;
$output = preg_replace('/(t+)/', '', $output);
$output = preg_replace('/(n)(s+)/', ' ', $output);
$output = preg_replace('/(s)(?=({|}))|(?=({|}))(s)|(?=(^))(s)|(?=n)(s*)(?=(//))/', '', $output);
$output = preg_replace('/(n+)/', '
', $output);
$modx->resource->set('content', $output);
Такой метод позволяет убрать дублирующиеся пробелы, лишние переносы строк, табуляции… По факту, это замедляет процесс генерации страницы, если не включено кеширование. Решать вам — тратить ресурсы сервера на сжатие страниц программным способом или пропустить этот пункт. Выгода небольшая — 0-2%.
Сократите JavaScript
Как писалось выше можно получить готовые сжатые скрипты с помощью сервисов, а можно сжимать их php-скриптами.
Сократите время ответа сервера
Тут рекомендациями могу служить следующее:
- переход на более мощный хостинг;
- переход на последнюю версию PHP (7.*);
- обновление CMS и её компонентов, плагинов…;
- оптимизация PHP-кода.
soltyk.ru
Google объявил, что скорость загрузки страниц сайта станет фактором ранжирования в мобильном поиске, начиная с июля 2018 года. Нововведение назвали Speed Update, и оно повлияет на «небольшой процент запросов», заверили в Google. Санкции грозят только страницам, загружающимся медленно и предоставляющим негативный пользовательский опыт.
Апдейт вступит в силу в июле 2018 года, поэтому у вебмастеров есть время подготовиться. Google советует воспользоваться инструментом , а также .
Помимо этого, Google представил ответы на самые популярные вопросы, касающиеся Speed Update:
Google по-прежнему будет использовать десктопный показатель скорости для десктопного индекса?
Да, здесь все останется без изменений.
Учитывая запуск mobile-first индекса, не будет ли при ранжировании на десктопах учитываться только скорость мобильного сайта?
Нет, изменение касается только мобильного поиска.
А что насчет сайтов, получивших результат «Unavailable» в Page Speed Insights? Как им подготовиться к нововведению?
Владельцам сайтов нужно задуматься о производительности своих ресурсов. Для улучшения показателей сайтов они могут использовать любые привычные инструменты.
PageSpeed Insights использует данные из отчета о пользовательском опыте юзеров Chrome. Для сайтов, не вошедших в выборку отчета, рекомендуется использовать Lighthouse.
Можете назвать процент запросов, которые будут затронуты нововведением?
Оно коснется очень небольшого числа запросов.
Насколько сильно сайт потеряет в позициях в случае попадания по санкции?
Скорость – это один из многих факторов ранжирования. Не забывайте, что смысл – это «сильный» фактор, и медленная страница с релевантным контентом все равно может ранжироваться довольно высоко.
Будут ли какие-либо уведомления в Search console, или нововведение абсолютно алгоритмическое?
Оно алгоритмическое. Нет такого инструмента, который смог бы показать, что на страницу наложили санкции из-за низкой скорости.
Speed Update использует те же данные, что и PageSpeed Insights – опыт пользователей Google Chrome?
Google не может раскрыть эту информацию.
Что если на сайте есть AMP-адреса, но канонические URL очень медленные? Как нововведение повлияет на сайт с AMP?
Ко всем страницам сайта, вне зависимости от технологии их создания, применяется один и тот же стандарт. Конкретно в этом случае, если пользователям будет показываться AMP, учитываться будет именно ее скорость. А если скорость такой страницы окажется низкой, то она попадет под санкции, как и любая другая.
Напомним, Google о том, что скорость станет фактором ранжирования в мобильном поиске в июне 2016 года. При этом чуть позже Джон Мюллер , что повышение скорости сайта не влияет на его ранжирование в поиске.
Источник:
www.seonews.ru
Онлайн сервисы для измерения скорости загрузки сайта
Во всяком случае именно так я относился до недавних пор к тому, чтобы попытаться ускорить свой ресурс. Но мне пришло в голову, что лучше не дожидаться неприятных тенденций в статистике посещаемости своего сайта (а именно уменьшения трафика с поисковой системы Google.ru, ибо она более критично относится к скорости загрузки), а исправить очевидный недочет прямо сейчас.
Надо просто осознать, что скорость, с которой загружается ваш сайт, блог или форум, является очень важным показателем. Если у вашего проекта с этим показателем не все в порядке, то это может повлечь за собой довольно неприятные последствия. И самое важное из них то, что посетители могут отказаться от работы с вашим ресурсом, т.к. он очень долго подгружает страницы. Кроме этого поисковики, в особенности Гугл, учитывают ее при общей оценке полезности того или иного ресурса.
Для того, чтобы понять, а как быстро подгружаются страницы вашего ресурса, можно воспользоваться, например, возможностями такого расширения для браузера FireFox, как FireBug, подробно описанный в статье по приведенной ссылке. А можно воспользоваться услугами сервисов, которые предназначены для этого. Далее я приведу в качестве примера несколько таких.
- Pingdom — здесь достаточно просто указать адрес страницы, скорость загрузки которой вы хотите измерить (это не обязательно должна быть главная страница, ибо скорость загрузки внутренних страниц не менее, а зачастую даже более важна).
В результате будет представлена диаграмма времени закачки отдельных объектов вебстраницы, а также их Урл и вес. Чем меньше объектов будет загружаться и чем легче будет весить каждый из них, тем лучше. Например, я для этой цели:
- объединил некоторые картинки из темы оформления сайта в так называемые спрайты
- а также по возможности уменьшил путем объединения число подгружаемых файлов стилей (CSS) и скриптов
- кроме этого имеется смысл включить Gzip сжатие статики на сервере
- и оптимизировать все используемые на сайте картинки
Собственно, некоторые проблемы и историю измерения скорости вашего сайта вы сможете отследить на соседних вкладках верхнего меню Pingdom.
Во всплывающем окне вам предложат скопировать постоянную ссылку на проделанный тест, а также отправить его по E-mail или в Твитер. Также в нижней части окна можно подписаться на мониторинг сайта на предмет доступности. Если ваш ресурс упадет (станет недоступен для посетителей), то вам будет выслано сообщение на E-mail, либо SMS на сотовый. Но эта услуга является платной, хотя и имеется возможность бесплатного триала.
Для измерения пинга для вашего сайта, а также для просмотра Traceroute, нужно будет выбрать в самом верху страницы вкладку «Ping and Traceroute». Вводите в предлагаемую форму Урл без http, ставите галочку в чекбокс «Traceroute» или «Ping» под этой формой, и жмете «Test now».
- WebPageTest — как обычно, вводите Урл проверяемой страницы (не обязательно главной). Сервис некоторое время обсчитывает скорость загрузки всех элементов сайта, после чего выдает очень наглядную диаграмму (точнее даже две — за первый проход и за второй, когда уже часть элементов сайта загружаются из кеша браузера):
На первой диаграмме уделяете внимание положению фиолетовой вертикальной линии — это будет время окончания отрисовки сайта. Вторая вертикальная линия (синяя) будет означать время полной загрузки. Хорошо, если первая линия находится на 1-1,5 секундах загрузки сайта, а вторая — раньше 4 секунд. Тогда следующие абзацы можно прочитать «для справки». Если сайт загружается дольше 4 секунд — то нужно озабачиваться исправлением этой ситуации.
- Google PageSpeed Insights — это инструмент для разработчиков от самого Гугла. Он дает оценку скорости загрузки вашего сайта (а точнее оптимизации этой скорости) по стобальной шкале. 100 — это идеал, который недостижим, а вот 80-90 получить вполне реально, тем более, что сервис дает очень подробные рекомендации по исправлению выявленных недочетов.
Как видно из приведенного скриншота, Google PageSpeed Insights дает комплексную оценку — для компьютерного браузера и для мобильного. Кроме этого, внизу будет приведена оценка удобства пользования вашим ресурсом на различных гаджетах. Если оптимизацией сайта под мобильные устройства вы еще не озаботились, то оценка там будет очень низкая (да и на приведенном справа скрине вашего сайта в окне смартфона все будет наглядно видно).
Но самое главное то, что Google PageSpeed Insights дает рекомендации, как увеличить оценку вашего сайта, т.е. как его ускорить. Начинать нужно, естественно, с самого верха, ибо эти исправления внесут наибольший вклад в ускорение.
У меня, например, была проблема с настройкой gzip сжатия и с заданием времени кеширования статики (картинок, css файлов и скриптов) в браузерах пользователей, ибо у меня Апач работает в связке с nginx, а с ним я работать не умею. Пришлось писать в техподдержку Инфобокса с просьбой все настроить — сделали, и даже денежек не взяли (спасибо им!). Кстати, изначально они мне поставили время хранения кеша в 1 час, но Google PageSpeed Insights по-прежнему ругался:
Пришлось покопаться в инструкции к этому онлайн сервису и вычитать там, что минимум нужно ставить 1 день хранения статики в кеше. Я попросил техподдержку хостинга поставить с запасом 1 неделю, что они и сделали. Теперича оценка чуток повысилась и шибко важных претензий к моему ресурсу у Гугла в плане скорости загрузки не имеется, что есть хорошо.
- Test my Site — новый сервис опять же от Гугла. В основном он делает акцент на оценку мобильной версии вашего сайта в том числе и по критерию его скорости загрузки:
Простенько и со вкусом, что называется. Можно подписаться на рассылку изменений.
- GTmetrix — опять таки «не мудрствуя лукаво» вводите Урл нужной страницы и чуток ждете окончания анализа. В результате вы получите отчет, сформированный на основе данных двух плагинов для браузеров — Page Speed (читайте о работе с ним ниже) и YSlow. Собственно, каким данным доверять и чьим рекомендациям следовать — решать вам.
Про то, что еще хорошего есть в GTmetrix и как его использовать я уже довольно подробно писал и поэтому повторяться не буду, чтобы не загромождать и без того уже громоздкую статью (дочитаете до конца — можете считать себя героем).
- Ping Admin — аналогичный онлайн ресурс для измерения время ответа сервера с разных уголков нашей огромной планеты.
- Host Tracker — практически то же самое, только страны другие.
- ByteCheck — позволяет измерить значение TTFB (Time To First Byte) для вашего сайта, на который часто обращают внимание при оптимизации. Это время получения первого байта данных браузером с сервера. Чем выше значение TTFB, тем медленнее обработка ресурсов сервером, что есть плохо. Читайте советы по оптимизации загрузки сайтов.
- Load Impact — это не совсем про скорость, но тоже важный сервис. Он позволяет протестировать нагрузочную способность вашего сайта и то, падает ли при этом скорость загрузки страниц. Весьма полезная штука.
- Web Page Speed — онлайн-сервис с дизайном начала девяностых, но вполне себе такой информативный, если приспособитесь к отсутствию юзабилити. Внизу даются общие рекомендации по исправлению ситуации.
Так ли важно отслеживать скорость загрузки страниц?
Но вернемся от измерения скорости к поиску возможностей ее увеличения. В Гугл Вебмастере, о котором я писал тут, раньше работала экспериментальная вкладка «Эффективность сайта», где давалась оценка скорости загрузки сайта.
В общем-то ничего криминального в указанной там скорости загрузки нет, но вот то, что мой блог KtoNaNovenkogo.ru загружался медленнее, чем 84 процента всех web ресурсов в интернете — это уже звоночек, на который следовало бы отреагировать. Но раз Гугл думает, что по скорости мой блог является аутсайдером, то стоит всерьез отнестись к этой проблеме и вплотную заняться решением вопроса — как ее увеличить.
Собственно, ничего особенно придумывать и не пришлось, ибо Google сам подсказывает наиболее оптимальное решение. Точнее, он предлагает воспользоваться инструментом, который в свою очередь поможет понять, что именно нужно предпринять для того, чтобы ваш сайт немного (или много) ускорить. Я говорю об онлайн-сервисе Page Speed (раньше были еще и одноименные расширения для браузера FireFox и Хром, которыми я в основном и пользовался).
Сразу оговорюсь, что этот инструмент оперирует достаточно сложными и не совсем понятными вещами рядовым вебмастерам, которые в основном связаны с тонкостями и нюансами работы Web сервера. Если вы никогда сервер не администрировали, но будет сложно.
Есть выход — напрячь вашего хостера на тему выполнения действий, которые предписывает Пейдж Спид. Согласится или нет — это уже другой вопрос. Нанимать для этой цели фрилансера я так и не решился, ибо стремно предоставлять доступ к серваку абы кому (вот такой вот я недоверчивый).
На главной странице PageSpeed даже предлагает установить модуль на свой сервер, если он работает под управлением Apache или Nginx (как раз мой случай):
Но я так и не понял, как это делается, ибо совсем не смыслю в администрировании серверов и никогда не работал с юникс подобными системами. Это намного сложнее, чем программу установить или плагин в WordPress залить. Другой уровень погружения. Хостера тоже не решился по этому поводу напрягать. В общем, сей модуль остался мною не испытан — возможно, что вы его уже попробовали и имеет место что сказать…
Вообще, в первый раз я использовал Page Speed в качестве расширения для браузера (сейчас оно, как я понял не фунциклирует). Раньше оно интегрировалось в инструменты для разработчиков в Фаерфоксе и в Хроме. Правда, попервости (несколько лет назад) я лишь мельком посмотрел какие советы он мне дает, и практически ничего не поняв решил, что это не для меня, после чего с легкой душой удалил плагин PageSpeed как не нужный и чуждый моему разуму элемент.
Дело в том, что даже понимая на что ругается этот плагин, я толком не знал что нужно сделать, чтобы все это устранить и хоть как-то ускорить свой блог. В общем, у меня нашлось сразу очень много более важных дел, по сравнению с которыми мышиная возня с настройками Web сервера (тем более, что я в них и не разбираюсь особо) показалась мелкой и несущественной.
Правда, в свое время я тоже отложил в долгий ящик решение проблемы безопасности при работе с электронными деньгами Webmoney и в результате поплатился за это потерей всех этих самых денег. Памятуя о случившемся, на днях решил упереться рогом и попробовать сдвинуть с места проблему увеличения скорости загрузки сайта, несмотря на всю непонятность и сложность для меня данного вопроса.
Короче, установил я повторно Пейдж Спид в Мазилу (сейчас этого делать уже не надо), посмотрел на что именно он особо сильно ругается и кое-что мне все же удалось улучшить и, надеюсь, хотя бы немного увеличить скорость.
Конечно же, я решил не все те проблемы, на которые обращал мое внимание этот плагин, но кое-что все же удалось сдвинуть с мертвой точки. Пока все не забыл, спешу поделиться с вами, мои уважаемые читатели, тем, что удалось нарыть и сделать. Возможно, что вам это пригодится и скорость сайта не будет для вас узким местом, существенно затрудняющим продвижение.
Page Speed — анализ скорости и советы по ее увеличению
P.S. Сейчас Page Speed можно использовать только онлайн и устанавливать его в браузер уже не требуется (во всяком случае с новыми версиями хрома этот плагин несовместим), хотя сути это не меняет.
Итак, раньше нужно было установить в свой браузер плагин, но сейчас достаточно перейти сюда, ввести Урл адрес страницы, которую вы хотите проанализировать (на разных типах страниц могут возникать разные проблемы со скоростью загрузки, посему в этом инструменте имеет смысл проверять все варианты) и нажать на синюю кнопку «Анализировать».
Дождавшись результатов процесса проверки вы увидите окно подобное тому, что я уже приводил на скриншоте выше по тексту (в пункте 3 описаний онлайн сервисов по проверки скорости загрузки сайтов). Т.о. в результате вы увидите целый список претензий, которые этот онлайн сервис имеет к вашему ресурсу, а именно к скорости его загрузки. Пир этом он даст вам некоторые указания по оптимизации работы Web сервера в купе с используемым вами движком.
Причем, в самом верху окна Page Speed будут расположены замечания и рекомендации, которые вам желательно будет посмотреть и изменить в первую очередь («исправьте обязательно»), ибо это даст наибольший эффект в плане увеличения скорости загрузки и потребует от вас не слишком больших усилий. Приведу пример анализа одного из моих второстепенных проектов, до которых руки особо не доходят:
Т.е. рекомендации и обнаруженные проблемы, помеченные красным прямоугольником с восклицательным знаком и расположенные в самом верху списка, являются наиболее важным и начать оптимизацию желательно именно с них (дешево и сердито, что называется), тем самым добьетесь наибольшего эффекта.
Замечания, помеченные оранжевым цветом, потребуют от вас больших усилий по исправлению, но при этом могут и не привести к очень значительному росту скорости. Увы и ах, пока их можно отложить в долгий ящик и заняться первостепенными задачами, которые помогут существенно ускорить проект.
У меня первоначальная картина несколько лет назад (еще при использовании плагина — сейчас то же самое можно увидеть в http://gtmetrix.com/, ибо он испльзует АПИ PageSpeed) для https://ktonanovenkogo.ru была такой:
Я решил тогда начать с самого первого пункта «Leverage browser caching» (сейчас это называется «Используйте кеш браузера»), ибо по логике работы Page Speed, эти рекомендации должны привести к наибольшему ускорению моего блога.
Если нажать на спойлер рядом с этой надписью, то появится список различных файлов, которые не удовлетворяют оптимальным требованиям кэширования статических объектов (скрипты, CSS файлы, файлы изображений используемых на web странице) в браузерах пользователей (т.е. у читателей):
Т.е. PageSpeed Insights советует нам для увеличения скорости загрузки настроить оптимальным образом кэширование различных элементов web страниц в браузерах пользователей для того, чтобы при просмотре других эти статические элементы не подгружались бы заново с сервера. В теории все это звучит довольно запутано, ибо я понятия не имею о механизмах кэширования используемого браузерами (читайте про то, что такое кэш браузера и как его очистить).
К тому же, оптимизацию кэширования статических объектов мы будем проводить за счет механизмов самого сервера вашего хостинга. Довольно запутанно, но я вам предложу уже готовые решения, найденные на просторах рунета, а вы их попробуете в действии и решите, какое именно наилучшим образом будет работать именно на вашем хостинге.
Оптимизация кэширования в браузере и проверка его работы
Правда на моем текущем хостинге это не сработало, ибо у меня сейчас стоит связка Апача с nginx (настраивать надо последний, что за меня сделал хостер не ведомым мне способом). Но если у вас чистый Апач, то предложенный ниже метод может сработать.
В общем, мы попытаемся повлиять на сервер где хостится ваш проект таким образом, чтобы он отдавал браузерам команды направленные на оптимизацию кэширования статических элементов. Делать это будем посредством довольно известного инструмента удаленного управления сервером — файла .htaccess. Знаете о существовании такого?
Живет он обычно в корневой папке. Естественно, что все нижеописанное будет работать только на серверах под управлением Apache, но их, как правило, большинство. После подключения к своему ресурсу по FTP (FTP клиент FileZilla был описан мною тут), откройте корневую папку (обычно это либо PUBLIC_HTML, либо HTDOCS) и проверьте наличие в ней файла .htaccess.
С этого момента вы все делаете на свой страх и риск. Посему обязательно скачайте на комп копию этого файла, чтобы в случае чего оперативно откатиться назад.
Если .htaccess не видно, то попробуйте в программе FileZilla выбрать из верхнего меню пункты «Сервер» — «Принудительно отображать скрытые файлы». Если и после этого он в корне не проявился, то создайте у себя на компьютере пустой текстовый файл в любом удобном для вас редакторе (я пользуюсь Нотепад плюс плюс), назовите его как-нибудь и скопируйте в корень.
После этого переименуйте этот файл в .htaccess в программе FileZilla. Теперь нужно будет открыть его на редактирование и добавить в него приведенный ниже код. Но сначала чуток поясню.
Наиболее популярные способы включения данной опции на веб-сервере под управлением Апач — с помщью модулей mod_headers или mod_expires. Расположенный ниже код поможет помочь вам включить кеширование статики в браузере, если онлайн-сервис хотя бы один из этих модулей Апача у вас на серваке установлен.
Сначала приведу код для модуля mod_headers. Обращаю ваше внимание, что в нем используется проверка
<ifModule mod_headers.c> #кэшировать html и htm файлы на один день <FilesMatch ".(html|htm)$"> Header set Cache-Control "max-age=43200" </FilesMatch> #кэшировать css, javascript и текстовые файлы на одну неделю <FilesMatch ".(js|css|txt)$"> Header set Cache-Control "max-age=604800" </FilesMatch> #кэшировать флэш и изображения на месяц <FilesMatch ".(flv|swf|ico|gif|jpg|jpeg|png)$"> Header set Cache-Control "max-age=2592000" </FilesMatch> #отключить кэширование <FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$"> Header unset Cache-Control </FilesMatch> </IfModule>
Комментарии (их строки начинаются со знака решетки) потом можете удалить, но они по-любому на работу кода влияния оказывать не будут.
Можно будет еще добавить блок кода, рассчитанного на модуль для mod_expires, где опять же используется проверка его наличия на вашем сервере, что гарантирует безопасность использования этого фрагмента кода:
<ifModule mod_expires.c> ExpiresActive On #по умолчанию кеш в 5 секунд ExpiresDefault "access plus 5 seconds" #кэшировать флэш и изображения на месяц ExpiresByType image/x-icon "access plus 2592000 seconds" ExpiresByType image/jpeg "access plus 2592000 seconds" ExpiresByType image/png "access plus 2592000 seconds" ExpiresByType image/gif "access plus 2592000 seconds" ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds" #кэшировать css, javascript и текстовые файлы на одну неделю ExpiresByType text/css "access plus 604800 seconds" ExpiresByType text/javascript "access plus 604800 seconds" ExpiresByType application/javascript "access plus 604800 seconds" ExpiresByType application/x-javascript "access plus 604800 seconds" #кэшировать html и htm файлы на один день ExpiresByType text/html "access plus 43200 seconds" #кэшировать xml файлы на десять минут ExpiresByType application/xhtml+xml "access plus 600 seconds" </ifModule>
Комментарии опять же потом можно будет удалить.
Если вдруг не сработало, но вы надеетесь на чудо, то вот еще несколько вариантов того же самого кода, но пробуйте их по очереди, а не все сразу:
-
<IfModule mod_expires.c> ExpiresActive On ExpiresByType application/javascript "access plus 1 year" ExpiresByType text/javascript "access plus 1 year" ExpiresByType text/css "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/png "access plus 1 year" </IfModule>
-
<IfModule mod_headers.c> <FilesMatch .*.(js|css)$> Header set Cache-control: private </FilesMatch> <FilesMatch .*.(gif|jpg|png)$> Header set Cache-control: public </FilesMatch> </IfModule>
-
<IfModule mod_setenvif.c> BrowserMatch "MSIE" force-no-vary BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary </IfModule> -
FileETag MTime Size <ifmodule mod_expires.c> <filesmatch ".(jpg|jpeg|gif|png|ico|css|js)$"> ExpiresActive on ExpiresDefault "access plus 1 month" </filesmatch> </ifmodule>
Теперь после того, как вы вставили в .htaccess код, позволяющий повысить скорость за счет оптимизации кэширования в браузере на стороне посетителя, и сохранили произведенные изменения, снова проверьте страницу вашего ресурса в PageSpeed Insights и убедитесь что проблема пропала:
Как видите, в моем случае «Используйте кеш браузера» уже не является критической недоработкой замедляющей загрузку, и значок рядом с этим замечанием сменился на оранжевый, но не на зеленый. К сожалению, повлиять на сторонние сервисы, откуда мой сайт подгружает статики (типа Янедкс, Гугла, Фидбернера и Аптулайка), я не в состоянии.
Что и требовалось доказать. Вот так вот играючи мы с вами разобрались с одной из самых существенных и весомых проблем найденных в Page Speed.
ktonanovenkogo.ru
Мотивация
Сайт-образец и так загружается довольно быстро, поэтому в данном случае будут улучшаться результаты до возможного максимума.
Однажды, при работе с PageSpeed Tool, было замечено, что сайт компании Google имеет удивительно низкие показатели для мобильных устройств — 59/100. Ситуация с версией для стационарных устройств была лучше — 92/100.
Казалось бы, что они должны были использовать свой же инструмент для оптимизации своего веб-сайта, не так ли? Так неужели результат 100/100 недостижим?
Именно это послужило стимулом для достижения максимально быстрой загрузки сайта, чтобы доказать, что достичь результатов 100/100 реально, и при желании вы также сможете это сделать. Это не одержимость, это просто стремление достичь совершенства.
Стартовые показатели подопытного сайта — 87/100.
В итоге, после применения определенных манипуляций, было получено следующие результаты:
О том, как удалось достичь таких показателей, читайте далее.
Как ускорить загрузку страниц?
Прежде чем приступить к пошаговым действиям согласно инструкции, позвольте отметить, что инструмент PageSpeed является всего лишь ориентиром для веб-мастеров на пути оптимизации ресурса. К тому же инструмент содержит рекомендации по ускорению загрузки страниц вашего сайта, а достижение положительных результатов во многом зависит от настроек сервера.
Обратите внимание, на то, что некоторые из шагов инструкции могут потребовать технических знаний, независимо от используемой системы управления контентом (CMS).
Итак, приступим:
Шаг № 1: Оптимизация изображений
Чтобы изображения загружались быстрее, PageSpeed Insights Tool предложил оптимизировать их за счет уменьшения размеров файлов. Чтобы решить эту задачу, необходимо выполнить две важные вещи:
- Сжать все изображения, используя такие инструменты как Compressor.io и TinyPNG. Это бесплатные инструменты, при помощи которых можно уменьшить размер графического файла более чем на 80%, а в некоторых случаях, без ухудшения качества самого изображения.
- Уменьшить размеры изображений до минимума без понижения их качества. Например, если на сайте нам нужна картинка 150x150px, то и на сервере картинка должна быть соответствующих размеров. Параметры изображений не должны подгоняться при помощи CSS или HTML-тегов.
Согласно вышеупомянутым правилам каждое изображение на сайте было загружено, а также вручную сжато и подогнано по размерам. А чтобы не заморачиваться с оптимизацией изображений после их загрузки на сайт, лучше выработайте привычку изначально оптимизировать все новые изображения, загружаемые на сервер. Каждое новое изображение должно быть сжато и подогнано до необходимых параметров.
PageSpeed Insights предлагает опцию загрузки уже оптимизированных изображений, поэтому их можно загрузить на сервер непосредственно с данного сервиса. То же самое можно сделать и с JavaScript и CSS.
Шаг № 2: Минимизация JavaScript, CSS и HTML
В примере, Google предлагает сократить объемы JavaScript и CSS файлов.
Процесс минимизации позволяет сократить объемы файлов, устраняя ненужные пробелы, переносы, строки, символы и комментарии в JavaScript и CSS файлах. Программисты часто оставляют много места и комментарии во время кодирования, что может удвоить объем JavaScript и CSS файлов.
Чтобы устранить эту проблему, на сервере был установлен Gulpjs. Это инструмент, который автоматически создает новый файл CSS и удаляет все ненужные пробелы. Также он автоматически создает новый файл CSS каждый раз, когда вы вносите новые изменения. В приведенном примере, это помогло уменьшить размер основного файла CSS приблизительно с 300Kb до 150Kb. Такая разница в размерах обусловлена ненужными символами.
Дополнительно уменьшить размеры JavaScript и CSS можно за счет переименования переменных, при условии корректной работы селекторов и обновления HTML.
Оптимизировать JavaScript можно при помощи Closure Compiler, JSMin или YUI Compressor. Вы можете создать специальную программу, которая используя вышеперечисленные инструменты, будет переименовывать файлы и сохранять их в рабочий каталог.
Уменьшить CSS можно, используя инструменты YUI Compressor и cssmin.js.
Минимизировать HTML код можно через PageSpeed Insights. Выполните анализ страницы и выберите «Сократить HTML». Чтобы оптимизировать код кликните на «Просмотреть оптимизированное содержание».
Детальнее об оптимизации JavaScript и CSS файлов вы узнаете по ссылке: https://developers.google.com/speed/docs/insights/MinifyResources
В случае использования WordPress, рекомендуется устанавливать плагин Autoptimize.
Также можно загрузить оптимизированные файлы непосредственно из PageSpeed Tool.
Вот результаты, полученные после минимизации JavaScript и CSS:
Шаг № 3: Использование кэш браузера
Для многих веб-мастеров этап использования кэширования браузера является самым сложным.
Чтобы решить этот вопрос, пришлось перенести все статические файлы с сайта на CDN (content delivery network/сеть доставки контента).
CDN представляет собой сеть серверов, расположенных в различных местах по всему миру. Они кэшируют статические версии веб-сайтов, такие как изображения, файлы JavaScript и CSS. На серверах CDN хранятся копии содержимого сайта, а при заходе на этот сайт, статическое содержимое загружается с ближайшего сервера.
Например, если основной сервер сайта находится в Техасае, то без CDN, посетителю из Амстердама придется ждать, пока контент сайта преодолеет весь путь от сервера расположенного в США. С CDN, сайт загрузится гораздо быстрее из ближайшего к пользователю сервера, в данном случае из Амстердама. Таким образом, сокращается расстояние доступа к данным и сайт загружаться практически мгновенно.
Вот визуализация того, как работает CDN:
На подопытном сайте все изображения, файлы JavaScript и CSS были перенесены на CDN, а на главном сервере остались храниться только файлы HTML. Размещение изображений на CDN играет важную роль в том, насколько быстро будут загружаться страницы сайта для посетителей.
После вышеупомянутых манипуляций инструмент PageSpeed досадно продолжал предлагать использовать кэширование браузера для отдельных сторонних ресурсов. Вот скриншот:
Чтобы решить этот вопрос, пришлось исправить скрипты социальных сетей путем замены счетчиков, на статические изображения, размещенные на CDN. Вместо сторонних скриптов, которые пытались получать доступ к данным из Twitter, Facebook или Google Plus, для подсчета подписчиков, был установлен автономный счетчик, что и помогло решить данный вопрос.
Но более досадным было то, что вдобавок к проблемам со скриптами социальных сетей работу веб-сайта замедлял код Google Analytics.
Решения проблемы со скриптом Google Analytics довольно сложная задача. Так как Analytics был нужен, и его нельзя удалять с сайта, пришлось искать другие решения.
Google довольно редко меняет код Analytics, раз или два в год. Поэтому, Razvan создал специальный скрипт, который каждые восемь часов проверяет наличие последних обновлений кода Analytics, и при обнаружении обновлений загружает их. Таким образом, можно разместить JavaScript код Analytics на сервер, исключая необходимость загружать его с серверов Google, при каждом посещении.
В случае отсутствия обновлений, код Analytics будет загружаться из кэшированной версии на CDN.
А когда Google обновит код JavaScript, то сервер автоматически загрузит новую версию и обновит его на CDN. Этот скрипт был использован для всех внешних сторонних скриптов.
Вот скриншот из Pingdom Tools на котором показаны все загрузки из CDN, в том числе и код Google Analytics. Единственный файл загрузки с сервера, это файл домашней страницы, объем которого всего лишь 15,5Kb. Устранение всех сторонних скриптов значительно улучшило общую скорость загрузки.
Шаг № 4: Удаление блокирующих кодов
Устранение блокираторов также является довольно сложным этапом в процессе повышения скорости загрузки страниц, требующий хороших технических знаний. Основная проблема, которую пришлось решать — это ревизия всего кода JavaScript начиная сверху от «header» и «body» до расположенного внизу «footer» на всех страницах сайта.
Более детально смотрите по ссылке: https://developers.google.com/speed/docs/insights/BlockingJS#InlineJS
Если ваш сайт на платформе WordPress, плагин Autopmize, скорее всего, поможет вам решить эту задачу. Проверьте свои настройки, а затем в <head> снимите отметку с «Force JavaScript» и установите ее на «Inline all CSS».
Шаг № 5: Включение сжатия
Включить сжатие вы можете в настройках сервера. Если вы не уверенны в своих технических способностях, обратитесь за помощью в службу технической поддержки, они помогут вам включить сжатие GZIP для сервера. Дополнительные рекомендации по установке GZIP сжатия смотрите здесь: https://developers.google.com/speed/docs/insights/EnableCompression#-
Шаг № 6: Оптимизация мобильного формата
Анализ мобильного формата показывает адаптивность мобильной версии сайта под различные типы разрешения, использование подходящих шрифтов, и наличие хорошей навигационной системы.
С помощью Google Chrome вы можете посмотреть, как ваш сайт выглядит в различных мобильных версиях. Для этого нажмите на иконку меню (гамбургер) настроек и управления браузером в верхнем правом углу, а затем выберите «Дополнительные инструменты → Инструменты разработчика». На панели инструментов выберите иконку с изображением мобильных устройств. Вот и все, смотрите:
В случае примера, не потребовалось каких-либо радикальных изменений.
uaweb.ua
Chrome User Experience Report
Как уже было сказано выше, это отчёт, содержащий набор метрик. В статье я рассмотрю основные из них, которые стоит учитывать при работе над улучшением скорости загрузки сайта, а именно:
- First Paint и First Contentful Paint.
- First Meaningful Paint (FMP) и Hero Element Timing.
- Time to Interactive.
- Long Tasks.
Эти метрики показывают этапы загрузки сайта (кроме Long Tasks). Нужны, чтобы лучше понимать, как загружается страница. Этапы выглядят так:
Про остальные метрики вы можете прочитать на сайте Google – «Chrome User Experience Report». Учтите, что материал на английском.
Теперь перейдём к первому ключевому этапу загрузки страницы.
First Paint и First Contentful Paint
First Paint (FP) – это время до начала прорисовки и появления контента. Первый ключевой момент, на который следует обращать внимание.
First Contentful Paint (FCP) – показывает время, когда браузер начал отображать любой текст, изображения (включая фоновые). Это первые элементы, которые пользователь увидит на странице.
Эти метрики показывают, сколько времени пройдёт до момента, когда пользователь увидит, что страница начинает загружаться. Почему это важный показатель: если пользователь будет видеть просто белый экран, он может решить, что страница не загружается и сайт не отвечает.
Для отслеживания FP / FCP понадобится аккаунт в Google Analytics. Используя данные Google Analytics, нужно добавить в код сайта следующее:
<head> <!-- Add the async Google Analytics snippet first. --> <script> window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date; ga('create', 'UA-XXXXX-Y', 'auto'); ga('send', 'pageview'); </script> <script async src='https://www.google-analytics.com/analytics.js'></script> <!-- Register the PerformanceObserver to track paint timing. --> <script> const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { // `name` will be either 'first-paint' or 'first-contentful-paint'. const metricName = entry.name; const time = Math.round(entry.startTime + entry.duration); ga('send', 'event', { eventCategory: 'Performance Metrics', eventAction: metricName, eventValue: time, nonInteraction: true, }); } }); observer.observe({entryTypes: ['paint']}); </script> <!-- Include any stylesheets after creating the PerformanceObserver. --> <link rel="stylesheet" href="..."> </head>
Таким образом вы сможете отслеживать скорость загрузки FP и FCP.
Для оптимизации FP/FCP попробуйте уменьшить время до отображения первого контента, удалив из <head> документа любые скрипты или стили, которые могут препятствовать отображению. Выберите минимальный набор стилей <head>, чтобы пользователь видел, что сайт начал загружаться.
First Meaningful Paint (FMP) и Hero Element Timing
First Meaningful Paint (FMP) и Hero Element Timing – это время загрузки наиболее важной части страницы.
Элемент, который должен грузиться в первую очередь, ещё называют «hero element». Чтобы понимать, что на странице должно быть «hero element», ответьте себе на вопрос «Полезна ли эта часть?». Само понятие «полезности» весьма специфично, но определить элемент легко – это наиболее полезная пользователю область страницы. Она и должна грузиться в первую очередь. Пример таких областей:
В YouTube основной «hero elements» – видео – будет наиболее важной частью страницы. В Twitter, вероятнее всего, это будут значки уведомлений и первый твит. В приложении для прогноза погоды – область с прогнозом погоды. На новостном сайте – вероятнее, область с основным сюжетом и картинкой анонса.
На страницах практически всегда есть части, приоритетнее остальных. Важно, чтобы они грузились в первую очередь, таким образом, пользователь может и не заметить, что остальная часть страницы ещё не прогрузилась, но уже получит ответ на свой запрос.
Отслеживать FMP и «hero elements» сложно, так как нет стандарта для определения FMP. Учитывая, что все страницы Вашего сайта могут быть разными, то и «hero elements» на них могут отличаться. Лучше всего смотреть в контексте одной страницы. Тогда FMP будет моментом, когда «hero elements» лучше всего видны на экране.
Как определить эту метрику, Google рекомендует прочесть в статье Стива Сандерса: «User Timing and Custom Metrics». Материал на английском, но если он Вас заинтересует, пишите в комментариях – мы сделаем перевод этой статьи.
Для оптимизации FMP выберите наиболее важные элементы страницы и убедитесь, что исходная загрузка скрипта содержит только тот код, который необходим для отображения «hero elements». Любой код, не связанный с вашим «hero elements», но содержащийся в исходном JavaScript, замедлит время загрузки. Не нужно принуждать пользователя ждать, а его устройство – анализировать код JavaScript, который ему сразу не нужен.
Time to Interactive
Time to Interactive (TTI) – время загрузки элементов взаимодействия, которые будут надёжно реагировать на действия пользователя.
Также очень важная метрика. Позволяет понять, как быстро пользователь сможет взаимодействовать с сайтом. Представьте, что вы вводите запрос в Google на телефоне, нажимаете «поиск», но ничего не происходит, а загрузка началась только после 6 нажатия на кнопку «поиск». Время, которое прошло, чтобы кнопка среагировала на нажатие, и будет TTI.
Отслеживать TTI нам снова поможет Google Analytics. В этот раз используем следующий код:
import ttiPolyfill from './path/to/tti-polyfill.js'; ttiPolyfill.getFirstConsistentlyInteractive().then((tti) => { ga('send', 'event', { eventCategory: 'Performance Metrics', eventAction: 'TTI', eventValue: tti, nonInteraction: true, }); });
Подробная инструкция по его установке и использованию – «Time to Interactive Polyfill».
Оптимизация TTI похожа на оптимизацию FMP. Вам нужно выбрать приоритетный элемент страницы и убедиться, что в исходной загрузке скрипта нет ничего лишнего, он содержит только тот код, который нужен, чтобы загружаемые элементы становились интерактивными. Любой другой код будет замедлять скорость загрузки элементов взаимодействия.
Long Tasks
Long Tasks – это задачи (скрипты), на выполнение которых уходит более 50 миллисекунд. Исходя из рекомендаций RAIL, они воспринимаются как долгие.
Нужно стараться упрощать Long Tasks. Так как скрипты грузятся поочерёдно, в случаях, когда выполнение одного скрипта занимает много времени, он блокирует загрузку других скриптов в очереди. Пользователь может принять это за лаг, что портит впечатление о сайте.
Для отслеживания Long Tasks нужно создать новый PerformanceObserver:
const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { ga('send', 'event', { eventCategory: 'Performance Metrics', eventAction: 'longtask', eventValue: Math.round(entry.startTime + entry.duration), eventLabel: JSON.stringify(entry.attribution), }); } }); observer.observe({entryTypes: ['longtask']});
Чтобы сократить Long Tasks, нужно разделить большой скрипт на несколько маленьких и определить, какой скрипт должен загружаться в первую очередь. Таким образом, вы не только сократите Long Tasks, но и ускорите загрузку интерактивных элементов страниц.
Рекомендую к ознакомлению руководство на английском языке: «User-centric Performance Metrics».
Также есть видео на английском:
Теперь, зная основные метрики, на которые нужно обращать внимание при работе над скоростью загрузки сайта, рассмотрим, какие сервисы Google рекомендует для их определения.
Сервис Google Developers PageSpeed Insights
Сервис PageSpeed Insights довольно популярный у SEO-специалистов и веб-мастеров. Я уже писал о нём в статье: «Как провести анализ сайтов конкурентов? 7 видов анализа». С момента её написания прошло немного больше месяца, но сервис решили обновить перед выходом «Speed Update». Несколько недель назад в него добавили новый отчёт, который показывает общие данные о скорости загрузки всех страниц.
Для получения данных в поле ввода нужно ввести следующую конструкцию:
origin:https://www.site.ru/
Рассмотрим на примере сайта группы «Metallica»: https://www.metallica.com/.
Так выглядит обычный отчёт после проверки сайта в PageSpeed Insights.
Теперь используем новую конструкцию:
На втором скриншоте мы видим сводный отчёт. Кроме того, в обоих отчётах данные о событиях первой отрисовки контента – это метрика FCP.
Несмотря на то, что Google рекомендует этот сервис для оценки производительности страниц, стоить помнить, что PageSpeed Insights показывает базовую информацию вроде: «Оптимизировать изображения» или «Использовать кеш браузера». Для более детального отчёта лучше использовать сервис Lighthouse.
Lighthouse
Lighthouse – это автоматизированный сервис с открытым исходным кодом, который используется для проверки и анализа страниц. Рассмотрим, как его использовать.
Этот сервис, как и PageSpeed Insights, показывает информацию о загрузке страницы, но использует для своих отчётов большее метрик.
Для его использования потребуется браузер Chrome и плагин Lighthouse. После установки плагина открываем интересующий сайт, нажимаем на иконку маяка около адресной строки и на Generate report.
Так как проверяется больше метрик, анализ займёт больше времени, чем в случае с PageSpeed Insights.
В результате получаем несколько отчётов:
- Performance.
- Progressive Web App.
- Accessibility.
- Best Practices.
- SEO.
Каждый из этих отчётов содержит информацию о том, что на сайте сделано хорошо, а что нужно исправить.
Например, отчёт о производительности (Performance) содержит данные об интересующих нас метриках: FCP, TTI, FMP.
Основным минусом этого сервиса может быть английский язык – все отчёты на английском. Он бесплатный, так что рекомендую как минимум попробовать.
Если хотите испытать сервис без установки, можно протестировать онлайн-версию на сайте WebPagetest.
Отчёт в нём выглядит так:
Мне удобнее проводить анализ через плагин, не нужно ждать очереди на проверку в WebPagetest.
И ещё один сервис анализа Google, но уже от меня.
Compare your mobile site speed
Сервис Compare your mobile site speed позволяет сделать сравнение скорости загрузки нескольких мобильных версий сайтов (ограничение в 10 доменов). Вот так это выглядит на практике:
Сервис позволяет указать регион и тип сети: 3G или 4G. Подойдёт для быстрого базового анализа вашего сайта и сайтов конкурентов.
Вывод
Обновление «Speed Update» только вступило в силу. Если нужно улучшить скорость загрузки сайта, важно учесть, что сейчас недостаточно оценивать этот показатель одной цифрой. Нужно смотреть, что загружается у пользователя в первую очередь, анализировать разные метрики:
- First Paint.
- First Contentful Paint.
- First Meaningful Paint.
- Long Tasks.
- Time to Interactive.
Для базового анализа мобильной версии сайта можно использовать Google PageSpeed Insights, но мне больше понравился плагин Lighthouse – в нём больше полезной информации. Если хотите сделать сравнительный анализ нескольких сайтов, можете использовать Compare your mobile site speed – сервис простой, но полезный.
siteclinic.ru