Comments 18
Вы забыли упомянуть показатель TTFB (Time To First Byte), ведь оптимизация загрузки страницы это только определенный шаг. Да, это уже по части серверной оптимизации,… но все же.
UFO just landed and posted this here
Насчет параллельно загрузки согласен, браузер находит критические ресурсы и пытается загрузить их как можно раньше.
А вот по поводу рендеринга — нет синхронный (обычный) JS блокирует рендеринг страницы, если его включение находится в начале кода страницы (все, что ниже блокируется до получения кода и его выполнения). Чтобы посмотреть это на практике, можете использовать примеры из статьи.
А вот по поводу рендеринга — нет синхронный (обычный) JS блокирует рендеринг страницы, если его включение находится в начале кода страницы (все, что ниже блокируется до получения кода и его выполнения). Чтобы посмотреть это на практике, можете использовать примеры из статьи.
UFO just landed and posted this here
Основной прирост от переноса JS вниз страницы даже не из-за отложенного парсинга, а из-за сетевых расходов на скачивание ресурса. В примере статьи два JS это около 240 кб сжатого трафика.
По парсингу: здесь важно разделять парсинг кода JS и CSS. Пока парсинг именно JS не очень быстрый: в примере из статьи jquery сам по себе выполняется у меня (десктоп) 20 мс, а jquery-ui 56 мс. А теперь представим мобильного пользователя: время парсинга JS легко может выйти за 100-200 мс, а это уже заметно.
По пересчету стилей при подгрузке: да, она происходит, есть даже перерисовка. Но так, как видимых изменений именно этот CSS не вносит, пользователь даже не видит этих действий. А рабочую страницу получает раньше (экономит 10 кб и один запрос).
По парсингу: здесь важно разделять парсинг кода JS и CSS. Пока парсинг именно JS не очень быстрый: в примере из статьи jquery сам по себе выполняется у меня (десктоп) 20 мс, а jquery-ui 56 мс. А теперь представим мобильного пользователя: время парсинга JS легко может выйти за 100-200 мс, а это уже заметно.
По пересчету стилей при подгрузке: да, она происходит, есть даже перерисовка. Но так, как видимых изменений именно этот CSS не вносит, пользователь даже не видит этих действий. А рабочую страницу получает раньше (экономит 10 кб и один запрос).
UFO just landed and posted this here
Объясните пожалуйста как перенос скрипта вниз страницы уменьшит скачиваемые трафик?
Общий трафик никак, трафик до начала рендеринга страницы: на размер ресурса.
Вам не кажется, что вы себе противоречите?
Для мобильного пользователя как раз перерисовка и повторное вычисление всех стилей будет очень даже ощутимо.
Я думаю, что перерисовка и вычисление стилей будет быстрее выполнения JS-кода и тем более быстрее сети (особенно мобильной). Это как общее правило. А на самом деле нужно тестировать в реальных условиях (на устройстве, с ограничением скорости сети).
По моему в стаьтье допущена серьезная ошибка — отложенная загрузка. В большинстве случаев (в приведенных примерах точно) не имеет смысла, а скорее всего приведет как раз к задержкам при повторном открытии страницы. Вот смотрите: при первом открытии страницы, когда файлы еще не закешированы, отложенная загрузка даст некоторый прирост. При последующих открытиях страницы все js и css будут уже в кеше браузера и никакие запросы к серверу не уйдут. Если у вас настроены кеш заголовки иначе, то я вам сочуствую и не может идти речи ни о какой оптимизации. При повторных открытиях будут выполнятся скрипты для загрузки стилей и скриптов, которые уже и так в браузере и могли бы уже к этому времени распарситься. По моему имеет смысл откладывать загрузку css со шрифтами и то указывая другой media типв теге, чтобы не блокироваться.
Специально для вас посмотрел: выполенние JS-инструкции о подгрузке CSS-файла занимает 0.8 мс. По-моему не страшная задержка. Если файл в кеше, то и здесь он не будет загружаться снова. Пересчет стилей после подгрузки CSS 2 мс.
Заметьте, что я отложил загрузку CSS именно для элементов, которые не показываются при начальном рендеринге страницы. Откладывать загрузку CSS с важными стилями (например, шрифтами): плохая идея, получится flash of unstyled content. По крайней мере, это нужно подробно тестировать.
Заметьте, что я отложил загрузку CSS именно для элементов, которые не показываются при начальном рендеринге страницы. Откладывать загрузку CSS с важными стилями (например, шрифтами): плохая идея, получится flash of unstyled content. По крайней мере, это нужно подробно тестировать.
Можно весь CSS поместить в style в HTML
Не надо так делать. Убивается весь эффект от кеширования, раздувается HTML.
Допустимо только разместить критический CSS при условии что он очень мал
Посмотрим основные шаги, которые включает в себя критический путь:
- Получить HTML-документ.
- Провести парсинг HTML на предмет включенных ресурсов.
- Построить DOM tree (document object model).
- Отправить запросы критических элементов.
- Получить весь CSS-код (также запустить запросы на JS-файлы).
- Построить CSSOM tree.
- Выполнить весь полученный JS-код.
- Перестроить DOM tree (при необходимости).
- Построить Render tree и начать отрисовку страницы.
Из этого утверждения может сложиться ложное впечатление, будто браузер никогда не отрисовывает страницы до момента завершения исполнения JS. Представленный алгоритм справедлив только для частных случаев, при которых внешние скрипты подключаются в теге head либо в начале тега body и не имеют атрибутов async.
Sign up to leave a comment.
Критический путь рендеринга веб-страниц