Перейти к содержимому 
Предварительная выборка DNS и предварительная загрузка активно сокращают время до появления первого видимого контента за счет раннего срабатывания DNS, TCP и TLS и заблаговременного предоставления критически важных файлов. Я покажу вам, как использовать Предварительная загрузка DNS, Предварительное подключение и предварительная загрузка Скорость работы сайта заметно - включая код, настройку WordPress и проверенные приоритеты.
Центральные пункты
- Предварительная загрузка DNSРаннее разрешение имен сокращает время ожидания.
- Предварительное подключениеЗаранее откройте DNS, TCP и TLS.
- Предварительная нагрузка: Активно расставляйте приоритеты в работе с важными файлами.
- Расстановка приоритетовНемногочисленные, но решающие домены.
- МониторингПроверьте эффекты в водопаде.
Предварительная выборка DNS: краткое объяснение
С Предварительная загрузка DNS Браузер заранее разрешает IP-адрес домена перед загрузкой файла, что позволяет сэкономить 20-250 мс на домен - особенно на мобильных соединениях с высоким трафиком. Латентность. Я задаю подсказки для внешних хостов, которые нужны мне в области над разворотом, например для шрифтов, аналитики или CDN. Браузер выполняет поиск DNS в фоновом режиме и тем самым сокращает критический путь до первого рендеринга. Современные браузеры иногда используют префетчинг автоматически, но я обеспечиваю этот эффект с помощью четкой подсказки в голове. Это сокращает количество обходов, стабилизирует раннее начало рендеринга и ускоряет процесс рендеринга. Основные показатели Web.
Разница: предварительная выборка DNS по сравнению с предварительным подключением
Предварительная выборка запускает только DNS-имена, в то время как Preconnect также открывает рукопожатие TCP и TLS и поддерживает соединение. Для критически важных хостов, таких как CDN для рендеринга CSS или веб-шрифтов, я предпочитаю Preconnect просто Prefetch. Я использую его редко, поскольку каждый открытый сокет занимает слоты браузера. Атрибут кроссориджин принадлежит всем хостам с CORS, чтобы последующие запросы не замедлялись. Наглядное представление о выборе и последовательности действий вы найдете в компактном документе Руководство по предварительной выборке.
Предварительная загрузка: предварительная загрузка определенных файлов
Предварительные нагрузки специфические Файлы активно попадают в кэш до того, как парсер обычно их запрашивает, что ускоряет работу FCP и LCP. Я использую его только для ресурсов, которые точно нужны, например, для критических CSS, изображений героев или шрифтов WOFF2. Атрибут fetchpriority направляет вес в сторону увеличения, не вытесняя полностью другие важные передачи. Я проверяю, чтобы тип MIME, атрибут as и фактическое использование совпадали, иначе я теряю пропускную способность. HTTP/3 является хорошим дополнением, как описано в статье о HTTP/3 и предварительная загрузка описанный.
Повышение производительности хостинга
Быстро Хостинг увеличивает эффект от подсказок, поскольку низкие RTT, HTTP/3 и близлежащая CDN сокращают время ожидания на каждом этапе. Я регулярно вижу, как TTFB снижается до секунды, когда DNS, TCP и TLS начинают предварительно нагреваться, а Origin быстро реагирует. На мобильных устройствах с высокой задержкой это окупается вдвойне, поскольку каждый сэкономленный раунд-трип идет напрямую в LCP. Я обращаю внимание на стабильную работу с TLS, сшивание OCSP и экономную конфигурацию TLS. Таким образом, браузер оптимально использует несколько одновременных соединений и ускоряет работу Скорость веб-сайта.
Быстрое сравнение: какая технология для чего?
Следующая таблица обобщает эффект, использование и примеры тегов и помогает мне выбрать правильную меру для каждого хоста. Я комбинирую prefetch для ширины, preconnect для критических хостов и preload для важных файлов. Я поддерживаю низкое количество одновременно открытых соединений. Это оставляет достаточно места для открытий парсера и критически важных активов на поздних стадиях. Этот обзор позволяет принимать решения по следующим вопросам Расстановка приоритетов проще.
| Технология | Что происходит | Типичное использование | Пример тега | Воздействие на FCP/LCP |
|---|---|---|---|---|
| Предварительная загрузка DNS | Ранний Разрешение на имя | Внешние узлы с более поздними запросами | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Умеренно положительный, в зависимости от задержки |
| Предварительное подключение | DNS + TCP + TLS предварительно нагревать | CDN, шрифты, критические API | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Однозначно положительный результат, экономия на поездках туда и обратно |
| Предварительная нагрузка | Файл активен предварительная нагрузка | Критический CSS, WOFF2, Hero-Image | <link rel="preload" as="style" href="/critical.css"> | Очень позитивно, если правильно выбрать |
Интеграция с WordPress: чистота и удобство обслуживания
В WordPress я устанавливаю подсказки в самом начале Глава, чтобы браузер видел их раньше, чем узкое место парсера. Я дедуплицирую хосты, проверяю наличие https и добавляю кроссориджин только если это необходимо. Следующий код размещает записи в верхней части, что позволяет добиться максимального эффекта. После развертывания я также проверяю, не были ли добавлены новые внешние хосты. Это позволяет поддерживать список подсказок в рабочем состоянии, обновлять его и эффективный.
function add_dns_prefetch() {
$domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com'];
$printed = [];
foreach ($domains as $domain) {
$key = preg_replace('#^https?:#', '', $domain);
if (isset($printed[$key])) { continue; }
$printed[$key] = true;
echo '' . "\n";
if (strpos($domain, 'https://') === 0) {
echo '' . "\n";
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1);
Лучшие практики: лаконично, но эффективно
Я ограничиваю "Преконнект" тремя-пятью Хозяева, Иначе браузер будет преждевременно блокировать слишком много сокетов. Я всегда размещаю подсказки в начале шапки, затем следуют предзагрузки, потом стили и скрипты. Для шрифтов я комбинирую Preconnect с Отображение шрифта: swap, чтобы текст появлялся сразу, а CLS оставался низким. Я убеждаюсь, что файлы предварительной загрузки гарантированно будут использованы, иначе я зря трачу полосу пропускания и не отдаю приоритет тому, что необходимо. Для сторонних скриптов я критически проверяю, все ли Домен необходимо.
Измерение и мониторинг: сделать успех видимым
На вкладке "Сеть" в DevTools я смотрю на порядок DNS, TCP и TLS и проверьте, запускаются ли они раньше, чем раньше. Сравнение "до" и "после" в водопаде наглядно показывает, работают ли подсказки. Я использую Lighthouse или PageSpeed Insights для наблюдения за FCP, LCP и CLS, а также за тенденцией TTFB. WebPageTest также предоставляет представления соединений и полосы пленки, которые документируют начало рендеринга. После серьезных изменений я повторяю измерения и удаляю устаревшие данные. Хозяева из списка подсказок.
HTTP/3, QUIC и коалесценция соединений
При использовании HTTP/3 через QUIC я сохраняю дополнительные круговые поездки, потому что настройка соединения, обработка потерь и мультиплексирование работают более эффективно. Я проверяю, предлагают ли моя CDN и Origin протокол HTTP/3, и продолжаю выборочно использовать Preconnect. Коалесцирование соединений сокращает количество отдельных соединений, если сертификаты и IP совпадают. Это позволяет хостам с одним и тем же сертификатом обслуживать несколько поддоменов через общий Соединение. В целом, ранний путь рендеринга значительно выигрывает, особенно при работе с большим количеством маленьких файлов.
Комбинируйте CDN warmup и prefetch
Я нагреваю CDN, когда ожидаю пика трафика, и сочетаю это с Префеч и Preconnect для узлов Edge. Это означает, что важные объекты хранятся в пограничном кэше, а рукопожатия уже подготовлены. Это снижает задержки, особенно при начальных вызовах и в мобильных условиях. Практические инструкции можно найти в статье CDN-разминка, который я люблю использовать в качестве контрольного списка. Перед развертыванием я проверяю частоту попадания в кэш и наблюдаю за тем. TTFB-развитие.
Управление: поддерживайте список подсказок в актуальном состоянии
Я веду короткую Инвентаризация всех внешних хостов и ежеквартально проверяю, не были ли добавлены новые скрипты, шрифты или изображения. Я удаляю удаленные интеграции вместе с подсказкой, чтобы сохранить список. Для каждого хоста я отмечаю назначение, критичность и используемую технологию (prefetch, preconnect или preload). Я сразу же вношу изменения в CDN или шрифты, чтобы не оставалось осиротевших записей. Это позволяет мне сохранять контроль, снижать накладные расходы и обеспечивать последовательное Производительность.
Поддержка браузеров, эвристика и ограничения
По моим расчетам, подсказки браузера выглядят следующим образом Сигналы но не в качестве команды. При низкой пропускной способности, активном сохранении данных или фоновой вкладке браузер может изменять приоритеты или дросселировать подсказки. Safari более консервативен с предварительными подключениями, Firefox иногда использует другую эвристику для DNS-кеша, а мобильные варианты сокращают параллельные сокеты. Поэтому я формулирую подсказки так точно и избежать чрезмерной сигнализации: небольшое количество хостов, четкое в роли-значения, правильные тип-информация. Для шрифтов я обращаю внимание на кроссориджин, В противном случае есть риск двойной выборки или поздней блокировки CORS. Если я хочу полностью контролировать предварительную выборку, я могу использовать . или с сайта влияют на автоматическую эвристику.
HTTP-заголовок и 103 ранних подсказки
Помимо HTML-тегов я использую Заголовок ссылки, Таким образом, подсказки приходят с первым ответом сервера - идеальный вариант для рендеринга на стороне сервера. 103 Ранние подсказки отправляют даже такие заголовки до окончательного ответа 200 и, таким образом, выиграть десятки миллисекунд на длинных линиях.
# NGINX: предварительное подключение и предварительная загрузка через заголовок ссылки
add_header Link '; rel=preconnect; crossorigin' всегда;
add_header Link '; rel=preload; as=style; fetchpriority=high' всегда;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' always;
# Apache (htaccess)
Заголовок добавляет ссылку '; rel=preconnect; crossorigin'
Заголовок добавить ссылку '; rel=preload; as=image'
Поддерживает ли сервер 103 Ранние подсказки, Я также отправляю заголовки ссылок заранее. Важно: я сохраняю список короткие, потому что каждая запись требует усилий по разбору и потенциального открытия соединения.
SPA и Service Worker: предварительная выборка маршрутов и данных
Для одностраничных приложений я перемещаю подсказки основанный на состоянии: Как только герой становится видимым, я запускаю целевую предварительную загрузку для следующего маршрута (JS-фрагмент, критическое изображение, схема API). В Service Worker я могу кэшировать результаты предварительной загрузки и использовать их после навигационных событий. Я определяю четкие критерии отмены (вкладка скрыта, процессор перегружен, слабая сеть), чтобы предварительная выборка не стала фактором затрат. Для ES-модулей я устанавливаю ранние modulepreload, чтобы цепочка зависимостей не замедлялась.
<link rel="modulepreload" href="/assets/js/app.entry.js">
<script>
// Vorsichtige SPA-Vorladung
if (navigator.connection?.saveData !== true) {
const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 300));
idle(() => {
const l = document.createElement('link');
l.rel = 'preload';
l.as = 'script';
l.href = '/assets/js/route-checkout.js';
document.head.appendChild(l);
});
}
</script>
Безопасность, защита данных и рекомендации
Я рассматриваю рамки политики: строгая CSP может блокировать предварительную загрузку, если font-src, style-src или img-src не разрешайте цели. кроссориджин является обязательным для шрифтов, иначе кэш не будет работать во всех источниках. С чувствительными третьими лицами я не распространяю никаких предварительных подключений, если могу удалить домен в будущем - каждый намек является сигналом для браузера и может ускорить работу скриптов слежения. Я также проверяю Сохранить данные и Экономия данныхВ этих режимах я снижаю агрессивность предварительной загрузки и оставляю активной предварительную выборку DNS только для центральных узлов.
Углубление практики измерений: API и журналы хронометража
В дополнение к водопадам я использую API синхронизации ресурсов и PerformanceObserverдля того чтобы в поле чтобы измерить, попадают ли подсказки в парсер и как domainLookupStart, connectStart и secureConnectionStart двигаться. Это позволяет мне распознать, действительно ли было использовано предварительное соединение или оно было отклонено браузером.
<script>
new PerformanceObserver((list) => {
for (const e of list.getEntriesByType('resource')) {
if (e.name.includes('fonts.gstatic.com')) {
console.log('DNS:', e.domainLookupEnd - e.domainLookupStart,
'TLS:', e.secureConnectionStart > 0 ? e.connectEnd - e.secureConnectionStart : 0,
'Start:', e.startTime.toFixed(1));
}
}
}).observe({ type: 'resource', buffered: true });
</script>
Я сравниваю эти данные с логами сервера и статистикой CDN (частота возобновления TLS, доля HTTP/3, хиты кэша). Если я вижу, что TLS почти всегда возобновляется, я могу уменьшить количество активных предварительных соединений и освободить слоты для обнаружения парсером.
Углубленное изучение WordPress: чистое использование фильтров ядра
WordPress уже имеет инфраструктуру для подсказок ресурсов. Я присоединяюсь к wp_resource_hints, вместо того, чтобы самому печатать сырой HTML, и передавать только дедуплицированные цели. Для предварительной загрузки я установил wp_enqueue_style/wp_enqueue_script и добавьте правильный в роли-атрибуты через wp_style_add_data.
// Предварительное подключение и предварительная выборка DNS через фильтр ядра
add_filter('wp_resource_hints', function($urls, $relation_type) {
$critical = [
'preconnect' => ['https://fonts.gstatic.com', 'https://cdn.example.com'],
'dns-prefetch' => ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de']
];
if (!empty($critical[$relation_type])) {
foreach ($critical[$relation_type] as $u) {
if (!in_array($u, $urls, true)) { $urls[] = $u; }
}
}
return $urls;
}, 10, 2);
// Корректная предварительная загрузка Enqueue
add_action('wp_enqueue_scripts', function() {
wp_enqueue_style('critical', get_stylesheet_directory_uri() . '/assets/css/critical.css', [], null);
wp_style_add_data('critical', 'preload', true);
wp_style_add_data('critical', 'as', 'style');
wp_register_style('font-inter', false);
wp_enqueue_style('font-inter');
add_action('wp_head', function() {
echo '' . "\n";
}, 2);
}, 1);
Я также слежу за тем, чтобы оптимизирующие плагины (отложить, комбайн) Не позволяйте подсказкам ускользать от парсера. После активации я проверяю, сохранился ли порядок в голове и нет ли дублирующихся предзагрузок.
Поиск и устранение неисправностей и антипаттерны
- Слишком много предварительных подключений: Более 3-5 хостов тратят сокеты. Я сокращаю до первый критический Цели (шрифты/CDN/API).
- Неправильный а/тип: A
as="font"безtype="font/woff2"может привести к неправильному приоритету или дублированию запросов. - Неиспользуемые предварительные нагрузки: Каждый неиспользуемый ресурс засоряет линию. Я удаляю прелоады, которые не используются в безопасном режиме.
- Забытый кроссориджин: При использовании шрифтов или внешних CDN это приводит к проблемам CORS и потере кэша.
- Порядок HTMLПодсказки должны располагаться в начале заголовка. Предварительная загрузка перед стилями, затем рендеринг CSS, затем критический JS.
- Набор изображений без размеровЯ добавляю
размеры изображений, чтобы браузер выбирал правильно, а загрузка оставалась плавной.
<link rel="preload" as="image" href="/assets/img/hero.webp"
imagesrcset="/assets/img/hero.webp 1x, /assets/img/[email protected] 2x"
imagesizes="(min-width: 1024px) 1200px, 100vw">
Правильно расставьте приоритеты
Я принимаю решение, исходя из нескольких вопросов: 1) Гарантирован ли хозяин/актив досрочно необходимо? 2) Как высоко задержка (мобильная, глобальная, холодная CDN)? 3) Есть ли альтернативы (встроенный подмножество CSS, самостоятельное размещение шрифтов)? 4) Можно ли использовать соединение повторно (коалесценция, H3, возобновление)? 5) Обесценение открытия синтаксического анализатора мер? Это следующее: Предварительная выборка для широких, благоприятных достижений; предварительное подключение выборочно для разминки; предварительная загрузка только для гарантированно необходимые файлы с чистым набором текста и правильной расстановкой приоритетов.
Краткое содержание
Я использую DNS Предварительная выборка для широкого и благоприятного выигрыша в латентности, предварительное подключение для нескольких, но центральных хостов и предварительная загрузка для файлов, которые гарантированно понадобятся. Последовательность в голове и экономный выбор дают наибольший эффект. Я измеряю каждое изменение, проверяю водопады и регулярно корректирую список подсказок. В сочетании с HTTP/3, близлежащей CDN и грамотной расстановкой приоритетов ресурсов я заметно увеличиваю FCP и LCP. Вот как я использую оптимизацию dns в браузере, эффективно и стабильно увеличивая Скорость веб-сайта.
