मॉड्यूल 12 · वेब एप्लिकेशन टेस्टिंग

वेब परफ़ॉर्मेंस

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

Web performance का मतलब है कि page अपना मुख्य content कितनी जल्दी दिखाता है, user के click या type करने पर कितनी जल्दी जवाब देता है, और load होते समय कितना स्थिर रहता है। इसे browser में, user की तरफ़ से मापा जाता है: 150 ms में जवाब देने वाली API के पीछे भी ऐसा page हो सकता है जिसकी मुख्य image चार seconds बाद दिखे।

Google के Core Web Vitals इन तीन अनुभवों को नाम देते हैं और उनके thresholds तय करते हैं: loading के लिए Largest Contentful Paint (LCP), responsiveness के लिए Interaction to Next Paint (INP) और visual stability के लिए Cumulative Layout Shift (CLS)। "Pay" button जो user के tap करते ही नीचे खिसक जाए, visual stability की समस्या है, और CLS उसे एक number में बदल देता है।

यह क्यों ज़रूरी है

User धीमे या उछलते page को टूटा हुआ page मानता है: layout खिसकने पर गलत button दब जाता है, कुछ होता न दिखे तो वह दो बार tap करता है, या चला जाता है। Functional tests यह शायद ही पकड़ते हैं, क्योंकि तेज़ office laptop पर page आख़िरकार काम कर ही जाता है।

Performance चुपचाप भी गिरती है: एक भारी image, एक नई third-party script या ऊपर जोड़ा गया एक banner किसी भी test case को fail किए बिना page को धीमा कर सकता है। जो tester metrics और thresholds जानता है, वह "धीमा लगता है" को मापे गए, reproducible defect में बदल देता है।

तीन Core Web Vitals और उनके thresholds

हर Core Web Vital अनुभव का एक हिस्सा मापता है, और web.dev हर एक के लिए तीन bands तय करता है: good (अच्छा), needs improvement (सुधार की ज़रूरत) और poor (खराब)।

  • LCP (Largest Contentful Paint), loading: navigation शुरू होने से लेकर viewport की सबसे बड़ी image, text block या video के render होने तक का समय। Good: 2.5 s या कम। Poor: 4.0 s से ज़्यादा।
  • INP (Interaction to Next Paint), responsiveness: click, tap या key press से लेकर browser के अगले painted frame तक की देरी; पूरी visit में सबसे धीमा interaction गिना जाता है, दुर्लभ outliers को छोड़कर। Good: 200 ms या कम। Poor: 500 ms से ज़्यादा। INP ने 2024 में First Input Delay (FID) की जगह ली।
  • CLS (Cumulative Layout Shift), visual stability: अचानक खिसकने वाले content का बिना unit वाला score, जो layout shifts के सबसे बड़े burst से लिया जाता है; user के अपने input के ठीक बाद होने वाले shifts गिने नहीं जाते। Good: 0.1 या कम। Poor: 0.25 से ज़्यादा।
  • Page को कैसे आँका जाता है: हर metric visits के 75th percentile (p75) पर पढ़ा जाता है, यानी वह value जिस तक या जिससे कम 75% visits रहती हैं, mobile और desktop के लिए अलग-अलग, और page तभी pass होता है जब तीनों good हों। Limits सटीक boundaries हैं: 2,500 ms का LCP good है, 2,501 ms नहीं।
  • उदाहरण: p75 पर LCP 3.1 s, INP 180 ms और CLS 0.18 वाला product page fail होता है, क्योंकि INP good होने के बावजूद LCP और CLS को सुधार की ज़रूरत है।
75th percentile पर Core Web Vitals के bands: उदाहरण वाला product page INP (180 ms) में अच्छा है, पर LCP (3.1 s) और CLS (0.18) में सुधार चाहिए, इसलिए वह fail होता है।

LCP: loading, seconds में

अक्ष 0 s से 6 s तक
  • ≤ 2.5 sअच्छा
  • 2.5–4.0 sसुधार की ज़रूरत
  • > 4.0 sखराब
  1. 13.1 s उदाहरण वाला product page, p752.5 s से ज़्यादा: सुधार की ज़रूरत।सावधानी

INP: responsiveness, ms में

अक्ष 0 ms से 700 ms तक
  • ≤ 200 msअच्छा
  • 200–500 msसुधार की ज़रूरत
  • > 500 msखराब
  1. 1180 ms उदाहरण वाला product page, p75200 ms या कम: अच्छा।पास

