Как ускорить загрузку сайта -2

- такой же как Forbes, только лучше.

Николай Лавлинский, технический директор «Метод Лаб», специально для Нетологии рассказал о том, как можно ускорить сайт и ничего при этом не потерять. Статья участвует в конкурсе блога.

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



Даже при относительно благополучной ситуации с сайтом (при быстрой загрузке на проводном интернете и современном компьютере), задержки в загрузке могут приводить к потерям аудитории и снижению конверсии. Например, компания Amazon проводила эксперимент, в котором выяснила, что каждые 100 мс (0,1 с) задержки приводят к снижению продаж на 1%.

Но более половины интернет-аудитории сегодня используют мобильные устройства для доступа к сайтам. Значит они могут использовать медленные каналы для доступа и процессоры для загрузки сайта.

Третья причина важности вопроса скорости сайта — техническая. Как правило, медленные сайты потребляют повышенный объём ресурсов хостинга, который приводит к дополнительным расходам. Тормоза серверной части снижают возможности беспроблемно переживать пики нагрузки на сайт.

Поэтому скоростью сайта нужно заниматься как с технической, так и с экономической точек зрения. В этой статье мы сконцентрируемся на технической стороне ускорения сайтов.

Скорость сайта: основные компоненты


Скорость сайта касается двух сторон: клиентской и серверной. На сегодняшний день каждая из этих частей равнозначна для конечного результата. Но каждая со своими особенностями.

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

Полный процесс загрузки сайта (первое посещение) выглядит следующим образом:

  1. DNS-запрос по имени сайта.
  2. Подключение к серверу по IP (ТCP-подключение).
  3. Установление защищённого соединения при использовании HTTPS (TLS-подключение).
  4. Запрос HTML-страницы по URL и ожидание сервера. (HTTP-запрос)
  5. Загрузка HTML.
  6. Разбор HTML-документа на стороне браузера, построение очереди запросов в ресурсам документа.
  7. Загрузка и парсинг CSS-стилей.
  8. Загрузка и выполнение JS-кода.
  9. Начало рендеринга страницы, выполнение JS-кода.
  10. Загрузка веб-шрифтов.
  11. Загрузка изображений и других элементов.
  12. Окончание рендеринга страницы, выполнение отложенного JS-кода.

В этом процессе некоторые позиции происходят параллельно, некоторые могут меняться местами, но суть остаётся той же.

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

Измерение скорости сайта


Главный вопрос: что нужно измерять? Существует множество метрик по скорости сайтов, но основных не так много.

Во-первых, это время до первого байта (TTFB — time to first byte) — это время от начала процесса загрузки до получения первой порции данных от сервера. Это основная метрика для серверной оптимизации.

Во-вторых, это начало рендеринга страницы (start render, first paint). Метрика показывает время до окончания периода «белого экрана» в браузере, когда начинается отрисовка страницы.

В-третьих, это загрузка основных элементов страницы (load time). Сюда входит загрузка и интерпретация всех ресурсов для работы со страницей, после этой отметки индикатор загрузки страницы перестаёт крутиться.

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

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

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

Один из самых мощных инструментов — панель разработчика в браузере. Наиболее развитая функциональность у панели в Chrome. На вкладке Network можно получить метрики по времени загрузки всех элементов, включая сам HTML-документ. При наведении на элемент можно узнать, сколько времени потрачено на каждый этап получения ресурса. Для оценки полной картины процесса загрузки страницы можно воспользоваться вкладкой Performance, которая даёт полную детализацию вплоть до времени декодирования картинок.

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

Среди веб-сервисов профессиональным стандартом стала система WebPagetest. Это сервис загружает сайт в реальных браузерах с заданным типом соединения и формирует подробный отчет по всем этапам и метрикам.

Для быстрой оценки клиентской оптимизации можно воспользоваться сервисом Google PageSpeed Insights, но нужно помнить, что он не включает в себя большинство важнейших метрик по времени загрузки. Наконец, полезно анализировать время загрузки сайта у реальных пользователей. Для этого есть специальные отчеты в системах веб-аналитики Яндекс.Метрике и Google Analytics.

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

Серверная оптимизация


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

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

