Frontend Observability: xatolar, Web Vitals, tarmoq va sessiyalar

Frontend Observability: xatolar, Web Vitals, tarmoq va sessiyalar

Sahifa 200 OK qaytarishi mumkin, ammo real foydalanuvchi ishlamayotgan checkout tugmasi, to‘rt soniyada yuklanayotgan kontent, muvaffaqiyatsiz API so‘rovi yoki bosishdan bir lahza oldin joyidan siljib ketadigan interfeysga duch kelishi mumkin. Faqat server monitoring bularning barchasini ko‘ra olmaydi, chunki zamonaviy ilovaning katta qismi bevosita brauzer ichida ishlaydi.

Frontend observability shu bo‘shliqni to‘ldiradi. U real brauzer sessiyalaridan dalillar to‘playdi va muhandislarga nafaqat “Sayt ishlayaptimi?”, balki “Foydalanuvchi aslida nimani boshdan kechirdi va nega?” degan savolga ham javob topishga yordam beradi.

Eng foydali frontend observability tizimlari to‘rtta turdagi ma’lumotni birlashtiradi: JavaScript xatolari, Web Vitals, tarmoq faolligi va sessiya konteksti.

Qisqa javob

Frontend observability — sayt yoki web ilovaning foydalanuvchilar brauzeridagi real xatti-harakatini telemetry orqali tushunish uchun uni instrumentatsiya qilish amaliyotidir. Observability odatda loglar, metrikalar va trace’lar kabi chiqish ma’lumotlariga tayanadi; frontend’da esa bunga brauzer xatolari, foydalanuvchi tajribasi metrikalari, resource timing, route o‘zgarishlari va sessiya konteksti tabiiy ravishda qo‘shiladi. (opentelemetry.io)

Maqsad hamma narsani yig‘ish emas. Maqsad alomat → ta’sirlangan sessiya → texnik sabab → tasdiqlangan tuzatish zanjirini qurish uchun yetarli dalillarni bog‘lay olishdir.

Muhim to‘rtta signal

Har bir signal alohida ham foydali. Ammo ular birga ishlaganda diagnostika ancha kuchli bo‘ladi.

INP qiymatining 620 ms bo‘lishi interaction sekin kechganini ko‘rsatadi. Xato biror funksiya muvaffaqiyatsiz bajarilganini bildiradi. Uch soniya davom etgan so‘rov tarmoq yo‘lida qimmat operatsiya bo‘lganini ko‘rsatadi. Ammo uchalasi ham aynan bir sessiya va interaction’ga tegishli bo‘lsa, muammoni tekshirish ancha aniq bo‘ladi.

Xatolarni ko‘rish

Brauzer konsoli development vaqtida foydali, ammo production’dagi xatolar siz nazorat qilmaydigan qurilmalarda yuz beradi. Shu sabab frontend error monitoring xatolarni ushlash va ularga foydali kontekst biriktirishdan boshlanadi.

Brauzerlar sinxron script xatolari uchun error event’ini, rejection handler bo‘lmagan Promise rad etilganda esa unhandledrejection event’ini taqdim etadi. MDN shuningdek cross-origin cheklovlari ayrim unhandled rejection hodisalarini qayd etishni cheklashi mumkinligini qayd etadi. (developer.mozilla.org)

Minimal implementatsiya quyidagicha ko‘rinishi mumkin:

window.addEventListener('error', (event) => {
    reportError({
        type: 'error',
        message: event.message,
        file: event.filename,
        line: event.lineno,
        column: event.colno,
        stack: event.error?.stack,
    });
});

window.addEventListener('unhandledrejection', (event) => {
    reportError({
        type: 'unhandledrejection',
        message: String(event.reason),
        stack: event.reason?.stack,
    });
});

Production’da xatoning o‘zi faqat boshlanishidir. Foydali yozuvlar odatda ilova release’i, route, brauzer, environment va sessiya identifikatorini ham o‘z ichiga oladi. Bundan tashqari, xatolar guruhlanishi kerak: 50 000 foydalanuvchiga ta’sir qilgan bitta defect 50 000 ta alohida incident sifatida ko‘rinmasligi lozim.

Minify qilingan production bundle’lar yana bir muammoni keltirib chiqaradi: stack trace masalan app.8f72d.js:1:48217 manzilini ko‘rsatishi mumkin. Source maps generatsiya qilingan kodni asl JavaScript, WebAssembly yoki CSS manbalariga bog‘laydi. Ularning formati ECMA-426 standarti bilan belgilangan, uning birinchi nashri 2024-yil dekabrda chop etilgan. (ecma-international.org)

