Швидкість сайту і Core Web Vitals у 2026: чому повільний сайт втрачає позиції та гроші

Відкрийте аналітику свого сайту і знайдіть дві цифри: скільки людей зайшло і скільки дійшло до форми чи дзвінка. Між ними — прірва, і частину цієї прірви пояснюють швидкість сайту і Core Web Vitals — не текст, не ціна і не дизайн. Вона живе в тих двох-трьох секундах, поки людина в телефоні в метро дивиться на білий екран і чекає, коли ж нарешті щось з’явиться. Половина з них не дочекається. Вони закриють вкладку й відкриють наступну — конкурента, у якого відкрилося одразу. Ви за цей відхід заплатили: чи рекламою, що привела людину на повільну сторінку, чи місяцями SEO, щоб вона взагалі вас знайшла. Гроші пішли, заявка — ні.

Швидкість сайту і Core Web Vitals — це не технічний каприз розробників і не рядок у звіті, який приємно бачити зеленим. Це той самий момент, де зустрічаються дві речі, які зазвичай вважають різними: позиції в пошуку і виручка. Повільний сайт гірше ранжується і водночас гірше продає — подвійний штраф за ту саму проблему. І у 2026 році ціна цієї проблеми зросла, бо майже весь трафік тепер мобільний, а телефон у реальній руці на реальній мережі куди повільніший за ноутбук, на якому ви милуєтеся своїм сайтом.

Розберімо по-людськи, що Google вимірює, які цифри він вважає хорошими, як саме повільні сторінки тихо з’їдають ваші заявки й піднімають вартість реклами, і — головне — що насправді гальмує сайти і як це лагодять. Без жаргону там, де без нього можна обійтися.

Core Web Vitals простими словами: три цифри, які бачить Google

Google давно зрозумів, що «швидкий сайт» — надто розпливчасто, щоб це вимірювати. Тому він звів відчуття швидкості до трьох конкретних показників і назвав їх Core Web Vitals. Кожен відповідає на просте питання живої людини, яка щойно відкрила вашу сторінку.

• LCP (Largest Contentful Paint) — «коли я нарешті щось побачу». Це час до відмальовування найбільшого блоку в першому екрані: головної картинки, заголовка, банера. Поки LCP не стався, людина дивиться на порожнечу і вирішує, чекати їй чи піти.
• INP (Interaction to Next Paint) — «коли сайт відповість на мій клік». Людина натиснула кнопку, тапнула по меню, почала гортати — за скільки сторінка відреагувала? Якщо між тапом і реакцією помітна затримка, сайт відчувається «залиплим», навіть якщо виглядає гарно. INP у 2026 році — чинна метрика чутливості; вона прийшла на зміну старому FID і питає суворіше.
• CLS (Cumulative Layout Shift) — «чому все стрибає». Ви зібралися натиснути кнопку, аж тут дозавантажилася картинка, вміст зсунувся, і палець влучив по рекламі. Це дратує фізично. CLS вимірює, наскільки вміст скаче під час завантаження.

Три метрики ловлять три різні болі: очікування, гальма й смикання. Сайт може бути ідеальним в одній і провальним в іншій — тому дивитися треба на всі три одразу.

Які значення вважаються хорошими

Тут Google не лишив простору для трактувань — пороги опубліковані. Ось орієнтир за чинними значеннями; тримайте його під рукою.

Метрика	Що вимірює	«Добре»	«Погано» (треба лагодити)
LCP	Швидкість завантаження основного вмісту	до 2,5 с	більше за 4,0 с
INP	Чутливість на дії	до 200 мс	більше за 500 мс
CLS	Візуальна стабільність	до 0,1	більше за 0,25

Один нюанс, який змінює все. Google оцінює ці пороги за 75-м перцентилем — тобто показник має вкладатися в норму приблизно у трьох чвертей ваших відвідувачів. Не в середньому, не на вашому ноутбуці, не «зазвичай нормально». Якщо у чверті людей сайт вантажиться по п’ять секунд, бо вони на старому телефоні й слабкій мережі, — у вас проблема, навіть коли особисто у вас усе літає. Саме тому самоперевірка «у мене ж швидко відкривається» майже завжди обманює.

