Mundarija (36)
- Bu darsda
- 1. Nega bu kerak?
- 2. O'lchov sharoiti
- 3. Bloklash va zanjir
- 3.1 Bitta link
- 3.2 @import zanjiri
- 3.3 preload zanjirni uzadi
- 4. media atributi: bloklamaydigan CSS
- 4.1 Chop etish fayli
- 4.2 Navbatni DevTools'da ko'rish
- 5. Critical CSS
- 5.1 G'oya
- 5.2 media="print" onload hiylasi
- 5.3 «Bahor» va CSP
- 6. Ishlatilmagan CSS
- 6.1 Coverage: qancha CSS ishlayapti?
- 6.2 PurgeCSS
- 7. Hajm: siqish va kompressiya
- 7.1 Ikki bosqich
- 7.2 Byudjet
- 8. Kod bo'lish va keyingi sahifa
- 9. Lighthouse bilan tekshirish
- 10. Ko'p uchraydigan xatolar
- 10.1 Chop etish CSS'ini @import bilan ulash
- 10.2 onload hiylasi kritik CSS'siz
- 10.3 Hammasini preload qilish
- 10.4 PurgeCSS dinamik class'ni o'chirdi
- 10.5 Faqat ballga qarash
- 11. Mashqlar
- 1-mashq (oson): bloklaydimi?
- 2-mashq (o'rta): zanjirni o'lchang
- 3-mashq (qiyin): Bootstrap'ni ozdiring
- 4-mashq: Portfolio qadami — portfolio CSS'ini o'lchang va zanjirni olib tashlang
- 12. Real ishda
- Xulosa
- Manbalar
CSS yuklash samaradorligi: render-blocking, critical CSS va media
Qisqacha: Brauzer
headdagi har CSS fayl kelmaguncha sahifani chizmaydi — CSS render'ni bloklaydi. Shuning uchun CSS kichik, kam faylli va erta topiladigan bo'lsin. Har@importpog'onasi bitta kutish qo'shadi — bittalinkyoki yig'ilgan fayl yaxshiroq. Hozir mos kelmaydigan fayl (<link media="print">) bloklamaydi va eng past navbatda yuklanadi. Katta saytlarda birinchi ekran uchun kerakli "kritik" CSSheadga yoziladi, qolgani keyin keladi. Ishlatilmagan CSS'ni olib tashlash, siqish (minify) va Brotli/gzip hajmni o'n baravargacha kamaytiradi.
Bu darsda
- CSS nega render'ni bloklashini tushuntirasiz va buni Chrome'da o'lchaysiz (FCP, so'rov navbati).
@importzanjiri,preloadvalinkningmediaatributi sahifa tezligiga qanday ta'sir qilishini raqam bilan asoslaysiz.- Critical CSS nima ekanini, uni qaysi vosita yasashini va «Bahor» CSP'si bilan qanday to'qnashishini bilasiz.
- Ishlatilmagan CSS'ni DevTools Coverage bilan topasiz, PurgeCSS, siqish va Brotli/gzip farqini raqamda ko'rasiz.
- Lighthouse hisobotidagi CSS tavsiyalarini o'qiysiz va CSS hajmiga byudjet qo'yasiz.
Oldin bilishingiz kerak: Renderni nima to'xtatadi, Resurs maslahatlari, CSS metodologiyalari, PostCSS va Lightning CSS, Rendering pipeline.
1. Nega bu kerak?
Aziz avtobusda, telefonda «Bahor» menyusini ochdi. Internet sekin. Ekran oppoq — bir soniya, ikki soniya. U "sayt ishlamayapti" deb orqaga qaytdi. Holbuki HTML allaqachon kelgan edi: sarlavha, taomlar, narxlar — hammasi telefonda turibdi. Brauzer uni ko'rsatmayapti, chunki CSS kelishini kutyapti.
Renderni nima to'xtatadi darsidan eslang: CSS — render'ni bloklovchi (render-blocking) resurs. Brauzer head dagi CSS faylni topsa, u kelmaguncha birorta piksel chizmaydi. Sababi oddiy: CSS'siz chizsa, foydalanuvchi avval "yalang'och" sahifani ko'radi, keyin u birdan o'zgaradi. Bu chaqnash — FOUC (Qorong'i rejim darsida uni tema uchun ko'rgan edik).
Demak, CSS sahifaning birinchi ko'rinishini to'g'ridan-to'g'ri kechiktiradi. Ikki o'lchov shunga bog'liq:
- FCP (First Contentful Paint) — ekranga birinchi matn yoki rasm chiqqan payt.
- LCP (Largest Contentful Paint) — eng katta element (odatda sarlavha yoki asosiy rasm) chiqqan payt. Google'ning Core Web Vitals o'lchovlaridan biri: 2.5 soniyadan tez — "yaxshi".
Bugun biz taxmin qilmaymiz — o'lchaymiz. CSS metodologiyalari darsidagi @import o'lchovini davom ettiramiz va CSS yetkazishning har usulini Chrome'da sinaymiz. Xuddi osh damlashdagidek: qozon qizigandan keyin sabzi uchun bozorga yugursangiz, osh kechikadi (Resurs maslahatlari). CSS ham shunday: nima erta kerak, nima keyin — shuni to'g'ri tashkil qilish kerak.
2. O'lchov sharoiti
Kichik lokal server yasadik. U har faylni — HTML'ni ham, har CSS'ni ham — ataylab 300 millisekund ushlab turadi, sekin mobil internetdagidek (xuddi CSS metodologiyalari darsidagi kabi). Sahifa — «Bahor» menyusining bo'lagi: header, h1, uchta taom-karta, bron-havola. CSS — o'sha darsdagi olti fayl (tokenlar.css, reset.css, asos.css, layout.css, komponentlar.css, yordamchi.css), jami 1.2 KB.
Brauzer — Chrome 154, ekran eni 360 piksel, kesh o'chirilgan. Har variant uch marta ochildi. FCP — performance.getEntriesByName("first-contentful-paint") bilan, so'rovlar navbati — Chrome'ning o'z protokolidan olindi. Bu JavaScript — 09-qismda o'qiy olasiz, hozir raqamlarning o'zi muhim.
Asosiy nuqta — CSS'siz sahifa: FCP 348–360 ms. HTML 300 ms kutildi, keyin darhol chizildi. Undan keyingi hamma raqamni shu bilan solishtiramiz.
3. Bloklash va zanjir
3.1 Bitta link
Olti faylni bitta hammasi.css ga qo'shdik va bitta link bilan uladik:
| Variant | FCP (3 marta) |
|---|---|
| CSS'siz | 348–360 ms |
Bitta link |
644–736 ms |
Nimaga qarang: ~300 ms qo'shildi — aynan CSS faylning kutish vaqti. Brauzer HTML'ni o'qib bo'ldi, lekin hammasi.css kelguncha (644-millisekund) kutdi. Chrome buni renderBlockingStatus: "blocking" deb belgiladi, so'rov navbati — VeryHigh (DevTools'ning Network panelida "Highest" deb ko'rinadi).
Bu — muqarrar narx. CSS'siz sahifa yaxshi emas; bitta tez fayl — normal holat. Muammo shundan keyin boshlanadi.
3.2 @import zanjiri
«Bahor»ning kirish fayli: asosiy.css ichida oltita @import.
| Variant | FCP | Qachon so'raldi |
|---|---|---|
Bitta link |
644–736 ms | hammasi.css — 332 ms |
@import, 1 pog'ona |
972–980 ms | asosiy.css — 308, oltitasi — 628 ms |
@import, 2 pog'ona |
1288–1296 ms | 314 → 625 → 951 ms |
Nimaga qarang: har pog'ona bitta to'liq kutish qo'shadi. Birinchi pog'onada oltita fayl bir vaqtda so'raldi (628 ms) — CSS metodologiyalari darsidagi natija qayta tasdiqlandi. Ikki pog'onali zanjirda (zanjir.css → ichki-1.css → ichki-2.css) esa uchinchi fayl faqat 951-millisekundda so'raldi: brauzer uning borligini ikkinchi faylni o'qigandagina bildi.
flowchart LR
H["HTML<br/>0–300 ms"] --> A["zanjir.css<br/>314–625"]
A --> B["ichki-1.css<br/>626–950"]
B --> C["ichki-2.css<br/>951–1260"]
C --> F["Chizish<br/>~1290 ms"]Nimaga qarang: to'rt kutish ketma-ket, hech biri parallel emas. Sekin 4G'da har kutish yarim soniyagacha bo'lishi mumkin (Resurs maslahatlari darsidagi ulanish narxi).
3.3 preload zanjirni uzadi
Zanjir fayllarini brauzerga oldindan aytsak-chi? Resurs maslahatlari darsidagi preload:
<link rel="preload" href="css/zanjir.css" as="style">
<link rel="preload" href="css/ichki-1.css" as="style">
<link rel="preload" href="css/ichki-2.css" as="style">
<link rel="stylesheet" href="css/zanjir.css">Natija: uchala fayl bir vaqtda — 316-millisekundda so'raldi. FCP 652–672 ms — bitta link bilan deyarli bir xil. @import qoldi, lekin brauzer endi uni kutmaydi: fayllar allaqachon kelgan.
Bu — build vositasiz eng oddiy yechim. Kamchiligi: preload ro'yxatini qo'lda yangilab turish kerak. Fayl qo'shsangiz va preload ni unutsangiz — zanjir qaytadi.
Tekshirib ko'ring: «Bahor»ning
asosiy.cssi oltita faylni bitta pog'onada import qiladi. Mehmon sahifani ikkinchi marta ochdi — fayllar brauzer keshida.@importendi zarar qiladimi?
Javob
Deyarli yo'q. Kutish — tarmoq so'rovi uchun. Fayllar keshdan olinsa (HTTP kesh), zanjir millisekundlarda o'tadi. Shuning uchun @import zarari asosan birinchi tashrifda — lekin aynan birinchi tashrif mehmon sayt haqida fikr qiladigan payt. Google ham birinchi tashrif tezligini o'lchaydi.
4. media atributi: bloklamaydigan CSS
4.1 Chop etish fayli
«Bahor»ning yordamchi.css i — asosan chop etish uchun (Foydalanuvchi afzalliklari). Uni media atributi bilan alohida link qilsak:
<link rel="stylesheet" href="css/ekran.css">
<link rel="stylesheet" href="css/chop.css" media="print">| Variant | chop.css navbati |
Bloklaydimi | FCP |
|---|---|---|---|
media siz |
VeryHigh |
ha | 672–684 ms |
media="print" |
VeryLow |
yo'q | 656–680 ms |
Nimaga qarang: chop etish fayli baribir yuklanadi (chop etish tugmasi bosilsa, u tayyor bo'lishi kerak), lekin eng past navbatda va sahifani to'xtatmaydi. Atributga istalgan media query yoziladi. media="(width >= 64rem)" ni 360 pikselli ekranda sinadik — natija xuddi shunday: VeryLow, bloklamadi. Ekran kattalashsa, brauzer uni darhol qo'llaydi.
Bu yerda FCP farqi kichik, chunki ikkala fayl ham bir xil 300 ms kutdi. Farqni ko'rish uchun chop etish faylini ataylab 1500 ms sekin qildik:
| Variant | FCP |
|---|---|
<link media="print">, sekin fayl |
676–692 ms |
@import url("yordamchi.css") print;, sekin fayl |
2192–2220 ms |
Nimaga qarang: link dagi media sahifani sekin fayldan himoya qildi. Import qatoridagi print esa himoya qilmadi: Chrome faylni VeryHigh navbatda so'radi va blocking deb belgiladi — sahifa 2.2 soniya oppoq turdi. Media sharti bilan ham @import kirish faylining bir qismi bo'lib qoladi.
Qoida: katta va hozir kerak bo'lmaydigan CSS (chop etish, faqat katta ekran uchun og'ir bo'lak) — @import emas, media li alohida link.
4.2 Navbatni DevTools'da ko'rish
Resurs maslahatlari darsidagi usul: Network panelida ustunlar sarlavhasiga o'ng tugma → Priority. media="print" li CSS qatorida — Lowest, oddiy CSS'da — Highest. Throttling ro'yxatidan "Slow 4G" ni tanlang — farq ko'zga tashlanadi.
Tekshirib ko'ring:
<link rel="stylesheet" href="katta-ekran.css" media="(width >= 64rem)">qo'yildi. Telefondagi mehmon uni yuklab oladimi?
Javob
Ha, yuklaydi — lekin eng past navbatda va sahifa chizilishini to'xtatmasdan. Brauzer faylni tashlab ketmaydi: mehmon telefonni yotqizib qo'ysa yoki oyna kattalashsa, fayl tayyor bo'lishi kerak. Trafik tejalmaydi, lekin tezlik tejaladi.
5. Critical CSS
5.1 G'oya
Mehmon sahifani ochganda birinchi ekranni ko'radi — telefonda header, sarlavha va bir-ikki karta. Footer, bron formasi, chop etish qoidalari hali kerak emas. Critical CSS (kritik CSS) — faqat birinchi ekran uchun kerak bo'lgan qoidalar. Ular <style> ichida HTML'ning o'ziga yoziladi, to'liq CSS esa bloklamasdan keyin keladi. Natija: CSS uchun alohida kutish yo'q — sahifa HTML bilan birga chiziladi.
Kritik CSS'ni qo'lda ajratish — xatoga moyil. Buni vositalar qiladi: Beasties (Google'ning eskirgan Critters vositasining davomi, beasties 0.5.4), critical paketi, Vite va Next.js plaginlari. Beasties'ni bitta link li sahifamizga qo'lladik:
Inlined 938 bytes (79% of original 1.15 kB) of css/hammasi.css.Tarjimasi: "hammasi.css dan 938 bayt (1.15 KB ning 79%) ichkariga yozildi." Kichik CSS'ning deyarli hammasi birinchi ekranda ishlatiladi — 79%. Vosita head ga <style> va <link rel="preload" as="style"> qo'ydi, asl link ni esa body oxiriga ko'chirdi. O'lchov: FCP 344–420 ms — CSS'siz sahifa bilan bir xil. hammasi.css — non-blocking.
Katta CSS'da manzara boshqacha. Xuddi shu menyuni Bootstrap bilan yozib (CSS freymvorklar), Beasties'dan o'tkazdik:
Inlined 9.58 kB (4% of original 226.67 kB) of bs/bootstrap.min.css.Birinchi ekranga 227 KB dan atigi 4% — 9.6 KB kerak ekan. Critical CSS aynan shunday — katta CSS'li saytlarda — o'zini oqlaydi.
5.2 media="print" onload hiylasi
Kritik CSS yozilgach, to'liq faylni bloklamasdan qanday yuklash kerak? Internetda mashhur hiyla:
<link rel="stylesheet" href="css/hammasi.css"
media="print" onload="this.media='all'">O'qilishi: "faylni chop etish uchun deb yukla (bloklamaydi — «media atributi» bo'limidagi qoida), yuklangach media ni all ga almashtir". onload — JavaScript: "yuklab bo'lingach shu kodni bajar" (hodisalar, 09-qism).
Kritik CSS'siz faqat shu hiylani sinadik. FCP — 344–356 ms, eng tez natija. Lekin 480-millisekunddagi kadrni ko'ring:
<style>
.ustun { display: flex; gap: 1rem; flex-wrap: wrap;
font-family: system-ui, sans-serif; }
.ustun > div { flex: 1 1 10rem; max-width: 12rem;
border: 1px solid #c9d6cf; padding: 0.5rem; }
.ustun > div > p:first-child { margin: 0 0 0.5rem;
font-size: 0.8rem; color: #5b6660; }
.yalangoch h1 { font-family: serif; margin: 0.3em 0; }
.yalangoch h2 { font-family: serif; font-size: 1.2em;
margin: 0.3em 0; }
.yalangoch { font-family: serif; }
.tayyor { background: #fffaf0; color: #1f2a24; }
.tayyor h1, .tayyor h2 { color: #2f6b3a; margin: 0.3em 0; }
.tayyor h2 { font-size: 1.2em; }
.tayyor .taom-karta { background: white; padding: 0.5rem;
border-radius: 0.5rem;
box-shadow: 0 1px 2px rgb(0 0 0 / 12%); }
.tayyor .narx { color: #b4461a; font-weight: bold; margin: 0; }
</style>
<div class="ustun">
<div>
<p>onload hiylasi, 480 ms</p>
<div class="yalangoch">
<h1>Menyu</h1>
<h2>Osh</h2>
<p>35 000 so'm</p>
</div>
</div>
<div>
<p>kritik CSS, 480 ms</p>
<div class="tayyor">
<h1>Menyu</h1>
<article class="taom-karta">
<h2>Osh</h2>
<p class="narx">35 000 so'm</p>
</article>
</div>
</div>
</div>Nimaga qarang: bu — ikki sahifaning bir paytdagi (480 ms) holati, Chrome skrinshotlaridan qayta chizilgan. Chapda — brauzerning standart ko'rinishi: serif shrift, qora matn, oq fon. 150 ms dan keyin CSS keladi va sahifa birdan o'zgaradi — FOUC. O'ngda esa birinchi kadrdanoq «Bahor» ko'rinishi. Xulosa: onload hiylasi faqat kritik CSS bilan birga ishlatiladi. Aks holda "tez" FCP — tez chiqqan xunuk sahifa. Kech kelgan CSS elementlar o'lchamini ham o'zgartiradi — bu CLS (Cumulative Layout Shift, sahifaning "sakrashi") ni oshiradi.
5.3 «Bahor» va CSP
«Bahor»da qat'iy CSP bor: default-src 'self' (CSS nima). Hiylani shu CSP bilan sinadik. Konsolda:
Executing inline event handler violates the following Content Security Policy directive 'default-src 'self''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback. The action has been blocked.Tarjimasi: "HTML ichidagi hodisa ishlovchisini bajarish CSP'ning default-src 'self' qoidasini buzadi. Ruxsat uchun 'unsafe-inline', hash (kodning "barmoq izi") yoki nonce (bir martalik ruxsat so'zi) kerak. Hash'lar hodisa ishlovchilari, style atributlari va javascript: havolalariga 'unsafe-hashes' bo'lmasa qo'llanmaydi. script-src alohida yozilmagan, shuning uchun default-src ishlatildi. Amal bloklandi."
Oqibati — eng yomon holat: onload ishlamadi, media doim print qoldi, sahifa hech qachon bezalmadi (fon shaffof, media: print — tekshirdik). Kritik CSS'ning <style> tegi ham shu CSP'da to'siladi — CSS nima darsidagi xabar.
Yechim bor, lekin murakkab: CSP'ga <style> ning hash'ini qo'shish (style-src 'self' 'sha256-...') va onload o'rniga alohida skript fayl. «Bahor» uchun bunga ehtiyoj yo'q: uning CSS'i 1–2 KB, bitta tez link bilan FCP ~650 ms. Critical CSS — katta sayt vositasi.
Tekshirib ko'ring: Nega Beasties to'liq CSS
linkinibodyning oxiriga ko'chirdi,headda qoldirmadi?
Javob
head dagi link bloklaydi — kritik CSS'ning butun foydasi yo'qoladi. body oxiridagi link dan oldingi kontent esa CSS'ni kutmasdan chiziladi (o'lchovda non-blocking, FCP ~350 ms). Kritik CSS birinchi ekranni bezaydi, qolgan qoidalar keyin keladi. head dagi preload esa faylni erta so'rab qo'yadi — link ga navbat kelganda u tayyor.
6. Ishlatilmagan CSS
6.1 Coverage: qancha CSS ishlayapti?
Yuqoridagi Bootstrap'li menyuda qancha CSS haqiqatan ishlatiladi? DevTools'da buni Coverage paneli ko'rsatadi: Ctrl + Shift + P → "Show Coverage" → yozib olish tugmasi → sahifani yangilash. Xuddi shu o'lchovni Chrome'ning dasturiy interfeysi bilan qildik:
bootstrap.min.css jami 232108 ishlatilgan 8563 3.7%96% qoidalar bu sahifada bekor yuklandi. Bu — freymvorkning narxi: u har qanday sahifa uchun hamma komponentni olib keladi. Lighthouse ham shuni aytdi: "Reduce unused CSS — Est savings of 218 KiB" ("Ishlatilmagan CSS'ni kamaytiring — taxminiy tejash 218 KiB").
Ehtiyot bo'ling: Coverage faqat shu sahifa, shu holat ni ko'radi. Hover, ochilgan menyu, xato xabari, boshqa sahifa, katta ekran — ularning CSS'i "ishlatilmagan" bo'lib chiqadi, lekin kerak.
6.2 PurgeCSS
PurgeCSS — HTML (va JS) fayllardagi so'zlarni o'qib, CSS'dan ularda uchramagan selektorlarni olib tashlaydigan vosita. Tekshirdik (purgecss 8.0.0):
npx purgecss --css bs/bootstrap.min.css \
--content bs-menyu.html --output tozalangan/Natija: 232 111 bayt → 11 012 bayt. Yigirma baravar kichik.
Tuzoq xuddi Tailwind CSS 4 darsidagi bg-${rang} kabi: PurgeCSS kodni ishga tushirmaydi, faqat matnni o'qiydi. JavaScript keyin qo'shadigan class (masalan, ochilgan modal uchun show) HTML'da yo'q — PurgeCSS uni o'chiradi va modal ochilmay qoladi. Bunday class'lar safelist sozlamasiga yoziladi.
Tailwind'da bu ish ichida: u faqat fayllarda uchragan utilitalarni yasaydi (Tailwind CSS 1). Tailwind loyihasiga PurgeCSS kerak emas.
7. Hajm: siqish va kompressiya
7.1 Ikki bosqich
Bootstrap fayllarida o'lchadik (Node'ning zlib moduli bilan, gzip — 9-daraja):
| Fayl | Xom | gzip | Brotli |
|---|---|---|---|
bootstrap.css |
280 311 | 32 943 | 24 474 |
bootstrap.min.css |
232 111 | 30 669 | 22 970 |
| PurgeCSS natijasi | 11 012 | 3 211 | 2 788 |
(baytlarda)
- Minifikatsiya (minify) — bo'sh joy, izoh va ortiqcha belgilarni olib tashlash (PostCSS va Lightning CSS darsidagi cssnano va Lightning CSS). Bu yerda 17% kichraydi.
- Kompressiya — server faylni uzatishdan oldin arxivlaydi, brauzer ochadi. gzip — eski va hamma joyda, Brotli — yangiroq, matnni yaxshiroq siqadi: bu yerda gzip'dan yana 25% kichik.
Nimaga qarang: kompressiya minifikatsiyadan ancha kuchli (280 KB → 24 KB). Lekin eng katta yutuq — keraksiz CSS'ni olib tashlash: 2.8 KB. Tartib: avval ortiqchasini olib tashlang, keyin siqing, keyin serverda kompressiya.
Kompressiyani odatda siz emas, server yoki hosting qiladi. Tekshirish: DevTools → Network → CSS faylni tanlang → Headers bo'limida content-encoding: br yoki gzip. Sarlavhalar haqida — HTTP sarlavhalari darsida.
Tekshirib ko'ring: Saytingiz CSS'i minifikatsiyadan keyin 200 KB, server kompressiya qilmaydi, sahifa esa CSS'ning 5% ini ishlatadi. Uchta ishdan qaysi biri eng katta yutuq beradi: yana minifikatsiya, Brotli yoqish yoki ishlatilmaganini olib tashlash?
Javob
Ishlatilmaganini olib tashlash: 200 KB → taxminan 10 KB, yigirma baravar (jadvaldagi PurgeCSS qatori kabi). Brotli ham kuchli — jadvalda taxminan o'n baravar. Ikkalasini birga qilsangiz, bir necha kilobayt qoladi. Yana minifikatsiya deyarli hech narsa bermaydi — fayl allaqachon siqilgan. Tartib shuning uchun: avval ortiqchasini olib tashlang, keyin kompressiya.
7.2 Byudjet
Kichik CSS — tez sahifa. Jamoalar CSS byudjeti qo'yadi: "kritik yo'ldagi CSS siqilgan holda 14 KB dan oshmasin" kabi. Bu son bejiz emas: yangi ulanishning birinchi "bo'lagida" server taxminan shuncha ma'lumot yubora oladi (TCP'ning boshlang'ich oynasi, web.dev tavsiyasi). Undan kattasi uchun qo'shimcha aylanma yo'l kerak bo'ladi.
«Bahor»ning butun CSS'i 1.2 KB — byudjetdan ancha pastda. Portfolio'ning yig'ilgan CSS'i izohlari bilan 13 390 bayt edi, siqilgani 7 541 bayt (PostCSS va Lightning CSS) — siqish va kompressiyadan keyin yana bir necha barobar kichik bo'ladi.
8. Kod bo'lish va keyingi sahifa
Kod bo'lish (code splitting) — CSS'ni sahifalarga bo'lish: bron formasining uslublari faqat bron/ sahifasida. Bosh sahifa ularni yuklamaydi. Resurs maslahatlari darsida aynan shunday misol bor edi: bron sahifasining CSS'ini prefetch bilan oldindan olib qo'yish.
Kichik saytda bu ortiqcha — bitta keshlangan fayl hamma sahifaga yetadi. Katta ilovada esa Vite (Vite I, 16-qism) buni o'zi qiladi: har sahifa (route) o'z CSS bo'lagini oladi.
Yana bir tomon — yuklashdan keyingi chizish. Rendering pipeline darsidagi content-visibility: auto ekrandan tashqaridagi bo'limlarni chizishni kechiktiradi. Bu yuklash tezligi emas, lekin uzun sahifaning birinchi chizilishini yengillashtiradi.
9. Lighthouse bilan tekshirish
Lighthouse va PageSpeed darsidagi Lighthouse CSS muammolarini alohida ko'rsatadi. Lighthouse 13.5.0 ni sahifalarimizga qo'lladik (Performance, mobil, sekin tarmoq simulyatsiyasi bilan):
| Sahifa | Ball | FCP | "Render-blocking requests" |
|---|---|---|---|
Bitta link |
100 | 1.4 s | 400 ms tejash |
@import, 1 pog'ona |
98 | 2.0 s | 1 050 ms |
@import, 2 pog'ona |
95 | 2.3 s | 1 330 ms |
| Critical CSS | 100 | 0.9 s | yo'q |
| Bootstrap menyu | 93 | 2.6 s | 1 650 ms |
Nimaga qarang: Lighthouse sekin telefon tarmog'ini simulyatsiya qiladi, shuning uchun soniyalar bizning 300 ms li o'lchovdan katta. Tartib esa bir xil. Hisobotning ikki bo'limi CSS uchun muhim:
- Render-blocking requests — qaysi fayl chizishni qancha kechiktirdi.
@importsahifasida olti import fayli alohida qatorlarda. - Network dependency tree — so'rovlar zanjiri daraxt ko'rinishida:
v2-import.html→asosiy.css→ oltita fayl. Zanjir qancha chuqur bo'lsa, shuncha yomon.
Ball 93–100 — hammasi "yashil". Lekin FCP 2.6 s va 0.9 s o'rtasidagi farqni sekin internetdagi Aziz sezadi. Ballga emas, o'lchovlarga qarang.
10. Ko'p uchraydigan xatolar
10.1 Chop etish CSS'ini @import bilan ulash
@import url("chop.css") print; — fayl baribir bloklaydi (o'lchovda 2.2 s). Tuzatish: <link rel="stylesheet" href="chop.css" media="print">.
10.2 onload hiylasi kritik CSS'siz
FCP tez, lekin sahifa avval yalang'och ko'rinadi. CSP bo'lsa — umuman bezalmaydi. Tuzatish: hiyla faqat kritik CSS bilan; qat'iy CSP'li kichik saytda — oddiy bitta link.
10.3 Hammasini preload qilish
Rasm, shrift, CSS, JS — hammasi preload. Ular bir-birining navbatini egallaydi (Resurs maslahatlari). Tuzatish: preload — faqat brauzer kech topadigan 1–3 fayl uchun.
10.4 PurgeCSS dinamik class'ni o'chirdi
Modal ochilmay qoldi — show class'i CSS'dan ketgan. Tuzatish: safelist, yoki class'lar fayl matnida to'liq yozilsin.
10.5 Faqat ballga qarash
"Lighthouse 98 — hammasi joyida". Tuzatish: FCP, LCP va Network zanjirini o'qing; "Slow 4G" da o'zingiz oching.
11. Mashqlar
Mashqlar kurs/mashqlar/06/tezlik/ da. Oddiy HTML va CSS fayllar, Live Server bilan.
1-mashq (oson): bloklaydimi?
Har link yoki qoida sahifa chizilishini bloklaydimi? Navbati qanday?
<link rel="stylesheet" href="asosiy.css"><link rel="stylesheet" href="chop.css" media="print"><link rel="stylesheet" href="keng.css" media="(width >= 64rem)">— 360 pikselli telefondaasosiy.cssichida@import url("chop.css") print;<link rel="preload" href="asosiy.css" as="style">(yolg'iz,stylesheetsiz)
Ishora: "media atributi" bo'limidagi ikki jadval va Resurs maslahatlari darsidagi "preload faqat yuklaydi".
Yechim
- Bloklaydi,
Highest. - Bloklamaydi,
Lowest— baribir yuklanadi. - Bloklamaydi,
Lowest— ekran kattalashsa qo'llanadi. - Bloklaydi,
Highest—@importdagi media sharti himoya qilmaydi (o'lchovda 2.2 s). - Bloklamaydi va qo'llanmaydi ham:
preloadfaylni faqat yuklab qo'yadi. Uni ishlatish uchunrel="stylesheet"kerak.
2-mashq (o'rta): zanjirni o'lchang
index.html→asosiy.css→@import url("qism.css")→@import url("ichki.css")zanjirini yasang (har faylda bitta-ikkita qoida).- DevTools → Network: "Disable cache" va "Slow 4G". Sahifani yangilang. Waterfall'da uchta CSS qachon boshlanganini yozing.
headga ikkitapreloadqo'shing (qism.css,ichki.css) va qayta o'lchang.- Lighthouse → Performance: "Network dependency tree" bo'limida zanjir qanday ko'rinadi?
Ishora: "preload zanjirni uzadi" bo'limi.
Yechim
Preload'siz waterfall'da uch CSS chizig'i zinapoya bo'lib turadi: har biri oldingisi tugagach boshlanadi. Slow 4G'da har pog'ona yuzlab millisekund. preload bilan uchala chiziq bir vaqtda boshlanadi — zinapoya yo'qoladi. Bizning o'lchovda (har fayl 300 ms) FCP 1290 ms dan 660 ms ga tushgan edi. Sizning raqamlaringiz tarmoq va kompyuterga bog'liq — lekin shakl bir xil bo'ladi.
Lighthouse'da preload'siz variantda "Network dependency tree" uch pog'onali daraxtni ko'rsatadi va bo'lim qizil/sariq belgi oladi.
3-mashq (qiyin): Bootstrap'ni ozdiring
npm install bootstrap(npm — 16-qismda to'liq, hozir aynan takrorlang).node_modules/bootstrap/dist/css/bootstrap.min.cssnicss/ga nusxalang.- Menyu sahifasini Bootstrap class'lari bilan yozing:
container,row,col-sm-6,card,btn btn-success. - DevTools Coverage bilan ishlatilgan ulushni o'lchang.
npx purgecss --css css/bootstrap.min.css --content index.html --output tozalangan/— hajmni solishtiring.- Tozalangan faylni ulang va sahifani 360 va 1280 pikselda tekshiring. Nima buzildi?
Ishora: "Ishlatilmagan CSS" bo'limidagi ikki ogohlantirish — boshqa holatlar va JavaScript class'lari.
Yechim
Bizning sahifada: ishlatilgan ulush 3.7%, PurgeCSS 232 111 → 11 012 bayt. Sizda raqamlar yaqin bo'ladi (sahifadagi class'larga bog'liq).
5-savol: odatda ko'rinish buzilmaydi — HTML'dagi hamma class saqlanadi, @media ichidagi col-sm-6 ham. Buziladigani — JavaScript'li komponentlar: Bootstrap'ning navbar menyusi yoki modal'ini qo'shsangiz, ular ochilganda qo'shiladigan show, collapsing class'lari o'chib ketgan bo'ladi. PurgeCSS sozlamasida safelist: ["show", "collapsing"] kabi ro'yxat kerak.
4-mashq: Portfolio qadami — portfolio CSS'ini o'lchang va zanjirni olib tashlang
Portfolio'ning asosiy.css i oltita faylni @import ... layer() bilan chaqiradi (Kaskadni boshqarish). Bu — bir pog'onali zanjir.
- Portfolio'ni internetdagi manzilida (GitHub Pages) oching. DevTools → Network: "Disable cache", "Slow 4G". Yettita CSS fayl qachon boshlanganini yozing. Lighthouse → Performance: FCP va "Render-blocking requests".
- Coverage bilan bosh sahifada har CSS faylning ishlatilgan ulushini ko'ring. Qaysi fayl eng kam ishlatiladi va nega bu normal?
- Zanjirni olib tashlang — ikki yo'ldan birini tanlang:
- A (build'siz): har sahifa
headiga oltita<link rel="preload" as="style">; - B (yig'ish): Lightning CSS bilan hammasini bitta faylga yig'ing va HTML'da shu faylni ulang.
- A (build'siz): har sahifa
- 1-qadamni qayta o'lchang. FCP qanchaga o'zgardi?
Ishora: B yo'li uchun npx lightningcss --bundle --minify --targets "defaults" ... (PostCSS va Lightning CSS darsidagi CLI; --bundle — importlarni bitta faylga qo'shish). @import yo'llari asosiy.css ga nisbatan. 404.html dagi / bilan boshlangan yo'lni unutmang.
Yechim
2: eng kam ishlatiladigani — yordamchi.css: unda chop etish qoidalari va .korinmas. Ekranda chop etish qoidalari ishlamaydi — bu normal, ular kerakli paytda ishlaydi.
3A — masalan, bosh sahifada:
<link rel="preload" href="assets/css/tokenlar.css" as="style">
<link rel="preload" href="assets/css/reset.css" as="style">
<link rel="preload" href="assets/css/asos.css" as="style">
<link rel="preload" href="assets/css/layout.css" as="style">
<link rel="preload" href="assets/css/komponentlar.css" as="style">
<link rel="preload" href="assets/css/yordamchi.css" as="style">
<link rel="stylesheet" href="assets/css/asosiy.css">Ichki sahifalarda yo'l ../assets/css/.... Kamchiligi: 6 sahifa × 6 qator, yangi fayl qo'shilsa — hammasini yangilash.
3B — portfolio papkasida:
npm install --save-dev lightningcss-cli
npx lightningcss --bundle --minify --targets "defaults" \
sayt/assets/css/asosiy.css -o sayt/assets/css/asosiy.min.css«Bahor» tuzilmasidagi shunday yetti faylda (1 506 bayt) sinadik: natija — bitta 1 157 baytli fayl, har import o'z @layer bloki ichida (@layer tokenlar{...}@layer reset{...}) — qatlamlar tartibi saqlandi. Sahifalarda asosiy.min.css ulanadi. Kamchiligi: har CSS o'zgarishidan keyin buyruqni qayta ishga tushirish kerak, asosiy.min.css ni esa qo'lda tahrirlamang (PostCSS va Lightning CSS darsidagi dist/ qoidasi). Bu qadamni 07-qismda GitHub Actions avtomatik qiladi.
Hozircha A yo'li portfolio uchun yetarli: build yo'q, zanjir yo'q. 4-qadamda bitta pog'ona kutish (Slow 4G'da odatda bir necha yuz millisekund) FCP'dan yo'qoladi. Raqamlaringizni yozib qo'ying — Yakuniy loyiha: landing darsida landing'ni shu o'lchovlar bilan tekshirasiz.
12. Real ishda
- Katta saytlar (yangiliklar, onlayn do'konlar) critical CSS'ni build paytida avtomatik yasaydi — Next.js, Astro, Vite plaginlari bilan. Birinchi ekran HTML bilan birga keladi.
- Freymvorklar narxi. Bootstrap'ning 227 KB CSS'idan menyu sahifasi 4% ini ishlatdi. Tailwind'ning "faqat ishlatilganini yasash" g'oyasi aynan shu muammoga javob.
- Core Web Vitals — Google qidiruvida sahifa tajribasi signallaridan biri. CSS yetkazish LCP va CLS ga bevosita ta'sir qiladi.
- Intervyuda so'raladi: "Render-blocking CSS nima?", "Critical CSS qanday ishlaydi?", "
@importnega sekin?", "media="print"lilinkyuklanadimi?", "Ishlatilmagan CSS'ni qanday topasiz?". Endi har biriga raqam bilan javob bera olasiz.
Xulosa
headdagi CSS render'ni bloklaydi: bitta tezlink— normal narx (bizda +300 ms).@importning har pog'onasi bitta to'liq kutish qo'shadi;preloadyoki bitta faylga yig'ish zanjirni uzadi.linkdagimediamos kelmasa — bloklamaydi vaLowestnavbatda;@importdagi media sharti esa himoya qilmaydi.- Critical CSS birinchi ekranni HTML bilan birga chizadi;
onloadhiylasi faqat u bilan birga, qat'iy CSP'da esa ishlamaydi. - Ishlatilmagan CSS — Coverage va Lighthouse; olib tashlash (PurgeCSS, Tailwind) siqish va Brotli'dan ham kuchliroq.
- Ballga emas, FCP/LCP va Network zanjiriga qarang; sekin tarmoqda o'zingiz oching.
Keyingi dars: Vizual ierarxiya va asosiy dizayn tamoyillari — CSS vositalaridan dizaynning o'ziga o'tamiz: ko'z avval nimani ko'rishini qanday boshqarish.
Manbalar
- web.dev: "Render blocking CSS", "Extract critical CSS", "Defer non-critical CSS", "Largest Contentful Paint (LCP)" — web.dev
- Chrome DevTools: "Coverage", "Network features reference" — developer.chrome.com/docs/devtools
- MDN: "@import", ": media", "rel=preload", "Resource Timing: renderBlockingStatus" — developer.mozilla.org
- Beasties — github.com/danielroe/beasties; PurgeCSS — purgecss.com; Lighthouse — developer.chrome.com/docs/lighthouse
Izohlar (0)
Izoh yozish uchun kiring.
- Hozircha izoh yo'q. Birinchi bo'ling!