CLS: visual stability, बिना unit का score

अक्ष 0 से 0.4 तक
  • ≤ 0.1अच्छा
  • 0.1–0.25सुधार की ज़रूरत
  • > 0.25खराब
  1. 10.18 उदाहरण वाला product page, p750.1 से ज़्यादा: सुधार की ज़रूरत।सावधानी

Thresholds web.dev से हैं और mobile व desktop के लिए अलग-अलग पढ़े जाते हैं; page तभी pass होता है जब तीनों metrics अच्छे हों।

Lab data और field data

Lab data एक नियंत्रित environment में मापा जाता है: एक device profile, एक network setting, आम तौर पर खाली cache। दो lab tools सबसे अहम हैं: DevTools का Performance panel, और Lighthouse, यानी Chrome DevTools में मौजूद audit tool, जो page को simulated mobile या desktop conditions में load करता है और metrics व एक score दिखाता है। Lab data दोहराया जा सकता है, release से पहले उपलब्ध होता है और कारण दिखाता है: LCP element, main thread रोकने वाली script, खिसकने वाला element।

Field data असली users से उनके अपने devices और networks पर आता है, जिसे real user monitoring (RUM) भी कहते हैं। Chrome User Experience Report (CrUX) इसे पर्याप्त Chrome traffic वाले public pages के लिए इकट्ठा करता है और पिछले 28 दिनों का p75 दिखाता है; Google का PageSpeed Insights web page इसे किसी URL के लिए Lighthouse lab run के साथ दिखाता है, और teams open-source web-vitals library से अपना data भी जमा कर सकती हैं। Field data बताता है कि users को असल में क्या मिलता है, लेकिन यह देर से आता है, staging के लिए होता ही नहीं और कारण शायद ही बताता है।

  • INP को असली interactions चाहिए, इसलिए सिर्फ़ page load करने वाला lab tool इसे नहीं माप सकता। Lighthouse lab proxy के रूप में Total Blocking Time (TBT) दिखाता है, यानी page load के दौरान long tasks ने main thread को कुल कितनी देर रोका: ऊँचा TBT चेतावनी है कि interactions धीमे हो सकते हैं, लेकिन यह INP नहीं है।
  • एक ही page के lab और field values आम तौर पर अलग होते हैं: असली users के devices अलग होते हैं, cache भरा होता है, screen sizes अलग होते हैं और इसलिए LCP elements भी अलग, और वे scroll और click करते हैं।
  • समस्या है या नहीं और कितनी बड़ी है, यह field data से तय करें; कारण ढूँढने, release से पहले builds की तुलना करने और fix confirm करने के लिए lab data इस्तेमाल करें। Lighthouse score (0 से 100) lab summary है, Core Web Vitals assessment नहीं।

Page speed टेस्टिंग, कदम दर कदम

Performance check को किसी भी दूसरे test की तरह लें: चुने हुए pages और interactions (search, product, checkout; filter लगाना, cart में जोड़ना), तय conditions, expected result और evidence। Mobile और desktop अलग-अलग टेस्ट करें।

  • Conditions तय करें: बिना extensions वाली incognito window, तय build और environment, Lighthouse की mobile setting या तय CPU और network throttling, और एक load खाली cache के साथ व एक भरे cache के साथ।
  • Lighthouse कई बार चलाएँ और median (नतीजों को क्रम में रखने पर बीच वाली value) लें, क्योंकि runs के बीच नतीजे बदलते हैं। सिर्फ़ score नहीं, metric values और LCP element भी record करें।
  • ज़रूरी interactions को CPU throttling के साथ Performance panel में record करें: main thread पर long tasks दिखाते हैं कि धीमा click किसका इंतज़ार करता है, और Layout shifts track दिखाता है कि कौन-सा element खिसका। बिना dimensions की images, देर से आने वाले banners और web fonts layout shifts के आम कारण हैं।
  • Network panel में सबसे बड़ी files, compression (Content-Encoding), static files के cache headers और HTML document आने में लगा समय देखें, क्योंकि server का समय LCP का हिस्सा है।
  • Baseline से तुलना करें: समान conditions में पिछला build, या team का तय किया budget, जैसे mobile setting पर LCP अधिकतम 2.5 s। यही अंतर आपका finding है।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र आज़माएँ: कैश हेडर एनालाइज़र