Хостинг (серверные ресурсы)


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

СУБД (сервер базы данных)


Здесь мы уже переходим к решению источника проблемы: низкой скорости работы программного кода. Часто большая часть времени веб-приложения тратится на запросы к БД. Это логично, потому что задача веб-приложения сводится к сбору данных и преобразованию их по определённому шаблону.

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

Оптимизация запросов и схемы данных это радикальный способ ускорения. За счет такой оптимизации можно получать ускорение на несколько порядков. Если изменение структуры БД может происходить без вторжения в программный код сайта, то оптимизация запросов такое вмешательство потребует.

Для выявления медленных запросов нужно собрать статистику по нагрузке на БД за довольно продолжительный промежуток времени. Далее проводится анализ лога и выявление кандидатов на оптимизацию.

Влияние CMS и программного кода


Довольно широко распространено мнение, что скорость сайта зависит только от CMS («движка»). Владельцы сайтов часто пытаются разделить CMS на быстрые и медленные. На самом деле, это не совсем так.

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

Тем не менее, помимо основного кода CMS, сайт может содержать дополнительные модули (плагины), расширения и модификации от разработчиков сайта. И уже этот код может оказывать негативное воздействие на скорость сайта.

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

Кэширование


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

Как правило, кэширование страниц позволяет сократить время отдачи страницы до десятков миллисекунд. Естественно, что в этом случае сервер легко переживает пики посещаемости. Проблемы здесь две: не всё можно закэшировать и кэш нужно грамотно инвалидировать (сбрасывать). Если проблемы решаются, кэширование можно рекомендовать как эффективное средство серверного ускорения.

Оптимизация TCP, TLS, HTTP/2


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

Тюнинг TCP сегодня требуется для больших проектов и серверов с подключением от 10G, основное, что нужно помнить: сетевая подсистема регулярно обновляется с выходом новых ядер Linux, поэтому стоит обновляться. Правильная настройка TLS (HTTPS) позволяет получить высокий уровень безопасности и максимально сократить время установления защищенного соединения. Хорошие рекомендации выпущены компанией Mozilla.

Новая версия HTTP протокола — HTTP/2 призвана ускорить загрузку сайтов. Этот протокол появился недавно и сейчас активно используется (около 20% доли среди веб-сайтов). В общем, в HTTP/2 действительно заложены механизмы ускорения, основной — снижение влияния сетевых задержек на время загрузки страницы (request multiplexing). Но ускорение за счет HTTP/2 далеко не всегда успешно, поэтому не стоит уповать на этот протокол.

Клиентская оптимизация


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

Оптимизация критического пути: CSS, JS


Критический путь рендеринга (critical rendering path) — набор ресурсов для начала отрисовки страницы в браузере. Как правило, в этот список входят сам HTML-документ, CSS-стили, веб-шрифты и JS-код.

Наша задача как оптимизаторов скорости сократить этот путь как по времени (с учетом задержек сети), так и по трафику (чтобы учесть медленные соединения).

Самый простой путь определить критический путь: запустить аудит в Chrome (в панели разработчика), плагин Lighthouse определяет его состав и время загрузки с учетом медленного подключения.

Основная техника в сокращении критического пути: убираем всё, что не нужно или можно отложить. Например, большинство JS-кода можно отложить до загрузки страницы. Для этого размещаем вызов JS-ресурса в конце HTML-документа или используем атрибут async.

Для отложенной загрузки CSS можно воспользоваться динамическим подключением стилей через JS (дождавшись события domContentLoaded).

Оптимизация веб-шрифтов


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

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

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

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

Повлиять на быстрое отображение веб-шрифтов можно с помощью новых спецификаций link rel=«preload» и CSS-свойства font-display. Preload позволит как можно раньше указать браузеру о необходимости загрузки файла шрифта, а font-display даёт гибкие возможности по управлению поведением браузера в случае задержки файла (подождать, отрисовать запасной, не ждать шрифт более трех секунд)

Оптимизация изображений


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

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

  • PNG для картинок с прозрачностью и текстом;
  • JPEG для фото и сложных изображений;
  • SVG для векторной графики.