Швидкість сайту і Core Web Vitals у позиціях: де правда, а де міф

Навколо швидкості накручено багато страху, тому скажімо чесно й без перебільшень. Core Web Vitals — це підтверджений чинник ранжування, але не головний. Google прямо каже: за інших рівних швидша й стабільніша сторінка отримує перевагу, але швидкість не витягне нагору слабку по суті сторінку й не втопить по-справжньому релевантну. Якщо хтось обіцяє вам топ-1 «просто за рахунок прискорення сайту» — він лукавить.

Але справжній вплив швидкості на позиції — не прямий, а через поведінку людей, і він куди сильніший за будь-який формальний сигнал. Працює це так:

• Зі швидкого сайту рідше йдуть одразу. Людина дочікується завантаження, починає читати — і Google бачить, що сторінка втримала увагу.
• На швидкому сайті дивляться більше сторінок і довше лишаються. Це сигнал, що вміст корисний.
• На швидкому сайті частіше доходять до заявки. А конверсія в дію — найчесніша ознака того, що сторінка відповідає на запит людини.

Пошуковику не треба «штрафувати» вас за повільність напряму — досить того, що люди голосують ногами, а Google цей голос зчитує. Тож швидкість — це і прямий сигнал, і підсилювач усіх інших. Якщо ви запитуєте себе, чому сайт не зростає в пошуку, технічна швидкість — один із перших пунктів, який варто перевірити, перш ніж винуватити контент.

Як повільний сайт тихо з’їдає заявки і піднімає ціну реклами

Ось частина, яку власники бізнесу недооцінюють найсильніше, бо її не видно у звіті напряму. Швидкість б’є по грошах у двох місцях одночасно.

Перше — конверсія. Кожна зайва секунда завантаження коштує вам частини людей, які вже були готові щось зробити. Галузеві дослідження з року в рік показують один і той самий напрямок: імовірність відходу різко росте в міру того, як сторінка тягнеться від однієї секунди до трьох і далі, а на мобільних це відчувається ще гостріше. Точні відсотки гуляють від дослідження до дослідження, і обіцяти «мінус X% виручки за секунду» було б нечесно — але напрямок залізний: повільніше майже завжди означає менше заявок. І найприкріше, що втрачаєте ви найгарячіших — тих, хто вже клікнув і прийшов.

Друге — вартість реклами. Тут зв’язок менш очевидний, але цілком реальний. Рекламні системи на кшталт Google Ads враховують якість посадкової сторінки, і швидкість із зручністю — частина цієї якості. Повільна сторінка тягне показник якості вниз, а це означає вищу ціну за клік за ту саму позицію. Подвійний удар: ви платите за клік дорожче і гірше перетворюєте ці кліки на заявки. Перш ніж піднімати рекламний бюджет, полагодьте сторінку, на яку ллєте трафік, — інакше ви доплачуєте за те, щоб швидше показувати людям повільний сайт.

Складіть обидва ефекти — і повільний сайт виявляється не «дрібним технічним боргом», а тихою течею у виручці, яку ви оплачуєте щодня.

Що насправді гальмує сайти

Хороша новина: причин у повільності небагато, і вони майже завжди ті самі. Ось чесний список головних винуватців — за спаданням того, як часто ми бачимо їх у реальних проєктах.

