Почему Page Speed ​​⌚️ имеет значение в SEO и что с этим делать

1. Шаг 1: Определите, стоит ли стремиться к скорости в вашей стратегии поиска
2. Что нужно посмотреть, чтобы определить возможность?
3. Шаг 2: Получите UX, Development и Execs на борту
4. Шаг 3: Начните с небольших изменений, которые не должны влиять на UX
5. Сокращение вашего кода (и разметки HTML)
6. Сжатие текстовых активов
7. Убедите вашу команду UX, что системные шрифты - это новый черный цвет
8. Используйте CDN
9. Шаг 4: Предоставьте лучшие практики и инфраструктуру для продвижения вперед
10. Кэшировать статические ресурсы
11. Ресурс намека и пре-вечеринка
12. Активировать HTTP / 2
13. Сократите CSS, JavaScript и HTML
14. Шаг 5: Определите любые дополнительные возможности для улучшения болевых точек, не отвлекаясь от UX
15. Переориторизация, консолидация и рефакторинг кода
16. Рассмотрим условно обслуживающий код
17. Шаг 6: Рассмотрим современные технологии (в том числе: PWA и AMP)
18. Рассмотрите возможность использования ускоренных мобильных страниц (AMP)
19. TL; DR

Алиса: Как долго это навсегда?

Белый Кролик: Иногда только одна секунда.

- Льюис Кэрролл, Приключения Алисы в Стране Чудес

(и любой, кто когда-либо ждал загрузки страницы более одной секунды ಥ_ಥ)

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

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

При разработке рекомендаций по задержке сайта для SEO, это может быть война двух фронтов с UX и командой веб-разработчиков. Всем нужен более быстрый сайт, но команда UX может не захотеть отказываться от своих причудливых шрифтов и загруженных библиотек. Плюс, у команды разработчиков уже есть список; действительно, исключительно длинный свиток, продолжающийся как минимум два года. У них также есть жизни вне работы (или, по крайней мере, Dungeons and Dragons в 7 вечера по четвергам). Кроме того, есть вероятность, что команда разработчиков уже хорошо осведомлена о производительности в сети. Но что делать, если их босс говорит им оживить пылающие огненные шары (для pizzazz… очевидно 😉)?

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

Эти сталкивающиеся элементы обеспечивают вызов; Тем не менее, второй побрился от загрузки страницы, оказалось, более чем стоит потраченных усилий особенно если это означает, что ваш сайт на 20% быстрее, чем конкурентный набор. Преимущества для SEO и пользовательский опыт предлагают большой потенциал. Ниже приведен один из подходов.

Шаг 1: Определите, стоит ли стремиться к скорости в вашей стратегии поиска

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

Начните с:

1. Используйте инструменты для сканирования, такие как Кричащая лягушка , Oncrawl , или же Botify для определения базового времени отклика в масштабе ( примечание : эти метрики представляют собой только время, необходимое для выдачи HTTP-запроса и получения полного HTTP-ответа с сервера без загрузки всех ресурсов, что означает, что здесь уместно <500 мс (½ с)) ,

1. Пробежать несколько страниц WebPageTest.org , Инструмент Google PageSpeed ​​Insights , а также GTmetrix чтобы:
   • Определите, есть ли и где есть какие-либо возможности для повышения производительности
   • Понять, где возникают основные узкие места

Что нужно посмотреть, чтобы определить возможность?

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

1. Илья Григорик предлагает что если страницы загружаются с временем загрузки менее 3 мс (классифицируется как «Меньшая ощутимая задержка» ), то у вас может быть сайт с хорошей производительностью (или хотя бы один, который не повлияет на ваш SEO). Но опять же, это 0,3 секунды, и самый популярный сайт, который загружается менее чем за секунду, - это жемчужина.

1. Виталий Фридман выделяет метрики и базовые цели в своем Контрольный список производительности переднего плана

• Первая значимая краска <1 с (жизненно важный этап в процессе загрузки)
• Индекс скорости <1250
• Время до Интерактивности <5 с на медленном 3G
• Для повторных посещений, Время до Интерактивности <2 с