INTERNAL LINK: JavaScript Source Maps Explained

Real foydalanuvchilardagi Web Vitals

Xatolar dastur qachon buzilganini ko‘rsatadi. Performance telemetry esa dastur texnik jihatdan ishlayotgan bo‘lsa ham, foydalanuvchi tajribasi yomon bo‘lishi mumkinligini ko‘rsatadi.

Hozirgi Core Web Vitals quyidagilar:

• Largest Contentful Paint (LCP): yuklanish samaradorligi.
• Interaction to Next Paint (INP): javob berish tezligi.
• Cumulative Layout Shift (CLS): vizual barqarorlik.

Google hujjatlarida “good” deb ko‘rsatilgan chegaralar: LCP ≤ 2.5 soniya, INP ≤ 200 millisekund va CLS ≤ 0.1. Ular page visit’larning 75-percentili bo‘yicha, mobil va desktop alohida hisobga olingan holda baholanishi kerak. (web.dev)

Bu percentil muhim. O‘rtacha qiymat sayt sog‘lom ko‘rinishiga sabab bo‘lishi mumkin, garchi foydalanuvchilarning sezilarli qismi muntazam ravishda yomon tajribaga duch kelayotgan bo‘lsa ham.

Production monitoring uchun Google’ning web-vitals kutubxonasi Web Vitals metodologiyasiga mos o‘lchovlarni yig‘ishni osonlashtiradi. Google shuningdek yomon natijalarni tahlil qilish uchun qo‘shimcha diagnostik kontekst beradigan attribution build’ni ham taqdim etadi. (web.dev)

import { onCLS, onINP, onLCP } from 'web-vitals/attribution';

function report(metric) {
    navigator.sendBeacon('/rum', JSON.stringify(metric));
}

onLCP(report);
onINP(report);
onCLS(report);

Bu yerda muhim farq — field data va lab data. Lighthouse va lokal profiling nazorat qilinadigan sharoitda muammolarni qayta hosil qilish va tekshirishga yordam beradi. Real User Monitoring, ya’ni RUM, real qurilmalar, real tarmoqlar va real sessiyalarda aslida nima sodir bo‘lganini ko‘rsatadi. Google real foydalanuvchilardagi Web Vitals’ni baholashda field o‘lchovlaridan foydalanishni aniq tavsiya qiladi. (web.dev)

INTERNAL LINK: Core Web Vitals Explained

Tarmoq observability

Sekin frontend har doim ham JavaScript muammosi degani emas. Brauzer DNS resolution, connection, serverda qayta ishlash, rasm, third-party script yoki API javobini kutayotgan bo‘lishi mumkin.

Resource Timing API resurslar qanday yuklanganiga oid batafsil ma’lumotlarni beradi. Amaldagi W3C Resource Timing draft’i PerformanceResourceTiming ni, jumladan sahifa resurslarini olish jarayoniga oid timestamp va metadata’larni belgilaydi. (w3.org)

Brauzerlar bu yozuvlarni Performance Timeline va PerformanceObserver orqali taqdim etadi. (w3.org)

const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        reportNetwork({
            url: entry.name,
            type: entry.initiatorType,
            duration: entry.duration,
            requestStart: entry.requestStart,
            responseStart: entry.responseStart,
            responseEnd: entry.responseEnd,
            transferSize: entry.transferSize,
        });
    }
});

observer.observe({
    type: 'resource',
    buffered: true,
});

PerformanceResourceTiming DNS lookup, connection setup, request start, response start va response end kabi bosqichlarni ko‘rsatishi mumkin. Bu turli kechikish turlarini bir-biridan ajratishga yordam beradi. (developer.mozilla.org)

Muhim cheklov mavjud: cross-origin resurslar uchun batafsil timing ma’lumotlari odatda cheklangan bo‘ladi. Third-party resurs timing ma’lumotlarini ko‘rsatishga Timing-Allow-Origin response header orqali aniq ruxsat berishi kerak. (w3.org)

Bu keng tarqalgan diagnostika xatosining oldini oladi. analytics.example.com/script.js ikki soniyada yuklangani bu ikki soniya DNS, connection o‘rnatish, server response time yoki response body’ni yuklab olishga ketganini avtomatik ravishda ko‘rsatmaydi. Siz ko‘ra oladigan dalillar brauzer xavfsizlik qoidalari va server konfiguratsiyasiga bog‘liq.

