🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📱 धडा 11 — Web performance: पालकांच्या phone वरचे निकालाचे page

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागे: lesson-10-database-queries · पुढे: lesson-12-load-testing-budgets

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि performance चा तो भाग जो user ला प्रत्यक्ष दिसतो: browser मधले page. Google चे Core Web Vitals — LCP (loading), INP (responsiveness) आणि CLS (visual stability) — आणि रोजचे उपाय: कमी bytes, compression, scripts defer करणे, लहान images, caching headers, आणि images साठी जागा राखून ठेवणे. perf/demo.py मधील web() आणि perf/sim.py मधील page_load, cls_score, inp_ms आणि rate — simulated page load, एक शिकवण्यासाठीचे model.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिनाची आई car park मध्ये, कमकुवत signal असताना, तिच्या phone वर क्रीडा दिनाचे निकालाचे page उघडते. 📱

Page जड आहे: एक मोठा script आणि finish line चा एक प्रचंड फोटो. मोठा फोटो आणि निकाल दिसण्याआधी ती 5 सेकंद थांबते. ती प्रतीक्षा म्हणजे LCP. 😴
ती "माझ्या मुलीच्या वेळा दाखवा" वर tap करते. सेकंदाच्या एक तृतीयांश वेळ काहीच होत नाही, कारण page एक लांब script चालवण्यात busy आहे. तो उशीर म्हणजे INP. 👆⏳
ती वाचायला सुरुवात करते — आणि मजकूर खाली उडी मारतो, कारण फोटो शेवटी load झाला आणि त्याने मजकूर ढकलला. ती कुठपर्यंत वाचले ते विसरते. ती उडी म्हणजे CLS. 😠

ऐश्वर्या page दुरुस्त करते: ती text files दाबून लहान करते (compression), मोठ्या script ला आपली पाळी येईपर्यंत थांबायला सांगते, लहान फोटो वापरते, आणि फोटोची जागा राखून ठेवते म्हणजे काहीच उडी मारत नाही. आता page सुमारे 1 सेकंदात दिसते. आणि दुसरी भेट आणखी वेगवान असते, कारण phone ने मागच्या वेळच्या files जपून ठेवल्या होत्या.

🗺️ आकृती

flowchart LR
    a["as built · 2210 KB<br/>LCP 5020 ms (poor)"] --> b["+ compress text<br/>LCP 3505 ms"]
    b --> c["+ defer the script<br/>LCP 3055 ms"]
    c --> d["+ smaller AVIF hero · 452.5 KB<br/>LCP 1055 ms (good)"]
    d --> e["repeat visit, cached<br/>LCP 450 ms"]
    cls["CLS 0.1875 → 0.0<br/>set width/height"]
    inp["INP 316 → 66 ms<br/>break up the long task"]

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l11

❓ काय

Core Web Vitals — user-केंद्रित तीन metrics ज्यांच्या मर्यादा Google प्रकाशित करते, खऱ्या page भेटींच्या (field data) 75th percentile वर, phones आणि desktops साठी वेगवेगळे मोजलेले:
- LCP (Largest Contentful Paint) — दृश्य भागातील सर्वात मोठी image किंवा text block केव्हा paint होतो. Good ≤ 2.5 s, poor > 4 s.
- INP (Interaction to Next Paint) — tap, click किंवा key press नंतर किती वेळाने page त्याचे उत्तर paint करते: input delay + event handling + presentation. Good ≤ 200 ms, poor
  
  500 ms. March 2024 मध्ये INP ने Core Web Vital म्हणून FID ची जागा घेतली (First Input Delay); FID फक्त पहिल्या interaction चा handler सुरू होण्याआधीचा उशीर मोजत असे.