1. Densy заявляет что «для того, чтобы пользователи едва могли видеть разницу во времени, ее необходимо изменить как минимум на 20%». Это означает, что пользователи заметят разницу в конкуренции, сайт должен быть на 20% быстрее конкурентов. ,
2. Google также предлагает мобильная карта показателей скорости это обрисовывает в общих чертах потенциальное влияние дохода на повышение скорости сайта.

Шаг 2: Получите UX, Development и Execs на борту

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

Помогите UX и разработчикам в политической битве за веб-производительность, сделав вступительный взнос ответственным за принятие решений. Создайте убедительное экономическое обоснование с соответствующими данными. Подумайте: производительность латентности сайта, конкурентная латентность, оценка воздействия на KPI и соответствующие тематические исследования (например, Тест Файнэншл Таймс , Блог исследований Google , Блог Mozilla , Walmart , Амазонка 100 мс увеличение , Продажи Amazon составили 1,6 миллиарда долларов , и т.п. ).

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

Шаг 3: Начните с небольших изменений, которые не должны влиять на UX

Остерегайтесь небольших расходов. Небольшая утечка потопит большой корабль »- Бенджамин Франклин

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

Сокращение вашего кода (и разметки HTML)

Самый быстрый и оптимизированный ресурс - это ресурс, который не был отправлен ». Google

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

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

Сделайте оценку JavaScript, CSS, HTML и ресурсы (изображения, видео и т. Д.) Стандартом и привычкой. Пер Илья , «Будьте бдительны в отношении аудита и удаления ненужных ресурсов». Следующие отчеты DevTool полезны для выявления избыточного контента.

Отчет об охвате DevTool

Панель элементов DevTool - при наведении курсора на ресурсы изображения вы можете видеть пиксели дисплея (обратите внимание на «0 x 0 пикселей», которые не используются ни в одной части страницы).

Инструменты :

Сжатие текстовых активов

GZIP - это популярный формат сжатия текстовых ресурсов (например, JavaScript, HTML, CSS).

WebPageTest.org Отчет «Обзор эффективности»:

Проверьте сжатие GZIP (хорошая проверка работоспособности) для HTML страницы:

Brotli Это новый альтернативный формат данных без потерь, набирающий популярность, который теперь поддерживается практически во всех основных браузерах (кроме IE).

Поддержка Brotli :

Узнайте больше :

Инструменты:

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

Чтобы определить цепочки и петли перенаправления, проверьте Screaming Frog's Цепочки перенаправления отчет, который отображает несколько перенаправлений.

Представления водопада WebPageTest.org (в разделе «Подробности») также идентифицируют 301 переадресацию (в скобках), так что вы можете легко определить, сколько времени было потрачено.

Убедите вашу команду UX, что системные шрифты - это новый черный цвет

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

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

Узнайте больше : Документация по оптимизации веб-шрифтов

Используйте CDN

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

Визуализация того, как CDN позволяют брендам стать ближе к пользователям:

Источник изображения: http://www.blog.marstechs.com/cdn/

Шаг 4: Предоставьте лучшие практики и инфраструктуру для продвижения вперед

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

Техническая оптимизация изображений должна быть автоматизирована, и команда должна инвестировать в инфраструктуру инструментов, которые могут гарантировать, что изображения всегда оптимизированы. Существует множество посредников, включая CDN (например, Akamai ) и третьих лиц (например, Cloudinary , Imgix ), которые предлагают автоматизированные решения по оптимизации изображений. В качестве альтернативы веб-мастера могут использовать исполнителей задач (например, хрюкать ) с инструментами сжатия изображений (например, Trimage , ImageAlpha , Оптимизатор файлов и только для Mac ImageOptim ) в сочетании с автоматизацией оптимизации изображений.

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

• Обеспечение оптимального формата файла
• Доставка масштабированных изображений
• Использование атрибута srcset тега <img> (опционально с тегом <picture>)
• Удаление любых ненужных запросов изображения
• Кэширование изображений с большей продолжительностью жизни
• Ленивая загрузка изображений ниже сгиба (ненужно для роботов поисковой системы, чтобы видеть)
• Использование подсказок по ресурсам (особенно предварительная загрузка и предварительная загрузка) для важных изображений на будущих страницах

