Блог

Как повысить скорость загрузки страниц от A до Я (ЧАСТЬ 2)

Предварительная загрузка

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

Браузер дает каждому запросу файла приоритет. Идея состоит в том, чтобы получить файлы, необходимые для отображения содержимого в верхней части страницы раньше (с более высоким приоритетом), и отложить те, которые не требуются, на более позднее время в процессе. Вы можете увидеть приоритет файлов на вкладке «Network» в Chrome Dev Tools. Просто щелкните панель правой кнопкой мыши, выберите «Priority» и добавьте его как столбец.


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

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

Примеры кода:

<link rel="preload" href="/my.css" as="style">
<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">

Выбор файлов для предварительной загрузки

Обычно у вас будет основной файл темы, содержащий много CSS для сайта. Разработчики часто называют это в честь темы, или называют это «стилем», а иногда называют его именем самого веб-сайта. Если у вас возникли проблемы с идентификацией этого файла или вы считаете, что может потребоваться предварительная загрузка и других файлов, то самый простой способ проверить это с помощью функции блокировки запросов в Chrome Dev Tools. Откройте вкладку «Network» и загрузите страницу, чтобы просмотреть запрошенные файлы. Вы можете щелкнуть их правой кнопкой мыши, чтобы добавить их в список блокировки. Когда вы перезагружаете страницу, если она по-прежнему выглядит нормально, вы, вероятно, не заблокировали нужный файл.


Что нужно знать о предварительной загрузке

  1. Вам понадобится перекрестная загрузка шрифтов, иначе вы получите двойную загрузку файла.
  2. Вам по-прежнему нужны обычные вызовы файлов для JS + CSS, поэтому не удаляйте их.
  3. Вы можете предварительно загрузить шрифт, даже если он вызывается в другом файле, таком как файл CSS.
  4. Будьте осторожны при предварительной загрузке. Вы можете столкнуться с проблемами, пытаясь предварительно загрузить слишком много файлов.

Сервер Push

Это было частью спецификации HTTP / 2 (H2). Это позволяет серверу доставить файл без его запроса. Таким образом, вместо цепочки, которая может быть HTML > CSS > Font, это позволяет сайту сказать, что мне понадобится этот шрифт, просто отправьте его.

Server Push проблематичен, и я обычно не рекомендую его, но если вы отличный разработчик или имеете к нему доступ, вы можете попробовать. Он запрашивает файлы с сервера по тому же соединению, что и запрос страницы. Сервер Push ресурсы может загружены дважды. Есть обходной путь с использованием файлов cookie и проверкой того, что вы уже отправили ресурсы пользователям, но это сложная реализация. Есть еще одна проблема, связанная с проблемами подключения, из-за которых файлы могут вообще не загружаться. Несмотря на всю дополнительную работу, вы все равно можете не увидеть значительного выигрыша от предварительной загрузки, потому что браузеры проверяют кеш страницы (где предварительная загрузка) до push-кеша.

Тип файла JavaScript

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

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

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

Двигаемся к Footer

Для встроенных скриптов вы можете переместить их в Footer. Помните, что JavaScript блокирует парсер, то есть блокирует чтение HTML. Перемещение этих скриптов в Footer гарантирует, что большая часть данных может быть обработана до того, как произойдет какая-либо блокировка. У вас есть другие варианты ссылок на скрипты, которые, вероятно, лучше, такие как defer и async.

Defer/Async

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


Источник: https://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html.

Примеры кода Defer / Async

Обычный:

<script src="https://www.domain.com/file.js"></script>

Асинхронный:

<script src="https://www.domain.com/file.js" async></script>

Отложенный:

<script src="https://www.domain.com/file.js" defer></script>

Ответная реакция

Отзывчивость обычно измеряется задержкой первого ввода (FID), которая представляет собой время с момента взаимодействия пользователя с вашей страницей до момента, когда он сможет ответить. Многие люди обычно измеряют время до интерактивности (Time To Interactive - TTI), то есть сколько времени требуется, чтобы страница стала полностью интерактивной.

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



Пользователи жалуются на медленную работу приложения Twitter… в Twitter.

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


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

Источник: https://web.dev/long-tasks-devtools

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

Сторонние теги

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


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

Распространенные источники раздутия JavaScript:

  • JQuery
  • Системы A / B тестирования
  • Системы тепловых карт
  • Системы мониторинга реальных пользователей (RUM)
  • Системы живого чата

