Pull to refresh

Comments 54

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

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

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

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

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

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

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

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

Ну и, напоследок, две статьи, по которым я уменьшил TTFB до >100мс в ряде php-приложений:
habrahabr.ru/post/278189
habrahabr.ru/post/278899
Использовать Google Pagespeed Insights можно, только, если понимаешь, что он тестирует. Для новичков часто эта оценка становится слишком важной и они пытаются изо всех сил её увеличить.
Например, GPSI вообще не меряет время загрузки страницы (ни start render, ни load), а это важнейшие метрики.
Любые действия нужно совершать только если понимаешь, зачем они.

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

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

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


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

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

Чаще всего не компромисс, а просто игнорирование вопросов скорости по причинам: «у меня всё работает» и «да чё там оптимизировать, щас у всех 4G».
Дык проблема не в скорости канала, а в производительности процессора… Типа открыл сайт с кучей перделок-свистелок — вентилятор на i7-5XXX завыл громче чем при полной сборке солюшена из нескольких тысяч проектов…
Проблема бывает и в скорости канала, и в CPU, зависит от конкретного сайта. Я привёл примеры отношения.
Поэтому я про отношение и не возразил -)

А так, да вполне жизненные варианты:
— если убрать в самом верху мультик из вертящихся двух десятков фоточек то загрузка сайта ускорится с 10 до 1 секунды
— нет, тогда некрасиво будет

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

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

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

Другое дело, что задача эта очень технически сложна, хотя в той же панели хрома можно найти список использованных селекторов css, да и standalone инструменты существуют. И делать ее придется для каждой страницы индивидуально. А на выходе легко получить нулевой выигрыш…
Не надо ничего вычленять. Представьте, что у вас на сайте используется фотогалерея (fancybox, lightbox не важно), у нее есть свой CSS (для слоёв и анимаций). Так вот его абсолютно спокойно можно грузить потом, никаких проблем.
Я такое никогда не использовал, потому не в курсе.
Есть пара вопросов: как выглядит эта галерея без css? Не как все фото в рядок, случаем? И второй: какого размера этот css? неужели это настолько прям может повлиять? Я сам — в познавательных целях — пробовал играть с этими вещами, и обнаружил, что на моих прожектах это все никакого смысла не имеет. Даже deferred pictures load почти не имеет, учитывая штраф от гугла.

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

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

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

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

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

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

И уж точно эти рецепты не имеют ничего общего с уровнем компетенции, описанным в статье.
Боты и гугл в частности берет страницу в том виде, в котором она находится после window.onload, $(document).ready и прочих «DOMContentLoaded». Во-первых посмотрите как боты рендерят их при тестах (со схлопнутыми менюшками), во-вторых lazy load картинки принимались бы за одну (заглушку) и не индексировались.
Ну да. Тут в том и трюк, что необязательные элементы — некритичный css и картинки (особенно, находящиеся за пределами экрана) грузятся после DOMContentLoaded JS-скриптом.
Иначе никакого выигрыша и нет…
И выходит, что после события ready страница меняется, что гугл и поставит на вид.
Простите, но это какой-то набор банальностей.
Может быть, но более 100 человек добавили эту статью в закладки. Интересно, зачем?

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

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

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


Потерять придётся как минимум деньги на эту работу, заплаченную разработчику.
Так что «ничего не потерять» невозможно.
Ну, если вы называете любое вложение средств в проект «потерей», то да.

Статья не актуальна по всем параметрам.

Начиная с методов замера скорости загрузки. Даже если вы измеряете из Dev Tools, то измерение происходит с вашего ПК. Ваш ПК по CPU и сети, явно будет гораздо мощнее любого смартфона. Поэтому данные замеры без троттлинга не будут говорить ни о чем.

Измерить можно по-прежнему на PageSpeed и на loading.express можно получить данные от замера lighthouse и Core Web Vitals. Эти кнопки там есть после замера внизу.

Как раз наоборот - замер PageSpeed для большинства сайтов неактуален, так как тест производится из Европы, с большими задержками до России. Использовать троттлинг в DevTools также никто не запрещает, там есть и по сети и по CPU.

Всё верно, из Европы, а про какие задержки речь? TTFB не учитывается в замере PageSpeed, но указывается.

А фронт с задержками не может отдаваться, какая разница в Хроме из какой страны открывать сайт, LCP, FCP, CLS — оно и в Африке будет LCP, FCP, CLS и разницы из-за ГЕО не будет никакой. Именно поэтому Core Web Vitals — это та собирательная метрика, на которую можно опираться при анализе.

Sign up to leave a comment.