🚀 धडा 09 — Performance: फलक पटकन उघडतो

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-design-tokens · पुढील: lesson-10-testing

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

धडे 01–08, आणि त्यासोबत फलक मंद का वाटतात आणि खरोखर काय दुरुस्त करते: कमी bytes, प्रामाणिक images, caching, आणि माणसाला जाणवणारा वेग सांगणारे तीन आकडे — Core Web Vitals.

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

फलक कंटाळवाण्या कारणांनी मंद असतो: तो जड असतो (download करायला खूप काही), तो थांबतो (एक file पुढच्या file ला अडवते), किंवा load होताना तो उड्या मारतो. प्रत्येकावर एक कंटाळवाणा उपाय आहे:

वजन ⚖️ — कमी पाठवा. Minify आणि compress करा (gzip/brotli), code असा विभागा की page ला फक्त लागेल तेवढेच load होईल, आणि एकदाच वापरलेली library काढून टाका. तुमच्या code आधीच framework ~140 KB असतो; आपला संपूर्ण फलक ~9 KB आहे.
Images 🖼️ — कोणत्याही फलकावरची बहुतेक वेळा सगळ्यात जड गोष्ट. योग्य आकार (200px card मध्ये 4000px photo नको), आधुनिक format (WebP/AVIF), fold च्या खालच्या प्रत्येक गोष्टीसाठी loading="lazy", आणि नेहमी width/height, म्हणजे त्या आल्यावर layout उडी मारत नाही.
Caching 🧊 — सगळ्यात जलद file म्हणजे जी आधीच वाचकाच्या machine वर आहे. Filename ला hash लावा (app.7f3c2a.js), वर्षभर cache करा, आणि content बदलला की नाव बदला. CDN ती वाचकाजवळ ठेवतो.

मग माणसाला काय जाणवते ते मोजा — Core Web Vitals: LCP (सगळ्यात मोठी गोष्ट किती लवकर दिसते), INP (taps ना किती पटकन प्रतिसाद मिळतो), CLS (गोष्टी किती उड्या मारतात). तुमच्या laptop वर नाही, तर throttled phone वर मोजा.

🗺️ आकृती

flowchart LR
    w["⚖️ weight<br/>minify · compress · split · delete"]
    i["🖼️ images<br/>right size · webp/avif · lazy · width+height"]
    c["🧊 caching<br/>hashed names + long max-age · CDN"]
    m["📏 measure<br/>LCP · INP · CLS on a slow phone"]
    w --> i --> c --> m
    m -->|"the number that moved"| w

❓ काय

Critical path: HTML → CSS (render-blocking) → JS. CSS छोटी आणि लवकर ठेवा; JS defer/type=module ने load करा म्हणजे parsing अडत नाही.
LCP ≤ 2.5 s: बहुतेक वेळा hero image किंवा heading — ती preload करा, lazy load करू नका. INP ≤ 200 ms: main thread वरचे काम छोटे ठेवा (लांब tasks taps अडवतात). CLS ≤ 0.1: images, ads आणि उशिरा येणाऱ्या fonts साठी जागा राखून ठेवा.
Fonts: font-display: swap, subset, self-host किंवा preconnect; उशिरा येणारा webfont ही CLS आणि LCP ची नेहमीची अडचण आहे. (आपला फलक system fonts वापरतो — शून्य bytes, लगेच.)
Caching headers: hashed assets साठी Cache-Control: max-age=31536000, immutable; HTML साठी छोटा किंवा no-cache. हा API शाळेचा धडा 10 आहे, browser च्या बाजूने पाहिलेला.
मोजा: DevTools → Lighthouse (lab) आणि CPU/network throttling सह Performance panel; खऱ्या users साठी PerformanceObserver किंवा RUM tool (धडा 12).
अंदाज करू नका: जो आकडा वाईट आहे तोच उपाय ठरवतो. 2 MB hero image load होत असताना 9 KB bundle optimise करणे म्हणजे नाटक.

🤔 का