Параметры очистки:

  1. Используйте меньше трекингов / скриптов. Это может быть трудным решением, поскольку маркетологи любят данные, но иногда объем собираемых данных просто абсурден.
  2. Консолидируйте системы с аналогичной функциональностью, например, если вы используете несколько систем аналитики или несколько систем, которые содержат информацию о пользователях. Многие программы имеют несколько функций, и иногда вы получаете сценарии, которые имеют такие же или похожие функции на другой сценарий, хотя, возможно, вы можете обойтись без одного из них.
  3. Сегментация. Например, некоторые системы A / B тестирования сохранят и заставят вас загрузить список всех тестов, находящихся в настоящее время в системе, увеличивая размер загрузки. Часто вы можете сегментировать сайт по разделам и создавать уменьшенные версии файла.
  4. Отслеживание на стороне сервера вместо отслеживания на стороне клиента. Есть компромиссы с отслеживанием, которые я не буду здесь описывать, но вы можете найти много ресурсов о том, почему вы можете использовать один вместо другого.
  5. Используйте веб-воркеры, чтобы переместить обработку из основного потока. Обратной стороной этого является то, что у веб-воркера не будет доступа к DOM. Это также довольно продвинуто и требует квалифицированных разработчиков.
  6. Service Workers / Edge Workers. Я очень рад тому, что ждет эту технологию в будущем. Это в основном позволяет JS запускаться на уровне Edge (или на уровне CDN), а не в клиентском браузере. Итак, раньше для системы A / B тестирования могло случиться так, что файл был загружен, а затем обработан и выполнен в браузере клиента. Поскольку тест может перезаписать части DOM и произойти позже при загрузке, вы можете увидеть визуальные вспышки при изменении. Теперь вы можете в основном предварительно обработать изменения, которые собирались внести, и доставить их вместе с HTML, который доставляется ботам и пользователям. Некоторые платформы уже используют это в своих интересах.
  7. Просто отложите выполнение загрузки файла, если он не нужен сразу, или инициируйте запрос файла только на основе действия, такого как клик. Например, система живого чата, вероятно, не понадобится в первые пять секунд загрузки страницы, поэтому отложите ее. Вы также можете запросить файл после того, как кто-то наведет курсор или щелкнет кнопку, чтобы он вообще не загружался с начальной страницей. Или используйте изображение с кнопкой воспроизведения вместо встраивания видео YouTube и загружайте только элементы видео YouTube и воспроизводите контент, когда пользователь нажимает.

Преимущества JS Framework:

Фреймворки JavaScript, такие как React, Angular и Vue, имеют некоторые преимущества перед традиционными системами.

  • Tree shaking: доставка только кода, используемого на странице. Любые ненужные дополнительные файлы или код не загружаются, поэтому файлы и страницы становятся меньше. Это устраняет код, традиционно требуемый для каждой другой страницы и возможности.
  • Разделение кода: разделение файлов на более мелкие части, чтобы было больше возможностей для интерактивности. Например, предположим, что у вас есть JS файл размером 1 МБ, который выполняется как длинная задача в основном потоке и блокирует интерактивность во время выполнения. Вы можете разделить его на блоки по 50 КБ, чтобы задачи не выполнялись так долго, а между ними было больше промежутков в более короткие периоды, когда страница могла реагировать на ввод пользователя.

Шрифты в виде файла

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

@font-face {
  font-family: 'Whatever';
  font-display: swap;
}

Если вы используете шрифты Google, это еще проще. Все, что вам нужно сделать, это добавить &display=swap в качестве параметра в URL.

<link href="https://fonts.googleapis.com/css?family=Whatever&display=swap" rel="stylesheet">

Тип файла изображения

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

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

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

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

На https://images.guide/ есть отличное руководство по оптимизации изображений и различным форматам.

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

CDN для оптимизации изображений:
Akamai Image Manager 
imgix
Image Engine
Cloudinary
Uploadcare

API оптимизации изображений:
ShortPixel
Fastly Image Optimizer
Kraken.io
TinyPNG 
Imagify 

Графический интерфейс:
ImageOptim 
Squoosh 

Командная строка:
Imagemin также имеет модуль npm, если вы используете webpack, gulp или grunt.

JPEG:
Guetzli 
MozJPEG

PNG:
pngquant 
Zopfli

GIF:
Gifsicle
SVGO 

WordPress / Drupal:
Особых рекомендаций у меня нет. Вы найдете множество вариантов для WordPress и Drupal.

Lazy Load Images (ленивая загрузка изображений)

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

Я бы сказал, вам нужна библиотека, которая использует IntersectionObserver, но, вероятно, имеет полифил из-за поддержки браузера. Самая популярная библиотека для этого - lazysizes, но вы найдете множество вариантов для своей установки.

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

Адаптивные изображения / изображения с измененным размером

Все дело в том, чтобы подать правильное изображение для правого экрана. Загрузка большого изображения с последующим его уменьшением - пустая трата времени и ресурсов. Для этого снова существует множество автоматизированных решений. Например, с этим справятся многие CDN, а также есть такие вещи, как пакет sharp npm, инструмент ImageMagick CLI или различные плагины / модули для разных систем.

Изменение форматов изображений

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

Размер страницы / Вес

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

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

Другие возможности веб-производительности

Есть много способов повысить скорость загрузки страниц. Я собираюсь затронуть еще несколько важных вопросов.