Узнайте больше :

Кэшировать статические ресурсы

Кэши хранят вещи в течение определенного периода времени, поощряя клиента хранить локальную копию, улучшая производительность сети. Думайте об этом как о запоминании наиболее важных ресурсов и предоставлении их по запросу. Для любого ресурса, совместимого с более длительными периодами времени (например, логотип), организация и консолидация настроек кэша поможет ускорить загрузку вашей страницы. Используйте заголовок Cache-Control, чтобы указать время жизни ресурса вместе с проверочным тегом ( Last-Modified или E-tag ).

Google Documentation Visual от Ильи Григорика Подробно о кэшировании заголовков:

Источник изображения: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

Узнайте больше :

Ресурс намека и пре-вечеринка

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

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

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

DNS Разрешение имен хостов заранее, чтобы избежать задержки DNS <link rel = "dns-prefetch" href = "// www.example.com" /> Предварительно подключиться к TCP-серверу назначения заранее, чтобы избежать задержки TCP-квитирования <link rel = "preconnect" href = "// example.com"> Предварительная выборка ресурсов Предварительно выбирайте критические ресурсы на странице, чтобы ускорить рендеринг страницы <link rel = "prefetch" href = "image. png "/> Prerender Page Извлекает всю страницу со всеми ее ресурсами заблаговременно, чтобы включить мгновенную навигацию при запуске пользователем <link rel =" prerender "href =" // example.com "/> Предварительная загрузка (директива) Извлечение ресурса и кешировать указанный ресурс

(Примечание: директива вместо подсказки)

Примечание: заголовок используется для push в HTTP / 2.

<link rel = "preload" href = "image.png" as = "image">

ИЛИ (заголовок HTTP)

Ссылка: <https://example.com/image.jpg>; отно = предварительная нагрузка; а = изображения

Примечание . Браузер может игнорировать уведомление о предварительной загрузке.

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

Узнайте больше :

Активировать HTTP / 2

HTTP / 2 - это обновленная версия протокола HTTP, официально стандартизированного в 2015 году. Основой HTTP / 2 послужила SDPY - протокол, разработанный Google для передачи контента с низкой задержкой (повышения скорости страницы) через World Wide Web. Основные различия между HTTP / 1.x и HTTP / 2 включают:

• Перейдите к двоичному (подумайте: компьютеры могут анализировать нули и единицы быстрее, чем текстовое кодирование)
• Мультиплексирование (подумайте: несколько запросов и ответ на одном соединении)
• Сжатие заголовка с помощью HPACK (представьте: адрес и основная информация (адрес источника и получателя, протокол, длина пакета и т. Д.) Объединены)
• Возможность отправлять ответы в кеш клиента (подумайте: устранение ненужных клиентских запросов (т. Е. Сервер отправляет ресурсы, которые, как он полагает, клиент впоследствии запросит))

Примечание : только то, что HTTP / 2 представляет мультиплексирование и push-ответы, не означает, что веб-разработчикам следует прекратить оптимизацию для повышения производительности. Те же рекомендации по разработке эффективного кода с приоритетом остаются в силе. Раздутый код с несколькими непредвиденными обстоятельствами остается более обременительным для сервера. Пер Илья «Наивная реализация HTTP / 2-сервера или прокси-сервера может« говорить »по протоколу, но без хорошо реализованной поддержки таких функций, как управление потоком и установление приоритетов запросов, она может легко привести к снижению оптимальной производительности. Например, он может насыщать полосу пропускания пользователя, отправляя большие ресурсы с низким приоритетом (например, изображения), в то время как браузер блокируется для отображения страницы до тех пор, пока он не получит ресурсы с более высоким приоритетом (такие как HTML, CSS или JavaScript) ».

Узнайте больше :

Сократите CSS, JavaScript и HTML

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

Обратите внимание на различия в двух файлах JavaScript ниже.

Minified (компьютерная версия)

Узнайте больше :

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

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

Переориторизация, консолидация и рефакторинг кода

Купите свою команду разработчиков немного кофе, 5-часовой ENERGY®, и убедитесь, что это не ночь D & D.

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

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

