Від запиту до рендерингу: що тестувати в SSR-застосунках

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт! Мене звати Артем, я тімлід QA-команди в VeliTech. Ми працюємо з вебзастосунками, що рендеряться на сервері (SSR), і цей підхід є базовим для наших продуктів. Кожного разу стикаюся з тим, що тестування таких систем стає викликом навіть для досвідчених спеціалістів.

SSR — це не SPA. Тут перший рендер формується на сервері, а між клієнтом і бекендом стоїть кілька рівнів кешування (Cloudflare, Next.js). Частину запитів ви взагалі не побачите у браузері.

У результаті: сторінка може відрендеритися коректно, але питання лишається — ви бачите свіжі дані з бекенду чи копію з кешу?

З власного досвіду скажу: ця невизначеність часто заводить тестувальників у глухий кут. Тому поділюся практичним підходом, що саме варто перевіряти в SSR, де шукати відповіді й як не загубитися, коли DevTools мовчить.

У цій статті ви знайдете:

• чому SSR складніше тестувати, ніж класичні SPA;
• як виглядає життєвий цикл запиту «зсередини»;
• де найчастіше ховаються проблеми (кешування, логування, реальний час);
• чекліст для QA, який реально допомагає в роботі.

На перший погляд SSR здається просто ще одним способом рендерингу фронту. Але...

У SPA схема проста:

користувач відкрив сторінку → фронт виконав запити → у Network видно Request та Response.

У SSR-застосунках усе складніше: сервер готує HTML ще до того, як користувач його побачить. Це дає кращу швидкість завантаження, безпеку, SEO та UX, але ускладнює тестування. Через це DevTools показує лише частину картини. SSR-запити виконалися до того, як сторінка доїхала до вас. А якщо ще й спрацював кеш Cloudflare чи Next.js, то бекенд взагалі міг не брати участі.

Типові проблеми:

• складно зрозуміти, який саме запит був виконаний і що пішло в кеш;
• не завжди можна подивитися «живу» відповідь (Cloudflare/Next.js Cache віддають Hit);
• різні шари логування (Elastic, Grafana, Gloo) плутають новачків;
• баги часто виникають не у фронті, а між кешем і бекендом.

Життєвий цикл запиту: від клієнта до рендеру

Щоб тестувати SSR, треба уявляти весь flow. Схематично він виглядає так:

Користувач → Cloudflare (CDN + кеш) → Next.js (SSR + кеш) → Backend (API, DB)

• Cloudflare: може одразу віддати кешовану сторінку (Cache Hit) або передати запит далі (Miss).
• Next.js: рендерить HTML на сервері. Має власний кеш.
• Backend: збирає дані, обробляє бізнес-логіку, повертає результат.

Якщо хоча б на одному етапі кеш віддав «старі» дані, тестувальник побачить зовсім не те, що відбувається реально на бекенді.

Де зазвичай виникають проблеми:

• Кеш Cloudflare або Next.js віддав копію → ви бачите старі дані.
• У Network відсутні SSR-запити → їх не видно, бо все відбулося на сервері.
• Затримки та тайм-аути важко локалізувати: чи це CDN, чи кеш на рівні Next.js, чи сам бекенд.

Тут легко переплутати кешову проблему з реальним багом на сервері.

Як шукати відповіді під капотом

Тут у гру вступають інструменти.

DevTools (Network) — швидка діагностика

Почніть із найпростішого: заголовки відповіді.

Звертайте увагу на:

• cf-cache-status: HIT/MISS (Cloudflare);
• x-nextjs-cache: HIT/MISS (Next.js).

Якщо бачите HIT, то бекенд міг узагалі не працювати. Це сигнал до перевірки логів далі.

Kibana (Elastic) — де видно справжні SSR-запити

Тут починається найцікавіше. У нашому випадку корисний індекс k8s-gloo*, у вас може бути інший.

Мінімальний набір полів, який варто додати у Discover:

• Path — який саме URL викликався;
• method — тип запиту;
• authority — домен;
• userAgent — хто викликав: ви чи бот;
• upstreamCluster — куди реально пішов запит;
• code і duration — статус і час виконання.

Далі вже фільтруєте за своїм path чи userAgent і дивитеся, чи дійсно бекенд отримав і обробив ваш запит.

Це критично: якщо в Kibana логів немає, отже кеш віддав відповідь ще до бекенду.

Grafana (Explorer) — картина зверху

У Kibana ви працюєте точково, а Grafana дозволяє зрозуміти масштаб проблеми:

• кількість запитів на секунду (RPS);
• середній час відповіді;
• відсоток помилок.

Типова ситуація: у Kibana бачите, що ваш запит не дійшов, але в Grafana можна перевірити, чи це одиничний випадок, чи глобальна деградація — наприклад, різкий стрибок 5xx-помилок для всіх користувачів.

Практичний кейс

Кейс 1. Після релізу клієнт скаржиться: «нові ігри не з’являються».

У DevTools усе виглядало ок: сторінка приходила. Але у заголовках відповіді світився cf-cache-status: HIT. У Kibana логів від бекенду не було — тобто запит навіть не доходив.

Очистили кеш на Cloudflare → нові ігри одразу з’явилися.

З цього кейсу винесли головне: не все, що «виглядає нормальним у браузері», реально відпрацьовує бекенд.

Кейс 2. «Різні дані у різних користувачів»

Один користувач бачив стару версію сторінки, інший бачив нову.

У Grafana підтвердили: бекенд отримував свіжі дані, але Next.js віддавав свій кеш.

Висновок: кешування на рівні SSR треба чітко контролювати.

Як тестувати SSR-застосунки: чекліст QA

• Перевіряти Response Headers (cf-cache-status, x-nextjs-cache).
• Дивитися «View Source», а не лише DOM у DevTools.
• Перевіряти логи в Kibana: шлях, метод, upstreamCluster, duration.
• Моніторити Grafana: RPS, latency, error rate.
• Тестувати з різними cookie, мовами, країнами.
• Валідовувати, чи правильно оновлюється кеш після змін у бекенді.

Важливо: завжди комбінуйте інструменти: DevTools → Kibana → Grafana. Жоден із них сам по собі не дасть повної картини.

Замість підсумків

SSR робить застосунки швидшими й безпечнішими, але для QA він додає новий рівень складності. Головна порада: не довіряй тільки тому, що бачиш у браузері. Завжди перевіряй кеш-статуси, логи й дані на бекенді.

У VeliTech ми переконалися, що цінність QA — це не тільки кліки по UI чи API-тести. Це розуміння архітектури продукту й уміння вчасно зловити проблеми на рівні кешу, логів і метрик.

Особисто я дивлюся на SSR-застосунок як на багатошарову систему: CDN → SSR-cache → бекенд. І завдання тестувальника — розібратися, на якому етапі щось пішло не так.

Отже, якщо ви тестуєте SSR-застосунок, ваша робота — не лише «знайти баг у верстці», а зрозуміти, чи працює правильно весь ланцюг від запиту до рендерингу. І саме це дає цінність усій команді.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.