В дополнение к этим форматам сейчас разрабатываются новые: например, WebP от Google. Этот формат может покрыть область использования PNG и JPEG — поддерживает сжатие с потерями и без потерь, прозрачность и даже анимацию. Для его использования достаточно создать копии картинок в WebP и отдавать их браузерам, которые их поддерживают.

Для PNG существует множество утилит по оптимизации, которые можно использовать для сокращения размера, например, OptiPNG, PNGout, ect и другие. Также внутреннюю оптимизацию сжатия данных можно проводить с помощью zopfliPNG. Основная идея такого софта в подборе оптимальных параметров компрессии, удалении лишних данных из файла. Здесь нужно быть осторожным: некоторые утилиты имеют режим с потерей качества, что может не подходить вам (если вы ожидаете на выходе точно такую же картинку).

Оптимизация JPEG также разделяется на два типа: с потерями и без потерь. В целом можно порекомендовать пакет Mozilla JPEG, который специально разработан для лучшего сжатия в этом формате. Для оптимизации без потерь можно использовать jpegtran, с потерями — cjpeg.

Кэширующие заголовки


Это наиболее простая методика клиентской оптимизации. Её смысл в кэшировании браузером редкоизменяемых ресурсов: картинок, CSS и JS-файлов, шрифтов, иногда даже самого HTML-документа. В результате каждый ресурс запрашивается с сервера только один раз.

Если вы используете Nginx, достаточно добавить директиву:

add_header Cache-Control "max-age=31536000, immutable";

С этого момента браузер имеет право кэшировать ресурсы на срок до года (что практически навсегда). Новый параметр «immutable» говорит о том, что ресурс не планируется изменять.

Конечно, возникает вопрос: а что делать, если нам нужно изменить закэшированный ресурс? Ответ прост: изменить его адрес, URL. Например, можно добавить версию в имя файла. Для HTML-документов такой метод также применим, но, как правило, используется более короткий срок кэширования (например, одна минута или час).

Сжатие данных


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

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

Во-вторых, можно использовать статическое сжатие, то есть предварительно сжать файлы и положить на диск. Тогда веб-сервер будет искать сжатую версию и сразу её отдавать.В-третьих, можно использовать более эффективные алгоритмы сжатия: zopfli (совместим с gzip) и brotli (новый алгоритм сжатия). Brotli будет работать только с HTTPS. Так как эти алгоритмы (особенно zopfli) затратны при сжатии, обязательно используем их в статическом варианте.

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

Использование CDN


Применение CDN (content delivery network) для ускорения сайтов очень разрекламированная мера, имеющая много маркетинговой шелухи вокруг сути технологии.

Теория: зачем


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

Решение этой проблемы было в создании CDN, то есть распределённой сети, к которой подключались клиенты (например, зрители), а хосты этой сети уже к серверу (origin). При этом количество подключений к серверу сокращалось до одного (нескольких), а количество подключений к CDN могло достигать миллионов за счет кэширования контента сетью.

Сегодня большинство CDN позиционируют себя как средство ускорения сайтов, в первую очередь за счет сокращения расстояния от контента до клиента (посетителя сайта).

Возможные эффекты


Как можно ускорить сайт с помощью CDN?

Да, действительно пользователь подключается, как правило, к ближнему (по времени доступа) серверу сети и получает быстрый процесс установления TCP и TLS-соединения. Далее, если контент находится на сервере CDN, пользователь может быстро его получить. Таким образом, снижается нагрузка на наш собственный сервер.

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

Недостатки использования CDN


Недостатки, как обычно, продолжение достоинств: объект может быть не в кэше узла CDN. Например, он ещё не запрашивался или его нельзя кэшировать (HTML-документ). В этом случае мы получаем дополнительные задержки между узлом CDN и нашим сервером.

Несмотря на то что CDN призваны ускорять доступ к сайту, возможны ситуации, когда сетевой маршрут будет менее оптимальным, чем без CDN. Особенно актуально для глобальных CDN, для которых Россия не является приоритетным рынком.

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

Закрепляем результат


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

Поддержка ускорения


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

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

Для оптимизации поступающего контента требуется интеграция оптимизирующих процедур в систему управления контентом. Прежде всего это касается обработки изображений.

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

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