1. Встроенные меньшие JavaScript-программы, необходимые для рендеринга вышеупомянутого контента. Браузер не должен запрашивать встроенный JavaScript, поэтому задержка, возникающая из цикла запрос-ответ, будет уменьшена.
2. Сделайте JavaScript асинхронным, добавив атрибут «async» в соответствующие теги <script>.

1. Отложите все скрипты в HTML (то есть поместите его ниже в HTML-документе), которые не важны для загрузки контента выше сгиба.

Учить больше:

Рассмотрим условно обслуживающий код

Условно обслуживающий код, основанный на поддержке браузера, является прогрессивным понятием (например, WebP (прогрессивное использование изображений JPEG), сжатие Brotli и т. Д.). Это позволяет оптимизировать работу более продвинутых браузеров, сохраняя при этом универсальную поддержку.

Шаг 6: Рассмотрим современные технологии (в том числе: PWA и AMP)

Рассмотрите возможность внедрения Прогрессивного веб-приложения (PWA)

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

Предостережение Примечание. Наличие PWA означает, что вам предложат добавить другое приложение на домашний экран (в настоящее время это только пользователи Android, хотя Apple активно концентрируется на предоставлении поддержки PWA). Признайте, что обычный пользователь, скорее всего, не поймет разницу между собственным приложением и PWA. Если у бренда сильное нативное приложение, они должны понять, как его клиенты реагируют на наличие нативного приложения и PWA, прежде чем разрабатывать PWA.

Узнайте больше : Документация для разработчиков Google PWA

Рассмотрите возможность использования ускоренных мобильных страниц (AMP)

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

Если вы находитесь в публикации, AMP - это почти требование к экосистеме. Тем не менее, другие отрасли должны взвесить цену / выгоду страниц AMP. AMP живет в странном пространстве в мире SEO. Это не считается фактором ранжирования для самих не издателей, но потенциальное увеличение скорости может поддержать ранжирование. Это ограничит вашу аналитику, команда разработчиков будет вынуждена поддерживать двойной опыт, могут возникнуть проблемы *, связанные с содержанием хостинга Google (например, https://www.google.com/amp/ people.com/health/stephen- Colbert-Ruth-Bader-Ginsburg-Workout / Amp /), и Движение AMP к веб-стандарту W3C может вызвать сдвиги в этой технологии.

* Примечание : Google настаивает на том, что они ничего не отслеживают на страницах AMP, и старательно работает над исправлением для удаления https://www.google.com/amp/ из строки URL; Тем не менее, некоторые компании могут иметь юридические ограничения, касающиеся размещения контента.

Узнайте больше :

Читать дальше :

И запомни:

"Потерянное время не вернешь."

- Бенджамин Франклин

Бен Франклин Источник изображения: Пит Кляйн

TL; DR

Когда сталкиваемся со скоростью доставки страницы:

• Шаг 1. Определите, может ли скорость быть инициативой, стоящей перед вашей стратегией поиска
• Шаг 2: Получите UX, разработку и execs на борту (вам понадобятся союзники)
• Шаг 3: Начните с небольших изменений, которые не должны влиять на UX
  • Удалите код (и HTML-разметку), отрежьте все, что не используется (глядя на вас случайные теги)
  • Сжатие текстовых активов
  • Консолидация нескольких цепочек перенаправления HTTP
  • Убедите вашу команду UX, что системные шрифты - это новый черный цвет
  • Используйте CDN
• Шаг 4: Институционализация и внедрение лучших практик в будущем
  • Оптимизировать изображения
  • Кэшировать статические ресурсы
  • Ресурс намекающий / pre- * party
  • Активировать HTTP / 2
  • Сократите CSS, JavaScript и HTML
• Шаг 5: Определите любые дополнительные возможности для улучшения болевых точек, не отвлекаясь от UX
  • Переориторизация, консолидация и рефакторинг кода, где это возможно
  • Рассмотрим условно обслуживающий код
  • Рассмотрите возможность внедрения Прогрессивного веб-приложения (PWA)
  • Рассмотрите возможность использования ускоренных мобильных страниц (AMP) в качестве краткосрочного решения

Спасибо что подписались!