Rel preload css не работает

Современная асинхронная загрузка CSS

Самый простой способ загрузить CSS в HTML-документ заключается в использовании тега link и атрибута rel=»stylesheet»:

Но есть и обратная сторона медали: это происходит синхронно. Другими словами, браузер останавливает рендеринг остальных частей страницы в процессе запроса, загрузки и парсинга файла. Это необходимо, чтобы браузер не начал отображать содержимое веб-страницы до того, как загрузится CSS. Но не все стили настолько критичны, чтобы задерживать доступ к контенту. Для этого необходимо загружать некритичные CSS файлы асинхронно, без блокировки рендеринга страницы.

Способы асинхронной загрузки CSS

Существует несколько способов заставить браузер загружать CSS асинхронно.

Первый способ (работает в современных браузерах) заключается в использовании JavaScript для создания и вставки ссылки на файл CSS в DOM:

Второй способ заключается в том, чтобы задать атрибуту media в теге link значение, которое не соответствует устройству пользователя. Например, media=»print».

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

Но чтобы задействовать асинхронно загруженные стили, нужно использовать JavaScript-обработчик события onload. Это позволит изменить значение media на соответствующее браузеру и устройству пользователя. Например, screen или all:

Примечание: мы используем комбинацию перечисленных выше приемов в библиотеке loadCSS.js, предназначенной для обработки асинхронной загрузки CSS. А также обходные пути для устаревших версий браузеров, которые не поддерживают события onload в элементах link.

Также можно загружать CSS асинхронно, используя значение rel=»alternate stylesheet». Оно используется для того, чтобы предложить пользователю альтернативное представление сайта:

Методы, описанные выше, работают. Но у них есть один общий недостаток: они используют JavaScript.

Современный метод

Существует решение, созданное специально для асинхронной загрузки CSS файлов: rel=»preload» . Но даже этот вариант использует обработчик события onload.

Ниже приведен использования rel=»preload»:

Значение атрибута rel=»preload» заставляет браузеры (которые его поддерживают) загружать, но не применять указанный файл. Поэтому необходим обработчик события onload, чтобы установить атрибут rel в значение stylesheet после загрузки.

Вариант с rel=»preload» имеет одно важное преимущество: браузеры начнут загружать CSS раньше, чем при использовании подхода с несоответствующим значением атрибута media.

Использование rel=preload c loadCSS

Поддержка rel=»preload» браузерами , ну… спасибо, что хотя бы Google Chrome его поддерживает. Другие популярные браузеры находятся на пути к этому.

Но мы можем обеспечить поддержку rel = ‘preload’ с помощью полифиллов. Проект loadCSS предлагает скрипт cssrelpreload.js , который заставляет rel=»preload» работать в браузерах, которые не поддерживают его по умолчанию.

Пошаговое руководство по использованию cssrelpreload.js можно найти в readme проекта . Ниже приведен пример применения скрипта:

loadCSS можно найти на Github и NPM .

Пожалуйста, оставьте свои отзывы по текущей теме материала. За комментарии, подписки, дизлайки, отклики, лайки низкий вам поклон!

Источник

Что делать, когда CSS блокирует парсинг страницы?

Недавно я проводил аудит одного сайта и наткнулся на паттерн preload/polyfill , который уже видел у нескольких клиентов. В наши дни использование этого паттерна, ранее популярного, не рекомендуется. Однако его полезно рассмотреть для того, чтобы проиллюстрировать важность осторожного использования механизма предварительной загрузки материалов веб-браузерами. Он интересен и тем, что позволяет продемонстрировать реальный пример того, как порядок элементов в документе может повлиять на производительность (именно об этом идёт речь в данном замечательном материале Гарри Робертса).

Материал, перевод которого мы сегодня публикуем, посвящён разбору ситуаций, в которых неправильное и несовременное обращение с CSS-ресурсами ухудшает работу веб-страниц.

О loadCSS

Я — большой поклонник Filament Group — они выпускают невероятное количество замечательных проектов. Кроме того, они постоянно создают бесценные инструменты и выкладывают их в общий доступ ради улучшения веба. Один из таких инструментов — это loadCSS, который долгое время был тем самым средством, который я рекомендовал всем использовать для загрузки некритических CSS-ресурсов.

