Сервис PageSpeed от Google дает рекомендацию удалять из верхней части страницы блокирующий код, в том числе и подключение CSS файлов - их загрузка блокирует отображение HTML. Проблема в том, что если мы перенесем подключение CSS к </body>, то сначала посетитель увидит страницу с дефолтными стилями браузера, затем страница моргнет и применятся стили от сайта. Что бы этого избежать необходимо в отдельный файл CSS выписать все правила, которые нужны для отображения первого экрана, затем из файла загрузить их инлайново в области HEAD, таким образом парсинг страницы браузером будет последовательным и быстрым. Естественно, что будет лучше, если файл будет сжат в одну строку, удалены все лишние пробелы и знаки табуляции.
Для решения этих задач я делаю следующее: 1. Выделяю в отдельный файл все необходимые стили для первого экрана; 2. Добавляю в /bitrix/php_interface/page_speed.php следующий код:
Здесь includeCSS проверяет, есть ли сжатая версия CSS, если нет, то создает её и выводит с помощью echo. А compressCSS удаляет много лишнего из CSS (но не всё, т.к. функция требует дополнительной отладки и проверки на множестве реальных проектах).
В области head страницы меняю $APPLICATION->SetAdditionalCSS на includeCSS. Все. Profit!
UPD1: Вариант использовать в готовых решениях по-быстрому: в папку с шаблоном кидаем functions.php с вышеописанным кодом, а в header.php пишем:
UPD2: Обратите внимание: редактор битрикса порезал код, в своем файле замените "st yle" на "style" UPD3: Обновил код. Теперь, при обновлении исходного CSS файла обновляется и кеш, удаляя старые версии кеша. UPD4: Подумал тут... надо бы сампоальное кеширование заменить штатным от битрикса. Так будет только лучше и надежнее. Не пойму, почему сразу так не сделал
Микулич Евгений, то что вы настраиваете в админке работает только со скриптами и стилями подключенными следующими методами: $APPLICATION->SetAdditionalCSS $APPLICATION->AddHeadScript
В моем варианте происходит замена SetAdditionalCSS на includeCSS. То есть инлайном выводится важная часть CSS, остальное придется подключать обычным <link внизу страницы, либо ShowCSS (или как-то так) с последующим отказом от ShowHead...
Микулич Евгений, по хорошему, нужно либо добавить параметров в setAdditionalcss что бы сделать её более гибкой, либо добавлять еще одну функцию. Кстати, когда вы нажимаете в настройках главного модуля галочку "Создавать сжату версию..." то на самом деле, сжатия как такового не происходит, то есть ничего подобного предложенному compressCSS.
А если пользователь заходит не на главную страницу, ну допустим, на детальку товара или новости- или сразу в корзину,, профиль и тд. может тогда сделать 1 css и минимизировать его (обфускация- например) и его загружать? так пробовали?
Черепанов Виталий, по идее, хорошо бы сделать самогенерируемый css для каждого типа страницы. Идея ведь в том, что бы подгрузить сначала необходимый для первого экрана CSS, там не должно быть ничего лишнего. Но вообще не пробовал. Пока стояла задача оптимизации только главной страницы.
Черепанов Виталий, я не это имел в виду. Имел в виду, что для каждой страницы скрипт должен сам определять, какие именно из существующих css правил необходимо включить в head для отображения первого экрана. Если вкратце, то алгоритм такой - парсим список существующих css селекторов, смотрим, какие из ссылаемых элементов находятся в области просмотра первого экрана, скажем на 1000px и выбирает их в инлайн, отсеивая всякие :hover, :active...
т.е. я так понимаю во время первого захода на сайт надо не ускорять загрузку, а наоборот использовать ПАРСЕР, чтобы вытащить все селекты страницы.... тогда смысл всего этого!
Черепанов Виталий, парсер запускать один раз - это как кеш получается. Первый хит - идет генерация CSS для данного типа страницы, а потом выдается из кеша - в моем примере из заметки именно такая методика и используется.
тогда интересно узнать результаты (время загрузки) 1. загрузка обычной страницы (т.е. загрузка с обычным шаблоном и всеми стилями и т.д.) 2. загрузка используя ВАШ метод 3. загрузка используя "КОМПОЗИТНЫЙ САЙТ" (хотя бы для одной страницы - для теста)
Черепанов Виталий, у всех способов подходы разные и назначение. Композитный нужен на случай, если на странице много ресурсоемких компонентов, тогда композитный сайт с html кешем выручит - страница загрузится быстро. "Мой" метод не сделает загрузку страницы быстрее, он её даже увеличит за счет увеличения кода html, но посетитель раньше(!) увидит содержимое страницы в том виде, в котором она должна быть.
Но, вообще, если проведете такой тест было бы интересно узнать результаты тем более, что я не представляю какую методику использовать при измерениях...
Постоев Олег написал: "Мой" метод не сделает загрузку страницы быстрее, он её даже увеличит за счет увеличения кода html,
и это не есть ГУД, надо стремится именно у уменьшению времени загрузки системы, и тогда пользователь еще раньше увидит нужную страницу так как надо....
Постоев Олег написал: Композитный нужен на случай, если на странице много ресурсоемких компонентов
ну почему Вы думаете что только при этому нужен композит, на обычных сайтах с небольшой динамикой композит ох как сильно влияет на время загрузки например мой сайт одностраничник - несколько выводов news.list и menu и все.... со 180 мс до 24мс.....
Хорошая вещь. Это актуально больше для мобильных устройств. И в первую очередь при первой загрузки сайта у пользователя, когда у него еще нет закешированных браузером подключаемых фалов. Я думаю композитный сайт только выиграет если к нему добавить эту метод загрузки важного CSS.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».