PageSpeed Insights анализирует страницу, чтобы определить, соответствует ли она нашим рекомендациям по обеспечению рендеринга страницы менее чем за секунду в мобильной сети. Исследования показали, что любая задержка более секунды заставит пользователя прервать поток мыслей, что приведет к ухудшению впечатления. Наша цель — поддерживать интерес пользователя к странице и обеспечивать оптимальное взаимодействие с ней независимо от устройства или типа сети.
Нелегко уложиться в бюджет на одну секунду. К счастью для нас, вся страница не обязательно должна отображаться в рамках этого бюджета, вместо этого мы должны доставить и отобразить контент над сгибом (ATF) менее чем за одну секунду, что позволяет пользователю начать взаимодействовать со страницей, как только возможный . Затем, пока пользователь интерпретирует первую страницу контента, остальная часть страницы может постепенно доставляться в фоновом режиме.
Адаптация к мобильным сетям с высокой задержкой
Соблюдение критерия ATF в одну секунду на мобильных устройствах создает уникальные проблемы, которых нет в других сетях. Пользователи могут получать доступ к вашему сайту через различные сети 2G, 3G и 4G. Задержки в сети значительно выше, чем при проводном соединении, и на рендеринг контента ATF уходит значительная часть нашего бюджета в 1000 мс.
4G является доминирующим типом сети во всем мире, поэтому следует ожидать, что большинство пользователей будут получать доступ к вашей странице в сети 4G. По этой причине мы должны предположить, что каждый сетевой запрос будет занимать в среднем 100 миллисекунд.
Имея это в виду, давайте теперь поработаем в обратном направлении. Если мы посмотрим на типичную последовательность обмена данными между браузером и сервером, то 300 мс из этого времени уже будут израсходованы накладными расходами сети: поиск DNS для преобразования имени хоста (например, google.com) в IP-адрес, сеть туда и обратно для выполнения TCP-квитирования и дополнительного TLS-соединения. Это оставляет нам 700 мс.
Предоставление опыта рендеринга менее чем за одну секунду
После вычета задержки в сети у нас остается всего 700 миллисекунд в нашем бюджете, и впереди еще много работы: сервер должен отобразить ответ, код клиентского приложения должен выполниться, а браузер должен разметить и отобразить содержание. Учитывая это, следующие критерии должны помочь нам уложиться в бюджет:
- (1) Сервер должен предоставить ответ (< 200 мс)
- Время ответа сервера — это время, необходимое серверу для возврата исходного HTML-кода, без учета времени сетевой транспортировки. Поскольку времени у нас очень мало, это время должно быть минимальным — в идеале в пределах 200 миллисекунд, а лучше даже меньше!
- (2) Количество перенаправлений должно быть сведено к минимуму.
- Дополнительные перенаправления HTTP могут добавить один или два дополнительных сетевых обхода (два, если требуется дополнительный поиск DNS), что приведет к увеличению задержки в сотни миллисекунд в сетях 4G. По этой причине мы настоятельно рекомендуем веб-мастерам минимизировать их количество, а в идеале — полностью исключить перенаправления — это особенно важно для HTML-документа (по возможности избегайте перенаправлений «m dot»).
- (3) Количество обращений к первому рендерингу должно быть сведено к минимуму.
Из-за того, как TCP оценивает пропускную способность соединения (т. е. TCP Slow Start ), новое TCP-соединение не может сразу использовать всю доступную пропускную способность между клиентом и сервером. Из-за этого сервер может отправить до 10 TCP-пакетов по новому соединению (~ 14 КБ) в первом двустороннем режиме, а затем ему приходится ждать, пока клиент подтвердит эти данные, прежде чем он сможет увеличить свое окно перегрузки и продолжить доставку большего количества данных.
Также важно отметить, что ограничение в 10 пакетов ( IW10 ) — это недавнее обновление стандарта TCP: вам следует убедиться, что ваш сервер обновлен до последней версии, чтобы воспользоваться этим изменением. В противном случае лимит скорее всего будет 3-4 пакета!
Из-за такого поведения TCP важно оптимизировать контент, чтобы свести к минимуму количество циклов передачи данных, необходимых для доставки необходимых данных для выполнения первого рендеринга страницы. В идеале содержимое ATF должно умещаться в размере менее 98 КБ — это позволяет браузеру отрисовывать страницу всего за три обращения, чтобы иметь достаточно времени для задержки ответа сервера и рендеринга клиента.
- (4) Избегайте внешней блокировки JavaScript и CSS в верхнем контенте.
Прежде чем браузер сможет отобразить страницу пользователю, он должен ее проанализировать. Если во время анализа он сталкивается с неасинхронным или блокирующим внешним скриптом, ему приходится остановить и загрузить этот ресурс. Каждый раз, когда он это делает, он добавляет сетевой обход, что приводит к задержке времени первого рендеринга страницы.
В результате JavaScript и CSS, необходимые для визуализации указанной выше области сгиба, должны быть встроены, а JavaScript или CSS, необходимые для добавления дополнительных функций на страницу, должны загружаться после доставки содержимого ATF.
- (5) Резервное время для верстки и рендеринга браузера (200 мс)
- Процесс анализа HTML, CSS и выполнения JavaScript требует времени и ресурсов клиента! В зависимости от скорости мобильного устройства и сложности страницы этот процесс может занять сотни миллисекунд. Мы рекомендуем зарезервировать 200 миллисекунд для накладных расходов браузера.
- (6) Оптимизировать выполнение JavaScript и время рендеринга.
- Выполнение сложных сценариев и неэффективного кода может занять десятки и сотни миллисекунд — используйте встроенные в браузер инструменты разработчика для профилирования и оптимизации вашего кода. Для ознакомления ознакомьтесь с нашим интерактивным курсом по инструментам разработчика Chrome.
Часто задаваемые вопросы
- Я использую библиотеку JavaScript, например JQuery, есть какие-нибудь советы?
- Многие библиотеки JavaScript, такие как JQuery, используются для улучшения страницы, добавляя дополнительную интерактивность, анимацию и другие эффекты. Однако многие из этих вариантов поведения можно безопасно добавить после визуализации содержимого ATF. Исследуйте перемещение выполнения и загрузки такого JavaScript до тех пор, пока страница не загрузится.
- Я использую фреймворк JavaScript для создания страницы. Есть какие-нибудь советы?
- Если содержимое страницы создано с помощью клиентского JavaScript, вам следует изучить возможность встраивания соответствующих модулей JavaScript, чтобы избежать дополнительных сетевых обращений. Аналогичным образом, использование рендеринга на стороне сервера может значительно повысить производительность загрузки первой страницы: визуализировать шаблоны JS на сервере, встроить результаты в HTML, а затем использовать шаблоны на стороне клиента после загрузки приложения.
- Как определить критический CSS на моей странице?
- В инструментах разработчика Chrome откройте панель «Аудит» и запустите отчет «Производительность веб-страницы». В созданном отчете найдите «Удалить неиспользуемые правила CSS». Или используйте любой другой сторонний инструмент или скрипт, чтобы определить, какие селекторы CSS применяются на каждой странице.
- Можно ли автоматизировать эти лучшие практики?
- Абсолютно. Существует множество коммерческих продуктов и продуктов с открытым исходным кодом для оптимизации веб-производительности (WPO), которые могут помочь вам удовлетворить некоторые или все из приведенных выше критериев. Если вам нужны решения с открытым исходным кодом, обратите внимание на инструменты оптимизации PageSpeed .
- Как мне настроить свой сервер так, чтобы он соответствовал этим критериям?
- Во-первых, убедитесь, что на вашем сервере установлена актуальная версия операционной системы. Чтобы воспользоваться увеличенным начальным размером окна перегрузки TCP (IW10), вам потребуется ядро Linux 2.6.39+. Для других операционных систем обратитесь к документации.
Чтобы оптимизировать время ответа сервера, инструментируйте свой код или используйте решение для мониторинга приложений, чтобы выявить «узкие места» — например, время выполнения сценариев, вызовы базы данных, запросы RPC, рендеринг и т. д. Цель — отобразить ответ HTML в течение 200 миллисекунд. - А как насчет Политики безопасности контента?
- Если вы используете CSP, вам может потребоваться обновить политику по умолчанию.
Во-первых, по возможности следует избегать встроенных атрибутов CSS в элементах HTML (например,< p style=...>), поскольку они часто приводят к ненужному дублированию кода и по умолчанию блокируются с помощью CSP (отключено с помощью «unsafe inline» в «стиль-src»). Если CSP включен, он по умолчанию блокирует все встроенные теги скриптов. Если у вас есть встроенный JavaScript, вам нужно будет обновить политику CSP, чтобы либо использовать хэши сценариев или одноразовые номера , либо использовать «unsafe-inline», чтобы разрешить выполнение всех встроенных сценариев. Если у вас есть встроенные стили, вам необходимо обновить политику CSP, чтобы либо использовать хэши стилей или одноразовые номера , либо использовать «unsafe-inline», чтобы разрешить обработку всех блоков встроенных стилей.
Есть еще вопросы? Пожалуйста, не стесняйтесь задавать вопросы и оставлять отзывы в нашей дискуссионной группе по адресу pagespeed-insights-discuss .
Обратная связь
Была ли эта страница полезной?