Синтетическое тестирование в идеальных лабораторных условиях очень полезно для оценки изменений в коде системы, но его недостаточно. В конце концов мы хотим, чтобы сайт работал быстро у реальных пользователей. Для сбора таких данных существует мониторинг скорости на стороне пользователей (RUM — real user monitoring).

Чтобы организовать RUM, достаточно подключить одну из систем веб-аналитики (Яндекс.Метрика, Google Analytics) и посмотреть отчеты по времени загрузки сайта. Для более подробных и точных данных можно использовать специализированные сервисы мониторинга скорости.

Выводы


Индустрия ускорения сайтов — довольно молодая отрасль веб-разработки и активно развивается. Важность скорости сайтов для интернет-бизнеса уже очевидна, она становится одним из факторов конкуренции. Именно поэтому стоит заниматься оптимизацией скорости сайта и делать вложения в эту область.

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

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



Комментарии (41):

  1. ibrin
    /#10414374 / +2

    Переставьте рендеринг с 9го места на 5е — до загрузки HTML и люди вам скажут спасибо.

    • Nickmob
      /#10414474

      Это зачем?

      • SirEdvin
        /#10414478

        Думаю, что бы не грузить клиенты сайтамы, которые выедают все CPU и прочее, особенно если их можно один раз отрендерить (скорее всего) js'ом на сервере, если у вас какой-то angular или что-то еще.

        • Nickmob
          /#10414486

          Здесь под рендерингом страницы понимается не обработка шаблонов и сборка страницы, а рендеринг браузером документа: блоки, буквы, пиксели…

          • SirEdvin
            /#10414522

            Ну, там у вас есть "выполнение JS-кода", вот имеется ввиду, что довольно часто, значительную его часть можно попробовать вынести на сервере.

            • Nickmob
              /#10414536

              Это клиентский код, его нельзя вынести на сервер. Например: веб-счетчик, виджет чата, jquery и т.д.

              • SirEdvin
                /#10414558

                Очень сильно зависит от. Вот гляньте код habrahabr. Там, скажем, происходит дорисовка google analytic и загрузка шрифтов. Скажем, я бы на телефоне отлично обошелся бы дефолтными, но нет.
                А некоторые сайты могут генерировать собирать себя через js, привет SPA.

                • Nickmob
                  /#10414570

                  SPA — да, там схема отличается. Вместо HTML-документа скорее всего будут AJAX-запросы и больше работы на клиенте.

  2. berezuev
    /#10414434 / +2

    Статья рассчитана на новичков, но примеров для них не указано совсем.
    Во-первых, для теста стоит упомянуть инструмент Google Pagespeed Insights.

    Также, всем интересующимся я рекомендую прочитать от корки до корки блог Ruhighload. Например, очень сильно лично мне помогла статья про асинхронное завершение выполнения php-скрипта.

    Ну и, напоследок, две статьи, по которым я уменьшил TTFB до >100мс в ряде php-приложений:
    habrahabr.ru/post/278189
    habrahabr.ru/post/278899

    • Nickmob
      /#10414460 / +1

      Использовать Google Pagespeed Insights можно, только, если понимаешь, что он тестирует. Для новичков часто эта оценка становится слишком важной и они пытаются изо всех сил её увеличить.
      Например, GPSI вообще не меряет время загрузки страницы (ни start render, ни load), а это важнейшие метрики.

      • berezuev
        /#10414490

        Любые действия нужно совершать только если понимаешь, зачем они.

        Но, как минимум GPSI советует включить браузерное кэширование, GZIP и оптимизацию ассетов. Если хотя бы три этих пункта применялись на всех сайтах, мир стал бы чуточку лучше.

        p.s. для полного умиротворения надо еще SSL на все сайты, где есть отправка данных пользователем.

        • Nickmob
          /#10414502

          Всё вышеперечисленное и даже больше есть в описанном в статье инструменте: Lighhouse, который сейчас стал закладкой Audits в DevTools Chrome.

  3. immaculate
    /#10414590 / +3

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


    Быстрые сайты — это минималистичные блоги каких-нибудь техногиков. Все остальное — жутко тормозит даже на современном железе и хорошем канале.

    • Nickmob
      /#10414596 / -4

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

  4. pm_wanderer
    /#10414628 / +2

    Для отложенной загрузки CSS можно воспользоваться динамическим подключением стилей через JS (дождавшись события domContentLoaded)

    И что это даст?

    • Nickmob
      /#10414632

      Сократит критический путь рендеринга: быстрее отрисуется страница.

      • pm_wanderer
        /#10414666

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

        • Nickmob
          /#10414672

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

          • pm_wanderer
            /#10414786

            А как выделить критичный css?
            Страница может открываться как на мобиле так и на 4k экране, где вероятно будет отображаться сразу полностью. Я считаю весь этот css critical-path лишним шаманством, которое не дает ощутих результатов, да и реализовано оно зачастую не качественно: страница вроде загрузилась, скроллишь ее вниз, все начинает тормозить и перестраиваться. И еще есть такой момент — на сайт могут перейти по ссылке, которая ведет на середину страницы, типа www.mysite.ru/index.html#about. И как быть в такой ситуации?

            • Nickmob
              /#10414914 / -3

              Вы здесь путаете расположение CSS в середине кода страницы и то, о чём говорится в статье: отложенной загрузке CSS через JS.
              К описанным выше проблемам при правильном применении отношения не имеет.

              • pm_wanderer
                /#10415072

                Вы имеете ввиду загружать сначала критичный css отдельным файлом, а потом весь остальной?

                • Psychosynthesis
                  /#10415322 / +1

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

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

            • mgremlin
              /#10415440

              Предположу, что тут имеется в виду тот css, который определяет структуру страницы: свернутое меню вместо списков html, flexbox, размеры заголовков, цвета фона — все то, без чего страница выглядит резко по-другому.
              А потом можно уже нагружать все остальное.

              Другое дело, что задача эта очень технически сложна, хотя в той же панели хрома можно найти список использованных селекторов css, да и standalone инструменты существуют. И делать ее придется для каждой страницы индивидуально. А на выходе легко получить нулевой выигрыш…

              • Nickmob
                /#10415524

                Не надо ничего вычленять. Представьте, что у вас на сайте используется фотогалерея (fancybox, lightbox не важно), у нее есть свой CSS (для слоёв и анимаций). Так вот его абсолютно спокойно можно грузить потом, никаких проблем.

                • mgremlin
                  /#10415716

                  Я такое никогда не использовал, потому не в курсе.
                  Есть пара вопросов: как выглядит эта галерея без css? Не как все фото в рядок, случаем? И второй: какого размера этот css? неужели это настолько прям может повлиять? Я сам — в познавательных целях — пробовал играть с этими вещами, и обнаружил, что на моих прожектах это все никакого смысла не имеет. Даже deferred pictures load почти не имеет, учитывая штраф от гугла.

                  Думается мне, тупая оптимизация картинок даст на порядок больший эффект. кэши всякие, работа с базой, агрессивный аякс…

                  • Nickmob
                    /#10415736

                    Галерея выглядит как надо. Подгружающиеся стили отвечают за открывание большой версии фото по клику.
                    Размер может быть от 10kb до 100kb, если это несколько плагинов.
                    Здесь дело не только в размере, но в приоритете загрузки CSS — он очень высокий (в отличие от картинок). Кроме того, CSS блокирует рендеринг страницы целиком, если объявлен в head.

                    • mgremlin
                      /#10415786

                      1. 100 кб css в зипленом виде на галерею?! В топку такие стили, вот честно. Нет смысла такое оптимизировать даже, как мне кажется.

                      2. А Inline js, которым вы собираетесь подгружать deferred css — не блокирует? 8-) проще — раз такая пьянка — выкинуть все ненужные стили вниз, и не заморачиваться. гугл, кстати, требует вообще все стили вниз отправлять, вне зависимости от критичности.

                      Лично я вообще привык, что, скажем, в среднем инетмаге на странице стили тянут на 10кб в зипе, а картинки — легко по 50 кб каждая, и будет их 20, 40, а то и 100. У неоптимизированных — еще и полсотни навигационных стрелочек загрузят. Примерно та же ерунда — в блоге, картинок меньше, зато они сами больше. А самое большое время занимает генерация динамической страницы…

                      У вас тут просят гик-порно — так вот если бы вы написали что-то типа
                      — — создаем «образы» страниц сайта — типа фреймов, полностью повторяющих структуру, но с условным бредом внутри, зато статических и очень быстрых.
                      — методами _ML/DL/что угодно_ при запросе определяем наиболее адекватную заглушку и выстреливаем ее
                      — с заглушкой грузится небольшой JS, который потом начинает аяксом подгружать кусками и актуализировать данные на странице.
                      результат: отстрел любого урла сайта — 0.6s DOM. Дальше вид и структура страницы уже принципиально не меняются — просто проявляются картинки вместо серых хэшей, чуть меняются(/проявляются в пустом месте) тексты, при этом заголовки и все такое — актуальны с самого начала.
                      — Вот это было бы интересно.

    • mgremlin
      /#10414658

      гугл оштрафует в выдаче за то, что пользователю сначала покажет не ту картинку 8-)

      • Nickmob
        /#10414664 / -1

        Во-первых, откуда у вас такая информация?
        Во-вторых, это не обзязательно приводит к перерисовке страницы.

        • mgremlin
          /#10414694 / +1

          1. на PI результат снижается — из непосредственно измеримого. И натурные эксперименты подтверждают (но это долго, и достоверность не 100%).
          2. если не приводит — тогда это не имеет смысла 8-) ну разве что в случае с фонтами.

          Конечно, мое высказывание скорее верно в отношении существенно более продвинутых методов, чем те детские примеры, что описаны в статье, но и css defer туда попадает тоже — теоретически разницы никакой.

          Кстати, это вообще вредный совет в ряде случаев: уже проводили массу исследований, и non styled flash приводит к куда большему падению конверсии, чем чуть более медленная загрузка.

          • Nickmob
            /#10414904

            Смысл имеет, если делать правильно: никакого FOUC не происходит.

            • mgremlin
              /#10415082

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

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

  5. mgremlin
    /#10414660 / +2

    Простите, но это какой-то набор банальностей.

  6. Karpion
    /#10415192 / +1

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

    • Nickmob
      /#10415510 / -1

      Так это будет проблема провайдеров, а не дизайнеров. Ничего не изменится.

      • Karpion
        /#10416286 / -2

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

        В общем случае я не верю в «невидимую руку рынка». Но в данном конкретном случае — я на неё надеюсь.

      • eov
        /#10416944 / -1

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

        • Nickmob
          /#10417032

          Даже если сократить размер трафика (шаблоны, картинки, CSS, JS) всех сайтов мира в 2 раза, провайдеры этого скорее всего не заметят: подавляющая часть это видео и голос, сайты даже рядом не стояли.

          • eov
            /#10417784

            подавляющая часть это видео и голос, сайты даже рядом не стояли.
            Видео — Да. Голос — скорее Нет. Голоса на фоне видео и торрентов не видно. Если-таки дело дойдет до хранения, то видео первое пойдет в исключение (статичное (не трансляции) не реально хранить и главное абсолютно бессмысленно). Второе от чего будут отказываться — это от гейминга и торентов (в их хранении тоже не много толка).
            Останутся сайты (соцсети, web-файлшаринг и web-почта), почта, голос, и месенджинг. Теперь давайте ранжировать по объемам то, что осталось…
            А если посмотреть всю картинку в целом, то в хранении экзабайт зашифрованного трафика скоро не будет смысла вообще (от слова совсем). Так что, получится что от оптимизации объемов сайтов:
            Ничего не изменится.

  7. Psychosynthesis
    /#10415326 / +2

    Для Хабра маловато гик-порно. В смысле «где код, Билли»?
    Большинство Хабраюзеров, интересующихся темой, уже давно все эти общие фразы знают. Вот если бы вы более подробно расписали, возможно кому-то было бы полезно. Тем более, что многие вещи по оптимизации уже придуманы и описаны (в том числе и на Хабре) до вас.

    • Nickmob
      /#10415512

      Полностью с вами согласен, острая нехватка гик-порно.