Как загружать CSS файлы асинхронно
Одним из наиболее эффективных способов повысить производительность и скорость загрузки страниц сайта является асинхронная загрузка CSS файлов. При использовании этого способа не будет происходить лишняя задержка для загрузки страницы из-за рендеринга этих файлов.
Задержка связана с тем, что по умолчанию браузеры загружают подключаемые CSS-файлы синхронно – останавливая весь рендеринг страницы, пока каждый CSS-файл загружается и анализируется. Конечно, хотя бы небольшая часть CSS стилей сайта должна быть загружена до того, как странице будет разрешено начать рендеринг.
Для сайтов с небольшим объемом контента этот способ может и не пригодиться, но если размер CSS велик (скажем, больше 50–60 КБ), это может помочь производительности скорости загрузки сайта. Разделите стили и загружайте менее критичный CSS в фоновом режиме – т.е., асинхронно. В сегодняшней практической статье мы рассмотрим оптимальный способ для асинхронной загрузки CSS стилей.
Существует несколько способов асинхронной загрузки CSS, но ни один из них не лежит на поверхности. В отличие от файлов JavaScript, здесь отсутствует атрибут async
или defer
, который можно просто применить к элементу ссылки (тег <link>
). Однако в последнее время браузеры стандартизировали свое поведение при загрузке CSS, поэтому специальные скрипты (например, такой как loadCSS) вероятно, больше не нужны.
Сегодня, обладая небольшим знанием того, как браузер обрабатывает различные атрибуты элементов <link>
, мы можем добиться эффекта асинхронной загрузки CSS с помощью небольшой HTML строки. Вот пример самого простого способа асинхронной загрузки таблицы стилей CSS:
<link rel="stylesheet" href="{путь к css файлу}" media="print" onload="this.media='all'">
Что делает этот код
Эта HTML строка лаконична, но не очень понятна, поэтому давайте разберем, что здесь происходит.
Для начала атрибут media
для ссылки установлен на печать (print
). Печать – это тип носителя, который гласит: «применять правила этой таблицы стилей для печатных носителей» или, другими словами, применять их, когда пользователь пытается распечатать страницу. Следует признать, что мы хотим, чтобы наша таблица стилей применялась ко всем носителям (особенно к ПК и мобильным), а не только к печати, но, объявив тип носителя, который не соответствует текущей среде, мы можем получить интересный и полезный эффект: браузер загрузит таблицу стилей без задержки рендеринга страницы, т.е., асинхронно! Это полезно, но это не все, чего мы хотим. Мы также хотим, чтобы CSS действительно применялся к экранным устройствам (screen
) после его загрузки. Для этого мы можем использовать атрибут onload
, чтобы установить значение all
для всех медиа, когда браузер завершит загрузку.
Можно ли этого добиться с использованием
rel=preload
?Да, аналогично! В последнее время веб-мастера довольно активно использовали для ссылки rel=preload
(вместо rel=stylesheet
), чтобы получить аналогичное поведение, рассмотренное выше. Этот подход все еще хорошо работает, однако есть несколько недостатков, которые необходимо учитывать при использовании предварительной загрузки. Во-первых, поддержка предварительной загрузки в браузерах все еще невелика, поэтому необходимо использовать
К счастью, если вам нужен высокоприоритетный выбор, который обеспечивает rel=preload
(в браузерах, которые его поддерживают), вы можете объединить его с приведенным выше шаблоном, например так:
<link rel="preload" href="{путь к css файлу}" as="style"> <link rel="stylesheet" href="{путь к css файлу}" media="print" onload="this.media='all'">
Учитывая простую и декларативную природу приведенного выше кода, этот подход с использованием media="print"
имеет право на жизнь.
А почему бы не использовать недействительный атрибут для
media
?Да, можно использовать недействительный атрибут для media
, например, такой как «only х
», что позволит достичь того же эффекта, что и «print
». Когда браузеры сталкиваются с типами media, которые не могут определить, они пока относятся к ним одинаково – все равно загружают эти файлы. Тем не менее, некоторые браузеры начинают различать несоответствующие типы мультимедиа и недопустимые (или которые вообще не распознаются браузером), и, возможно, не будут загружать эти файлы. В целях безопасности мы рекомендуем использовать допустимый, но не соответствующий текущему типу, такой как
например.
Вот и все.
Надеемся, что сегодняшняя практическая статья была вам полезна. Спасибо за внимание!
Теги: CSS3
- 1476
- Опубликовано
- CSS, Уроки программирования
- прокомментируйте статью
- расскажите друзьям
WOW павлин | Как ускорить сайт на WordPress
5/5 — (1 голос)
Основной полезный ресурс PageSpeed Insights от Гугль для проверки скорости загрузки сайта.
https://developers.google.com/speed/pagespeed/insights/
В результате мы видим оценку (отдельно для мобильных устройств и для десктопа) и рекомендации по оптимизации. На картинке ниже — для desctop — в целом неплохо.
Ответ от базы данных MySql
Самое узкое место в работе CMS. База данных — это таблицы с данными, фактически файлы, которые хранятся на сервере.
Читаем статью
База данных MySql
Серверу нужно выбрать правильные записи, собрать страницу и отдать её браузеру для показа клиенту.
И чем база быстрее отвечает — тем быстрее клиент получит страницу. Но база рано или поздно разрастается, в ней добавляется мусор. И запросы обрабатываются медленнее.
Читаем статью
Чистим базу данных WP
Загрузка внешних ресурсов
Проверяем в первую очередь. Ваш сайт может работать идеально — но может ждать результатов загрузки с других ресурсов.
Это может быть:
- загрузка шрифтов Google (встроено в WordPress) — желательно отключить
- картинки с других сайтов — такого надо избегать
- внешние джаваскрипты и таблицы стилей
На самом деле — самая опасная тема для продвижения сайта. Например, были случаи, когда шрифт от Гугль грузился более 1 сек. Какие-то технические проблемы либо у Гугль, либо на канале интернета, либо опять кто-то чего-то заблокировал.
Тут же все вебмастеры выкинули предупреждение, что сайт грузится более 3 сек. А это уже чревато понижением в выдаче с поиска (и потом потребуется время для восстановления). Поэтому лучше загрузку всех внешних ресурсов отключать.
В идеале должно остаться только два внешних скрипта:
- счетчик Яндекс
- счетчик Google
Вот они.
Проверьте только, что бы сам код счетчика был последней версии. Современные версии асинхронные и на скорость загрузки сайта практически не влияют.
По этой же причине сейчас и Яндекс и Гугль предлагают устанавливать счетчики в header, а не в конец страницы.
Замедляют ли плагины работу сайта?
Довольно популярная тема для обсуждения на форумах. В целом плагины написаны на PHP и выполняются сервером (до того, как отдать результат браузеру и пользователю).
Т.е. как бы на работу плагинов затрачивается процессорное время на сервере, но в реальности оно ничтожно мало по сравнению с работой самого ядра WordPress. К тому нам нужно получить функциональный сайт, а не экономить процессорное время (можно взять тариф подороже на хостинге).
Можно ставить большое количество плагинов себе для украшения сайта и будет только польза? Вреда не будет?
Не всё так просто 🙁
а) Первая больная причина — плагины пишут живые люди и они могут ошибаться. Но ядро WordPress может даже работать с плагином, в котором есть ошибки PHP. Вот конечно время на обработку сильно добавляется.
Есть хороший плагин для разработчиков Query Monitor
Устанавливаем, смотрим на раздел «ошибки PHP» (и другие разделы), принимаем меры.
Из личного опыта — в плагине была ошибка, при вызове хука функция была без кавычек = но всё работало. Да, плагин Query Monitor ругался на неопределенную переменную (в двух местах — в самом плагине и в системном файле, который отвечает за подключение плагинов). Но ядро WordPress все-таки «понимало», что это указана функция, а не переменная — и плагин работал. Но время, время…. терялось сильно.
б) Вторая больная причина — плагины, они сложные, там у многих есть джаваскрипты и форматирование вывода (т.е. файл CSS). Итого сам сайт не замедляется, но с каждым таким установленным плагином скорость загрузки сайта замедляется на целых 0,2 секунды!
- 100 мс (в среднем) — на загрузку js
- 100 мс (в среднем) — на загрузку таблицы CSS
Вот например плагин popup для обратной связи
При загрузке сайта, будьте добры, потратить 180 ms (таблица стилей CSS и java script)
Итого 5 установленных плагинов = минус 1 секунда при загрузке сайта….
Для мониторинга временных затрат на использование плагинов устанавливаем P3 (Plugin Performance Profiler) и анализируем результат.
Смотрим за период использования (день, неделя и пр.) — анализируем «затраты» сервера PHP на работу активных плагинов.
Да — установленные и неактивные плагины только занимают место на сервере, на работе сайта это никак не сказывается.
Загрузка картинок
Вот отчет из сервиса PageSpeed Insights Гугль по скорости загрузки картинок.
В целом ничего не понятно, кроме предложений оптимизировать изображения.
На самом деле WordPress очень хорошо оптимизирован для показа картинок. Ключевые слова — «набор изображений srcset». Т.е. WordPress «умеет» под разные устройства отдавать изображения разных размеров (точнее умеет браузер и html5 — но движок WP всё правильно готовит). Нужно только соблюдать правила «гигиены»
- не использовать картинки с чужих ресурсов (ибо время)
- не использовать формат PNG (нужна Вам прозрачность в обмен на большой размер файла?), а использовать JPG (ибо есть сжатие jpg)
- не вставлять изображение через тэги html, а использовать медиабиблиотеку WordPress (и тогда будет работать scrset)
- не забывать устанавливать у каждой записи / страницы изображение страницы featured image
В двух словах — не надо вставлять в статью картинку PNG вручную через тэги HTML и не надо использовать в качестве миниатюры первую полноразмерную картинку. Используйте медиабиблиотеку WordPress (даже Гугль это пишет) — и будет Вам счастье.
Читаем статьи (и тогда плагины дополнительной навигации не будут брать первую полноразмерную картинку для анонса)
Как добавить картинки на сайт CMS WordPress
Миниатюры (thumbnails) записей и страниц WordPress
Используем плагин для контроля за миниатюрами
Плагин добавления колонки featured image в административной панели
Читаем, почему нельзя использовать внешние картинки для миниатюр
Миниатюра WordPress по URL
Загрузка скриптов и таблиц CSS
Посмотрим на загрузку таблиц стилей и скриптов
Таблицы стилей:
- 11 файлов
- максимально 1120 мс = 1,1 сек
Загрузка java script
- 9 файлов
- 790 мс = 0,8 сек
Общее время загрузки = 1910 мс или 1,9 сек
Что с этим можно сделать? Это «дорогие» файловые операции на сервере, попробуем оптимизировать загрузку.
Есть такой плагин для оптимизации Clearfy
Заходим в раздел «Производительность»
Выбираем вариант «оптимизировать» и проверяем результат. В загрузке появились файлы вида
…css/wmac_single_0e55521….css
…js/wmac_single_5001783….js
Это оптимизированные файлы, которые создал плагин в своей папке кэша /wp-content/cache/wmac/ Общее время загрузки уменьшилось до 1750 мс, немного выиграли.
Плагин еще предлагает объединить файлы — но тут необходимо вручную проверять результат внешнего вида сайта.
Резюме
Можно заметить, что в настоящее время ни скорость канала интернета, ни скорость работы сервера не оказывают существенного влияние на скорость загрузки сайта. Зато как много мелких дисковых операций:
- загрузка изображений
- загрузка таблиц стилей CSS
- загрузка java script
- загрузка самой страницы html (готовой из кэша) или загрузка файлов PHP для обработки сервером
- еще чтение из базы MySQL
Можно и нужно пойти другим путем — на хостинге поменять тариф, что бы там был SSD. В отличии от HDD — твердотельный накопитель хорошо работает с большим количеством мелких файлов.
Подпишитесь в VKontakte — нажмите кнопку | ||
Подпишитесь в Telegram — нажмите кнопку | ||
Наша группа ODNOKLASSNIKI |
Вы можете сохранить ссылку на эту страницу себе на компьютер в виде htm файла
Пишите на электронную почту (тема и email будут добавлены автоматически в письмо)
В Вашем браузере должна быть настроена обработка ссылок mailto
[email protected]
или просто скопируйте адрес e-mail
Почитать в разделе
WordPress
WordPress — система управления сайтом. Официальный сайт wordpress.org Изначально была ориентирована больше на ведение блогов, но и обычный сайт на этой системе можно сделать неплохой. Первый релиз был выпущен в мае 2003 года. Система написана на PHP, поддерживает базы MySQL. Возможно создание нескольких сайтов под управлением одной копии системы (в одной базе MySQL будут использованы разные префиксы таблиц для разных сайтов). Большим плюсом является поиск и установка плагинов непосредственно из административной панели.
Система CMS WordPress позволяет: создавать страницы (page), для показа на сайте их нужно добавить в меню
создавать записи/посты (post) для своего блога (новости,…
- Всего статей в разделе: 11
- Показано статей в списке: 10
- Сортировка: название по алфавиту
«Мусорные» страницы
Страницы конечно не «мусорные» (это обеспечение расширенных возможностей WordPress), но они реально мешают в продвижении. И да — эти страницы сделаны движком WP без Вашего участия. Такие особенности движка WordPress. 1. Страницы так называемых вложений. Под каждую картинку WP создает отдельную страницу для этой картинки.
WP Cron — планировщик задач
WP Cron — это планировщик задач для Вашего блога Помимо стандартных задач WordPress (проверка обновлений и прочее) — сюда также дописывают свои задачи плагины. Важно видеть, что там есть в расписании — потому что вся эта дополнительная деятельность грузит сервер. Крон также отвечает за публикацию отложенных записей, автопостинга в социальные сети. Название Cron взято из UNIX-подобных операционных систем. Образовано от греческого слова χρόνος (хрόнос) — время. Вот подробная статья
WP Cron (планировщик задач)Файл wp-cron.php находится в корневой директории сайта Как работает WP Cron А работает он очень интересно.
(Читать полностью…)
Базовые настройки темы Graphene
Рассмотрим одну из привлекательных тем для WordPress — Graphene.
Тема устанавливается как обычно — поиск — установить — активировать.
Можно также скачать с сайта разработчика www.graphene-theme.com
Тема прелесть:
— адаптивный дизайн (т.е. и на ПК и на телефоне будет по разному показываться)
— можно задавать двух- или трех- колоночный дизайн
— можно выбирать ширину колонок и ширину основного макета сайта
— при выводе постов можно добавить свой баннер
— можно сделать бесконечную прокрутку постов — как в Facebook
— можно выбирать, какие категории постов показывать на главной странице
— и да, можно сохранить все настройки темы в отдельный файл
Смотрим основные настройки Общая…
Базовые темы WordPress
Посмотрим на базовые темы WordPress, которые устанавливаются по умолчанию в системе. Можно обратить внимание, что название темы образовано по году ее анонса 🙂
Например, Twenty Ten = 2010 Итак, список базовых тем WoedPress по порядку.
Twenty Ten — базовая тема для WordPress до версии 3.4 включительно Тема для WordPress стильная, настраиваемая, простая и читабельная. Сделайте ее своей с произвольным меню, изображением заголовка и фоном. 2010 год
поддерживает шесть областей виджетов (две на боковой панели, четыре в подвале)
автор поста — показывается (не отключается в настройках — только дополнительный плагин)
картинка по умолчанию над заголовком — не…
Выбор темы для сайта на WordPress
Выбираем внешний вид сайта. Что тут сложного? Собственно — формат внешнего вида сайта обычно такой. Но следует понимать, что WordPress как бы состоит из двух частей — собственно «движка» сайта и «темы», которая определяем его внешний вид. Т.е. один и тот же сайт после смены темы будет выглядеть совершенно по другому.
(Читать полностью…)
Дочерняя тема WordPress
Зачем нужна дочерняя тема? В двух словах — разработчик периодически выдает обновления своей темы.
Если тему обновить — то все наши ручные правки пропадут.
Предвижу возражения — «я там ничего не правил, все сделано стандартными методами…». Я тоже так думал, это как бы как с движком WordPress — можно периодически обновлять, будут исправлены какие- ошибки и будут добавлены новые..
Да, только в случае с темой это становится критичным. Кто-то где-то сделал ошибку в новой версии темы — и всё, сайту конец 🙁 Что-то съехало, что-то перестало показываться. К тому же предполагается, что тема отвечает только за вывод.
Но некоторые разработчики добавляют разный функционал в тему,…
(Читать полностью…)
Кэширование WordPress
Зачем нужно какое-то кэширование? Немного английского языка: cash — наличные деньги
cache — кэш, буфер для хранения чего-либо
на русском звучит одинаково 🙂
Вспоминаем, из чего состоит сайт: простой текстовые документ HTML при работе CMS изначального этого документа не существует
его собирает сервер (для WP — движок на PHP) ссылка в этом документе на картинки, которые надо показать
вызовы файлов CSS (таблицы стилей — инструкции браузеру, как показать HTML страницу)
вызовы в этом документе разных скриптов (JS, библиотека JS jquery) скрипты могут загружаться с Вашего хостинга (Ваши скрипты)
внешние скрипты (счетчики, реклама и…
(Читать полностью…)
Подготовка блога WP к работе нескольких авторов
Несмотря на то, что у блога WP может быть много пользователей (и авторы в том числе) — необходимо дополнительно подготовить блог к многопользовательской работе. Добавляем аватар пользователя (автора)
По умолчанию для аватаров в WordPress используется сервис Gravatar. Но с применением плагина Simple Local Avatars можно использовать картинку из медиатеки WordPress. В настойках пользователя появляется возможность загрузить свой аватар.
Организуем дополнительную защиту блога
Читаем основную статью про защиту сайта на CMS WordPress
Защита WP
Авторов будет несколько, они будут создавать контент — его тоже надо защитить.
Читаем статью
Защита текста и картинок от…
(Читать полностью…)
Чистим базу данных WP
Откуда в базе данных появляется мусор? Собственно — чем больше база данных (число таблиц, размер в байтах) — тем медленнее работает сайт. Основная самая «дорогая» процедура по времени — запрос к базе данных.
Что такое вообще база данных — читаем статью
База данных MySql
Итак, мусор: редакции записей и страниц (WP заботливо сохраняет всю историю изменений после нажатия кнопки «Обновить»)
некоторые лпагины по умолчанию не чистят свои таблицы (например TOP10 ведет ежедневную статистику с записью в базу — а галочку «очищать более 180 дней» надо ставить самостоятельно)
забытые таблицы от удаленных плагинов (таблица не используется, но занимает место на. ..
(Читать полностью…)
Что хранится в файле wp-config.php
Файл wp-config.php нужен для хранения основных настроек CMS WorfPress Вашего сайта. Сам файл wp-config.php представляет из себя обычный PHP скрипт, в котором определены разные классические переменные вида: $var (как и положено в PHP со знаком доллара)
определенные константы через функцию PHP define()
При старте WP этот файл подключается стандартным образом через функцию include PHP = и указанные переменные становятся доступны движку WP. Файл wp-config.php загружается до файлов ядра Вордпресс, то есть если вы измените значение какой-то константы, то изменения коснутся всего сайта.
Файл wp-config.php создается при установки WP на хостинг на основе шаблона…
(Читать полностью…)
Асинхронная загрузка CSS — База знаний WP Rocket
Мы рекомендуем Удалить неиспользуемый CSS в качестве метода оптимизации CSS. Асинхронно загружать CSS следует использовать только в том случае, если есть проблема с удалением неиспользуемых CSS.
Кроме того, асинхронную загрузку CSS нельзя включить одновременно с удалением неиспользуемых CSS.
Параметр Загружать CSS асинхронно учитывает рекомендацию PageSpeed:
Устранение ресурсов, блокирующих рендеринг
Это выполняется автоматически:
- Создание критического пути CSS, необходимого для отображения видимой части вашего веб-сайта
- Асинхронная загрузка всех остальных файлов CSS, то есть отложенная, без блокировки рендеринга.
Примечание: Эта функция автоматически отключается в средах, где для константы WP_ENVIRONMENT_TYPE
установлено значение local, поскольку для создания CSS критического пути необходимо установить соединение с инструментом WP Rocket.
В настоящей статье
- Как создается CSS критического пути
- Критический путь для мобильных устройств CSS
- Создать критический путь CSS для определенной страницы/сообщения
- Как проверить работоспособность
- Когда регенерировать критический CSS
- Предотвращение автоматического создания критического CSS
Как создается CSS критического пути
При активации Загружать CSS асинхронно , CSS критического пути будет сгенерирован для вашего веб-сайта в фоновом режиме и добавлен при загрузке следующей страницы. После этого CSS будет загружаться без блокировки рендеринга на вашем сайте.
Наш внешний инструмент извлечет первую запись каждого общедоступного типа сообщений (сообщения, страницы, продукты и т. д.), а также общедоступные страницы архива таксономии (категории, теги, категории продуктов и т. д.). Он извлечет CSS критического пути для каждого из этих типов страниц отдельно и отправит код обратно в плагин WP Rocket, который затем добавит его на соответствующие страницы по запросу посетителя или в предварительный загрузчик кеша WP Rocket.
CSS критического пути будет удален после загрузки страницы. Это должно помочь предотвратить проблемы с макетом, когда сайт внедряет JavaScript или обновляет классы CSS после применения CSS критического пути.
CSS хранится в следующей папке на вашем сервере: /wp-content/cache/critical-css/
Будут внесены некоторые изменения в код:
- Относительные пути к изображениям и шрифтам будут автоматически изменены на абсолютные URL-адреса.
- Критический CSS будет тщательно обрезан и минимизирован. Это означает, что все необходимые пробелы (например, внутри операций
calc()
) или обратные косые черты (например,'\f311'
для глифа в иконочном шрифте) будут сохранены.
Если вы видите уведомление об ошибке администратора при создании критического CSS, обратитесь к нашему руководству по устранению неполадок.
Критический путь для мобильных устройств CSS
Если вы активировали Отдельные файлы кеша для мобильных устройств, на вкладке «Кэш», плагин сгенерирует 2 набора критически важных CSS — один для рабочего стола и один для мобильных устройств.
Всякий раз, когда вы повторно создаете CSS критического пути для своего сайта, CPCSS для мобильных устройств будет автоматически установлен.
Как создать критический путь CSS для конкретной страницы/записи
Если на ваших страницах есть CSS, которые различаются в зависимости от типов контента, и вам необходимо создать определенный CSS критического пути для конкретной страницы или публикации, вы можете сделать это на экране редактирования для этого контента.
В мета-окне WP Rocket Options нажмите кнопку: Создать конкретный CPCSS
Для этой страницы будет создан CSS критического пути. Если вам больше не нужен CPCSS для конкретной страницы, вы можете удалить его, нажав кнопку: Вернуться к CPCSS по умолчанию
ПРИМЕЧАНИЕ. Если вы видите ошибку 403 при нажатии кнопки «Восстановить», это, вероятно, означает, что функция безопасности на вашем сайте блокирует наш запрос REST API.
Как проверить, работает ли асинхронная загрузка CSS
1. В источнике страницы найдите:
- тег в стиле ракетно-критического CSS:
- Для каждой ссылки на таблицу стилей будут добавлены следующие атрибуты:
-
отн='предварительная загрузка'
-
as="style" onload="this.onload=null;this.rel='stylesheet'"
-
асинхронная ракета данных = "стиль"
- Включить параметр Асинхронная загрузка CSS
- Переключить тему
Итак, ссылка
вот так:
example.org/wp-content/themes/twentytwenty/style.css?ver=1.6' media='all' / >
становится:
2. В PageSpeed файлы CSS больше не будут отображаться как блокирующие рендеринг
Когда регенерировать критический CSS
Когда вы вносите изменения в таблицы стилей или добавляете/изменяете пользовательский CSS с помощью настройщика WordPress (или плагина), вам следует вручную повторно сгенерировать критически важный CSS через меню панели инструментов WP Rocket:
Критический CSS будет автоматически воссоздан, если вы:
Предотвращение автоматического создания критического CSS
Вы можете предотвратить автоматическую генерацию критического CSS, установив следующий вспомогательный плагин.
📥 Загрузить (.zip): WP Rocket | Нет автоматического создания критического CSS
Разработчики: вы можете найти код этого плагина на GitHub.
Для устранения проблем с дисплеем, связанных с этой опцией, см. это руководство
Вы получили ответ на свой вопрос?
Спасибо за ответ Не удалось отправить отзыв. Пожалуйста, повторите попытку позже.
Самый простой способ асинхронной загрузки CSS
Одним из наиболее действенных способов повышения производительности и отказоустойчивости страницы является загрузка CSS таким образом, чтобы не задерживать рендеринг страницы. Это связано с тем, что по умолчанию браузеры загружают внешний CSS синхронно — останавливая отрисовку всех страниц, пока CSS загружается и анализируется — и то, и другое влечет за собой потенциальные задержки. Конечно, по крайней мере часть CSS-кода сайта должна быть загружена до того, как странице будет разрешено начать рендеринг, и чтобы сразу получить этот первоначальный CSS-код в браузере, мы рекомендуем встроить (или отправить на сервер HTTP2) CSS-код. Для сайтов с небольшим общим объемом одного этого может быть достаточно, но если CSS большой (скажем, больше 15–20 КБ), разделение его по приоритету может повысить производительность. После разделения менее важный CSS должен загружаться в фоновом режиме — он же 9.0010 асинхронно . В этом посте я хочу описать наш предпочтительный способ сделать это в наши дни, который на самом деле существует уже много лет.
Существует несколько способов асинхронной загрузки CSS, но ни один из них не является настолько интуитивным, как можно было бы ожидать. В отличие от элементов script
, здесь нет атрибута async
или defer
, который можно было бы просто применить к элементу link , поэтому в течение многих лет мы поддерживали проект loadCSS, чтобы сделать процесс загрузки асинхронного CSS немного проще. Однако в последнее время браузеры стандартизировали свое поведение при загрузке CSS, поэтому специальный скрипт, такой как loadCSS, для обработки их незначительных различий, вероятно, больше не нужен.
Код
Сегодня, вооружившись некоторыми знаниями о том, как браузер обрабатывает различные ссылки
атрибуты элементов, мы можем добиться эффекта асинхронной загрузки CSS с помощью короткой строки HTML. Вот он, самый простой способ асинхронно загрузить таблицу стилей:
Разбираем это…
Эта строка HTML краткая, но не очень интуитивная, так что давайте разберем, что здесь происходит.
Для начала атрибуту link
media
присвоено значение print
. «Печать» — это носитель типа
, который говорит «применить правила этой таблицы стилей для печатных носителей», или, другими словами, применять их, когда пользователь пытается распечатать страницу. Правда, мы хотим, чтобы наша таблица стилей применялась ко всем носителям (особенно к экранам), а не только к печати, но, объявив тип носителя, не соответствующий текущему окружению, мы можем добиться интересного и полезного эффекта: браузер загрузит таблицу стилей. без задержки рендеринга страницы, асинхронно! Это полезно, но это не все, что нам нужно. Мы также хотим, чтобы CSS на самом деле применить к среде экрана после ее загрузки. Для этого мы можем использовать атрибут onload
, чтобы установить ссылку
для мультимедиа на все
, когда он завершит загрузку.
Не может ли rel=preload сделать это тоже?
Да, аналогично! В последние год или два мы использовали ссылку link[rel=preload]
(вместо rel=stylesheet
) для достижения аналогичного шаблона, как указано выше (переключение атрибута rel
после загрузки вместо носителя ). 9атрибут 0027 соответственно). Этот подход по-прежнему хорошо работает, однако есть несколько недостатков, которые следует учитывать при использовании
preload
. Во-первых, браузерная поддержка предварительной загрузки по-прежнему невелика, поэтому полифилл (например, тот, который предоставляет loadCSS) необходим, если вы хотите полагаться на него для извлечения и применения таблицы стилей в разных браузерах. Что еще более важно, preload
извлекает файлы очень рано, с наивысшим приоритетом, что потенциально снижает приоритет других важных загрузок, и это может иметь более высокий приоритет, чем вам действительно нужно для некритического CSS.
К счастью, если вам нужна высокоприоритетная загрузка, которую обеспечивает rel=preload
(в браузерах, которые ее поддерживают), вы можете комбинировать ее с приведенным выше шаблоном, например:
Учитывая простой и декларативный характер приведенного выше кода, мы предпочли бы его полифиллу, поэтому сейчас мы снова отдаем предпочтение подходу с переключением печатных носителей.
Почему бы не использовать фиктивный медиа-атрибут?
Любой, кто следил за тем, как мы писали об этом в течение последних нескольких лет, может вспомнить, что мы использовали значения медиа-атрибутов, такие как «только x», для достижения того же эффекта, что и «печать», предоставляя значение, которое не соответствует ни одной среде. , поскольку x
— это бессмысленный тип носителя. Когда браузеры сталкиваются с несовпадающими типами мультимедиа, они в настоящее время обрабатывают их все одинаково — они все равно загружают файл. Тем не менее, некоторые команды браузеров начинают рассматривать возможность различия между несовпадающими типами мультимедиа и теми, которые не совпадают.0004 недопустимо (или вообще не распознаются браузером) и, возможно, не запрашивает файлы, связанные с использованием недопустимых типов мультимедиа. Это нарушит работу многих существующих реализаций загрузки CSS, так что это маловероятно, но в целях безопасности мы рекомендуем использовать допустимый несоответствующий тип, например print
.