Лицемерие google. PageSpeed Insights
Google Page Speed Insights — это сервис от гугла, который позволяет определить производительность сайта и дает рекомендации по его оптимизации. Очень важно понимать, что это всего лишь рекомендации! Некоторые воспринимают эти рекомендации настолько серьезно, что готовы реализовать все что там написано в ущерб функционалу своего сайта, что в итоге может даже навредить. Но это довольно сложная тема с множеством нюансов, а данная статься лишь мои мысли в слух и пара замечаний самому google.
Есть такая рекомендация:
Используйте современные форматы изображений:
Форматы JPEG 2000, JPEG XR и WebP обеспечивают более эффективное сжатие по сравнению с PNG или JPEG, поэтому такие изображения загружаются быстрее и потребляют меньше трафика
С этим не поспоришь, а WebP, когда я его первый раз увидел, я был потрясен. Отличное сжатие без явной потери качества. Но там же сразу можно перейти по ссылке и увидеть, какова же поддержка браузерами данного формата?
На момент написания данной статьи, это всего 80%. Вполне не плохо, но еще слишком мало чтобы использовать повсеместно. И как вы думаете что делает с этой информацией сам PageSpeed Insights? Правильно, он использует PNG:
Ну ладно, не то что сами рекомендуют, но почему бы не SVG? Нужно же подать пример, но зачем? А давайте проверим на оптимизацию сам сайт developers.google.com на котором находится данный сервис:
Мобильная версия всего лишь 51, а вы видели эту страницу? Она практически пустая, несколько меню сверху и снизу, пара новостей и поиск:
Очевидно, что они клали на эту оптимизацию, ведь оно им не надо. Они даже не попытались показать пример… Хотя может это и есть пример? Пример того, что не нужно бездумно пытаться реализовать все рекомендации в ущерб функционалу и здравому смыслу?
В общем любая оптимизация полезна, любая рекомендация имеет смысл быть, но давайте без фанатизма. Спасибо за внимание.
Разгоняем Google PageSpeed до 100 и больше
Простые и полезные советы, которые позволят вам максимально разогнать сайт без необходимости закапываться в метриках Google PageSpeed и Lighthouse.
JavaScript
Тогда первая загрузка будет быстрее, но не будет кэширования JavaScript файла.
Отложенная загрузка
Вместо кода, который предлагает ВК:
Вставляем чуть измененный код под отложенную загрузку:
В результате получаем код, который загрузится только когда экран долистает до виджета.
Код карты, который предлагает вставить Google на сайт:
Если карта находится в попапе или далеко в футере, то человек зайдя на вашу страницу, сразу же начнет подгружать очень много лишнего из этого фрейма и скорость загрузки подобной страницы будет очень низкой, Google PageSpeed вам поставит минус и большой!
Вставляем чуть измененный код под отложенную загрузку:
Все сводится к тому, чтоб не давать браузеру src=»» сразу, а только когда человеку это реально понадобится. И так со всеми объектами!
Jquery
Если вы подключение шрифта вставите в через тег
Если у вас уникальные стили для каждой страницы или вам важнее чтоб первая загрузка страницы была чуть быстрее, то вместо файла вставляем тег style:
, чтоб можно было использовать современные форматы изображений (JPEG 2000, JPEG XR и WebP). Google PageSpeed обращает на это внимание, если у вас нет ленивой загрузки изображений.
Так же можно использовать media и подставлять разные изображения под разные разрешения и разную плотность пикселей.
Подобное полезно как для картинок, так и для видео.
Выжать PageSpeed 108 или больше пунктов невозможно 🙂
Даже 100 пунктов выжимать под мобилу бессмысленно. Мы должны стремиться к 100, а не впадать в параною! Это всего лишь один из многих показателей, которые важны для сайта.
Можете посмотреть пример страницы, где показатели для мобилы 97-98 и 100 для компа.
На этой странице есть 2 ютуб видео в попапах и видео активируется только когда попап открыт.
Все фотки помещены в ленивую загрузку.
Весь JavaScript вынесен из в футер страницы.
Но при этом в подключаются: Jquery, GoogleFonts и Яндекс(Google) счетчики.
на этой странице не используется.
На странице есть целый ряд разделов, которые присутствуют на странице, но доступны только по прямой ссылке для клиентов, их нужно будет сделать подгружаемыми по необходимости, что уменьшит количество html и css кода.
Как провести аудит страницы при помощи PageSpeed Insights и ускорить ее
Пошаговый гайд по работе с бесплатным инструментом Google для вебмастеров и SEO-специалистов
В сентябре этого года Google завершил апдейт под названием Page Experience, важными составляющими которого стал комплекс сигналов Core Web Vitals. Отныне официально скорость загрузки страницы и удобство взаимодействия с ней пользователя являются сигналами ранжирования.
Узнать, насколько быстро грузится веб-страница и как ее ускорить, можно с помощью бесплатного инструмента от Google — PageSpeed Insights. Рассказываем, что он собой представляет и как с ним работать.
PageSpeed Insights: что это за инструмент и как он работает
Page Speed Insights (PSI) — бесплатный инструмент Google, который анализирует скорость загрузки веб-страницы на мобильных устройствах и компьютерах и дает рекомендации по ее ускорению.
PSI оценивает скорость загрузки на основании таких данных:
Инструмент оценивает скорость загрузки страницы по 100-бальной шкале. Оценка формируется на основании результатов, полученных по данным наблюдений за последние 28 дней. Все загрузки веб-страницы принимаются за 100%. Далее инструмент отслеживает, какой процент загрузок страницы прошел быстро, какой со средней скоростью, а какой с низкой.
Например, в отчете обязательно оценивается два показателя — первая отрисовка контента (FCP) и первая задержка ввода (FID). Данные берутся из отчета об удобстве пользования браузером Chrome.
На основании анализа этих и других результатов инструмент дает общую оценку скорости работы страницы. Вот шкала оценки:
PSI оценивает работу сайта сразу на компьютерах и мобильных устройствах и предоставляет отчеты с оценкой скорости загрузки и рекомендациями по ее ускорению отдельно для ПК и мобильных. Оба отчета содержат идентичную информацию.
Как работать с PageSpeed Insights: пошаговая инструкция
Оцениваем уровень оптимизации в баллах
Переходим на страницу инструмента PageSpeed Insights. Вводим домен сайта и кликаем «Анализировать».
Для просмотра отчета по загрузке страницы на компьютере переходим на вкладку «Для компьютеров»:
Скорость загрузки десктопной версии страницы инструмент оценил в 97 баллов. Это высокий уровень оптимизации.
Для просмотра отчета по загрузке страницы на мобильных устройствах переходим на вкладку «Для мобильных»:
Скорость загрузки мобильной версии оценена в 53 балла. Это средний уровень оптимизации, требуются мероприятия по ускорению работы страницы.
Ниже рассмотрим отчет по скорости загрузки мобильной версии страницы.
Нет времени и ресурсов на аудит и техническую оптимизацию сайта? Поможет PromoPult! В модуле SEO все работы выполняются в срок и по чек-листу. Можно доверить специалистам комплексную оптимизацию или часть работ взять на себя. В системе много бесплатных инструментов, понятные отчеты, готовые для внедрения рекомендации. Возможно продвижение в рассрочку.
Получаем скорость загрузки по данным наблюдений
Отчет PageSpeed Insights состоит из несколько блоков:
Оценка скорости загрузки по данным наблюдений отражает опыт взаимодействия со страницей пользователей через браузер Chrome. Анализ проводится по четырем метрикам. Справа можно посмотреть, как отображается страница сайта после полной загрузки.
Разберем метрики и результаты по ним.
Первая отрисовка контента (FCP) — время с момента перехода пользователя на страницу до момента отрисовки первого бита контента из DOM. Это может быть любой контент на странице: текст, картинка, иконка и т. д.
В нашем отчете были получены такие результаты по показателю FCP:
Первая задержка ввода (FID) обозначает, сколько времени прошло с момента первого взаимодействия пользователя с сайтом до момента отклика страницы. Например, пользователь кликнул по ссылке. Оценивается, сколько времени понадобилось браузеру на то, чтобы ответить на это взаимодействие.
В отчете мы получили такие результаты по FID:
Плохой показатель по FID не был зарегистрирован за последние 28 дней.
Отрисовка крупного контента (LCP) — время, которое требуется браузеру на отображение самого крупного видимого элемента на странице.
Накопительный сдвиг макета (CLS) — показатель оценивает визуальную стабильность сайта. Учитывает суммарное смещение всех элементов, происходящее вне зависимости от действий посетителя страницы.
По результатам наблюдений PSI делает выводы о том, что за последние 28 дней страница соответствует требованиям Core Web Vitals. Вот шкала соответствия:
В нашем примере при 95% случаев загрузки страницы показатель LCP был меньше 2,5 секунд, в 97% случаев FID — менее 100 мс, в 100% случаев показатель CLS меньше 0,1.
Это данные по конкретному URL. Для получения оценки по сайту в целом надо установить галочку напротив опции «Показать данные об источнике»:
После этого инструмент покажет оценку всего сайта по рассмотренным выше четырем показателям:
Оценка по всему источнику ниже, чем по рассмотренной выше веб-странице. В выводе сказано, что источник не отвечает требованиям Core Web Vitals.
Подробно о том, что отражают показатели Core Web Vitals и как достичь приемлемых параметров, читайте в статье.
Оцениваем результаты имитации загрузки страниц
PSI имитирует загрузку страниц для сбора достаточного объема данных о скорости работы страницы. При этом используется инструмент Lighthouse, поэтому и метрики для оценки производительности страницы берутся из него.
Вот какие результаты были получены в отчете по имитации загрузки страницы:
Анализ проводится по шести показателям. Четыре показателя (FCP, LCP, FID, CLS) мы уже рассмотрели выше. Поэтому расшифровывать будем только новые метрики.
Первая отрисовка контента (FCP). В отчете этот показатель составляет 2,7 секунды. Показатель средний, поэтому напротив него стоит оранжевый квадрат.
Индекс скорости загрузки (SI) отражает, сколько времени потребуется браузеру на то, чтобы отобразить весь контент на странице. В примере SI составляет 3,9 секунды. Это средний показатель, поэтому он отмечен оранжевым квадратом.
Отрисовка крупного контента (LCP) занимает 5 секунд. Это низкая скорость, поэтому напротив стоит красный треугольник.
Время загрузки для взаимодействия (TTI) — сколько времени потребуется странице для полного взаимодействия с пользователем. Страница считается интерактивной, если реагирует на действия пользователя в течение 50 мс, а на странице отображается весь контент, который измеряется с помощью показателя FCP.
В отчете TTI составило 9,5 секунды. Это означает, что страница медленно загружается для взаимодействия. Поэтому напротив этого показателя стоит красный треугольник. Быстрая загрузка занимает от 0,5 до 2 секунд.
Время блокировки ввода (TBT) — время между отрисовкой первых элементов до момента, когда можно взаимодействовать со страницей.
Считается, что если время выполнения задачи занимает более 50 мс, то она выполняется долго. Поэтому оптимальный показатель TBT составляет 50 мс. В отчете показатель TBT составляет 650 мс — и вновь красный треугольник.
Накопительный сдвиг макета (CLS) равен нулю. Это оптимальное значение, поэтому напротив стоит зеленый кружок.
Показатели производительности тестируемой страницы могут меняться. На результаты влияет множество факторов: изменения маршрутизации интернет-трафика, тестирование на разных устройствах, работа антивирусных программ и т. д.
Анализируем карту эффективности
После отчета по метрикам в PSI отображается поэтапный процесс отрисовки страницы с момента первого взаимодействия пользователя с браузером.
Для получения более подробной информации кликаем на «Открыть карту эффективности»:
В открывшемся окне отобразятся все подвязанные к веб-странице ресурсы, которые уменьшают производительность при загрузке. К таким ресурсам относятся счетчики Яндекс.Метрики, Google Analytics, Facebook и т. д.
В таблице указан размер установленного скрипта и доля использования:
Рекомендации по улучшению: внедряем или принимаем к сведению
На основании полученных результатов PSI предоставляет рекомендации. Их внедрение, по мнению Google, ускорит работу страницы. Реализовать все рекомендации в полном объеме или выбрать самые критичные — зависит от наличия у вас времени, квалифицированных специалистов в штате и особенностей CMS вашего сайта.
На страницу выведены все рекомендации по улучшению производительности. Но при необходимости можно посмотреть результаты аудита в разрезе определенных показателей — FCP, LCP, TBT, CLS:
В таблице рекомендаций слева указаны действия, которые помогут ускорить процесс загрузки сайта. Справа — сколько получится сэкономить при их внедрении.
Рекомендации поделены на несколько блоков.
1. Оптимизация. Советы направлены на повышение производительности страниц. Исправление обнаруженных проблем повышает оценку PSI по скорости загрузки. Каждая возможность обозначена определенным знаком: красный треугольник означает, что выявленная проблема приводит к сильному снижению скорости страницы; оранжевый квадрат — загрузка протекает со средней скоростью из-за обнаруженных неполадок.
В примере ниже инструмент рекомендует удалить неиспользуемый JavaScript код. Прогнозируется, что его удаление позволит сэкономить 2,29 секунды времени. Также рекомендуется устранить ресурсы, блокирующие отображение, удалить неиспользуемый код CSS, использовать современные форматы изображений и т. д.
Для просмотра более подробных рекомендаций разворачиваем список напротив выбранной проблемы. Например, посмотрим, какие проблемы обнаружил инструмент с JavaScript кодом во время аудита:
В рекомендациях указано, где надо удалить неиспользуемый код для ускорения страницы:
Или вот рекомендации по использованию современных форматов изображений. После загрузки картинок в форматах WebP и AVIF можно будет увеличить скорость страницы на 0,15 секунды.
2. Диагностика. В этом блоке перечисляются проблемы, исправление которых повысит производительность сайта. В примере инструмент рекомендует настроить показ текста во время загрузки веб-шрифтов, уменьшить влияние стороннего кода, что повысит скорость на 450 мс, сократить размер структуры DOM и т. д.
Раскроем рекомендации инструмента относительно правил эффективного использования кеша для статистических объектов. Всего найдено 156 ресурсов, в которых PSI рекомендует сократить размер структуры. Внедрение этих рекомендаций позволит быстрее загружаться странице при повторных посещениях.
3. Успешные аудиты. В этом блоке перечислен список успешно пройденных аудитов. Всего их 18. Например, настроен подходящий размер изображений, уменьшен размер кода JavaScript, включено сжатие текста и т. д.
PSI обнаружит проблемы и посоветует, как их исправить
PageSpeed Insights обнаруживает неочевидные проблемы с сайтом и подсказывает, как их исправить. Однако основная задача специалиста по SEO или вебмастера должна заключаться не в достижении оценки 90–100 баллов, а в устранении причин, снижающих производительность страницы.
Есть несколько мероприятий, которые помогут ускорить загрузку:
Как оптимизировать скорость сайта с помощью Google PageSpeed
Привет читателям Хабра!
Меня зовут Сергей Кузнецов, я руковожу отделом frontend-разработки в компании AGIMA. Сегодня мне бы хотелось поговорить про оптимизацию сайта в разрезе показателей Google PageSpeed.
Статей разной свежести и полезности много, но обычно в них даются наиболее простые и распространенные рекомендации, которые известны любому, кто хоть немного дружит с вебом. Что-то вроде: «Выносите скрипты вниз страницы» или «Минифицируйте файлы». Но что делать, когда базовые рекомендации были учтены еще на этапе разработки, а показатели все еще далеки от идеальных?
Давайте попробуем разобраться с этой проблемой. Поговорим о тех пунктах, которые описаны в рекомендациях PageSpeed Insights довольно обобщенно, например: «Минимизируйте работу в основном потоке» или «Сократите время выполнения кода». Отличные рекомендации, но только что конкретно требуется?
Ниже примеры вопросов, которые могут поставить в тупик недостаточно погруженных в тему оптимизации разработчиков.
Что делать с аналитикой или сторонними виджетами?
Что работает быстрее: секвенция или видео?
Имеет ли смысл настраивать CDN?
Нормально ли, что показатели периодически скачут, хотя вы ничего не делали?
И другие подобные моменты из практики. Конечно, мы не сможем охватить в одной статье все подобные моменты, но постараемся коснуться наиболее распространенных проблем, чуть более сложных, чем: «На страницу загрузили не сжатую картинку на 20 мегабайт» или «Забыли на сервере включить GZIP».
Еще несколько лет назад многие рекомендации не имели особого смысла кроме тех случаев, когда загрузка сайта была настолько долгой, что не требовались специальные метрики, чтобы это понять. Но в связи с последними изменениями в политике поисковой выдачи Google оптимизация приобретает бОльший вес. Поэтому давайте для начала кратко пробежимся по последним изменениям от Google PageSpeed.
Изменения в Google PageSpeed
В конце 2018 старый механизм PageSpeed заменили оценками и аналитикой Lighthouse. И этот новый инструмент также встроен в Google Chrome. Основное отличие от предыдущих версий — баллы, которые теперь присуждаются не только за выполнение рекомендаций, но и непосредственно за скорость. Загрузка страницы начала оцениваться по нескольким временным параметрам:
в какой момент времени после начала загрузки становится виден контент;
когда можно взаимодействовать со страницей — кликать или вводить данные;
насколько медленно это все грузится, и когда все операции будут завершены.
Полученные значения характеристик потом сравниваются с другими сайтами из базы, которые недавно проходили проверку, и превращаются в баллы. Именно из-за «средней температуры по палате» полученные баллы могли двигаться в ту или иную сторону с течением времени. Кроме того, возможно изменение коэффициентов в алгоритме подсчета баллов, изменение параметров «тестовых устройств», да и вообще, даже в серии замеров, которые идут подряд друг за другом, результат может отличаться на несколько баллов, хотя ничего не менялось.
Вот как написано на официальном сайте:
«На результат измерения скорости загрузки в разной степени влияет множество факторов. Основные из них — это доступность локальной сети, доступность аппаратных средств клиента и наличие конфликтов при доступе к ресурсам клиента.»
На самом деле, повлиять может все что угодно, поэтому для более релевантной оценки, рекомендуется сделать не 1 замер, а 3-5 в течение дня в разное время суток.
В 2020-ом произошло обновление движка Lighthouse 6, на базе которого работает PageSpeed Insights. В Lighthouse 6 разработчиками было добавлено несколько значительных изменений. Появились новые метрики, которые ощутимо влияют на общую оценку быстродействия страницы. Обновились аудиты для «доступности» и Javascript.
Largest ContentFul Paint (LCP) — отрисовка крупного контента. Время, за которое большая часть контента отрисовывается на экране. Желательное время до 2,5 секунд, приемлемое — до 4 секунд.
First Input Delay (FID) — задержка между первым действием пользователя и реакцией браузера. Желательное время до 100 мс, приемлемое — до 300 мс.
Cumulative Layout Shift (CLS) — совокупный сдвиг макета. Показывает оценку визуальной стабильности страницы. Нацелено на борьбу с всплывающей рекламой и блоками, которые появляются и пропадают без действий со стороны пользователя. Если изображение «скачет», то показатели падают. Нормальное значение до 0,1, допустимое — до 0,25.
И вот эти показатели из отчета входят в Core Web Vitals. А значит, метрики будут существенно влиять на ранжирование поисковой выдачи. Важное условие — как минимум 75% страниц сайта должны соответствовать нижним границам этих трёх показателей. Иначе сайт будет признан Google плохо оптимизированным. Но при этом сами показатели имеют разные веса в учете суммарной оценки, например, LCP или FID влияют на итоговую сильнее, чем CLS.
В ноябре 2020 года Google подтвердил, что Core Web Vitals станет фактором ранжирования с мая 2021 года. Рекомендации как и раньше есть, но теперь они напрямую не связаны с баллами. Совершенно не факт, что следование рекомендациям улучшит ситуацию, так как выполнение некоторых из них может ухудшить ситуацию или быть неприемлемым с точки зрения поддержки различными браузерами. Ранее частенько встречалась ситуация, когда очевидно тормозящие сайты выдавали отличные оценки, а быстрые сайты оценивались плохо. Теперь с изменением алгоритмов становятся важными именно скорость и восприятие пользователем. Все маркетинговые погремушки, которые так любят запихнуть на первый экран, теперь неизбежно будут ухудшать оценку, как ты их не отлаживай. Поэтому рекомендация на будущее: на странице, особенно на первом экране, должен быть только максимально необходимый контент, желательно с минимумом анимаций и сторонних включений.
Как улучшить производительность?
Итак, что мы можем сделать для улучшения общей картины производительности?
Широко рекомендуется использовать асинхронную загрузку. При этом следует помнить, что асинхронный и «не влияющий на скорость загрузки» — разные вещи. Да, он позволяет загружать ресурсы параллельно, не блокируя какой-то из них, но общее время все равно увеличивается. Далее, если код вы уже вынесли вниз страницы, то добавление асинхронности ничего в плане блокирования загрузки контента не изменит. Так что асинхронность не панацея, а лишь способ частично улучшить ситуацию. Намного эффективнее — это использовать как можно меньше кода в целом, например, загружать не всю библиотеку, а только те компоненты, которые вам необходимы конкретно на этой странице.
Отсюда вытекает, что билд лучше дробить на составные части, дабы в дальнейшем мы могли подключать и задействовать только те вещи, которые нужны только на этой странице, более того, даже такой код лучше разбить на 2 части. Первая — это «критические» вещи, отвечающие за каркас вашего приложения и наполнение первого экрана. Вставляем их прямо в код. Все остальное ниже, а интерактив, требующий действий пользователя, вообще в конец страницы.
Особенно часто проблемы вызывает аналитика и прочие подобные вещи подключаемые через GTM. Сам по себе GTM страницу не замедляет, замедляет то, что вы кладете в контейнер, более того, подключение тех же сценариев непосредственно в код сайта, наоборот, может ситуацию ухудшить. Вариантов действий тут не так много, например:
Можно настроить кэширование на своем сервере и обновлять по крону, но помимо банального неудобства такого решения оно может ничего и не улучшить. А вот настройка самого контейнера на загрузку сценариев по событию способно поправить ситуацию. Нас интересует, естественно, отложенная загрузка по событию. В идеале подгрузку таких вещей стоило бы отложить до полной загрузки страницы, но аналитики скорее всего будут против, так как, например, если пользователь уйдет с сайта до момента полной загрузки, они не получат вообще никакой информации. Но, как минимум, стоит ориентироваться на событие DOM Ready только для сбора наиболее критичных метрик.
Можно использовать service worker, он будет кешировать часть или всё содержимое HTML-страницы. Сервис обновляет кеш только при каких-либо изменениях на странице.
Указывайте размеры изображений и видео в тэгах, это опять полезно. Если изображения адаптивные, указывайте хотя бы пропорции (например, 16:9).
Хочется обратить внимание, что рекомендация: сводить все изображения в спрайт, сейчас скорее вредит, чем помогает. Гораздо больше пользы принесет отложенная или «ленивая загрузка» не попадающих в текущую область видимости. Помните, что «ленивую загрузку» можно применять и для видео. Недавно я подробнее рассказывал об анимации. Во-первых, для видео, которое не нужно автоматически прокручивать, используйте атрибут preload=»none». Для видео, которое используется в качестве анимаций, указывайте атрибут poster=»» и используйте код JavaScript, аналогичный примерам отложенной загрузки изображений на основе Intersection Observer.
Некоторые необязательные вещи можно вообще вынести со страницы, подтягивать их только после действий пользователя. Это также относится и к скриптам, выполняющим специфические задачи, вроде: обращения к сторонним ресурсам, перестроения графиков данных или капчи. Это позволит нам не грузить лишние строки, а также уберет пункты из показателя «неиспользуемый код».
Можно применить web-workers — специальное API-решение, позволяющее загружать JavaScript, который не связан с пользовательским интерфейсом в фоновом режиме. Можно отказаться от отрисовки тяжелого содержимого в браузере в пользу серверного рендеринга. Так вы сократите время ответа сервера. Держите проект на быстром хостинге или VPS/VDS, мониторьте потребление ресурсов, оптимизируйте базу данных, настройте кеширование. Перейдите на новую версию PHP. Версия 7.3 работает в 3-4 раза быстрее старых редакций.
Используйте протокол http/2, он позволяет быстрее и эффективнее передавать данные между браузером и сервером. В отличие от http/1 он не создает отдельные соединение для загрузки каждого файла, а загружает их параллельно. Таким образом, http/2 уменьшает нагрузку на сервер и экономит его ресурсы.
Если ваша аудитория не ограничивается одним географическим регионом, тогда настройте CDN. Распределённая сеть доставки контента снижает нагрузку на хостинг благодаря распределению файлов на несколько источников. Изображения и видео являются самым ресурсоемким контентом, поэтому можно подгружать их через CDN или перенести на поддомен.
Что касается предпочтительности той или иной анимации, то все упирается в качество изображения и продолжительность. В силу наиболее продвинутых алгоритмов сжатия, видео предпочтительнее использования секвенции. Кроме того, в самом видео предпочтительно использовать новый формат WebM, поскольку он специально разработан для потоковой передачи через интернет. WebM намного меньше по сравнению с MP4. А такие решения как гиф-анимация вообще вызывают предупреждение PageSpeed с просьбой использовать более современные форматы. Выбор же между WebGL или видео для анимаций уже сильно неоднозначен, предсказать результат заранее не получится. В целом следует исходить из соотношения веса решений к их продолжительности.
Также иногда возникает вопрос: на некоторых сайтах сперва изображения не очень четкие, а потом они прогружаются, это же ускорение работы сайта? Визуально — да, но по факту — нет. Для подобной технологии мы сперва вынуждены грузить маленькие по весу изображения, а потом асинхронно подтягивать качественные. Это не частичная загрузка большого файла «побыстрей», а дополнительная предзагрузка маленького. Для пользователя это неплохо, а вот метрики таким не улучшить.
Не забываем про шрифты, помимо использования подходящих форматов, рекомендуется использовать rel=»preload» как и для скриптов.
Также в стилях стоит указать font-display:swap; — это даст возможность использовать встроенные шрифты в ожидании загрузки основного.
Частым кейсом проблем со смещением макета, не связанным с всплывающей рекламой, являются слайдеры и плавающие сайдбары. В первом случае проблема связана с тем, что в странице создана только обертка слайдера, а все внутренности и размеры задаются уже после инициализации скрипта, что вызывает изменение размеров и пересчет координат всей страницы, поэтому не забывайте заранее указывать в стилях размеры нужного блока. А для плавающих сайдбаров вместо изменения значений с помощью скриптов лучше используйте свойство position: sticky.
Надеюсь, что статья была вам полезна, и будет круто, если вы поделитесь в комментариях примерами проблем и успешного их решения, которые я не упоминал в статье.