Worked example: Core Web Vitals में fail होने वाला product page

PageSpeed Insights एक online shop के product page का mobile field data दिखाता है: LCP 3.1 s, INP 180 ms, CLS 0.18। कारण ढूँढने के लिए tester staging पर Lighthouse पाँच बार चलाती है और एक Performance trace record करती है:

  • Lab LCP (4.4 s) field LCP (3.1 s) से खराब है, throttling और खाली cache की वजह से; दोनों एक ही दिशा दिखाते हैं, और यही मायने रखता है।
  • Finding 1: 2.4 MB की LCP image पर loading="lazy" है, इसलिए browser उसे देर से request करता है। Evidence: LCP element और waterfall।
  • Finding 2: promo banner पहले render के बाद price के ऊपर, बिना reserved space के, जुड़ता है और content को नीचे धकेलता है। Evidence: trace और screen recording।
  • Field में INP good है, इसलिए सिर्फ़ TBT के आधार पर responsiveness defect नहीं बनता; इसे दोबारा जाँचने वाले risk के रूप में note किया जाता है।
  • Fixes के बाद confirmation testing वही lab runs दोहराती है (LCP 2.2 s, CLS 0.02)। Field values धीरे-धीरे सुधरती हैं, क्योंकि CrUX पिछले 28 दिनों को cover करता है।
Product page /p/1042, staging, build 5.8.0
Lighthouse in DevTools, mobile, incognito, 5 runs, median

  Metric   Median   Good up to   Observation
  LCP      4.4 s    2.5 s        LCP element: hero image, 2.4 MB
  TBT      620 ms   -            lab proxy for INP, no CWV threshold
  CLS      0.21     0.1          shift when the promo banner appears

Network  hero.jpg  2.4 MB  loading="lazy"  request starts at 1.9 s
Trace    layout shift at 2.6 s: banner inserted above the price

आम गलतियाँ

  • सिर्फ़ तेज़ office laptop और network पर टेस्ट करके मान लेना कि page तेज़ है।
  • कई runs का median, metric values और conditions देने की बजाय एक Lighthouse run या सिर्फ़ score report करना।
  • Lab और field numbers के मेल खाने की उम्मीद करना, या lab values को users का असली अनुभव मान लेना।
  • Loading जाँचना पर responsiveness भूल जाना: page जल्दी load होकर भी हर tap पर धीरे react कर सकता है।
  • FID जैसे पुराने metrics या पुराने articles के thresholds इस्तेमाल करना, web.dev पर जाँचे बिना।
  • "Page धीमा है" लिख देना, बिना page, device setting, throttling, build और baseline के, ताकि न कोई उसे reproduce कर सके न fix verify कर सके।

QA का नज़रिया

असली team में performance user को दिखने वाले pages के acceptance criteria का हिस्सा होती है। Refinement में पूछें: किन pages का budget है, किस device class के लिए, और field data CrUX से आता है या team की अपनी monitoring से? Performance एक non-functional requirement है, यानी वह requirement जो बताता है कि page कितनी अच्छी तरह काम करता है, न कि क्या करता है; इसके testable requirement में metric, percentile, device class और limit होते हैं।

Release से पहले release candidate की पिछले build से समान lab conditions में तुलना करें; release के बाद developers के साथ field data देखें। Performance defect report में metric और value, conditions, baseline या threshold, ज़िम्मेदार element या script और evidence होते हैं।

अभ्यास

Core Web Vitals के नतीजे classify और report करें

आपका काम

एक search results page के field और lab नतीजे नीचे हैं। हर field value को classify करें, तय करें कि page mobile और desktop पर Core Web Vitals assessment pass करता है या नहीं, और समझाएँ कि lab और field LCP अलग क्यों हैं।

फिर एक defect report का summary और evidence लिखें और अपना अगला measurement बताएँ। हो सके तो यही routine किसी ऐसे public page पर दोहराएँ जिसे टेस्ट करने की आपको अनुमति हो।

सामग्री
Search results page /search

Field data (CrUX), 75th percentile
            LCP      INP      CLS
  Mobile    2.4 s    380 ms   0.05
  Desktop   1.6 s    120 ms   0.02

Lighthouse in DevTools, /search?q=shoes, mobile, incognito, same staging build
  Run 1   LCP 3.0 s   TBT 900 ms   CLS 0.04   Score 61
  Run 2   LCP 2.7 s   TBT 760 ms   CLS 0.04   Score 68
  Run 3   LCP 2.9 s   TBT 820 ms   CLS 0.05   Score 64