कारण वेग हे असे वैशिष्ट्य आहे जे लोकांना इतर कोणतेही लक्षात येण्याआधी जाणवते, आणि कारण सरासरी network वरचा सरासरी phone तुमच्या machine पेक्षा खूपच मंद असतो. कोणीही केलेल्या प्रत्येक अभ्यासात load चा प्रत्येक सेकंद conversions गमावतो — आणि शाळेच्या फलकावर, तो कंटाळून सोडून देणारा पालक गमावतो.

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

फलक कमी गोष्टी असल्यामुळे जलद आहे: तीन files, system fonts, inline SVG avatars (image requests अजिबात नाहीत), framework नाही, build नाही. ही सगळ्यात स्वस्त performance रणनीती आहे — आणि खरा project जड झाल्यावर ज्याच्याशी तुलना करायची तो पाया.

🧪 करून पाहा

python3 ui/mock_api.py
# 1) the honest baseline:
wc -c ui/index.html ui/styles.css ui/app.js     # ~9 KB total, uncompressed
# 2) Lighthouse: DevTools → Lighthouse → Mobile → Analyze. Note LCP, CLS, and the score.
# 3) feel a slow network: DevTools → Network → throttle to "Slow 4G", reload. Then Performance → CPU 4× slowdown.
# 4) create CLS on purpose: remove width="40" height="40" from the card <img> in index.html, reload on Slow 4G —
#    watch the cards shift as avatars arrive. Put them back.
# 5) create a long task: in the Console run  let t=Date.now(); while(Date.now()-t<800){}  and try clicking during it — that is bad INP.

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

Lighthouse फलकाला उच्च performance score देतो, आणि LCP 2.5 s च्या बरीच खाली असते. Image dimensions काढल्यावर मंद connection वर layout स्पष्टपणे उडी मारतो (आणि CLS वाढतो); ते परत लावल्यावर ते दुरुस्त होते. Busy-loop मुळे page जवळजवळ एक सेकंद प्रतिसाद देत नाही — हेच INP मोजतो.

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

User ला जसा अनुभव येतो तसा तुम्ही फलक मोजलात, आणि layout shift आणि अडलेला main thread मुद्दाम घडवून दुरुस्तही केला.

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

मोठी, optimise न केलेली image LCP वर राज्य करत असताना bundle size optimise करणे
hero image lazy-load करणे (तोच LCP element आहे — तो लगेच load करा)
images वर width/height नसणे (CLS)
HTML वर्षभर cache करणे (नवीन version कोणालाच कधीच दिसत नाही)
फक्त office wifi वरच्या जलद laptop वर test करणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: Core Web Vitals browsers प्रत्यक्ष वापरातून मोजतात आणि search ranking साठी वापरल्या जातात; त्याहून महत्त्वाचे म्हणजे लोक ज्याबद्दल तक्रार करतात त्याच्याशी त्या जुळतात. या धड्यात "हे मंद वाटते" हे कृती करता येणारा आकडा बनते.

⏭️ पुढे

पुढच्या बदलात मोडत असेल तर जलद आणि सुंदर असणे पुरेसे नाही: UI testing — unit, component, end-to-end आणि तुमच्याकडे आधीच असलेला smoke test.

git checkout lesson-10-testing

🚀 Lesson 09 — Performance: the board loads fast

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-design-tokens · Next: lesson-10-testing

📦 What's in this branch

Lessons 01–08, plus why boards feel slow and what actually fixes it: fewer bytes, honest images, caching, and the three numbers that describe speed as a person experiences it — Core Web Vitals.

🧒 Explain like I'm 5

A board is slow for boring reasons: it is heavy (too much to download), it waits (one file blocks the next), or it jumps around while loading. Each has a boring fix:

Weight ⚖️ — send less. Minify and compress (gzip/brotli), split code so a page loads only what it needs, and delete the library you used once. A framework is ~140 KB before your code; our whole board is ~9 KB.
Images 🖼️ — usually the heaviest thing on any board. Right size (not a 4000px photo in a 200px card), modern format (WebP/AVIF), loading="lazy" for anything below the fold, and always width/height so the layout does not jump when they arrive.
Caching 🧊 — the fastest file is the one already on the reader's machine. Hash the filename (app.7f3c2a.js), cache it for a year, and change the name when the content changes. A CDN keeps it near the reader.