Хотя теперь это изменилось (и компания Filament Group опубликовала отличную статью о том, что её сотрудники предпочитают использовать в наши дни), я всё ещё, проводя аудит сайтов, часто вижу, как loadCSS используют в продакшне.

Один из паттернов, который мне доводилось встречать — это паттерн preload/polyfill . Используя этот подход, любые файлы со стилями загружают в режиме предварительной загрузки (атрибут rel соответствующих ссылок устанавливается в значение preload ). После этого, когда они будут готовы к использованию, применяют их события onload для их подключения к странице.

Непорядок в сетевых приоритетах

Я никогда не был ярым фанатом этого паттерна. Предварительная загрузка — это грубоватый инструмент. Материалы, загружаемые с помощью ссылок с атрибутом rel=»preload» , с успехом борются с другими материалами за сетевые ресурсы. Использование preload предполагает, что таблицы стилей, которые загружают асинхронно из-за того, что они не играют важнейшей роли в выводе странице, получают от браузеров очень высокий приоритет.

Следующее изображение, взятое из WebPageTest, очень хорошо демонстрирует эту проблему. В строках 3-6 можно видеть асинхронную загрузку CSS-файлов с использованием паттерна preload . Но, в то время как разработчики считают эти файлы не настолько важными, чтобы их загрузка блокировала бы рендеринг, использование preload означает, что они будут загружены до получения браузером остальных ресурсов.

CSS-файлы, при загрузке которых используется паттерн preload, прибывают в браузер раньше других ресурсов, даже несмотря на то, что они не являются ресурсами, чрезвычайно необходимыми при начальном рендеринге страницы

Блокировка HTML-парсера

Проблем, связанных с приоритетом загрузки ресурсов, уже достаточно для того, чтобы в большинстве ситуаций избегать применения паттерна preload . Но в данном случае ситуация усугубляется присутствием ещё одного файла стилей, который загружается обычным образом.

Тут имеются те же проблемы, когда использование preload приводит к тому, что не самые важные файлы получают высокий приоритет. Но так же важно, и возможно, менее очевидно то, какое воздействие это оказывает на возможность браузера по парсингу страницы.

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

Обычно загрузка стилей блокирует рендеринг страницы. Браузеру нужно запросить и распарсить стили для того, чтобы получить возможность вывести страницу. Однако это не мешает браузеру парсить остальной HTML-код.

Скрипты, с другой стороны, блокируют парсер в том случае, если они не помечены как defer или async .

Так как браузеру приходится предполагать, что скрипт, возможно, будет манипулировать либо самим содержимым страницы, либо стилями, применяемыми к ней, ему нужно проявлять осторожность в отношении момента запуска этого скрипта. Если браузер знает о том, что загружается какой-то CSS-код, он будет ждать прибытия этого CSS-кода, а уже после этого запустит скрипт. А так как браузер не может продолжить парсинг документа до выполнения скрипта, это означает, что стили уже не просто блокируют рендеринг. Они не дают браузеру парсить HTML.

Это поведение справедливо как для внешних скриптов, так и для скриптов, встроенных в страницу. Если CSS загружается, встроенные скрипты не запускаются до прибытия этого CSS в браузер.

Изучение проблемы

Самый понятный способ визуализации этой проблемы заключается в использовании инструментов разработчика Chrome (мне невероятно нравится тот уровень, до которого доросли эти инструменты).

Среди инструментов Chrome есть вкладка Performance , с помощью которой можно записать профиль загрузки страницы. Я тут рекомендую искусственно замедлить сетевое соединение для того, чтобы проблема проявилась бы ярче.

В данном случае я провёл испытание, воспользовавшись настройкой сети Fast 3G. Если присмотреться к тому, что происходит с главным потоком, то можно понять, что запрос на загрузку CSS-файла происходит в самом начале парсинга HTML (примерно через 1.7 секунд после начала загрузки страницы).

Небольшой прямоугольник, находящийся ниже блока парсинга HTML, представляет запрос на получение CSS-файла

