Comments 39
Эх, если бы все было так просто :[
(в США достигнут порог 50-процентного внедрения)
По ссылке 26.66%
Лично у меня не было ни одного проекта, где можно было бы отдельно выделить стили, которые позволили бы нормально отрисовать первую видимую часть страницы.
Я могу выделить стили, которые нормально построют каркас страницы, могу выделить стили для раскраски, для заполнения бэкграундом, для оформления текста, для установки шрифтов, для анимации…
И да, я это могу все подгружать не сразу, но вот выделить стили, которые позволят нормально показать верхнюю часть, а потом уже стили, которые покажут нормально все остальное, я никогда не видел в природе.
Уверен, что какой-то синтетический пример придумать можно, но в жизни мне такие не встречались. А вам?
Очень раздражает, когда в погоне за скоростью отрисовки, выводят текст, но без форматирования страницы. Начинаешь читать, а тут погружается баннер/картинка, и тебя перекидывается в произвольное место текста (на страницу вверх или вниз). И начинаеш искать, а где я читал?
P.S. Дорогие TM, уже несколько версий в андроид-приложении сидит этот баг — оцениваешь или отвечаешь на комментарий, а плюсик или ответ улетают соседнему комменту сверху!
В общем я увлекаюсь последнее время подобными технологиями. Считаю, что это типо mobile 2.0 (то что раньше делали m.my.domain).
По поводу асинхронной загрузки. Я тоже пытался сделать Google Page Speed 99%, но у меня это пришло к тому, что у меня страница просто лагала, когда я все асинхронно загружал.
Как сделать так, что бы некие минимальные стили bootstrap-а грузились вместе со страницей а все остальное варьево позже? Это нужно для того, что бы страница от асунка не лагала. Расковыривать бутстрап я не решился, а готовых решений не нашел
14кб — это «бюджет» вообще всей первой загрузки по TCP, а вовсе не только CSS.
Там разговор про 14кб идёт именно в контексте критического СSS («включите в <head>» звучит немного неоднозначно, но когда говорят про critical rendering path, то имеют ввиду именно инлайн), так что тут 14кб на всё про всё.
Если бы мы отправляли критический CSS отдельным файлом и без HTTP/2, то тогда так бы и было.
Но я не встречал, чтобы кто-дь предлагал такой вариант. Если уж мы делаем критический CSS, то выводим его инлайн. Иначе это лишний round-trip, который довольно критичен.
Если не использовать все эти новомодные JS фреймворки то скорость и так выше некуда.
Мне кажется мы сами себе придумали проблему, а теперь героически её решаем.
Так что нет, скорость ни разу не «выше не куда», а эти «новомодные JS-фреймворки» решают существующие, а не надуманные, как некоторым хотелось бы верить, проблемы.
Вы не поняли моего мессаджа. React и собраться сделаны для реализации веб приложений и в этом случае наверное от их аналогов никуда не деться, но сейчас на них начинают клепать сайты которые великолепно бы легли на шаблоны сервера и работали бы мега быстро даже с полным обновлением страницы.
ЗЫ а для решения "layout trashing" надо больше css юзать, а не через JS всё проставлять.
Поскольку формат разработан Google, неудивительно, что браузеры принимают его только при посещении сайтов через HTTPS.
Does not compute
Сегодня Brotli не предустанавливается на большинстве серверов, и его не так просто настроить без перекомпилированных NGINX или Ubuntu.
????
Отсутствие смысла, вероятно, вызвано незнанием переводчиком предметной области, потому внесу ясность: для использования бротли нет необходимости перекомпилировать веб-сервер и уж тем более Убунту (особенно для тех, кто использует другую ОС). Достаточно собрать соответствующий модуль от google или cloudflare и динамически подключить его, для чего nginx понадобится только лишь перечитать конфиг и всё.
Автору топика в любом случае спасибо за труд, материал полезный и актуальный для широкой аудитории.
Какие-то моменты знал и использовал, какие-то не знал и лично я использовать вряд ли буду (всё-таки много специфичного для фронт-энд), но кое-что почерпнул нового для себя как бэк-эндщика.
Спасибо, много действительно полезных вещей!
33 способа ускорить ваш фронтенд в 2017 году