Critical CSS जनरेटर

(critical-css-extractor.kigo.studio)

7 पॉइंट द्वारा GN⁺ 2025-05-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Critical CSS वह न्यूनतम CSS है जो पेज के पहले दिखाई देने वाले हिस्से (above the fold) को render करने के लिए आवश्यक होता है। इसे HTML में inline करने पर FCP(First Contentful Paint) जैसे Core Web Vitals बेहतर होते हैं
इसे HTML के <head> में inline किया जाता है ताकि browser पूरी stylesheet का इंतज़ार किए बिना जल्दी content render कर सके
इसके फायदे हैं लोडिंग स्पीड का बेहतर अनुभव, Lighthouse स्कोर में बढ़ोतरी, और SEO व UX में सुधार
non-critical CSS को <body> के अंत में <link> से लोड किया जा सकता है, या JavaScript से lazy load करके performance को और optimize किया जा सकता है
ध्यान रहे कि उपयोगकर्ता को CSS link path और asset references को खुद adjust करना होगा

Critical CSS Generator

Critical CSS Generator एक ऐसा टूल है जो वेबपेज से केवल आवश्यक न्यूनतम CSS code निकालता है, जिससे उपयोग के उद्देश्य के अनुसार optimized CSS extraction संभव होती है
Critical CSS वह न्यूनतम CSS rules हैं जो पेज के पहले दिखाई देने वाले हिस्से को style करने के लिए चाहिए होते हैं
इस तरीके से browser सभी stylesheets के लोड होने का इंतज़ार किए बिना तुरंत मुख्य content दिखा सकता है, जिससे performance और Core Web Vitals (जैसे FCP) बेहतर करने में मदद मिलती है

इसका उपयोग क्यों करें?

शुरुआती लोडिंग का अनुभव अधिक तेज़
Lighthouse स्कोर में सुधार
SEO और user experience में सुधार

🔧 लागू करने का तरीका

Step 1: Critical CSS को inline करें

<style> टैग के अंदर Critical CSS डालें और उसे HTML <head> के सबसे ऊपर रखें
इसे अन्य stylesheets या scripts से पहले रखना चाहिए
internal asset paths को आवश्यकता अनुसार संशोधित करना पड़ सकता है
```
<style>  
  /* Critical CSS for your page */  
  /* ... CSS content ... */  
</style>  
```

Step 2: non-critical CSS को defer से लोड करें (मूल तरीका)

मूल <link> टैग को <head> से हटाकर </body> से ठीक पहले रखें

इससे शुरुआती render केवल Critical CSS के साथ होगा और non-critical CSS बाद में लोड होगा

<html>  
  ...  
  <body>  
    ...  
    <link rel="stylesheet" href="/css/vendors.min.css">  
    <link rel="stylesheet" href="/css/style.min.css">  
  </body>  
</html>

Step 3 (वैकल्पिक): JavaScript से asynchronous style loading

पेज लोड पूरा होने के बाद JavaScript से non-critical CSS को dynamically load करें
network speed धीमी होने पर performance में सुधार हो सकता है

मौजूदा <head> से सभी non-critical CSS <link> हटाने होंगे

window.addEventListener("DOMContentLoaded", function () {  
  console.log("✅ Page loaded, now loading non-critical stylesheets...");  
  let stylesheets = [  
    // "/css/vendors.min.css",  
    // "/css/style.min.css",  
  ];  
  let loadedCount = 0;  
  function checkAllStylesLoaded() {  
    loadedCount++;  
    if (loadedCount === stylesheets.length) {  
      console.log("✅ All non-critical stylesheets loaded...");  
    }  
  }  
  stylesheets.forEach(function (href) {  
    var link = document.createElement("link");  
    link.rel = "stylesheet";  
    link.href = href;  
    link.onload = checkAllStylesLoaded;  
    link.onerror = () => console.warn(`Failed to load stylesheet: ${href}`);  
    document.head.appendChild(link);  
  });  
});

1 टिप्पणियां

GN⁺ 2025-05-15

Hacker News की राय