В течение следующего отрезка времени, который равняется примерно секунде, главный поток бездействует. Тут можно видеть небольшие островки деятельности. Это — срабатывание событий, указывающих на завершение загрузки стилей, это отправка механизмом предварительной загрузки ресурсов других запросов. Но браузер совершенно прекращает парсинг HTML.

Если взглянуть на общую картину, то окажется, что после начала загрузки CSS главный поток бездействует более 1.1 секунды

Итак, прошло 2.8 секунды, стиль загружен, браузер его обрабатывает. Только тогда мы видим обработку встроенного скрипта, а уже после этого браузер, наконец, возвращается к парсингу HTML.

CSS прибывает примерно через 2.8 секунды, после чего мы видим, что браузер продолжает парсинг HTML

Firefox — приятное исключение

Вышеописанное поведение характерно для Chrome, Edge и Safari. Firefox — приятное исключение из списка популярных браузеров.

Все другие браузеры приостанавливают парсинг HTML, но используют упреждающий парсер (средство предварительной загрузки материалов) для просмотра кода на предмет наличия в нём ссылок на внешние ресурсы и для выполнения запросов на загрузку этих ресурсов. Firefox, однако, идёт в этом деле на шаг дальше: он спекулятивно строит дерево DOM, даже несмотря на то, что ожидает выполнения скрипта.

Если только скрипт не будет манипулировать DOM, что приведёт к необходимости отказаться от результатов спекулятивного парсинга, этот подход позволяет Firefox получить преимущество. Конечно, если браузеру придётся отбросить спекулятивно построенное дерево DOM, это значит, что он, строя это дерево, ничего полезного не сделал.

Это — интересный подход. Мне было страшно любопытно узнать о том, насколько он эффективен. Сейчас, однако, в профилировщике производительности Firefox сведений об этом нет. Там нельзя узнать о том, работал ли спекулятивный парсер, о том, нужно ли переделывать сделанную им работу, и, о том, если её всё же нужно переделывать, как это скажется на производительности.

Я поговорил с теми, кто отвечает за инструменты разработчика Firefox, и могу сказать, что у них есть интереснейшие идеи относительно того, как в будущем представлять подобные сведения в профилировщике. Надеюсь, у них всё получится.

Решение проблемы

В случае с клиентом, о котором я упоминал в самом начале, первый шаг решения этой проблемы выглядел крайне просто: избавиться от паттерна preload/polyfill . Предварительная загрузка некритичного CSS-кода — бессмысленное действие. Здесь нужно переключиться на использование, вместо rel=»preload» , атрибута media=»print» . Именно это и рекомендуют специалисты из Filament Group. Такой подход, кроме того, позволяет полностью избавиться от полифилла.

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

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

До внесения изменений в код страницы HTML-парсер остановился на строке 1939, встретив встроенный скрипт, и оставался здесь около секунды. После оптимизации он смог добраться до строки 5281

Раньше парсер останавливался на строке 1939 и ждал загрузки CSS, а теперь он доходит до строки 5281. Там, в конце страницы, есть ещё один встроенный скрипт, который снова останавливает парсер.

Это — решение проблемы на скорую руку. Перед нами не тот вариант, который представляет собой окончательное решение проблемы. Изменение порядка элементов и избавление от паттерна preload/polyfill — это лишь первый шаг. Лучше всего решить эту проблему можно, встроив критически важный CSS-код в страницу, а не загружая его из внешнего файла. Паттерн preload/polyfill предназначен для использования в дополнение к встроенному CSS. Это позволяет нам полностью игнорировать проблемы, связанные со скриптами и обеспечить то, чтобы у браузера, после выполнения первого запроса, были бы все необходимые ему для рендеринга страницы стили.

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

Итоги

• Если вы используете loadCSS и паттерн preload/polyfill , перейдите на паттерн загрузки стилей print .
• Если у вас имеются внешние стили, загружаемые обычным образом (то есть — с использованием обычных ссылок на файлы этих стилей), переместите все встроенные скрипты, допускающие перемещение, выше ссылок на загрузку стилей.
• Встраивайте критически важные стили в страницу для того, чтобы обеспечить как можно более быстрое начало рендеринга.

