Badoo corporate blog
High performance
Website development
JavaScript
Programming
Comments 39
+8
34. Не делайте все это сразу после создания репозитария проекта.
0
+1, все действительно ни разу не просто. Более того, не стоит воспринимать статью как набор ачивок, это может только навредить.
0
Не рекламы ради, но блин, как приятно для глаза работает сайт автора… Статья в закладку!
+1
(в США достигнут порог 50-процентного внедрения)

По ссылке 26.66%

+4
Никак не могу понять, как люди справляются с рекомендацией насчет стилей для первой видимой части страницы, «CSS без прокрутки экрана».

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

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

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

Уверен, что какой-то синтетический пример придумать можно, но в жизни мне такие не встречались. А вам?

UFO landed and left these words here
-2
Посмотрите инструменты вроде criticalcss. В чем проблема вычислить critical-часть для каждой страницы, а потом подгрузить остальной?
UFO landed and left these words here
UFO landed and left these words here
+1
Если все разбито на компоненты, сами подключающие свои стили, то при сборке c webpack можно выделить нужные компоненты для «первой видимой части страницы» в отдельный бандл и сперва загрузить только его, либо вообще заинлайнить html/css выхлоп, если доступен server-side rendering.
0
Вам наверное будет вот это интересно почитать про критический css. Есть инструменты которые позволяют его вычислить. Вообще если ваша страница с заинлайненным css весит меньше 14К то оно вообще и не требуется.
+1

Очень раздражает, когда в погоне за скоростью отрисовки, выводят текст, но без форматирования страницы. Начинаешь читать, а тут погружается баннер/картинка, и тебя перекидывается в произвольное место текста (на страницу вверх или вниз). И начинаеш искать, а где я читал?

+4
Еще хуже, когда загрузилось меню, я по нему кликаю, но за миллисекунду до этого грузится баннер, сдвигает меню вниз и мой клик приходится угадайте куда? И это не какой-то там MFA-сайт, это один из самых крупных отечественных банков.

P.S. Дорогие TM, уже несколько версий в андроид-приложении сидит этот баг — оцениваешь или отвечаешь на комментарий, а плюсик или ответ улетают соседнему комменту сверху!
0
Особая благодарность автору за instantarticles. Про AMP я знал, а это…
В общем я увлекаюсь последнее время подобными технологиями. Считаю, что это типо mobile 2.0 (то что раньше делали m.my.domain).

По поводу асинхронной загрузки. Я тоже пытался сделать Google Page Speed 99%, но у меня это пришло к тому, что у меня страница просто лагала, когда я все асинхронно загружал.

Как сделать так, что бы некие минимальные стили bootstrap-а грузились вместе со страницей а все остальное варьево позже? Это нужно для того, что бы страница от асунка не лагала. Расковыривать бутстрап я не решился, а готовых решений не нашел
0

14кб — это «бюджет» вообще всей первой загрузки по TCP, а вовсе не только CSS.

-1
Если речь идет не о HTTP 2.0, то все равно за каждым файлом открывается отдельное соединение. Поэтому 14кб на файл.
0

Там разговор про 14кб идёт именно в контексте критического СSS («включите в <head>» звучит немного неоднозначно, но когда говорят про critical rendering path, то имеют ввиду именно инлайн), так что тут 14кб на всё про всё.
Если бы мы отправляли критический CSS отдельным файлом и без HTTP/2, то тогда так бы и было.
Но я не встречал, чтобы кто-дь предлагал такой вариант. Если уж мы делаем критический CSS, то выводим его инлайн. Иначе это лишний round-trip, который довольно критичен.

+3

Если не использовать все эти новомодные JS фреймворки то скорость и так выше некуда.
Мне кажется мы сами себе придумали проблему, а теперь героически её решаем.

0
Слышали ли вы про layout trashing и как с ним бороться? Через request animation frame. Ок, но тогда нужно как-то узнать в raf нужно ли действительно перерисовываться или лезть в DOM за новыми значениями? Следовательно, вам нужно отделение сухих данных для ui и какой-то механизм проверки их на изменения. Так вот, когда вы напишете свою реализацию глубоких проверок и вычленения нужных DOM-нод для последующего обновления, вы поймете, что свелосипедили React.

Так что нет, скорость ни разу не «выше не куда», а эти «новомодные JS-фреймворки» решают существующие, а не надуманные, как некоторым хотелось бы верить, проблемы.
+1

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


ЗЫ а для решения "layout trashing" надо больше css юзать, а не через JS всё проставлять.

0
А, вы про это, ну тут да, согласен. Имея молоток, все кажется гвоздями.

Далеко не всегда хватает css. Для сайтов достаточно, для какого-то интерактива уже нет.
0
Поскольку формат разработан Google, неудивительно, что браузеры принимают его только при посещении сайтов через HTTPS.


Does not compute
+2
Сегодня Brotli не предустанавливается на большинстве серверов, и его не так просто настроить без перекомпилированных NGINX или Ubuntu.


????

Отсутствие смысла, вероятно, вызвано незнанием переводчиком предметной области, потому внесу ясность: для использования бротли нет необходимости перекомпилировать веб-сервер и уж тем более Убунту (особенно для тех, кто использует другую ОС). Достаточно собрать соответствующий модуль от google или cloudflare и динамически подключить его, для чего nginx понадобится только лишь перечитать конфиг и всё.

Автору топика в любом случае спасибо за труд, материал полезный и актуальный для широкой аудитории.
0
Спасибо, за замечание — сейчас поправлю. опыта с brotli действительно не было.
0
Спасибо за перевод.
Какие-то моменты знал и использовал, какие-то не знал и лично я использовать вряд ли буду (всё-таки много специфичного для фронт-энд), но кое-что почерпнул нового для себя как бэк-эндщика.
0
Интересно, сколько стартапов похоронит эта статья?
Спасибо, много действительно полезных вещей!
Only those users with full accounts are able to leave comments.  , please.