Как SEO могут извлечь выгоду из Google Lighthouse - показатели эффективности веб-сайта

1. Что такое Google Lighthouse?
2. Преобразователь игры с точки зрения измерения скорости сайта
3. Каковы ориентированные на пользователя метрики скорости веб-сайта?
4. Как пользователь воспринимает скорость сайта?
5. Как измерить восприятие пользователя
6. Ориентированные на пользователя метрики в Google Lighthouse
7. Как применить это в реальной жизни SEO
8. Полезные инструменты и постоянный мониторинг производительности
9. Резюме

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

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

Вы также можете извлечь выгоду из этой статьи, если вы абсолютно новичок в SEO - она ​​объяснит, что такое Lighthouse и как он может поддержать ваши усилия по охвату вашего потенциального клиента / аудитории.

Что такое Google Lighthouse?

Google Lighthouse является частью Chrome DevTools. Это первый сложный инструмент, предназначенный для оценки оптимизации сайта, предоставленный Google напрямую. Ранее у нас были PageSpeed ​​Insights, Mobile-Friendly Test, Инструмент тестирования структурированных данных и т. Д., Но эти инструменты были сосредоточены исключительно на одной области. Google Lighthouse выходит за рамки этого и, в основном ориентируясь на производительность, он рассматривает данную страницу с разных сторон. Для проведения множественных аудитов и обеспечения четкой оценки требуется значительное количество факторов.

Первая версия Lighthouse была выпущена в июне 2016 года. В мире SEO не было много шума, потому что пользовательский интерфейс и функции были очень ограничены. С тех пор у него было много выпусков, с двумя основными - версиями 1.5.0 и 2.5.0. На момент написания этой статьи версия 2.8.0 была последней версией.

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

Говоря об этом, вы можете получить доступ к Google Lighthouse на вкладке Audits в Chrome DevTools, из командной строки или в качестве модуля Node. Вы также можете использовать его как расширение Chrome или запустить его на WebPageTest.org ,

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

Преобразователь игры с точки зрения измерения скорости сайта

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

Теперь давайте перейдем к самой интересной части: как мы должны измерять скорость сайта?

На какие показатели мы должны смотреть? Какое значение достаточно хорошо? Является ли событие времени до первого байта (TTFB) или window.onload наиболее важным?

«Стандартный» подход заключается в измерении того, насколько быстро выполняются последующие части процесса загрузки. Для этого могут использоваться следующие метрики: TTFB, событие DOMContentLoaded, событие Onload, событие Fully Loaded и т. Д.

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

« TTFB измеряет продолжительность от браузера пользователя, выполняющего HTTP-запрос, до первого байта, возвращаемого сервером «.

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

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

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

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

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

Каковы ориентированные на пользователя метрики скорости веб-сайта?

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

Другими словами: вам нужно заботиться о среднестатистическом пользователе при оптимизации производительности вашего сайта, а не только о том, кто подключен к iPhone X и 30 Мбит / с LTE. Средний пользователь использует MotoG4 для подключения 3G. Кроме того, помимо обычного пользователя, вы должны знать, что сроки для взаимодействия с пользователем различаются в разных условиях. Скорость страницы - это не число, это набор чисел. Таким образом, гистограмма является гораздо лучшим способом представления этой информации:

Как пользователь воспринимает скорость сайта?

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

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

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

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

Согласно этой модели, производительность зависит не только от времени загрузки страницы. RAIL предоставляет конкретные временные рамки, в которые веб-сайт или веб-приложение должны реагировать на различные действия пользователя. Вся идея не в том, чтобы разорвать связь между действием и реакцией в течение всего опыта. Другими словами, RAIL направлена ​​на то, чтобы пользователи не замечали задержки на протяжении всего жизненного цикла веб-сайта или приложения (от входа на сайт до его выхода).

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

Бьюсь об заклад, вы знаете из опыта: расстраивающее отставание при прокрутке на мобильном телефоне, зависание анимации, медленно реагирующие кнопки, поля ввода видимы, но не готовы к использованию…

Тьфу, звучит как кошмар!

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

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

Как измерить восприятие пользователя

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

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

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

Есть много инструментов, которые вы можете использовать для RUM. Некоторыми примерами являются Pingdom Visitor Insights, TraceView или mPulse. RUM может использоваться для тестирования на этапе до или после развертывания, чтобы проверить, как ваши новые функции влияют на поведение пользователя. Как разработчик, вы можете использовать такие API, как PerformanceObserver , PerformanceEntry , а также DOMHighResTimeStamp проверять ориентированные на пользователя метрики на реальных устройствах.

Ориентированные на пользователя метрики в Google Lighthouse

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

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

1. First Paint - первый пиксель меняется на экране
2. First Contentful Paint - часть содержимого появляется в DOM и отображается на экране
3. Первая значимая краска - основные элементы, видимые на странице - «элементы героя»