Уважаемые читатели! Сталкивались ли вы с проблемами замедления рендеринга страниц из-за CSS?

Источник

Preload, prefetch и другие теги

Есть много способов повышения веб-производительности. Один из них — предзагрузка контента, который понадобится позже. Префетчинг CSS, предварительный рендеринг полной страницы или резолвинг доменного имени. Делаем всё заранее, а потом мгновенно отображаем результат! Звучит круто.

Ещё круче, что это очень просто реализовано. Пять тегов
дают браузеру команду на предварительные действия:

Вкратце расскажем, что они делают и когда их использовать.

preload

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

Браузер ничего не делает с ресурсом после загрузки. Скрипты не выполняются, таблицы стилей не применяются. Ресурс просто кэшируется и немедленно предоставляется по запросу.

Синтаксис

href указывает на ресурс, который вы хотите скачать.

as может быть чем угодно, что можно скачать в браузере:

• style для таблиц стилей,
• script для скриптов,
• font для шрифтов,
• fetch для ресурсов, загруженных с помощью fetch() или XMLHttpRequest ,
• полный список см. на MDN.

Важно указать атрибут as – это помогает браузеру правильно расставлять приоритеты и планировать загрузку.

Когда использовать

Используйте предзагрузку, когда ресурс понадобится в самое ближайшее время. Например:

Нестандартные шрифты из внешнего файла:

По умолчанию comic-sans.woff2 начнёт загружаться только после загрузки и разбора index.css . Чтобы не ждать так долго, можно загрузить шрифт раньше с помощью
:

Если вы разделяете свои стили согласно подходу Critical CSS на две части, критическую (для немедленного рендеринга) и некритическую:

При таком подходе некритические стили начнут загружаться только при запуске JavaScript, что может произойти через несколько секунд после рендеринга. Вместо ожидания JS используйте
, чтобы начать загрузку раньше:

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

Не путайте с префетчингом. Не используйте

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

.

Подробности

Это обязательный тег для исполнения браузером (если он его поддерживает), в отличие от всех других тегов

, связанных с предварительной загрузкой. Браузер обязан загрузить ресурс, указанный в

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

Приоритеты. Разным ресурсам (стили, скрипты, шрифты и т. д.), браузеры обычно назначают разные приоритеты, чтобы в первую очередь загружать самые важные ресурсы. В данном случае браузер определяет приоритет по атрибуту as . Для браузера Chrome можете посмотреть полную таблицу приоритетов.

prefetch

просит браузер загрузить и кэшировать ресурс (например, скрипт или таблицу стилей) в фоновом режиме. Загрузка происходит с низким приоритетом, поэтому не мешает более важным ресурсам. Это полезно, если ресурс понадобится на следующей странице, а вы хотите заранее его кэшировать.

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

Синтаксис

href указывает на ресурс, который вы хотите скачать.

as может быть чем угодно, что можно скачать в браузере:

• style для таблиц стилей,
• script для скриптов,
• font для шрифтов,
• fetch для ресурсов, загруженных с помощью fetch() или XMLHttpRequest ,
• полный список см. на MDN.

Важно указать атрибут as — это помогает браузеру правильно расставлять приоритеты и планировать загрузку.

Когда использовать

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

• У вас интернет-магазин, и 40% пользователей уходят с главной страницы на страницу товара. Используйте
• , загружая файлы CSS и JS для рендеринга страниц с продуктом.
• У вас одностраничное приложение, а разные страницы загружают разные пакеты. Когда пользователь посещает какую-то страницу, можно предварительно загрузить пакеты для всех страниц, на которые она ссылается.

Вероятно, этот тег можно безопасно использовать в любом объёме. Браузеры обычно планируют prefetch с наименьшим приоритетом, так что он никому не мешает. Только имейте в виду, что расходуется трафик пользователя, который может стоить денег.

Не для срочных запросов. Не используйте

, когда ресурс понадобится через несколько секунд. В этом случае применяйте

.

Подробности

Необязательный тег. Браузер не обязан следовать этой инструкции, он может проигнорировать её, например, на медленном соединении.