1. Важкі картинки. Винуватець номер один. Фотографія на чотири мегабайти, завантажена як є й стиснута до маленького блока силами браузера, убиває LCP сама-одна. Сюди ж — відсутність сучасних форматів і одна гігантська картинка замість версій під різні екрани.
2. Роздутий JavaScript. Забагато скриптів, які браузер мусить скачати, розібрати й виконати, перш ніж сторінка стане чутливою. Це головний убивця INP. Кожен віджет, чат, попап і лічильник додає ваги — а половина з них на сторінці взагалі не потрібна.
3. Render-blocking — скрипти та стилі, що блокують відмальовування. Коли важкі CSS- і JS-файли вантажаться на початку й не дають браузеру показати сторінку, поки не завантажаться самі, людина дивиться на білий екран довше, ніж мала б.
4. Дешевий або перевантажений хостинг. Якщо сам сервер думає над відповіддю по секунді, прискорювати вже нема чого — фундамент повільний. Дешевий спільний хостинг, де на одній машині тісняться сотні сайтів, регулярно стає вузьким горлом.
5. Роздуті конструктори й плагіни. Універсальні шаблони вантажать кілобайти CSS і JS «на всі випадки життя», які вашій конкретній сторінці не потрібні. Десяток плагінів, кожен зі своїми скриптами й стилями, перетворює просту сторінку на важковаговика. Про це — окремо нижче.
6. Відсутність кешування і CDN. Коли кожному відвідувачу все збирається наново, а файли їдуть з одного сервера через пів світу, швидкість просідає там, де її легко було б повернути.
7. Сторонні скрипти. Аналітика, пікселі, чати, карти, шрифти зі сторонніх доменів — кожен тягне свою нитку запитів. Окремо дрібниця, разом — помітний вантаж, який ще й поза вашим прямим контролем.

Зауважте закономірність: майже все в цьому списку — рішення, ухвалені під час розробки. Швидкість не «налаштовують» наприкінці SEO-галочкою. Її або закладають в основу сайту, або потім болісно відвойовують по крихтах.

Окремо про конструктори: чому «все включено» часто означає «все важке»

Конструктори сайтів зручні, і для простої візитки їх часто вистачає. Але у зручності є ціна в кілобайтах. Щоб один шаблон підходив мільйонам різних сайтів, у нього закладають усе підряд — а ваша сторінка використовує п’ять відсотків цього й тягне решту дев’яносто п’ять мертвим вантажем. Додайте сюди плагіни: кожен, щоб працювати «з коробки» у всіх, вантажить свої скрипти й стилі на кожній сторінці, навіть там, де він не потрібен.

Стиснення картинок, лінива загрузка й чистка зайвих плагінів реально допомагають і варті того, щоб їх зробити. Але є стеля: якщо роздутість зашита в саму архітектуру білдера, вище за певний рівень швидкості ви не стрибнете, скільки б не оптимізували. У якийсь момент чесний розрахунок показує, що переїхати на легкий, зібраний під вас сайт дешевше й швидше, ніж роками лікувати симптоми. Це та сама розвилка, що й у загальнішому виборі агенція чи конструктор: конструктор економить на старті, але стелю швидкості й гнучкості задано платформою, а не вами.

Як виміряти швидкість свого сайту

Гадати не треба — Google дає безкоштовні інструменти, які показують рівно ті цифри, за якими він сам вас оцінює.

• PageSpeed Insights. Вставляєте адресу сторінки — отримуєте звіт. Головне правило: дивіться насамперед на польові дані (CrUX), а не на лабораторний результат. Лабораторний тест — це один прогін на стандартному пристрої в ідеальних умовах. Польові дані — це реальні Core Web Vitals ваших живих відвідувачів за останні 28 днів, зібрані з браузера Chrome. Саме їх Google використовує для ранжування, і саме вони кажуть правду про те, як сайт відчувається у людей, а не у вас.
• Search Console, звіт Core Web Vitals. Показує картину по всьому сайту одразу, окремо для мобільних і десктопа, і групує проблемні URL — зручно, коли сторінок багато і треба зрозуміти, де тече масово.
• Польові проти лабораторних. Якщо лабораторія каже «чудово», а поле — «погано», вірте полю. Розбіжність зазвичай означає, що у реальних людей пристрої слабші та мережі повільніші, ніж у тестового стенда. Лагодьте під поле.

Одна практична порада: не зациклюйтеся на гарному числі «загального бала» в PageSpeed — він скаче від прогону до прогону. Дивіться на самі LCP, INP і CLS у польових даних: це те, що реально рахує Google і відчуває ваш клієнт.