Sessiya konteksti

To‘rtinchi signal boshqa savolga javob beradi: muammo yuz bergan paytda nimalar sodir bo‘layotgan edi?

Cannot read properties of undefined nomli xatoni tasavvur qiling. Kontekstsiz muhandis uni qo‘lda qayta hosil qilishi kerak bo‘lishi mumkin.

Endi quyidagilarni qo‘shamiz:

Release: 2026.09.25-4
Route: /checkout/payment
Session: a8f2...
Previous action: Click "Pay"
API: POST /payments → 500
INP: 684 ms
Error: PaymentForm.submit

Endi incidentning o‘zi voqealar ketma-ketligini ko‘rsatib turibdi.

Sessiya konteksti har bir foydalanuvchi amalini yozib olish degani emas. Yengil metadata’dan boshlash mumkin: session ID, route, navigation ketma-ketligi, release, tegishli action’lar, xatolar, performance o‘lchovlari va request correlation.

Session replay qo‘shimcha vizual kontekst berishi mumkin, ammo u privacy bo‘yicha jiddiy mas’uliyatni ham keltirib chiqaradi. Implementatsiya browser observability standarti emas va vendor’ga bog‘liq. Masalan, Datadog Session Replay uchun masking boshqaruvlarini hujjatlashtiradi va maskalangan qiymatlar foydalanuvchi qurilmasidan tashqariga chiqmasligini ta’minlash mumkinligini qayd etadi. (docs.datadoghq.com)

Amaliy qoida oddiy: muammoni diagnostika qilish uchun zarur bo‘lgan eng kam ma’lumotni yig‘ing. Form qiymatlari va sensitive DOM kontentini maskalang, parollar va authentication token’larini umuman yig‘mang, sampling’dan foydalaning va ma’lumotlarni saqlash muddatini ongli ravishda belgilang.

Signallarni bog‘lang

Frontend observability’dagi eng katta yaxshilanish odatda yana bir yangi metrika yig‘ishdan emas, mavjud signallarni o‘zaro bog‘lashdan keladi.

Tasavvur qiling, mijozlar product page’lar ba’zan “qotib qolgandek” bo‘lishini aytmoqda.

Foydali tekshiruv quyidagi zanjir bo‘yicha borishi mumkin:

Alomat: “Add to Cart” sekin javob beradi. O‘lchov: yomon INP ko‘rsatgan sessiyalar aniqlanadi. Mumkin bo‘lgan sabab: uzoq client-side task yoki qimmat application logic. Tasdiqlash: INP attribution muammoli interaction’ni ko‘rsatadi; ayni sessiyalarda muayyan JavaScript execution path ham ko‘rinadi. Tuzatish: bloklovchi ishni kamaytirish yoki qismlarga bo‘lish. Qayta o‘lchash: yangi release’dan keyin INP taqsimotini solishtirish.

Boshqa incident yuqori LCP bilan boshlanishi, keyin Resource Timing’da sekin image request’ga olib borishi va oxir-oqibat origin yoki CDN konfiguratsiyasidagi muammoni ko‘rsatishi mumkin.

Observability muhandis ushbu signallar o‘rtasida o‘tib, hodisani bir-biriga bog‘lanmagan dashboard’lardan qo‘lda qayta tiklashi shart bo‘lmaganda ishlaydi.

Keng tarqalgan xatolar

Faqat o‘rtacha qiymatlarni kuzatish. Performance taqsimotlari muhim. Median sezilarli miqdordagi foydalanuvchilarda yomon tajribani yashirib qo‘yishi mumkin.

Release ma’lumotlarisiz xatolarni yig‘ish. Muammoni qaysi deployment keltirib chiqargani yoki qaysi deployment tuzatganini bilish kerak.

Web Vitals’ni attribution’siz o‘lchash. INP 600 ms ekanini bilish, aynan qaysi interaction shu natijaga sabab bo‘lganini bilishdan kamroq foydali.

Har bir network request’ni cheksiz log qilish. Katta hajmdagi telemetry saqlash hajmini, xarajatni va privacy xavfini oshiradi. Aqlli sampling ishlating va barcha payload’larni indiscriminate saqlash o‘rniga diagnostik jihatdan foydali field’larni saqlang.

Session replay’ni o‘zi observability deb hisoblash. Muammoli sessiyani ko‘rish nima sodir bo‘lganini ko‘rsatishi mumkin, ammo xatolar, timing va request correlation aynan nega bunday bo‘lganini tushuntiradi.