- CLS (Cumulative Layout Shift) — दिसणारा content अनपेक्षितपणे किती उडी मारतो. एका shift चा score impact fraction × distance fraction असतो; CLS म्हणजे अशा scores चा सर्वात मोठा गट ("session window"). Good ≤ 0.1, poor > 0.25.
Lab विरुद्ध field data — Lighthouse आणि DevTools एका simulated device वर एक load मोजतात (lab); Chrome UX Report आणि web-vitals library खरे users मोजतात (field). खऱ्या interactions शिवाय lab tools INP मोजू शकत नाहीत; त्याऐवजी Lighthouse Total Blocking Time दाखवतो.
Render-blocking resources — CSS, आणि defer/async शिवाय <head> मधील scripts, download (आणि run) होईपर्यंत पहिला paint थांबवतात.
Compression — text (HTML, CSS, JS, JSON) gzip किंवा Brotli ने (आणि नव्या browsers मध्ये zstd ने) खूप छान compress होतो. Browser च्या Accept-Encoding header मधून server एक निवडतो. Images आणि video आधीच compressed असतात; त्याऐवजी modern formats (AVIF, WebP) आणि योग्य आकार वापरा.
Caching headers — ज्या files च्या नावात content hash आहे (app.3f9a1c.js) त्यांच्यासाठी Cache-Control: max-age=31536000, immutable: browser न विचारता वर्षभर त्या पुन्हा वापरतो. HTML साठी Cache-Control: no-cache: browser ते ठेवू शकतो पण त्याला revalidate करावे लागते (ETag सह If-None-Match), आणि काहीच बदलले नसेल तर त्याला छोटासा 304 Not Modified मिळतो. (no-store चा अर्थ "ठेवू नका" असा आहे.)

🤔 का

कारण user चा वेळ page वरच जातो. 2 MB च्या page मागचे वेगवान API म्हणजे हळू product. कमकुवत signal असलेल्या phone वर प्रत्येक round trip आणि प्रत्येक kilobyte महाग असतो (पुन्हा धडा 07 चा toll), आणि लांब script मुळे प्रत्येक tap बिघडल्यासारखा वाटतो. Search engines सुद्धा ranking च्या एका signal म्हणून हे metrics वापरतात.

🔧 कसे (या repo मध्ये)

perf/sim.py मधील page_load(...) हे हळू phone network वरच्या एका load चे model आहे: connect करायला 2 round trips (TCP + TLS 1.3) लागतात, HTML ला 1 round trip अधिक त्याचे bytes, मग पहिल्या मोठ्या paint साठी लागणारे सगळे (CSS, hero image, आणि defer केलेला नसेल तर script) bandwidth वाटून parallel download होते. ते संपते तेव्हा LCP. compress=True text 25% पर्यंत लहान करते (एक नेहमीचे प्रमाण — एक गृहीतक). खऱ्या browsers मध्ये priorities, HTTP/2 आणि HTTP/3 multiplexing आणि TCP slow start असतात, जे model सोडून देते. cls_score, inp_ms आणि rate वरील व्याख्या आणि मर्यादा लागू करतात.

🧪 करून पाहा

python3 perf/demo.py web
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import page_load, rate
for rtt, bw in ((50, 2000), (150, 500), (300, 150)):
    for label, kw in (("as built", {}), ("all fixes", dict(compress=True, defer_js=True, hero_kb=200))):
        lcp, kb = page_load(rtt_ms=rtt, kb_per_s=bw, **kw)
        print(f"RTT {rtt:>3} ms, {bw:>4} KB/s, {label:<9} → LCP {lcp:>5} ms ({rate('LCP', lcp)})")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

web हे छापते:

── the sports-day results page on a phone: 150 ms round trip, 500 KB/s (a teaching model of one page load)
   as built: 30 KB HTML, 80 KB CSS, 900 KB JS, 1200 KB hero image   LCP  5020 ms (poor) ·   2210 KB
   + compress text (gzip/Brotli, text to about 25%)                 LCP  3505 ms (needs improvement) · 1452.5 KB
   + defer the script (no longer blocks the first paint)            LCP  3055 ms (needs improvement) · 1452.5 KB
   + resize the hero and serve AVIF (1200 → 200 KB)                 LCP  1055 ms (good) ·  452.5 KB
   repeat visit: files cached, the HTML revalidated (304)           LCP   450 ms (good) ·      0 KB
   (hashed files: Cache-Control: max-age=31536000, immutable · the HTML: Cache-Control: no-cache)
── CLS: an image with no width/height pushes the text down a quarter of the screen → 0.1875 (needs improvement) · with width/height set → 0.0 (good)
── INP: a tap runs 300 ms of script in one piece → 316 ms (needs improvement) · in 50 ms chunks that yield → 66 ms (good)

तुमचा snippet हे छापतो:

RTT  50 ms, 2000 KB/s, as built  → LCP  1305 ms (good)
RTT  50 ms, 2000 KB/s, all fixes → LCP   314 ms (good)
RTT 150 ms,  500 KB/s, as built  → LCP  5020 ms (poor)
RTT 150 ms,  500 KB/s, all fixes → LCP  1055 ms (good)
RTT 300 ms,  150 KB/s, as built  → LCP 15933 ms (poor)
RTT 300 ms,  150 KB/s, all fixes → LCP  2717 ms (needs improvement)