Чому швидкість — це стик розробки та SEO (і чому Webtor робить і те, і те)

Швидкість сайту живе рівно на межі двох професій, які в більшості компаній сидять нарізно й кивають одна на одну. SEO-фахівець бачить у Search Console червоний звіт по Core Web Vitals і пише: «треба прискорити сайт». Розробник відповідає: «дайте задачу конкретніше». А реальна лагодка вимагає обох одночасно: розуміти, що LCP, INP і CLS — це сигнали, які рухають позиції й заявки, і вміти залізти в картинки, скрипти, рендеринг і хостинг, щоб ці цифри зрушити. Коли між цими двома людьми лежить межа компаній, проблема зависає в повітрі місяцями.

Тому ми у Webtor свідомо тримаємо розробку і SEO під одним дахом. Сайт, який ми збираємо, від початку проєктується швидким: оптимізовані картинки, мінімум зайвого JavaScript, чистий код без баласту універсальних шаблонів, нормальний хостинг і кешування. А потім той самий підхід обслуговує позиції — бо швидкий, стабільний сайт легше просувати, і він сам допомагає решті SEO працювати. Це не дві послуги, які ми продаємо поряд. Це одна робота, яку неправильно ділити.

Якщо ви прикидаєте, у що це обійдеться, швидкість не існує у відриві від решти — вона частина того, скільки коштує хороший сайт, і частина вартості SEO-супроводу. Дешевий сайт на важкому шаблоні економить гроші в день запуску й повертає цей рахунок потім — у втрачених заявках і переплаті за рекламу. Закладена з самого початку швидкість, навпаки, окупається тихо й щодня.

З чого почати цього тижня

Якщо читати це як список на пів року — так, по-крупному будова чимала. Але зрушити можна за тиждень, і за спаданням віддачі порядок такий:

1. Проженіть три головні сторінки через PageSpeed Insights — головну, ключову сторінку послуги й одну посадкову з реклами. Дивіться польові дані, випишіть LCP, INP і CLS.
2. Почніть із картинок. Це майже завжди найшвидший виграш: стисніть важкі зображення, віддавайте версії під розмір блока, увімкніть ліниву загрузку для всього, що нижче за перший екран.
3. Приберіть зайве. Кожен плагін, віджет і сторонній скрипт, який ви не використовуєте свідомо, — кандидат на видалення. Менше скриптів — швидший INP.
4. Перевірте хостинг. Якщо сервер відповідає повільно сам по собі, решта — косметика. Іноді переїзд на нормальний хостинг дає більше, ніж десяток дрібних правок.
5. Передивіться за пару тижнів. Польові дані оновлюються не миттєво — дайте CrUX накопичити реальні візити і знову звіртеся з порогами.

Зробіть це для трьох сторінок, побачте результат на цифрах — а далі вирішуйте, лагодити решту за списком чи, якщо в основі роздутий білдер, переїжджати на сайт, у якого швидкість закладена у фундамент.

Хто зрештою виграє

Повернімося до людини в метро, яка дивиться на білий екран. Вона не злиться на вас і не пише скарг — вона просто йде, мовчки, до того, у кого відкрилося одразу. Ви про цей відхід ніколи не дізнаєтеся напряму: він не лишить сліду у формі зворотного зв’язку, він розчиниться в зазорі між «зайшов» і «дійшов до заявки». І щодня таких — десятки.

Швидкість сайту і Core Web Vitals виграє не той, у кого гарніша картинка бала в PageSpeed, а той, у кого реальна сторінка на реальному телефоні відкривається раніше, відповідає на тап без затримки і не стрибає під пальцем. Цей сайт Google ставить трохи вище, і з нього частіше доходять до дзвінка — два виграші за одну вкладену в швидкість роботу. У 2026 році, коли майже весь трафік мобільний, а увага людини вимірюється секундами, це вже не тонке налаштування для гіків. Це різниця між сайтом, який заробляє, і сайтом, який тихо втрачає — і заявки, і місце у видачі, і гроші на рекламу, які ви за все це вже заплатили.