Then measure what a person feels — Core Web Vitals: LCP (how soon the biggest thing appears), INP (how quickly taps respond), CLS (how much things jump). Measure on a throttled phone, not on your laptop.

🗺️ Diagram

flowchart LR
    w["⚖️ weight<br/>minify · compress · split · delete"]
    i["🖼️ images<br/>right size · webp/avif · lazy · width+height"]
    c["🧊 caching<br/>hashed names + long max-age · CDN"]
    m["📏 measure<br/>LCP · INP · CLS on a slow phone"]
    w --> i --> c --> m
    m -->|"the number that moved"| w

❓ What

The critical path: HTML → CSS (render-blocking) → JS. Keep CSS small and early; load JS with defer/type=module so parsing is not blocked.
LCP ≤ 2.5 s: usually a hero image or heading — preload it, do not lazy load it. INP ≤ 200 ms: keep main-thread work short (long tasks block taps). CLS ≤ 0.1: reserve space for images, ads and late fonts.
Fonts: font-display: swap, subset, self-host or preconnect; a late webfont is a classic CLS and LCP problem. (Our board uses system fonts — zero bytes, instant.)
Caching headers: Cache-Control: max-age=31536000, immutable for hashed assets; short or no-cache for HTML. This is the API school's lesson 10 seen from the browser side.
Measure: DevTools → Lighthouse (lab) and the Performance panel with CPU/network throttling; PerformanceObserver or a RUM tool for real users (lesson 12).
Do not guess: the fix is whichever number is bad. Optimising a 9 KB bundle while a 2 MB hero image loads is theatre.

🤔 Why

Because speed is a feature people feel before they notice any other one, and because the median phone on the median network is far slower than your machine. Every second of load costs conversions in every study anyone has run — and on a school board, it costs a parent who gives up.

🔧 How (in this repo)

The board is fast by having little: three files, system fonts, inline SVG avatars (no image requests at all), no framework, no build. That is the cheapest performance strategy there is — and the baseline you compare against when a real project gets heavy.

🧪 Try it

python3 ui/mock_api.py
# 1) the honest baseline:
wc -c ui/index.html ui/styles.css ui/app.js     # ~9 KB total, uncompressed
# 2) Lighthouse: DevTools → Lighthouse → Mobile → Analyze. Note LCP, CLS, and the score.
# 3) feel a slow network: DevTools → Network → throttle to "Slow 4G", reload. Then Performance → CPU 4× slowdown.
# 4) create CLS on purpose: remove width="40" height="40" from the card <img> in index.html, reload on Slow 4G —
#    watch the cards shift as avatars arrive. Put them back.
# 5) create a long task: in the Console run  let t=Date.now(); while(Date.now()-t<800){}  and try clicking during it — that is bad INP.

✅ Verify — what you should see

Lighthouse gives the board a high performance score with an LCP well under 2.5 s. Removing the image dimensions makes the layout visibly jump on a slow connection (and CLS rises); restoring them fixes it. The busy-loop makes the page unresponsive for the better part of a second — the thing INP measures.

🏁 What you just proved

You measured the board the way a user experiences it, and you caused and cured a layout shift and a blocked main thread on purpose.

⚠️ Common mistakes

optimising bundle size while a huge unoptimised image dominates LCP
lazy-loading the hero image (it is the LCP element — load it eagerly)
no width/height on images (CLS)
caching HTML for a year (nobody ever sees the new version)
testing only on a fast laptop on office wifi

🏭 Why this matters in production: Core Web Vitals are field-measured by browsers and used by search ranking; more importantly they match what people complain about. "It feels slow" becomes an actionable number in this lesson.

⏭️ Next

Fast and pretty is not enough if it breaks on the next change: testing UI — unit, component, end-to-end and the smoke test you already have.

git checkout lesson-10-testing

← Previousdesign tokens Next →testing

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