चरण
  1. छह field values classify करें।
  2. हर device class के लिए pass या fail तय करें।
  3. हर lab metric का median निकालें और lab व field LCP की तुलना करें।
  4. Summary, evidence और अगला measurement लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Mobile: LCP 2.4 s good, INP 380 ms needs improvement (200 ms से ज़्यादा, पर 500 ms से ज़्यादा नहीं), CLS 0.05 good, इसलिए page mobile पर fail होता है। Desktop: तीनों good, इसलिए pass।

Lab medians: LCP 2.9 s, TBT 820 ms, CLS 0.04। Lab LCP ज़्यादा है, क्योंकि mobile setting CPU और network को throttle करती है और खाली cache से शुरू होती है, जबकि कई असली users के phones तेज़ हैं या files cache में हैं।

ऊँचा TBT field INP के धीमे होने से मेल खाता है: main thread busy है, इसलिए taps इंतज़ार करते हैं। Summary: "Search results, mobile: p75 पर INP 380 ms, good 200 ms या कम; lab TBT 820 ms"। Evidence: PageSpeed Insights का field data, build और settings के साथ तीनों Lighthouse reports, और एक Performance trace।

अगला measurement: page के असली interactions, जैसे filters खोलना या sort order बदलना, CPU throttling के साथ Performance panel में record करें, ताकि देरी के पीछे का long task मिले। Lighthouse score खुद defect नहीं है।

अक्सर पूछे जाने वाले सवाल

क्या Lighthouse performance score Core Web Vitals का नतीजा है?

नहीं। 0 से 100 का score simulated conditions में एक run के lab metrics का weighted summary है। Core Web Vitals assessment 75th percentile पर field data इस्तेमाल करता है और इसमें LCP, INP और CLS तीनों का good होना ज़रूरी है। Score को समान conditions में builds की तुलना के लिए इस्तेमाल करें, pass criterion के रूप में नहीं।

Page Lighthouse में ठीक दिखता है, पर field data में fail क्यों होता है?

दोनों अलग चीज़ें मापते हैं। Lighthouse page को lab में एक बार, असली interactions के बिना load करता है, इसलिए INP नहीं माप सकता और users के scroll करते समय होने वाले shifts चूक जाता है। Field data कई devices पर 28 दिनों की असली visits cover करता है। फ़ैसले के लिए field data पर भरोसा करें और जाँच के लिए lab इस्तेमाल करें।

क्या मैं staging environment पर Core Web Vitals टेस्ट कर सकता हूँ?

हाँ, और release से पहले regressions पकड़ने के लिए staging पर lab values ज़रूर मापें। Staging का CrUX field data नहीं होता, क्योंकि असली users वहाँ नहीं आते; field values release के बाद ही, CrUX या team की अपनी monitoring से, दिखती हैं।

Web performance, load testing से कैसे अलग है?

इस lesson वाली web performance एक user के browser का अनुभव है: loading, जवाब देना और स्थिर रहना। Load testing, जो performance testing module में आती है, मापती है कि बहुत सारे users के एक साथ आने पर server कैसा व्यवहार करता है। एक user के साथ Core Web Vitals good होकर भी load में page धीमा हो सकता है, जब server का response time बढ़ता है।

संदर्भ

  • Web VitalsGoogle (web.dev)Core Web Vitals (LCP, INP, CLS): वे क्या मापते हैं और अच्छे यूज़र अनुभव की सीमाएँ क्या हैं।
  • What are browser developer tools? — MDNMDN Web Docs (Mozilla)ब्राउज़र में बने developer tools का परिचय — inspector, JavaScript console और debugger — टेस्ट करते समय पेज की जाँच के लिए।
टूल्स

Mutqan tools से अभ्यास करें

रिस्पॉन्स साइज़ एनालाइज़र

रिस्पॉन्स साइज़ का विश्लेषण: कच्चे बनाम compressed बाइट, हेडर का साइज़, JSON ढाँचे का भार और सबसे बड़े फ़ील्ड।

परफ़ॉर्मेंस

कैश हेडर एनालाइज़र

Cache-Control, Expires, ETag, Last-Modified, Vary और Age हेडर जाँचें और समझें कि ब्राउज़र तथा CDN रिस्पॉन्स को कैसे कैश करेंगे।

वैलिडेशन

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा