Как реализовать асинхронную загрузку CSS специально для PageSpeed Insights?

Question

[amorphine]

Имеется проект, по которому заказчик хочет получить "зеленые карточки" PageSpeed Insights ( >= 85 баллов). Фронтенд сторона проекта представляет из себя монолитный кусок CSS от старых разработчиков размером ~350 кбайт + 400 кбайт CSS от fancybox, semantic и десятка других фреймворков/непонятно чего. В общем, минифицированные и конкатенированные CSS весят >700 кбайт.
Результаты PageSpeed на данный момент 63 - мобильная и 79 - десктопная версия сайта. Рекомендовано "оптимизировать" и "избежать блокировки" css-файлами при загрузке страницы.
Первое, что было сделано - использование uncss, что в три раза снизило "вес", однако PageSpeed не придал этому значения. Так же был использован популярный метод динамической загрузки css через манипуляции с аттрибутом media:

link href="/css-skin/skin-blue.css" rel="stylesheet" media="none" onload="media='all'"

Но и тут PageSpeed словно игнорирует динамическую загрузку, считая, что рендер все равно не начинается без подгрузки этих файлов.
Ради эксперимента перед изменением media был задан таймаут в 10 секунд. На этот раз голую страницу без CSS PageSpeed принял как родную и дал "зеленые карточки". Естественно, оставлять посетителей без css на 10 секунд не то, что нужно, чтобы угодить PageSpeed. Посоветуйте, как можно решить этот вопрос?
Были испробованы:
1. подгрузка css из js - PageSpeed считает их блокирующими,
2. использование rel=preload (на данное время поддерживается лишь Chrome 50, дает хорошие результаты, но малораспространено),
3. Использование "критического" css - генерируемый утилитой critical инлайновый style дает нужные баллы только на главной странице. На подстраницах он уже не годится + мало баллов.
4. Интересная особенность - из утилиты ngrok хорошо себя показывает способ динамической загрузки через media + onload, а безCSS-ное безобразие на время загрузки прикрывается loader-ом. Однако будучи выгруженным на боевой сервер "динамические" css вновь оказываются "блокирующими"

Comments

[sim3x]

уже есть такой курс на аудасити
https://www.udacity.com/course/website-performance...

[Салават Ситдиков]

А вообще есть модуль для nginx - ngx_pagespeed, вроде как часть функционала он берет на себя.

Answer 1

[Салават Ситдиков]

В footer. Либо повесить на document.ready

<script type="text/javascript">
    var head = document.head
            , link = document.createElement('link');

    link.type = 'text/css';
    link.rel = 'stylesheet';
    link.href = '{{ css_file }}';
    head.appendChild(link);
</script>

Comments

[Салават Ситдиков]

1. Комбинировать все css в один. Минимизировать их.
2. Включить сжатие для них. Если стоит nginx, модуль gzip_static и вместе с минимизированной версией сразу хранить сжатую (style.css.min.gz)
3. В блоке head иметь critical css для главной, для внутренних подругражть свой. Либо использовать объединенный critical для главной и внутренних.

[amorphine]

Салават Ситдиков: Если все CSS комбинировать в один, то начинает лагать верстка. Разделение логики и визуализации - это не про этот проект.
critical css так же вызывает сбои в работе верстки, хотя и дает хорошие баллы.

[Салават Ситдиков]

amorphine: не спорю. У самих та же проблема, но подчистили critical - чтобы не так страшно было.

[amorphine]

Салават Ситдиков: critical вручную делали, получается? Видимо, действительно critical css - единственный способ поладить с PageSpeed

[xmoonlight]

Салават Ситдиков: вплане контейнера: гугл вообще советует под html-тэг: https://developers.google.com/speed/pagespeed/modu...

[Салават Ситдиков]

amorphine: через плагин css remove and combine для начала - а потом ручками чистили уже.

Answer 2

[xmoonlight]

100/100 x2
precosts.com
Смотрим исходник и тестируем
Делаем аналогично.
PS: вся соль в минификаторе CSS который выдаёт строку в инлайн через echo динамически (соотв., на сервере - она в кэше) и выносим вниз остальное, что не критично для первичной разметки.
PS2: Считаю, что время загрузки (избавляясь от JS) дороже валидации недоговорившихся валидаторов гигантов IT-индустрии при корректной работе решения на большинстве устройств, поэтому тэг link - стоит внутри body, несмотря на правила сообщества w3c.
Иными словами: между JS-надстройками для отложенной загрузки CSS и неверной (с точки зрения валидации w3c), но рабочей разметке - лучше выбрать разметку, минимизировав нагрузку на клиентское устройство в момент рендеринга страницы.
PS3: Вот еще неплохой сервис для проверки: www.webpagetest.org
(пошел "полировать до блеска" свой код )))
---------------
Все линки на тесты: тут
Еще пару ресурсов по советам оптимизации:
Yahoo: https://developer.yahoo.com/performance/rules.html
Google: https://developers.google.com/speed/pagespeed/modu...
--------------
PS4: Про "critical CSS":
Можно вставить слегка переделанный скрипт из ответа на SO на все страницы и собрать стили по каждому URLу, запустив по всем линкам crawler и потом - найти пересечения между ними (П1).
Затем - объединить (merge) все возможные стили (О1), которые грузятся из файлов на сервере и снова найти пересечения между П1 и О1.
Результатом и будет искомый "critical css".

Comments

[Салават Ситдиков]

Тег link должен находиться в head, вроде как. Нет?

[amorphine]

Спасибо, что нашли время на ответ.
Данный способ хорошо себя показывает на небольших страницах. Все CSS страницы вмещаются в строку. Здесь же имеется проект на ~30 тыс строк css-правил, причем правила тянутся аж с первого запуска сайта, никто никогда не занимался никакой чисткой и упорядочиванием. Помимо самого старого "ядра" - минифицированная масса которая отвечает "за все понемногу" сюда добавляются CSS кучи фреймворков + фиксы, которые вносятся в процессе сопровождения. Выделить логически из этого гордиева узла тот самый критический CSS, который можно заинлайнить, невозможно. Автоматические средства дают такой critical css, что верстка начинает разваливаться.

[xmoonlight]

amorphine: https://www.npmjs.com/package/browserify-css

[xmoonlight]

Салават Ситдиков: с точки зрения w3c - да, я нарушил. Однако, в данном случае (ввиду разрозненности валидаторов-гигантов), я готов променять время работы JS-надстройки на загрузку CSS через onload на неверную разметку и поставить хак: условие для скрытия линка от w3c валидатора.
Здесь, к сожалению, они не договорились с гуглом.)

Answer 3

[Дмитрий]

https://github.com/filamentgroup/loadCSS

Comments

[amorphine]

Спасибо за ответ.
PageSpeed все равно считает все подгружаемые CSS в процессе onload блокирующими. Хотя на данный момент этот способ дает наибольшее, но недостаточное, количество баллов, стоит признать

[Дмитрий]

amorphine:
>PageSpeed все равно считает все подгружаемые CSS в процессе onload блокирующими
на самом деле нет:
"Учтите, что под блокировкой подразумевается только приостановка вывода страницы. При этом браузер скачивает все CSS-файлы независимо от того, блокируют они вывод или нет. Приоритет скачивания выше у тех файлов, без которых вывод страницы невозможен."
https://developers.google.com/web/fundamentals/per...

Все будет хорошо, если вы разделите css на два файла, один critical, второй полный.
и первый либо вставите инлайн либо в хедере подключите, а второй через этот скрипт.

Как вариант, можно еще переложить все css на cdn. Если скорость загрузки с cdn будет выше, чем с вашего сервера, тоже пару баллов даст.

[amorphine]

dimasmagadan: Я неверно выразился. Имел в виду, что PageSpeed пишет ХХ% страницы можно загрузить без ожидания загрузки указанных далее файлов (и приводит список всех моих css, хотя все css-линки имеют аттрибут rel=preload или же вообще из JS подгружаются). По-медвежьи, тут нужно аппликацию стилей производить после событий onload, но это значит, что страница будет без стилей дольше времени, либо работать critical css.
Все ответы сходятся в одном: нужно выработать оптимальный critical css. Спасибо

Answer 4

[Dolosweb]

У меня ccs файлы максимум 2-10 кб, грамотное построение и наследования. Не знаю даже 400кб css в нем роман война и мир между строк записан наверное. В любом случае css надо менять, в погоне за циферками - реальный результат будет реальным.