अगर responsive support भी हो जाए तो बढ़िया होगा, responsive critical styles को dedupe करना मुश्किल होता है इसलिए आखिर में हमेशा stylesheet को हाथ से edit करना पड़ता है, critical CSS का size महत्वपूर्ण है तो CSS variables जैसी चीज़ों को down-compile करने का option भी अच्छा होगा, और non-critical CSS के <link> tag को </body> से ठीक पहले रखने की सलाह मैं recommend नहीं करूंगा, CSS जल्दी मिलना चाहिए इसलिए इस तरीके से CSS discovery delay होती है और download भी देर से शुरू होता है, इसकी जगह preload और noscript के combination वाला तरीका recommend करूंगा <link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="styles.css"></noscript>
- मुझे यह जिज्ञासा है कि preload में JS code लिखने वाला यह तरीका CSP में unsafe-inline allow न करने पर block नहीं हो जाएगा क्या
- मैं CSS को JS hack से load करने का तरीका इस्तेमाल नहीं करना चाहता, stylesheet apply होने पर पूरे page का layout/style recalculation हो सकता है, browser page के नीचे होने पर भी stylesheet जल्दी fetch कर लेता है
- सिर्फ prefetch attribute, HTTP header hints, और CDN के combination से भी ऐसा ही effect मिल सकता है, critical CSS को बार-बार rebuild करने की ज़रूरत नहीं है, CF जैसे CDN को ठीक से इस्तेमाल करो तो बहुत तेज़ होता है
- बात सही लगती है, ऐसा option डालने का plan है, 'before body' की जगह 'DOMCONTENTLOADED' option आज़माया था और पुराने फोन, slow network आदि पर भी UX और Lighthouse के लिहाज़ से काफ़ी ठीक चला
- responsive support वाली बात से पूरी तरह सहमत हूँ
मेरे हिसाब से यह बहुत early optimization जैसा लगता है, CSS बहुत complex हो या load होने वाले resources बहुत ज़्यादा हों तभी इसकी value होगी, लेकिन ज़्यादातर स्थितियों में CSS, HTML, JS को साफ़-सुथरा लिखना ज़्यादा efficient है और यह तरीका अनावश्यक या उल्टा नुकसानदेह भी हो सकता है
- बहुत उपयोगी है, मैं freelancer के रूप में अक्सर WordPress websites पर काम करता हूँ और कई developers/agencies से गुज़रने के बाद CSS/JS पूरी तरह बिखरा हुआ मिलता है, ऐसा tool मैं सच में इस्तेमाल करना चाहूँगा
- CSS जितनी complex हो या resources जितने ज़्यादा हों, optimization का net effect उतना ही कम हो जाता है, यहाँ target RTT latency optimization है, लेकिन critical CSS जितना बड़ा होगा optimization cost उतनी बढ़ेगी और net gain उतना घटेगा
- अगर यह 12 साल पहले होता तो मैं ऐसे tool पर पैसे खर्च करता, कई सालों में जमा हुआ बहुत बड़ा CSS था और कौन-से rules critical हैं यह समझना मुश्किल था
- बहुत-सी sites के लिए यह सचमुच early optimization हो सकता है, लेकिन news/media जैसी click-sensitive sites के लिए “instant” page load बहुत महत्वपूर्ण है, 1 सेकंड पार होते ही bounce rate और ad revenue गिरने लगते हैं, HuffPost ने भी 10 साल पहले यह optimization आज़माया था
- frontend development की मौजूदा हालत देखें तो यह वाकई हद से ज़्यादा लगता है, Lighthouse जैसे tools ने बेकार के numbers के लिए optimization पर obsession पैदा कर दिया है, नतीजा यह कि build complexity ही बढ़ती है और असली users को फ़र्क भी महसूस नहीं होता, लेकिन development और असुविधाजनक हो जाता है, ऊपर से ऐसी sites भी बहुत दिखती हैं जिनमें बुनियादी UI/state management की गलतियाँ भरी रहती हैं, बहुत निराशा होती है
- साफ़ CSS, HTML, JS ही जवाब है, लेकिन कभी-कभी आपको messy project inherit करना पड़ता है या template इस्तेमाल करना पड़ सकता है, और खुद develop करते हुए भी design उलझ सकता है
- मेरे लिए CSS loading strategy development के शुरुआती चरण में ही ज़रूर सोचने वाली चीज़ है, हमारे web पर page speed test score कम होने की वजह से clients छोड़कर जा रहे थे, performance का SEO पर असर पड़ता है इसलिए यह बहुत महत्वपूर्ण है, Google Lighthouse में 100 score पाने के लिए page optimization को मैंने खुद नए सिरे से design किया, CSS/JS loading order और तरीका सब शुरुआत से plan करना पड़ता है तभी बाद में rework कम होता है, हमने above-the-fold/below-the-fold CSS भी अलग करके जहाँ ज़रूरी था वहीं inline include किया, below-the-fold JS को scroll होने तक evaluate ही नहीं किया, Lighthouse जो कुछ suggest करता है सब लागू किया, पहले के system में हर page पर पूरे website का CSS (3~4MB) जाता था, JS तो उससे भी बदतर था, वजह यही थी कि शुरुआत में optimization design नहीं हुआ था, अभी भी वही system इस्तेमाल हो रहा है इसलिए नाम नहीं बता सकता लेकिन अंदरूनी तौर पर यह लगातार समस्या बना हुआ है, अगर performance goal है तो मेरे हिसाब से early optimization जैसी कोई चीज़ नहीं होती, सब कुछ शुरू से ही सोचना चाहिए, नतीजा यह हुआ कि mobile सहित सभी clients पर 100 performance score मिला और competitors की तुलना में बढ़त भी रही, मैंने यह tool अपनी site पर चलाकर देखा लेकिन optimize करने को कुछ बचा ही नहीं था इसलिए इसका असर नहीं हुआ
Astro framework से बने मेरे page के हिसाब से HTML 27.52KB (compressed होने पर 6.1KB), JS 10KB से कम, critical CSS 57KB (compressed होने पर 7KB) है, इसी तरह की दूसरी sites 100KB~1MB तक जाती हैं, साफ़-सुथरा बनाओ तो inline CSS/JS के बिना भी resource hints से काफ़ी fast हो सकता है, nginx+HTTP/2+edge cache combination में critical CSS/inline JS के बिना भी 100/100 performance संभव है, हर page में 7KB extra जोड़ना inefficient लगता है, implementation के लिहाज़ से SPA/edge caching कहीं ज़्यादा eco-friendly और तेज़ है, बेवजह Elementor की तरह बहुत भारी HTML भेजने की ज़रूरत नहीं है, mobile battery limited होती है तो अनावश्यक data क्यों भेजें
- अच्छी trick है, लेकिन जब CDN और HTTP/2 पहले से आम हो चुके हैं तो ऐसी optimization आखिर में सिर्फ bandwidth बर्बाद करती है, benchmark numbers थोड़ा सुधरते हैं, असल में बस 10~20ms के आसपास ही फ़र्क पड़ता है
- हर page में critical CSS शामिल करना ही सही जवाब नहीं है, first visit (जब cache न हो) या session के starting page पर ही इसे selectively इस्तेमाल करना भी unnecessary data bloat से बचने का तरीका हो सकता है
client की request पर critical CSS extraction tool ढूँढा लेकिन मनचाहा feature नहीं मिला, इसलिए Puppeteer और अपने बनाए solution को share किया, page load के बाद कितना wait करना है यह specify किया जा सकता है, paid services भी इस्तेमाल की थीं लेकिन पसंद नहीं आईं इसलिए refund ले लिया, feedback welcome है और अभी इसे free में खोला है
- जानना चाहूँगा कि क्या existing tools जैसे penthouse package में दिक्कत थी
- CSS न होने वाली site डालो तो error आता है
- क्या code public है, मैं इसे Vite/Astro plugin के रूप में भी इस्तेमाल करना चाहूँगा
- पूछना चाहूँगा कि क्या यह penthouse का UI version है, कई settings बहुत मिलती-जुलती हैं
यह तरीका उल्टा नुकसानदेह है, लगातार FOUC (style लागू न होने की स्थिति का flicker) होता है, अगर बीच में layout बदल जाए तो जो user पहले से कुछ click कर रहा हो उसे बड़ी असुविधा होगी, यह सिर्फ aesthetics की समस्या नहीं बल्कि वास्तविक usability issue है
- मैंने भी यह तरीका लागू करने के बाद कुछ styles बदले थे, लेकिन आखिर में CLS (cumulative layout shift) 0 तक optimize करना संभव हुआ, budget कम हो और template में libraries बहुत हों तो यह बहुत उपयोगी हो सकता है
- क्या CSS network request को block किए बिना FOUC रोकना ही इसका मूल उद्देश्य नहीं है?
यह तरीका उस मान्यता में ज़्यादा meaningful है कि first page view पर CSS cache बिल्कुल नहीं है, असल में नए/returning visitors का अनुपात, CSS cache setting, CDN, 103 early hints, critical CSS/initial congestion window जैसी कई चीज़ों के बीच trade-off होता है
- हाँ, यह first entry के लिए है और इसे कोई बहुत strongly recommend किया जाने वाला तरीका नहीं बल्कि एक trade-off कहना ज़्यादा सही है, सबसे अच्छा यही है कि सारा code और styles खुद लिखे जाएँ और libraries का इस्तेमाल कम किया जाए
performance measurement करते समय localhost पर CSS का असर लगभग न के बराबर था, CSS को पूरी तरह हटाने पर भी 7ms से कम सुधार मिला और वह भी measurement error की range में था
- client-server latency performance optimization localhost जैसे low-latency environment में स्वाभाविक रूप से बेमानी है, मैं यह नहीं कहता कि यह optimization ज़रूरी ही है, लेकिन localhost testing अच्छा benchmarking नहीं है
मैंने अपनी site पर यह tool चलाया तो ऐसे debugging elements तक CSS में extract हो गए जो ज़रूरी नहीं थे, जैसे site grid overlay के लिए body::after वगैरह भी CSS में शामिल हो गया (मैं तो इसे भूल ही गया था, इसी से पता चला)
मैं ऐसे HTML लिखना पसंद करता हूँ जो CSS के बिना भी अर्थ स्पष्ट करे, इससे document structure बेवजह complex होने से पहले ही रोकी जा सकती है
- लेकिन यह हर site पर लागू नहीं होता, जैसे ऐसे कई UI होते हैं जिनमें बाएँ→दाएँ, ऊपर→नीचे पढ़ना default नहीं होता
idea ताज़ा है इसलिए मैंने इसे अपनी personal site पर आज़माया, लेकिन penthouse library से CSS missing error आया {"error":true,"name":"Error","message":"css should not be empty" ...}
- इस case को भी check करूँगा, धन्यवाद