Ниже приведен пример элементов героя на разных веб-страницах:

1. Визуально готов - страница не пропускает никаких визуальных компонентов в восприятии пользователя
2. Time to Interactive - страница может отвечать на запросы пользователей
3. Полностью загружен - страница полностью функциональна

Вы заметили огромную разницу еще? При таком подходе нам все равно, когда загружены все файлы JS и CSS. Мы также не заботимся о полной DOM и когда страница становится бездействующей. Нам важно следующее: когда пользователи видят первое визуальное изменение на странице, когда первый контент становится видимым, когда основной контент становится видимым и когда страница становится полностью интерактивной.

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

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

Как применить это в реальной жизни SEO

Хорошо, но это в основном метрики UX, что это значит для SEO?

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

Некоторые из выводов SEO, основанных на новых метриках производительности:

• Не относитесь к скорости сайта как к чему-то статичному. Одного теста недостаточно.
• Оптимизация для среднего пользователя, или диапазона пользователей, или всего распределения пользователей вашего сайта. Не оптимизируйте для лабораторных условий.
• Тестируйте мобильный и рабочий стол отдельно.
• Не говорите разработчикам объединять все файлы JS или CSS в один. Во-первых, загрузите столько JS и CSS, сколько необходимо для поддержки основных функций. Затем постепенно добавляйте последующие функции.
• Не рекомендуем откладывать загрузку JavaScript в пользу визуального контента. Пользователь не воспользуется визуально готовой страницей, если не сможет выполнить с ней основные действия. Постарайтесь, чтобы содержание и функциональность шли рука об руку.
• Не говорите разработчикам сделать все JS внешними. Небольшие части встроенного JS могут работать быстрее, чем внешние.
• Если вы используете несколько файлов JS и CSS, рекомендуем оптимизировать их порядок. Помогите браузеру определиться ( Googlebot - это браузер а также) какие файлы должны быть загружены в первую очередь.
• Рекомендуем подавать изображения в том размере, в каком они будут использоваться на странице. Они не должны быть изменены в CSS.
• Рекомендовать ленивую загрузку изображений, которые требуют взаимодействия с пользователем, чтобы стать видимыми.
• Рекомендую покрасить первый пиксель как можно быстрее. Удалите элементы, блокирующие первую краску и первую содержательную краску.
• Рекомендуем избегать длинных заданий (занимающих более 50 мс). Код должен выполняться небольшими порциями, желательно асинхронно - он оставит место для ответа на ввод пользователя.
• Рекомендовать предоставить пользователю обратную связь для действий, которые будут занимать более 500 мс.
• Не относитесь к стороннему коду как к чему-то, что нельзя оптимизировать. Удалите или замените его, если это ухудшает производительность веб-сайта и, следовательно, ваш бизнес.

Полезные инструменты и постоянный мониторинг производительности

Какие инструменты, кроме Google Lighthouse, могут помочь вам познакомиться с этим новым подходом к производительности в вашей повседневной работе?

Некоторыми инструментами тестирования, которые реализуют ориентированные на пользователя метрики (полностью или частично), являются GTmetrix и WebPageTest.

GTmetrix отображает метрики First Paint, First Contentful Paint и DOM:

Вы также можете увидеть бета-версию First Interactive метрики в стандартном отчете WebPageTest:

Похоже, это не просто каприз Google. Мы должны скорректировать наши рекомендации и поставить пользователя на первое место.

А как насчет мониторинга? Я знаю, что вы не можете запускать ревизии вручную все время. Было бы здорово настроить постоянный мониторинг, и вы можете использовать калибр или же SpeedCurve для этого.

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

Можно настроить свой профиль тестирования, например, изменив устройство и добавив несколько страниц анализа.

Что если у меня неплохо оптимизированный сайт и я не хочу его портить? Как сохранить хорошее состояние сайта?

Во-первых, вы должны поговорить с разработчиками (страшно!) И убедить их включить тестирование Google Lighthouse как часть стандартного процесса разработки. Можно настроить желаемые результаты аудита и сравнить страницу с ними. Если запланированное развертывание делает оценку ниже порогового значения, оно не идет в производство. Таким образом, вы всегда должны быть в безопасности.

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

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

Резюме

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

Не доверяйте каждому инструменту, который вы найдете в Интернете, потому что он может принести больше вреда, чем пользы. Познакомьтесь с Chrome DevTools, а также с Google Lighthouse, чтобы найти общий язык с людьми, работающими над кодом. Представляя Lighthouse 2.0, Google сказал: « Поскольку сеть продолжает развиваться, компания Lighthouse примет эти [последние и лучшие] лучшие практики ”, Что означает, что вы должны следовать этим правилам, чтобы обеспечить максимальную отдачу для своих клиентов или для себя.

Если вам интересно узнать больше о Google Lighthouse, проверьте мой обзор его нового SEO аудита ,

Похожие

Комментарии