Приоритет в Chrome. В Chrome
обычно выполняется с минимальным приоритетом (см. полную таблицу приоритетов), то есть после загрузки всего остального.

preconnect

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

Браузер должен установить соединение, если извлекает какие-то ресурсы с нового стороннего домена. Например, если загружает шрифты Google Fonts, React из CDN или запрашивает ответ JSON с сервера API.

Установка нового соединения обычно занимает несколько сотен миллисекунд. Она производится один раз, но всё равно отнимает время. Если вы заранее установили соединение, то сэкономите время и быстрее загрузите ресурсы с этого домена.

Синтаксис

href указывает на доменное имя, для которого нужно определить IP-адрес. Можно указывать с префиксом ( https://domain.com ) или без него ( //domain.com ).

Когда использовать

Используйте для доменов, которые скоро понадобятся для загрузки оттуда важного стиля, скрипта или изображения, но вы пока не знаете URL ресурса. Например:

• Ваше приложение размещается на my-app.com и делает AJAX-запросы к api.my-app.com : вы не знаете заранее конкретные запросы, потому что они делатся динамически из JS. Здесь вполне уместно использование тега для предварительного подключения к домену.
• Ваше приложение размещается на my-app.com и использует шрифты Google Fonts. Они загружаются в два этапа: сначала загружается файл CSS с домена fonts.googleapis.com , затем этот файл запрашивает шрифты с fonts.gstatic.com . Вы не можете знать, какие конкретные файлы шрифтов из fonts.gstatic.com вам понадобятся, пока не загрузите файл CSS, поэтому заранее мы можем только установить предварительное соединение.

Читайте также:  Миракаст для телевизора как настроить

Используйте этот тег, чтобы немного ускорить какой-то сторонний скрипт или стиль за счёт предварительной установки соединения.

Не злоупотребляйте. Установка и поддержание соединения — дорогостоящая операция как для клиента, так и для сервера. Используйте этот тег максимум для 4-6 доменов.

Подробности

Необязательный тег. Браузер не обязан следовать этой инструкции и может проигнорировать её, например, если уже установлено много соединений или в каком-то другом случае.

Что включает в себя процесс подключения. Для подключения к каждому сайту браузер должен выполнить следующие действия:

• Резолвинг DNS. Найти IP-адрес сервера ( 216.58.215.78 ) для указанного доменного имени ( google.com ).
• Рукопожатие TCP. Обмен пакетами (клиент → сервер → клиент), чтобы инициировать TCP-соединение с сервером.
• Рукопожатие TLS (только для сайтов HTTPS). Два раунда обмена пакетами (клиент → сервер → клиент → сервер → клиент), чтобы инициировать безопасный сеанс TLS.

Примечание: HTTP/3 улучшит и ускорит механизм рукопожатия, но он ещё далеко.

dns-prefetch

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

Браузер должен определить IP-адрес домена, если будет извлекать какие-то ресурсы с нового стороннего домена. Например, загружать шрифты Google Fonts, React из CDN или запрашивать ответ JSON с сервера API.

Для каждого нового домена разрешение записи DNS обычно занимает около 20−120 мс. Это влияет только на загрузку первого ресурса с данного домена, но всё равно представляет задержку. Если осуществить разрешение DNS заранее, то мы сэкономим время и загрузим ресурс быстрее.

Синтаксис

href указывает на доменное имя, для которого нужно установить IP-адрес. Можно указывать с префиксом ( https://domain.com ) или без него ( //domain.com ).

Когда использовать

Используйте для доменов, которые скоро понадобятся для загрузки оттуда ресурсов, о которых браузер не знает заранее. Например:

• Ваше приложение размещается на my-app.com и делает AJAX-запросы к api.my-app.com : вы не знаете заранее конкретные запросы, потому что они делатся динамически из JS. Здесь вполне уместно использование тега для предварительного подключения к домену.
• Ваше приложение размещается на my-app.com , и использует шрифты Google Fonts. Они загружаются в два этапа: сначала загружается файл CSS с домена fonts.googleapis.com , затем этот файл запрашивает шрифты с fonts.gstatic.com . Вы не можете знать, какие конкретные файлы шрифтов из fonts.gstatic.com вам понадобится, пока не загрузите файл CSS, поэтому заранее мы можем только установить предварительное соединение.

Используйте этот тег, чтобы немного ускорить какой-то сторонний скрипт или стиль за счёт предварительной установки соединения.

Обратите внимание схожие характеристики на

и

. Использовать их вместе для одного домена обычно не имеет смысла:

уже включает в себя

и многое другое. Это можно оправдать в двух случаях:

• Вы хотите поддерживать старые браузеры.
• поддерживается начиная с IE10 и Safari 5.
• некоторое время поддерживался в Chrome и Firefox, но был добавлен в Safari только в 11.1 и по-прежнему не поддерживается в IE/Edge. Если нужно поддерживать эти браузеры, используйте
• в качестве запасного варианта для
• .
• Вы хотите ускорить подключение более чем к 4−6 доменам. Тег
• не рекомендуется использовать более чем с 4−6 доменами, так как установка и поддержание соединения — дорогостоящая операция.
• потребляет меньше ресурсов, поэтому в случае необходимости используйте его.

Подробности

Необязательный тег. Браузер не обязан следовать этой инструкции, поэтому может не выполнять резолвинг DNS, например, если на странице много таких тегов или в каком-то другом случае.

Что такое DNS. Каждому серверу в интернете соответствует уникальный IP-адрес, который выглядит как 216.58.215.78 . В адресной строке браузера обычно вводится название сайта (например, google.com ), а серверы DNS (Domain Name System) сопоставляют его с IP-адресом сервера ( 216.58.215.78 ).

Чтобы определить IP-адрес, браузер должен выполнить запрос к DNS-серверу. Он занимает 20−120 мс при подключении к новому стороннему домену.

DNS кэшируется, хотя и не очень надёжно. Некоторые ОС и браузеры кэшируют DNS-запросы: это сэкономит время при повторных запросах, но на кэширование нельзя полагаться. В Linux оно обычно вообще не работает. У Chrome есть кэш DNS, но он живёт только минуту. Windows кэширует DNS-ответы в течение пяти дней.

prerender

просит браузер загрузить URL-адрес и отобразить его на невидимой вкладке. Когда пользователь нажимает на ссылку, страница должна отобразиться немедленно. Это полезно, если вы уверены, что пользователь посетит определённую страницу, и хотите ускорить её отображение.

Несмотря на исключительную эффективность этого тега (или из-за неё), в 2019 году
плохо поддерживается основными браузерах. Подробнее см. ниже.

Синтаксис

href указывает на URL, для который вы хотите запустить рендеринг в фоновом режиме.

Когда использовать

Когда вы действительно уверены, что пользователь перейдёт на определённую страницу. Если у вас «туннель», по которому 70% посетителей страницы A переходят на страницу Б, то
на странице А поможет очень быстро отобразить страницу Б.

Не злоупотребляйте. Предварительный рендеринг чрезвычайно дорого обходится с точки зрения трафика и памяти. Не используйте
более чем для одной страницы.

Подробности

Необязательный тег. Браузер не обязан следовать этой инструкции и может проигнорировать её, например, на медленном соединении или при недостаточном объёме свободной памяти.

Ради экономии памяти Chrome не выполняет полный рендеринг, а только предзагрузку NoState. Это означает, что Chrome загружает страницу и все её ресурсы, но не делает рендеринг и не выполняет JavaScript.

Firefox и Safari вообще не поддерживают этот тег. Это не нарушает спецификацию, так как браузеры не обязаны выполнять данную инструкцию; но всё равно печально. Баг реализации в Firefox был открыт в течение семи лет. Есть сообщения, что Safari тоже не поддерживает этот тег.

Резюме

• — когда вам понадобится ресурс через несколько секунд
• — когда понадобится ресурс на следующей странице
• — когда вы знаете, что вам скоро понадобится ресурс, но вы ещё не знаете его полный URL
• — аналогично, когда вы знаете, что вам скоро понадобится ресурс, но вы ещё не знаете его полный URL (для старых браузеров)
• — когда вы уверены, что пользователи перейдут на определённую страницу, и хотите ускорить её отображение

Источник