Кеширование

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

Кэш сервера

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

Проверка обычно выглядит примерно так: CDN cache > Server cache (например, Varnish) > Origin (страница должна быть создана на лету). Как правило, кэш более высокого уровня, такой как CDN, будет быстрее, поэтому большинство ваших обращений было на этом уровне.

Например, на одном из моих сайтов в Cloudflare, показанном ниже, у меня коэффициент попадания в кеш чуть более 50% для уровня CDN. К сожалению, это означает, что многие запросы не обслуживаются CDN и должны возвращаться в кеш уровня сервера. Или, если в нем нет текущей кэшированной версии, ему придется создавать страницу на лету, что использует много ресурсов базы данных и будет медленнее для пользователя.


Кэш браузера

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

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

1-я загрузка:


2-я загрузка:


Вы увидите проблемы с кешированием, помеченные в таких инструментах, как Lighthouse, как «обслуживание статических ресурсов с помощью эффективной политики кеширования». Установка продолжительности времени для кеширования зависит от системы, но, как правило, вам нужно использовать HTTP- заголовок ответа Cache-Control. Максимальный возраст - это время, которое можно сохранить в секундах, и может быть установлено следующим образом: Cache-Control: max-age=31536000

У Varvy есть руководство по настройке элементов управления кешем на разных серверах, которое стоит прочитать.

Установите лимит производительности (возможно)

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

Адаптивная загрузка

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

Одна часть этого - API сетевой информации, который предоставляет вам информацию о подключении пользователя. Вы можете изменить свои изображения / контент или сделать что-то вроде отключения видео на основе сетевой информации входящего запроса. Многие CDN образов делают это с помощью API сетевой информации.

Используйте другие подсказки ресурсов

Предварительная выборка

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

Предварительная загрузка

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

AMP

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


Источник: https://www.ampproject.org/latest/blog/why-amp-caches-exist/

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

Тестирование скорости страницы и инструменты

Лабораторные данные против полевых данных


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

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

ПРИМЕЧАНИЕ. Будьте осторожны с тем, как долго вы используете инструменты Real User Monitoring (RUM), которые позволяют собирать полевые данные. Хотя эти инструменты отлично подходят для просмотра того, как страницы загружаются для пользователей, они также могут увеличить время загрузки. Ваша цель - сделать ваш сайт быстрее, и это может быть полезно при диагностике проблем, но если оставить их включенными, ваши страницы будут загружаться медленнее.

Инструменты для измерения скорости страницы

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


  • TestMySite - содержит таблицу показателей скорости, в которой вы можете оценить свою скорость по сравнению с конкурентами, имеет калькулятор влияния, чтобы вы могли оценить влияние скорости на ваш бизнес, и позволяет вам создать отчет, который включает эти и некоторые рекомендации, на которых нужно сосредоточиться. 
  • Lighthouse (в Chrome Dev Tools) - позволяет тестировать производительность страниц и приложений.
  • PageSpeed ​​Insights - запускает Lighthouse и предоставляет рекомендации. На запуск Lighthouse в вашем браузере влияют многие вещи, такие как ваш компьютер, ваша сеть, расширения в вашем браузере и т. д. PageSpeed ​​Insights позволяет создать довольно стабильную тестовую среду, которая даже не использует ресурсы вашего сервера, как при масштабной настройке Lighthouse.
  • Инструменты разработчика Chrome - множество полезных функций, позволяющих узнать, что и как загружается страница, например вкладки «Сеть» и «Производительность».
  • Отчет о пользовательском опыте Chrome (CrUX) - общедоступный набор данных о реальных пользовательских впечатлениях для тех, кто решил поделиться в Chrome, который охватывает миллионы веб-сайтов. Поле Data (данные реальных пользователей) для скорости страницы.
  • Web.dev - еще один инструмент тестирования Google, поддерживаемый Lighthouse. Здесь также есть раздел для получения дополнительной информации о скорости страницы.

Какие данные использует Google для определения скорости страницы?

По словам аналитика Google Webmaster Trends Джона Мюллера в этом видео, Google использует теоретическую скорость страницы (с использованием лабораторных данных) и реальные полевые данные пользователей, которые пытались использовать эти страницы. Он говорит, что это похоже на данные в отчете о пользовательском опыте Chrome.

Реальность такова, что не было публичного подтверждения источника используемых данных. Хотя Джон не говорит, что они используют данные PageSpeed ​​Insights и CrUX, полученные от них данные, вероятно, являются репрезентативными для данных, используемых Google. Мое лучшее предположение (и это чисто умозрительное) заключается в том, что они используют меры, принятые во время процесса рендеринга, в качестве лабораторных данных (возможно, Lighthouse, но, возможно, нет), и у них, вероятно, есть внутренний ресурс, аналогичный CrUX, который они используют для поля данные.

Оценка воздействия изменений

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

В заключение

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