🏁 तुम्ही आत्ताच काय सिद्ध केले

Developer च्या वेगवान connection वर good (1305 ms) दिसणारे page पालकांच्या phone वर poor (5020 ms) आहे, आणि खूप हळू connection वर जवळजवळ 16 सेकंद — तुमच्या users कडे असलेल्या network वर test करा. समस्येचा बहुतेक भाग bytes होते: compression, defer करणे आणि योग्य आकाराची image यांनी LCP 5020 वरून 1055 ms वर आणला, आणि caching ने पुन्हा भेट 450 ms वर आणली — फक्त तीन round trips, bytes शून्य. CLS shift 0.75 × 0.25 = 0.1875 होता; image ची जागा राखून ठेवल्याने तो 0 झाला. 300 ms च्या task चे 50 ms चे तुकडे केल्याने page ने tap ला 66 ms मध्ये उत्तर दिले — एकूण काम तेवढेच, पण page मधेमधे paint करू शकते.

⚠️ नेहमीच्या चुका

office Wi-Fi वरच्या वेगवान laptop वरच test करणे
hero image वर loading="lazy" — तोच LCP element आहे; तो लवकर load करा (fetchpriority="high")
width आणि height (किंवा CSS aspect-ratio) नसलेल्या images, content च्या वर घुसवलेल्या ads आणि banners — layout shifts
page paint होण्याआधी सगळे काही करणारा एकच लांब event handler
Cache-Control: no-cache चा अर्थ "cache करू नका" असा घेणे — त्याचा अर्थ "आधी revalidate करा"
नावात hash नसलेल्या files वर लांब cache times — users कडे जुन्या versions राहतात

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — compression आणि caching headers तपासा:

curl -sI -H 'Accept-Encoding: br, gzip' https://results.school.example/app.3f9a1c.js | grep -iE 'content-encoding|cache-control|etag'
npx lighthouse https://results.school.example/ --only-categories=performance --form-factor=mobile

उपाय लागू केलेले HTML:

<link rel="stylesheet" href="/style.8c1d2e.css">
<script src="/app.3f9a1c.js" defer></script>
<img src="/hero-800.avif" width="800" height="450" fetchpriority="high" alt="Runners crossing the finish line">

NGINX: text साठी gzip, hashed assets साठी लांब caching (Brotli ला ngx_brotli module लागतो):

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
location ~* \.[0-9a-f]{6,}\.(js|css|avif|woff2)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }
location = /index.html { add_header Cache-Control "no-cache"; }

web-vitals library ने खरे users मोजा, आणि लांब tasks चे तुकडे करा:

import { onLCP, onINP, onCLS } from 'web-vitals';
[onLCP, onINP, onCLS].forEach(on => on(m => navigator.sendBeacon('/vitals', JSON.stringify(m))));

async function showTimes(rows) {
  for (const chunk of chunks(rows, 200)) {
    render(chunk);
    await (globalThis.scheduler?.yield?.() ?? new Promise(r => setTimeout(r, 0)));   // let the browser paint
  }
}

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: phones साठी p75 वरचा field data पाहत राहा, प्रत्येक page ला byte budget द्या, आणि प्रत्येक नव्या third-party script ला कारण लागणारा performance बदल समजा.

⏭️ पुढे

प्रत्येक धड्याने काहीतरी वेगवान केले. शेवटचा धडा ते वेगवान राहील याची खात्री करतो: load tests, CI मधले performance budgets, आणि संपूर्ण चित्र.

git checkout lesson-12-load-testing-budgets

📱 Lesson 11 — Web performance: the results page on a parent's phone

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-database-queries · Next: lesson-12-load-testing-budgets

📦 What's in this branch

Lessons 01–10, plus the part of performance the user actually sees: the page in the browser. Google's Core Web Vitals — LCP (loading), INP (responsiveness) and CLS (visual stability) — and the everyday fixes: fewer bytes, compression, deferring scripts, smaller images, caching headers, and reserving space for images. web() in perf/demo.py and page_load, cls_score, inp_ms and rate in perf/sim.py — a simulated page load, a teaching model.

🧒 Explain like I'm 5

Katrina's mum opens the sports-day results page on her phone, in the car park, with a weak signal. 📱