Brauzer telemetry’sini cheklanmagan deb hisoblash. Cross-origin policy’lar, brauzer qo‘llab-quvvatlashi va API cheklovlari qaysi ma’lumotlarni ko‘rish mumkinligiga ta’sir qiladi.

SeoNest tavsiyasi

Frontend observability’ni bosqichma-bosqich quring.

Production error reporting va release tracking’dan boshlang. So‘ng real foydalanuvchilardagi LCP, INP va CLS’ni qo‘shing. Keyin ilovangiz uchun muhim bo‘lgan request va resource’lar bo‘yicha network timing yig‘ing. Oxirida bu signallarni privacy-safe session identifier orqali bog‘lang va sampled session replay’ni faqat u qo‘shimcha diagnostik qiymat beradigan joylarda ishlating.

Maqsadli arxitektura muhandisga “checkout failure’lar ko‘paydi” yoki “mobil product page’lar sekinlashdi” kabi biznes alomatidan boshlab, taxmin qilmasdan texnik dalillargacha yetib borish imkonini berishi kerak.

OpenTelemetry tizimlar o‘rtasida trace, metric va log’larni standartlashtirishga yordam berishi mumkin, ammo browser instrumentation alohida baholanishi kerak: OpenTelemetry JavaScript hujjatlarida client-side browser instrumentation hozircha experimental va asosan unspecified deb tasvirlangan. (opentelemetry.io)

FAQ

Frontend observability monitoring bilan bir xilmi?

To‘liq emas. Monitoring odatda oldindan belgilangan savollarga javob beradi, masalan error rate yoki LCP muayyan threshold’dan oshganmi. Observability esa kengroq tushuncha: yig‘ilgan telemetry oldindan kutmagan muammolarni ham tekshirishga yordam berishi kerak.

Har bir sessiyani yozib olish kerakmi?

Odatda yo‘q. Xatolar va yengil RUM signallarini ancha kengroq miqyosda yig‘ish mumkin, session replay esa storage, cost va privacy sababli sampling orqali ishlatilishi mumkin.

Core Web Vitals yetarlimi?

Yo‘q. Ular foydalanuvchi tajribasining muhim tomonlarini ko‘rsatadi, ammo har bir muammoning sababini tushuntirib bermaydi. Web Vitals xatolar, resource’lar, application action’lar va release ma’lumotlari bilan bog‘langanda ancha foydali bo‘ladi.

O‘z observability platformamni yaratishim kerakmi?

Odatda standard browser API’lari va ishonchli telemetry backend’dan boshlash yaxshiroq. Custom collection faqat talablaringiz qo‘shimcha engineering va operational xarajatlarni oqlaganda ma’qul.

Yakuniy xulosa

Frontend observability — bu shunchaki brauzer metrikalari to‘plangan dashboard emas. Bu o‘zaro bog‘langan dalillar tizimi.

Xatolar nima buzilganini ko‘rsatadi. Web Vitals foydalanuvchi nimani his qilganini ko‘rsatadi. Network telemetry vaqt qayerga sarflanganini aniqlashga yordam beradi. Sessiya konteksti esa muammo atrofida nimalar sodir bo‘lganini ko‘rsatadi.

Bu signallar yetarli kontekst orqali bog‘langanda, production debugging noaniq shikoyatlarni qayta hosil qilishga urinishdan chiqib, muammo haqiqatan ham yuz bergan brauzerdagi aniq dalillarni tekshirishga aylanadi.

Manbalar

• OpenTelemetry — What is OpenTelemetry? Current documentation. OpenTelemetry documentation
• OpenTelemetry — Observability Primer. Current documentation. Observability Primer
• Google / web.dev — Web Vitals. Web Vitals
• Google / web.dev — Getting Started with Measuring Web Vitals. Web Vitals measurement guide
• GoogleChrome — web-vitals library documentation. web-vitals repository and documentation
• W3C Web Performance Working Group — Resource Timing, Candidate Recommendation Draft, September 1, 2026. W3C Resource Timing specification
• MDN Web Docs — Window: error event, updated August 21, 2026. MDN error event documentation
• MDN Web Docs — PerformanceResourceTiming. MDN PerformanceResourceTiming documentation
• Ecma International — ECMA-426: Source map format specification, 1st edition, December 2024. ECMA-426
• Datadog — Reducing Data Related Risks / RUM & Session Replay. Datadog data security documentation