Comments 54
Думаю, что бы не грузить клиенты сайтамы, которые выедают все CPU и прочее, особенно если их можно один раз отрендерить (скорее всего) js'ом на сервере, если у вас какой-то angular или что-то еще.
Ну, там у вас есть "выполнение JS-кода", вот имеется ввиду, что довольно часто, значительную его часть можно попробовать вынести на сервере.
Очень сильно зависит от. Вот гляньте код habrahabr. Там, скажем, происходит дорисовка google analytic и загрузка шрифтов. Скажем, я бы на телефоне отлично обошелся бы дефолтными, но нет.
А некоторые сайты могут генерировать собирать себя через js, привет SPA.
Во-первых, для теста стоит упомянуть инструмент Google Pagespeed Insights.
Также, всем интересующимся я рекомендую прочитать от корки до корки блог Ruhighload. Например, очень сильно лично мне помогла статья про асинхронное завершение выполнения php-скрипта.
Ну и, напоследок, две статьи, по которым я уменьшил TTFB до >100мс в ряде php-приложений:
habrahabr.ru/post/278189
habrahabr.ru/post/278899
Например, GPSI вообще не меряет время загрузки страницы (ни start render, ни load), а это важнейшие метрики.
Но, как минимум GPSI советует включить браузерное кэширование, GZIP и оптимизацию ассетов. Если хотя бы три этих пункта применялись на всех сайтах, мир стал бы чуточку лучше.
p.s. для полного умиротворения надо еще SSL на все сайты, где есть отправка данных пользователем.
Странно, если скорость так важна, то почему все популярные сайты имеют страницы размером в мегабайты, которые загружают мегабайты стилей и десятки, если не сотни мегабайт картинок? Да еще и кучу трекеров-счетчиков и прочей подобной ерунды, которая вызывает ощутимое подтормаживание.
Быстрые сайты — это минималистичные блоги каких-нибудь техногиков. Все остальное — жутко тормозит даже на современном железе и хорошем канале.
Или дизайнеры и менеджеры, которые требуют максимум контента с эффектами и рекламы на страницу.
Для отложенной загрузки CSS можно воспользоваться динамическим подключением стилей через JS (дождавшись события domContentLoaded)
И что это даст?
Нужно делать с умом: только для тех стилей, которые не критичны для начального состояния страницы. Их подгрузка будет происходить незаметно для пользователя.
Страница может открываться как на мобиле так и на 4k экране, где вероятно будет отображаться сразу полностью. Я считаю весь этот css critical-path лишним шаманством, которое не дает ощутих результатов, да и реализовано оно зачастую не качественно: страница вроде загрузилась, скроллишь ее вниз, все начинает тормозить и перестраиваться. И еще есть такой момент — на сайт могут перейти по ссылке, которая ведет на середину страницы, типа www.mysite.ru/index.html#about. И как быть в такой ситуации?
К описанным выше проблемам при правильном применении отношения не имеет.
А потом можно уже нагружать все остальное.
Другое дело, что задача эта очень технически сложна, хотя в той же панели хрома можно найти список использованных селекторов css, да и standalone инструменты существуют. И делать ее придется для каждой страницы индивидуально. А на выходе легко получить нулевой выигрыш…
Есть пара вопросов: как выглядит эта галерея без css? Не как все фото в рядок, случаем? И второй: какого размера этот css? неужели это настолько прям может повлиять? Я сам — в познавательных целях — пробовал играть с этими вещами, и обнаружил, что на моих прожектах это все никакого смысла не имеет. Даже deferred pictures load почти не имеет, учитывая штраф от гугла.
Думается мне, тупая оптимизация картинок даст на порядок больший эффект. кэши всякие, работа с базой, агрессивный аякс…
Размер может быть от 10kb до 100kb, если это несколько плагинов.
Здесь дело не только в размере, но в приоритете загрузки CSS — он очень высокий (в отличие от картинок). Кроме того, CSS блокирует рендеринг страницы целиком, если объявлен в head.
2. А Inline js, которым вы собираетесь подгружать deferred css — не блокирует? 8-) проще — раз такая пьянка — выкинуть все ненужные стили вниз, и не заморачиваться. гугл, кстати, требует вообще все стили вниз отправлять, вне зависимости от критичности.
Лично я вообще привык, что, скажем, в среднем инетмаге на странице стили тянут на 10кб в зипе, а картинки — легко по 50 кб каждая, и будет их 20, 40, а то и 100. У неоптимизированных — еще и полсотни навигационных стрелочек загрузят. Примерно та же ерунда — в блоге, картинок меньше, зато они сами больше. А самое большое время занимает генерация динамической страницы…
У вас тут просят гик-порно — так вот если бы вы написали что-то типа
— — создаем «образы» страниц сайта — типа фреймов, полностью повторяющих структуру, но с условным бредом внутри, зато статических и очень быстрых.
— методами _ML/DL/что угодно_ при запросе определяем наиболее адекватную заглушку и выстреливаем ее
— с заглушкой грузится небольшой JS, который потом начинает аяксом подгружать кусками и актуализировать данные на странице.
результат: отстрел любого урла сайта — 0.6s DOM. Дальше вид и структура страницы уже принципиально не меняются — просто проявляются картинки вместо серых хэшей, чуть меняются(/проявляются в пустом месте) тексты, при этом заголовки и все такое — актуальны с самого начала.
— Вот это было бы интересно.
Во-вторых, это не обзязательно приводит к перерисовке страницы.
2. если не приводит — тогда это не имеет смысла 8-) ну разве что в случае с фонтами.
Конечно, мое высказывание скорее верно в отношении существенно более продвинутых методов, чем те детские примеры, что описаны в статье, но и css defer туда попадает тоже — теоретически разницы никакой.
Кстати, это вообще вредный совет в ряде случаев: уже проводили массу исследований, и non styled flash приводит к куда большему падению конверсии, чем чуть более медленная загрузка.
И уж точно эти рецепты не имеют ничего общего с уровнем компетенции, описанным в статье.
Если введут закон "провайдеры обязаны хранить всю передаваемую ими информацию", то вопрос размера сайта встанет очень остро. Может, хоть тогда дизайнеры перестанут пихать в страницы по десять байт мусора на каждый байт текста.
А затем сайтовладельцы начнут пинать дизайнеров.
В общем случае я не верю в «невидимую руку рынка». Но в данном конкретном случае — я на неё надеюсь.
подавляющая часть это видео и голос, сайты даже рядом не стояли.Видео — Да. Голос — скорее Нет. Голоса на фоне видео и торрентов не видно. Если-таки дело дойдет до хранения, то видео первое пойдет в исключение (статичное (не трансляции) не реально хранить и главное абсолютно бессмысленно). Второе от чего будут отказываться — это от гейминга и торентов (в их хранении тоже не много толка).
Останутся сайты (соцсети, 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 — это та собирательная метрика, на которую можно опираться при анализе.
Как ускорить загрузку сайта