Повільний DNS-пошук майже ніколи не означає, що «інтернет поганий». Це пауза ще до того, як браузер узагалі торкнеться сервера сайту: комп’ютер питає, за якою IP-адресою ховається ім’я на кшталт monobank.ua чи youtube.com, і чекає відповіді. Якщо цей крок займає 150–300 мс замість 10–20 мс, кожна нова вкладка, кожен CDN, кожен шрифт і віджет додають свою порцію очікування. Найкоротший шлях прискорити повільний DNS-пошук такий: змінити резолвер провайдера на швидкий публічний, очистити зіпсований кеш, прибрати «мертві» VPN-адаптери й прописати той самий резолвер на роутері, щоб виграли всі пристрої вдома.
У нашій практиці цього достатньо в більшості домашніх мереж. Провайдерський DNS часто відповідає за 80–200 мс, тоді як Cloudflare 1.1.1.1, Google 8.8.8.8 чи Quad9 9.9.9.9 з будь-якого міста України зазвичай вкладаються в десятки мілісекунд. Якщо ж гальмує лише один сайт, проблема вже не у вашому резолвері, а в авторитетних серверах цього домену, ланцюжку CNAME або занадто короткому TTL.
У 2026 році до класичної схеми додалися шифровані протоколи DoH, DoT і навіть DoQ. Вони не завжди б’ють «голий» UDP за швидкістю, зате прибирають підміни, зайві редіректи оператора й таймаути, через які сторінка «висить» 5–15 секунд, ніби канал раптом помер.
Чому DNS-пошук гальмує навіть на швидкому каналі
DNS працює як довідник: ви диктуєте ім’я, система шукає номер. Спочатку браузер дивиться у власний кеш, потім операційна система, потім роутер, потім рекурсивний резолвер, і лише тоді запит може піти до авторитетних серверів домену. Кожен рівень або віддає готову відповідь за одиниці мілісекунд, або запускає новий раунд очікування. Коли канал 300 Мбіт/с, а перший байт сторінки з’являється через дві секунди, винним часто буває саме цей довідник, а не «поганий тариф».
Типовий домашній сценарій виглядає буденно. Ноутбук бере DNS з роутера, роутер бере його з DHCP провайдера, провайдер тримає слабкий резолвер у сусідній області. Некешований запит іде туди й назад 80–200 мс. Сучасна сторінка тягне десятки сторонніх імен: аналітика, шрифти, платіжний віджет, карта, CDN картинок. Десять таких пошуків по 120 мс — це вже понад секунда чистого простою ще до завантаження HTML.
Окремий випадок — «мертвий» перший сервер. Windows або Android надсилає запит на адресу, яка більше не відповідає: старий VPN, корпоративний DNS, який живе лише всередині тунелю, забутий IPv6-резолвер. Система чекає таймаут 2, 5, інколи 15 секунд і лише тоді пробує запасний. За моїм досвідом саме ця пауза найчастіше маскується під «повільний інтернет»: ping до 8.8.8.8 нормальний, швидкість завантаження файлу теж, а сайти відкриваються з нудною затримкою.
У 2026 році до класичних причин додалися ще дві. Перша — фільтри безпеки на шлюзі, які розгортають кожен запит через довгий ланцюжок політик. Друга — кривий IPv6: пристрій вважає, що AAAA-запис має прийти швидко, не отримує відповіді й лише потім падає на IPv4. Телефон на LTE при цьому може працювати жваво, а той самий акаунт у домашньому Wi-Fi — ні, бо роутер роздає зламаний IPv6-DNS.
Практична пастка: люди змінюють DNS лише в браузері або лише на одному адаптері Wi-Fi, забуваючи Ethernet, ВПН-профіль і гостьову мережу. Тоді «то швидко, то ні» — не містика, а різна конфігурація на різних інтерфейсах. Поки ви не подивитеся, куди реально йде запит, лікуватимете не ту хворобу.
Ключові цифри. Кешована відповідь поруч із вами — одиниці мілісекунд. Некешований запит до живого anycast-резолвера — зазвичай 10–40 мс. Резолвер провайдера часто тримає 80–200 мс. Усе, що стабільно вище 100 мс, уже відчувається; 200–300 мс псує сприйняття сторінки; 5–15 секунд — це вже не «повільний DNS», а таймаут до недоступного сервера. За останніми зрізами DNSPerf публічний 1.1.1.1 тримає близько 13 мс глобально, 8.8.8.8 — близько 20 мс, 9.9.9.9 — близько 22 мс. HTTP Archive у звіті 2025 року зафіксував медіану DNS на десктопі 52 мс для CDN проти 129 мс для «голого» origin. Кожна зайва секунда на старті сторінки історично піднімає відмови: стрибок завантаження з 1 до 3 секунд дає близько 32% вищого bounce.
Як виміряти затримку, перш ніж щось ламати
Без вимірювання ви лікуєте відчуття, а не причину. Найчесніший інструмент на macOS і Linux — dig: дивитеся рядок Query time. На Windows зручний PowerShell. Браузер показує DNS Lookup у вкладці Network, якщо увімкнути колонки таймінгу. Важливо міряти двічі: перший запит холодний, другий уже з кешу. Якщо холодний 18 мс, а «повільність» лишається, DNS тут ні при чому.
На Windows відкрийте PowerShell і виконайте Measure-Command { Resolve-DnsName www.google.com } | Select-Object TotalMilliseconds. Потім те саме з явним сервером: Resolve-DnsName www.google.com -Server 1.1.1.1. Якщо системний резолвер дає 180 мс, а 1.1.1.1 — 14 мс, ви вже знаєте, що міняти. Команда Get-DnsClientServerAddress покаже, який DNS прописаний на кожному адаптері, включно з прихованими тунелями.
На macOS і Linux цикл порівняння виглядає так: dig www.example.com @1.1.1.1, потім @8.8.8.8, @9.9.9.9 і @IP-вашого-роутера. Записуйте Query time. У нашій практиці різниця між резолвером провайдера й публічним у години пік по Києву чи Львову часто сягає 5–10 разів на некешованих іменах. Якщо всі публічні сервери однаково повільні, дивіться кабель, Wi-Fi, CGNAT або перевантажений роутер, а не «магію DNS».
Перевіряйте не лише популярні домени. Візьміть сайт банку, новин і якусь дрібну крамницю. Великі імена майже завжди в кеші будь-якого резолвера, тому штучно виглядають швидкими. Дрібний домен без кешу покаже правду. Якщо гальмує лише один бренд, копайте його NS-записи: dig NS example.com +short і запит безпосередньо до авторитетного сервера. Інколи власник тримає DNS на одному слабкому VPS у далекому регіоні — ви тут нічого не вдієте, окрім як написати підтримці.
Типова помилка 2026 року — міряти ping до 1.1.1.1 і вважати це часом DNS. Ping показує ICMP, не резолв імені. ICMP можуть різати, пріоритезувати інакше, пускати іншим маршрутом. Для DNS потрібен саме DNS-запит. Друга помилка — один вимір. Зробіть 10–20 запитів і дивіться медіану: випадковий сплеск 200 мс на фоні 12 мс не привід панікувати, а стабільні 150 мс — привід міняти резолвер сьогодні.
Зміна DNS-резолвера: крок, який дає найбільший виграш
Найдієвіший спосіб прискорити повільний DNS-пошук — перестати користуватися резолвером провайдера. Публічні anycast-мережі тримають вузли в сотнях міст, тож ваш запит майже завжди приземляється поруч, а не їде в обласний вузол через три зайві хопи. Cloudflare 1.1.1.1 і 1.0.0.1, Google 8.8.8.8 і 8.8.4.4, Quad9 9.9.9.9 і 149.112.112.112 — це робоча трійка 2026 року. AdGuard 94.140.14.14 варто брати, якщо потрібне блокування реклами на рівні імен, Control D і NextDNS — якщо хочете профілі на сім’ю й окремі пристрої.
Для чистої швидкості без фільтрів ставте 1.1.1.1. Для балансу швидкості й відсікання шкідливих доменів — 9.9.9.9. Google лишається запасним варіантом із величезною мережею, хоча за глобальними зрізами він трохи повільніший за Cloudflare. Сімейні профілі Cloudflare 1.1.1.2 (шкідливе ПЗ) і 1.1.1.3 (шкідливе ПЗ плюс дорослий контент) майже не додають затримки порівняно з «голим» 1.1.1.1, якщо не вмикати важкі корпоративні політики.
| Резолвер | Основний / запасний IPv4 | Кому підходить |
|---|---|---|
| Cloudflare | 1.1.1.1 / 1.0.0.1 | Максимальна швидкість, мінімум логів |
| Google Public DNS | 8.8.8.8 / 8.8.4.4 | Стабільність і широке покриття |
| Quad9 | 9.9.9.9 / 149.112.112.112 | Блок шкідливих доменів «із коробки» |
| AdGuard DNS | 94.140.14.14 / 94.140.15.15 | Реклама й трекери на рівні DNS |
Таблиця не замінює тест у вашій точці. У Вінниці Quad9 інколи відповідає швидше за Cloudflare, у прифронтовому регіоні з кривим маршрутом оператора перемагає Google. Завжди залишайте два адреси: основний і запасний. Якщо пропишете лише один і він моргне, браузер зависне на таймауті.
Підводний камінь: корпоративний ноутбук із NRPT і політиками домену. Публічний DNS зламає внутрішні імена на кшталт mail.company.local. Для домашнього ПК це не проблема, для робочого — спочатку перевірте, чи є внутрішні зони. Другий камінь — батьківський контроль провайдера, зав’язаний саме на їхній DNS. Після зміни резолвера фільтр зникне, і це може бути як плюс, так і сюрприз для родини.
Емоційно цей крок найприємніший: сайти, які «думають» перед відкриттям, раптом стартують одразу. Не швидкість завантаження фільму зміниться, а саме відчуття жвавості інтерфейсу — той самий клац, після якого сторінка більше не тупить у порожнечу.
Міфи vs реальність. Міф: «DNS прискорює інтернет у мегабітах». Реальність: він скорочує час до першого байта, а не ширину каналу. Міф: «1.1.1.1 завжди найшвидший у світі». Реальність: у вашому районі перемогу може взяти Quad9 або навіть DNS оператора, якщо той стоїть за 2 мс від вас. Міф: «Шифрований DNS завжди швидший». Реальність: DoH додає рукостискання TLS; виграш з’являється, коли провайдер ріже, підміняє або чергами душить звичайний порт 53. Міф: «Очистити кеш — назавжди вилікує повільний пошук». Реальність: це ліки від зіпсованих записів, а не від повільного резолвера.
Очищення кешу: коли стара відповідь гірша за нову
Кеш — друг, поки не зіпсується. Після зміни DNS, стрибка з VPN, зміни Wi-Fi або переїзду сайта на нову IP-адресу система ще хвилинами (іноді годинами) віддає застарілий запис. Браузер при цьому може показувати «підключення…», крутити індикатор і створювати ілюзію повільного пошуку. Очищення кешу не робить резолвер швидшим назавжди, але прибирає мертві адреси й змушує систему сходити по свіжу відповідь.
На Windows у командному рядку від адміністратора виконайте ipconfig /flushdns. У PowerShell той самий ефект дає Clear-DnsClientCache. На macOS потрібні дві команди підряд: sudo dscacheutil -flushcache і sudo killall -HUP mDNSResponder. На Linux із systemd-resolved: sudo resolvectl flush-caches. Якщо крутиться dnsmasq або nscd, перезапустіть відповідну службу. Після цього зробіть контрольний dig або Resolve-DnsName — час має стати чесним, без сюрпризів із минулого.
Браузер тримає окремий шар. У Chrome, Edge і Brave відкрийте chrome://net-internals/#dns (для Edge — edge://) і натисніть Clear host cache. На сусідній сторінці сокетів скиньте пул з’єднань. Firefox ховає це в about:networking#dns. Приватне вікно часто допомагає швидше за всі команди: якщо там сайт леткий, а в звичайному профілі ні — винен не DNS системи, а розширення, старий service worker або сам кеш браузера.
Історія з практики: після нічної зміни IP на хостингу інтернет-магазин «не відкривався» половині клієнтів до обіду. Канал був живий, ping проходив на стару адресу, яка вже нікого не слухала. Комусь допоміг flush, комусь — просто перезапуск браузера. TTL стояв 3600, тож частина резолверів чесно тримала мертвий запис годину. Це не привід ставити TTL 30 секунд назавжди: короткий TTL б’є всіх відвідувачів зайвими запитами щодня, а не лише в ніч переїзду.
Не чистіть кеш щогодини «для швидкості». Ви навпаки змушуєте кожен новий візит іти в мережу. Чистіть після зміни резолвера, після VPN, після міграції домену і коли конкретне ім’я резолвиться «не туди». У 2026-му додався ще один привід: профіль корпоративного Zero Trust, який підміняє DNS лише поки увімкнений агент. Вимкнули агент — і кеш ще годину тягне внутрішні відповіді в цивільний інтернет.
Windows, macOS і Linux: де саме прописати нові адреси
На Windows 11 шлях короткий: Параметри → Мережа та Інтернет → ваш адаптер Wi-Fi або Ethernet → Призначення DNS-сервера → Редагувати → Вручну. Увімкніть IPv4, впишіть 1.1.1.1 і 1.0.0.1. Одразу нижче ввімкніть DNS поверх HTTPS у режимі On (automatic template) — Windows сам підхопить шаблон для Cloudflare, Google і Quad9. Те саме зробіть для IPv6: 2606:4700:4700::1111 і 2606:4700:4700::1001. Якщо IPv6 залишити на автоматі з DNS провайдера, система знову ходитиме «в обхід» вашого швидкого резолвера.
На Windows 10 інтерфейс старіший: властивості адаптера → IPv4 → Властивості → «Використовувати наступні адреси DNS». DoH там не такий зручний, тож або оновіться, або поставте шифрування в браузері. Окремо вимкніть невикористовувані віртуальні адаптери Hyper-V, старого VPN і «фантомні» тунелі в ncpa.cpl. Windows інколи надсилає запит саме в них і чекає таймаут, перш ніж піти в живий Wi-Fi.
macOS: Системні параметри → Мережа → Wi-Fi → Деталі → DNS. Мінус старі адреси, плюс 1.1.1.1 і 1.0.0.1. Для шифрування на всі мережі, включно з мобільним модемом, зручніший профіль DoH/DoT або програма 1.1.1.1. Linux залежить від дистрибутива: у Ubuntu з systemd-resolved дивіться resolvectl status, адреси задають через netplan або NetworkManager. Слідкуйте, щоб /etc/resolv.conf не перезаписувався роутером після кожного DHCP-лізу.
| Система | Очистити кеш | Побачити поточний DNS |
|---|---|---|
| Windows | ipconfig /flushdns | Get-DnsClientServerAddress |
| macOS | dscacheutil -flushcache і killall -HUP mDNSResponder | scutil –dns |
| Linux (systemd) | resolvectl flush-caches | resolvectl status |
Команди з таблиці варто зберегти в нотатках. Після будь-якої зміни DNS без flush ви ще якийсь час живете старим життям і вирішуєте, що «нічого не допомогло». На Linux окремий грабель — stub-резолвер 127.0.0.53: ви думаєте, що ходите на 1.1.1.1, а насправді спочатку стукаєте в локальну заглушку, яка форвардить куди їй скаже NetworkManager.
У 2026 році Windows Server отримав можливість приймати клієнтські DoH-запити після червневого оновлення безпеки. Для домашнього користувача це сигнал простіший: шифрований DNS уже не екзотика ентузіастів, а штатна опція клієнта. Увімкнули шаблон — і браузер, термінал, Steam і банк ходять одним і тим самим захищеним шляхом, без окремої магії в кожній програмі.
Чек-лист швидкого ремонту
- Перевірити сайт у приватному вікні й на іншому браузері.
- Зняти час через dig / Resolve-DnsName на системному DNS і на 1.1.1.1.
- Очистити кеш ОС і кеш хостів браузера.
- Вимкнути VPN і зайві віртуальні адаптери, повторити замір.
- Прописати публічний DNS на адаптері й окремо на IPv6.
- Якщо гальмують усі пристрої — змінити DNS у DHCP роутера й перезапустити його.
- Якщо гальмує один домен — перевірити NS і CNAME цього домену.
Йдіть зверху вниз і зупиняйтесь, щойно холодний запит стабільно падає нижче 40–50 мс. Не треба вмикати всі пункти «про запас»: кожна зайва надбудова — це новий шанс зламати резолв внутрішніх імен або captive-портал готелю.
Смартфон і планшет: Private DNS без танців із додатками
На телефоні повільний DNS-пошук б’є болючіше, ніж на ПК: кожен перехід у додаток банку, карти чи маркетплейсу стартує з резолву. Android 9 і новіші мають штатний Приватний DNS. Шлях: Налаштування → Мережа та Інтернет → Приватний DNS → Ім’я хоста постачальника. Для Cloudflare впишіть dns.cloudflare.com або one.one.one.one, для Quad9 — dns.quad9.net, для AdGuard — dns.adguard.com. Це DNS over TLS, працює і в Wi-Fi, і в мобільній мережі. IP на кшталт 1.1.1.1 сюди вставляти не можна — потрібен саме хост.
Після збереження відкрийте сторінку перевірки 1.1.1.1/help і подивіться, чи горить Using DNS over TLS. Якщо інтернет «зник» на гостьовому Wi-Fi готелю, винен captive-портал: приватний DNS не дає відкрити сторінку авторизації. Тимчасово поставте «Вимкнено», пройдіть портал, потім поверніть хост. Це не баг вашого телефону, так влаштований шифрований канал: оператор більше не бачить імена, тож і свою заглушку показати не може.
На iOS ручна зміна DNS живе всередині конкретної Wi-Fi-мережі: Налаштування → Wi-Fi → іконка «i» → Налаштувати DNS → Вручну. Для стільникового зв’язку цього мало. Тому на iPhone логічніший офіційний застосунок 1.1.1.1 або конфігураційний профіль DoH/DoT. Профіль ставиться один раз і працює в усіх мережах. За моїм досвідом саме стільниця дає найбільший виграш: DNS оператора в роумінгу або на перевантаженій базовій станції вміє думати сотні мілісекунд на просте ім’я.
Не ставте одночасно і системний Private DNS, і VPN із власним резолвером, і ще «прискорювач інтернету» з маркету. Три шари починають сперечатися, хто головний, і ви отримуєте ті самі 10-секундні паузи, від яких тікали. Один джерело істини. Якщо VPN потрібен для роботи — нехай DNS роздає він, а системний Private DNS на цей час відпочиває.
У 2026-му виробники оболонок Android ховають пункт у різних місцях: у когось це «Підключення та спільний доступ», у когось пошук по слову DNS рятує швидше за ручне блукання. Знайшли, прописали, перевірили на LTE і на домашньому Wi-Fi окремо. Телефон, який літає на мобільному інтернеті й тупить удома, майже завжди вказує пальцем на роутер, а не на «поганий Android».
Роутер, VPN і пастки, через які страждає вся квартира
Якщо ноутбук, телевізор і телефон туплять синхронно, лікуйте роутер, а не кожен пристрій. Зайдіть у панель (часто 192.168.0.1 або 192.168.1.1), знайдіть WAN/Internet DNS або DHCP DNS і поставте ті самі 1.1.1.1 / 1.0.0.1. Збережіть, перезавантажте роутер, на клієнтах зробіть оновлення оренди DHCP. Усі «розумні» лампочки й телевізори після цього теж перестануть ходити до сонливого резолвера оператора. Це один із тих рідкісних випадків, коли одна зміна лікує десяток гаджетів.
VPN — головний генератор 5–15-секундних зависань. Тунель упав, а адаптер лишився з DNS офісу, який з інтернету не відповідає. Система чесно чекає таймаут. Вимкніть VPN, вимкніть «підключатись при старті», у Windows перегляньте адаптери й вимкніть зайві. Якщо робочий VPN потрібен щодня, увімкніть у клієнті split DNS або «використовувати DNS тунелю лише для внутрішніх зон». Інакше кожна публічна сторінка ходитиме в офіс за IP-адресою Google.
Попередження. Не прописуйте публічний DNS на робочому ноутбуці з Active Directory, поки не перевірите внутрішні зони. Не змішуйте IPv4 від Cloudflare і IPv6 від провайдера: саме ця суміш дає «інколи літає, інколи думає 10 секунд». Не ставте на роутері одночасно адресу Pi-hole і 8.8.8.8 як рівноправні — клієнт випадково піде в Google й обійде ваші фільтри, або навпаки впаде в Pi-hole, який саме перезавантажується. Після будь-якої зміни DNS у гостьовій мережі перевірте captive-портали й банківські додатки з перевіркою сертифікатів.
Pi-hole, AdGuard Home і подібні коробки вдома — чудовий щит, але погано налаштований резолвер стає вузьким місцем. Порівняйте dig @IP-pi-hole і dig @1.1.1.1. Якщо локальний повільніший на сотні мілісекунд, дивіться апстрім, блок-листи на сотні тисяч правил, SD-картку в Raspberry Pi та IPv6. У нашій практиці стара Pi 3 з гігантським списком дає затримку, яку люди місяцями списують на «Київстар» чи «Водфон».
Ще одна тиха отрута Windows — зайві суфікси пошуку, LLMNR і NetBIOS, коли DNS не відповів з першого разу. Система починає мультичат по локалці, чекає, пробує коротке ім’я, знову чекає. Для домашнього ПК без мережевих дисків це мертвий вантаж. Для офісу з старими NAS — навпаки, необхідність. Вимикайте лише якщо розумієте, чим користуєтесь. У 2026-му Microsoft давно штовхає мережу в бік mDNS, але «на всяк випадок» увімкнені протоколи досі живуть на мільйонах ноутбуків і додають секунди там, де їх ніхто не чекає.
Прошивка роутера теж вміє старіти. Бюджетна модель з 2019 року тримає крихітний DNS-кеш, зависає на DNSSEC і інколи переписує відповіді. Оновлення прошивки, вимкнення «прискорення сайтів» від виробника й окремий DNS на WAN знімають дивні симптоми, які не лікуються жодним flush на ноутбуці.
Шифрований DNS у 2026-му й оптимізація для власників сайтів
Звичайний DNS летить відкритим текстом на порт 53. Провайдер бачить кожне ім’я, може підмінити відповідь, вставити свою заглушку, віддати рекламну IP для неіснуючого домену. DoH ховає запит у HTTPS, DoT — у TLS на порт 853, DoQ несе DNS прямо поверх QUIC. У березні 2026-го Quad9 увімкнув DNS over HTTP/3 і DNS over QUIC на всій мережі. Для домашнього користувача практичний шлях усе ще DoH у Windows 11 і DoT в Android Private DNS: це вже штатно, без танців.
Шифрування не обіцяє мінус 50 мс завжди. Рукопожаття коштує. Виграш з’являється, коли оператор чергами душить порт 53, коли в мережі «безкоштовний Wi-Fi» з підміною, коли антивірус перехоплює запити й віддає їх сонливо. Після ввімкнення DoH повторіть заміри. Якщо стало гірше на 20–30 мс, а підмін немає — можна лишити звичайний UDP на 1.1.1.1. Швидкість тут чесніша за моду.
Власникам сайтів повільний DNS-пошук відвідувача — це вже ваша репутація. Тримайте NS на anycast-провайдері, а не на одному VPS. Скорочуйте ланцюжки CNAME: кожен зайвий аліас — зайвий RTT. Для кореня домену використовуйте ALIAS або flattening, щоб не змушувати клієнта стрибати двічі. TTL для стабільних A/AAAA ставте 3600 або більше; 60 секунд залишайте лише на ніч переїзду. У HTML додавайте rel=”dns-prefetch” і ще краще rel=”preconnect” для шрифтів, аналітики й платіжного домену, щоб браузер резолвив їх, поки користувач ще дивиться шапку сайта.
Приклад з життя: лендінг тягнув шрифт з fonts.googleapis.com, віджет з cdn стороннього чату і піксель із третього домену. Без prefetch перший екран чекав три холодні DNS плюс TLS. Після трьох рядків у
LCP просів на сотні мілісекунд без жодної зміни серверного коду. У 2025–2026 роках частка сторінок із dns-prefetch досі близько чверті: тобто троє з чотирьох власників дарують конкурентам фору на старті.Не вмикайте на авторитетних серверах одночасно і важкий DNSSEC із кривим ланцюжком, і мікроскопічний TTL, і географічно один вузол. Перевірка підпису додає обчислення; якщо ключі зламані, частина резолверів взагалі не відповість, і клієнт вирішить, що «сайт лежить». Порівняйте dig звичайний і dig +cd. Різниця в секундах означає, що копати треба не кеш користувача, а ваш підпис.
Фінальний робочий ритм на 2026 рік простий і не героїчний. Виміряли. Змінили резолвер там, де він справді повільний. Очистили кеш один раз. Прибрали мертві тунелі. Прописали DNS на роутері. На телефоні ввімкнули Private DNS. Для свого сайта прибрали CNAME-ліани й дали браузеру prefetch. Після цього «інтернет думає» зникає не тому, що канал став ширшим, а тому, що довідник нарешті відповідає в темпі живої розмови, а не поштового листування.
Вердикт. Прискорити повільний DNS-пошук у домашній мережі можна за 15 хвилин: публічний резолвер, flush, роутер, Private DNS на Android. Цілі в цифрах — холодний запит стабільно нижче 50 мс, без 5-секундних «ямин». Якщо після цього гальмує лише один сайт, це вже його інфраструктура, не ваша. Якщо гальмує все навіть на 1.1.1.1 — шукайте Wi-Fi, VPN і IPv6, а не новий «магічний» DNS з реклами. Швидкий довідник не замінить нормальний канал, але саме він найчастіше відділяє нервове очікування від відчуття, що сторінка відкривається одразу.
Leave a Reply