Comments 18
Вы забыли упомянуть показатель TTFB (Time To First Byte), ведь оптимизация загрузки страницы это только определенный шаг. Да, это уже по части серверной оптимизации,… но все же.
Да, в статье далеко не все рекомендации по ускорению. Такой задачи и не стояло. Кстати, важное дополнение: идеально, если размер критического пути в килобайтах укладывался в 14 кб. Это связано с TCP congestion window размером в 10 пакетов (примерно 14-15 кб).
Насчет параллельно загрузки согласен, браузер находит критические ресурсы и пытается загрузить их как можно раньше.
А вот по поводу рендеринга — нет синхронный (обычный) JS блокирует рендеринг страницы, если его включение находится в начале кода страницы (все, что ниже блокируется до получения кода и его выполнения). Чтобы посмотреть это на практике, можете использовать примеры из статьи.
А вот по поводу рендеринга — нет синхронный (обычный) JS блокирует рендеринг страницы, если его включение находится в начале кода страницы (все, что ниже блокируется до получения кода и его выполнения). Чтобы посмотреть это на практике, можете использовать примеры из статьи.
Основной прирост от переноса 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 кб и один запрос).
Объясните пожалуйста как перенос скрипта вниз страницы уменьшит скачиваемые трафик?
Общий трафик никак, трафик до начала рендеринга страницы: на размер ресурса.
Вам не кажется, что вы себе противоречите?
Для мобильного пользователя как раз перерисовка и повторное вычисление всех стилей будет очень даже ощутимо.
Я думаю, что перерисовка и вычисление стилей будет быстрее выполнения 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 при условии что он очень мал
В smashingmagazine так и делают (посмотрие лекцию Виталя Фридмана) — с помощью phantomjs, если я правильно помню, выявляются стили, которые необходимы для отображения первых 1000px по высоте и кладут их в html.
Sign up to leave a comment.
Критический путь рендеринга веб-страниц