The page is heavy: a big script and a giant photo of the finish line. She waits 5 seconds before the big photo and the results appear. That wait is LCP. 😴
She taps "show my daughter's times". Nothing happens for a third of a second, because the page is busy running a long script. That delay is INP. 👆⏳
She starts reading — and the text jumps down, because the photo finally loaded and pushed it. She loses her place. That jump is CLS. 😠

Aishwarya fixes the page: she squeezes the text files (compression), tells the big script to wait its turn, uses a smaller photo, and reserves the photo's space so nothing jumps. Now the page appears in about 1 second. And the second visit is even faster, because the phone kept the files from last time.

🗺️ Diagram

flowchart LR
    a["as built · 2210 KB<br/>LCP 5020 ms (poor)"] --> b["+ compress text<br/>LCP 3505 ms"]
    b --> c["+ defer the script<br/>LCP 3055 ms"]
    c --> d["+ smaller AVIF hero · 452.5 KB<br/>LCP 1055 ms (good)"]
    d --> e["repeat visit, cached<br/>LCP 450 ms"]
    cls["CLS 0.1875 → 0.0<br/>set width/height"]
    inp["INP 316 → 66 ms<br/>break up the long task"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l11

❓ What

Core Web Vitals — three user-centred metrics Google publishes thresholds for, judged at the 75th percentile of real page visits (field data), separately for phones and desktops:
- LCP (Largest Contentful Paint) — when the biggest image or text block in view is painted. Good ≤ 2.5 s, poor > 4 s.
- INP (Interaction to Next Paint) — how long after a tap, click or key press the page paints its response: input delay + event handling + presentation. Good ≤ 200 ms, poor
  
  500 ms. INP replaced FID (First Input Delay) as a Core Web Vital in March 2024; FID only measured the delay before the first interaction's handler started.
- CLS (Cumulative Layout Shift) — how much visible content jumps unexpectedly. One shift scores impact fraction × distance fraction; CLS is the largest burst ("session window") of such scores. Good ≤ 0.1, poor > 0.25.
Lab vs field data — Lighthouse and DevTools measure one load on one simulated device (lab); the Chrome UX Report and the web-vitals library measure real users (field). Lab tools cannot measure INP without real interactions; Lighthouse shows Total Blocking Time instead.
Render-blocking resources — CSS, and scripts in <head> without defer/async, stop the first paint until they have downloaded (and run).
Compression — text (HTML, CSS, JS, JSON) compresses very well with gzip or Brotli (and zstd in recent browsers). The server picks one from the browser's Accept-Encoding header. Images and video are already compressed; use modern formats (AVIF, WebP) and the right size instead.
Caching headers — Cache-Control: max-age=31536000, immutable for files whose name contains a content hash (app.3f9a1c.js): the browser reuses them for a year without asking. Cache-Control: no-cache for the HTML: the browser may keep it but must revalidate (If-None-Match with the ETag), and gets a tiny 304 Not Modified if nothing changed. (no-store is the one that means "do not keep it".)

🤔 Why

Because the page is where the user's time goes. A fast API behind a 2 MB page is a slow product. On a phone with a weak signal, every round trip and every kilobyte is expensive (lesson 07's toll, again), and a long script makes every tap feel broken. Search engines also use these metrics as one ranking signal.

🔧 How (in this repo)

page_load(...) in perf/sim.py is a model of one load on a slow phone network: connecting costs 2 round trips (TCP + TLS 1.3), the HTML costs 1 round trip plus its bytes, then everything needed for the first big paint (CSS, the hero image, and the script unless it is deferred) downloads in parallel, sharing the bandwidth. LCP is when that finishes. compress=True shrinks text to 25% (a typical ratio — an assumption). Real browsers have priorities, HTTP/2 and HTTP/3 multiplexing and TCP slow start, which the model leaves out. cls_score, inp_ms and rate apply the definitions and thresholds above.

🧪 Try it

python3 perf/demo.py web
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import page_load, rate
for rtt, bw in ((50, 2000), (150, 500), (300, 150)):
    for label, kw in (("as built", {}), ("all fixes", dict(compress=True, defer_js=True, hero_kb=200))):
        lcp, kb = page_load(rtt_ms=rtt, kb_per_s=bw, **kw)
        print(f"RTT {rtt:>3} ms, {bw:>4} KB/s, {label:<9} → LCP {lcp:>5} ms ({rate('LCP', lcp)})")
EOF

✅ Verify — what you should see

web prints:

── the sports-day results page on a phone: 150 ms round trip, 500 KB/s (a teaching model of one page load)
   as built: 30 KB HTML, 80 KB CSS, 900 KB JS, 1200 KB hero image   LCP  5020 ms (poor) ·   2210 KB
   + compress text (gzip/Brotli, text to about 25%)                 LCP  3505 ms (needs improvement) · 1452.5 KB
   + defer the script (no longer blocks the first paint)            LCP  3055 ms (needs improvement) · 1452.5 KB
   + resize the hero and serve AVIF (1200 → 200 KB)                 LCP  1055 ms (good) ·  452.5 KB
   repeat visit: files cached, the HTML revalidated (304)           LCP   450 ms (good) ·      0 KB
   (hashed files: Cache-Control: max-age=31536000, immutable · the HTML: Cache-Control: no-cache)
── CLS: an image with no width/height pushes the text down a quarter of the screen → 0.1875 (needs improvement) · with width/height set → 0.0 (good)
── INP: a tap runs 300 ms of script in one piece → 316 ms (needs improvement) · in 50 ms chunks that yield → 66 ms (good)

Your snippet prints:

RTT  50 ms, 2000 KB/s, as built  → LCP  1305 ms (good)
RTT  50 ms, 2000 KB/s, all fixes → LCP   314 ms (good)
RTT 150 ms,  500 KB/s, as built  → LCP  5020 ms (poor)
RTT 150 ms,  500 KB/s, all fixes → LCP  1055 ms (good)
RTT 300 ms,  150 KB/s, as built  → LCP 15933 ms (poor)
RTT 300 ms,  150 KB/s, all fixes → LCP  2717 ms (needs improvement)

🏁 What you just proved

The page that looks good (1305 ms) on the developer's fast connection is poor (5020 ms) on a parent's phone, and nearly 16 seconds on a very slow one — test on the network your users have. Bytes were most of the problem: compression, deferring and a right-sized image took LCP from 5020 to 1055 ms, and caching took the repeat visit to 450 ms — all three round trips, no bytes. The CLS shift was 0.75 × 0.25 = 0.1875; reserving the image's space made it 0. Breaking a 300 ms task into 50 ms chunks let the page answer the tap in 66 ms — the same total work, but the page can paint in between.

⚠️ Common mistakes

testing only on a fast laptop on office Wi-Fi
loading="lazy" on the hero image — it is the LCP element; load it early (fetchpriority="high")
images without width and height (or CSS aspect-ratio), ads and banners injected above content — layout shifts
one long event handler doing everything before the page can paint
Cache-Control: no-cache read as "do not cache" — it means "revalidate first"
long cache times on files without a hash in the name — users keep old versions

🏭 In production

On a real account — check compression and caching headers:

curl -sI -H 'Accept-Encoding: br, gzip' https://results.school.example/app.3f9a1c.js | grep -iE 'content-encoding|cache-control|etag'
npx lighthouse https://results.school.example/ --only-categories=performance --form-factor=mobile

The HTML that gets the fixes:

<link rel="stylesheet" href="/style.8c1d2e.css">
<script src="/app.3f9a1c.js" defer></script>
<img src="/hero-800.avif" width="800" height="450" fetchpriority="high" alt="Runners crossing the finish line">

NGINX: gzip for text, long caching for hashed assets (Brotli needs the ngx_brotli module):

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
location ~* \.[0-9a-f]{6,}\.(js|css|avif|woff2)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }
location = /index.html { add_header Cache-Control "no-cache"; }

Measure real users with the web-vitals library, and break up long tasks:

import { onLCP, onINP, onCLS } from 'web-vitals';
[onLCP, onINP, onCLS].forEach(on => on(m => navigator.sendBeacon('/vitals', JSON.stringify(m))));

async function showTimes(rows) {
  for (const chunk of chunks(rows, 200)) {
    render(chunk);
    await (globalThis.scheduler?.yield?.() ?? new Promise(r => setTimeout(r, 0)));   // let the browser paint
  }
}

🏭 Why this matters in production: watch the field data at p75 for phones, give each page a byte budget, and treat every new third-party script as a performance change that needs a reason.

⏭️ Next

Every lesson made something faster. The last one makes sure it stays fast: load tests, performance budgets in CI, and the whole picture.

git checkout lesson-12-load-testing-budgets

← Previousdatabase queries Next →load testing budgets

This page is the lesson's README from the lesson-11-web-performance branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.