Show HN: Jampack - स्थिर वेबसाइट ऑप्टिमाइज़ेशन के लिए पोस्ट-प्रोसेसिंग चरण

 (github.com/divriots)
4 पॉइंट द्वारा GN⁺ 2024-03-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Jampack एक पोस्ट-प्रोसेसिंग टूल है जो Static Site Generator के आउटपुट को लेकर user experience और Core Web Vitals स्कोर को ऑप्टिमाइज़ करता है, और यह कोई bundler या framework नहीं है
  • यह HTML के <img> और <picture> को responsive images में बदलता है, और WebP·AVIF जैसे formats, srcset, sizes, width, height, loading="lazy", decoding="async" आदि को अपने-आप जोड़ता है
  • CDN images को URL parameter-आधारित srcset के साथ responsive बनाया जा सकता है, और external images को _jampack के नीचे डाउनलोड करके optimized local images में बदला जा सकता है
  • Above-the-fold assets को high priority के साथ प्रोसेस किया जाता है और छोटी images को HTML में inline किया जाता है, जबकि below-the-fold images और iframe को lazy load किया जाता है
  • इसे static site build result folder पर npx @divriots/jampack./dist चलाकर लागू किया जाता है, और CSS·JS·HTML·SVG·image compression तक second pass में किया जाता है

Jampack की भूमिका

  • Jampack Static Site Generator, यानी SSG, द्वारा बनाए गए आउटपुट को input के रूप में लेकर static websites को optimize करता है
  • इसका लक्ष्य user experience और Core Web Vitals स्कोर को बेहतर बनाना है
  • README, Jampack को “ना bundler और ना framework” के रूप में अलग करके बताता है
  • परिचय लेख Read the introduction blog post में उपलब्ध है

इमेज ऑप्टिमाइज़ेशन

  • सामान्य <img> को responsive image में बदला जाता है
    • मूल src के लिए WebP file बनाई जाती है और srcset जोड़ा जाता है
    • sizes="100vw", loading="lazy", decoding="async", width, height जैसे attributes जोड़े जाते हैं
  • <picture> element को कई image formats शामिल करने वाली responsive structure में बदला जाता है
    • AVIF के लिए <source type="image/avif"> जोड़ा जाता है
    • WebP के लिए <source type="image/webp"> जोड़ा जाता है
    • मूल <img> में भी srcset, sizes, loading, decoding, width, height शामिल होते हैं
  • image optimization फीचर optimize-images दस्तावेज़ से जुड़ता है, लेकिन README में दिया गया लिंक relative path है

CDN और external images की प्रोसेसिंग

  • CDN images में remote URL को बनाए रखते हुए responsive srcset जोड़ा जा सकता है
    • उदाहरण में Unsplash image URL में w, fit=min, auto=format parameters जोड़कर अलग-अलग width candidates बनाए जाते हैं
    • मूल image में loading="lazy", decoding="async", sizes="100vw" भी जोड़े जाते हैं
  • External images को डाउनलोड करने के बाद optimized local files में बदला जा सकता है
    • उदाहरण में external Unsplash image को _jampack/ab99b9d280ce4cf7cfc810b59f3a7739.jpg.webp जैसे path में बदला गया है
    • बदली गई image में width, height, srcset, sizes, loading, decoding शामिल होते हैं

Above-the-fold और CSS·link optimization

  • Jampack above-the-fold assets को अलग से optimize करता है
    • images को ज्यादा priority के साथ load किया जाता है
    • छोटी images को HTML में embed किया जाता है
  • below-the-fold assets को lazy load किया जाता है
    • image और iframe lazy load के target हैं
  • Critical CSS को HTML में inline किया जाता है
    • इसका उद्देश्य stylesheet download और parsing के दौरान होने वाले FOUC से बचना है
    • बाकी CSS को lazy load किया जाता है
  • link prefetch भविष्य के page navigation को तेज़ करने के लिए है
    • quicklink का उपयोग करके, जब link viewport में आता है तब इसे dynamically handle किया जा सकता है

Asset compression और चलाने का तरीका

  • Jampack second pass में उन सभी assets को compress करता है जिन्हें पहले नहीं छुआ गया, और वही नाम व वही format बनाए रखता है
  • extension के अनुसार compression tools इस प्रकार हैं
  • जब static website dist folder में हो, तो इसे नीचे दिए गए command से चलाया जाता है
npx @divriots/jampack ./dist
  • अतिरिक्त options CLI options में देखे जा सकते हैं

Use cases और नाम का अर्थ

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-26
Hacker News टिप्पणियाँ

  • यही टूल मैं ढूंढ रहा था। इस तरह की image optimization के लिए मैं Sharp-आधारित script खुद लिखता रहा हूँ, लेकिन Jampack उसे पूरी तरह replace कर देता है और कहीं बेहतर काम करता है
    Quarto static site build करने के बाद Jampack चलाया तो folder size 32% कम हो गया, और अभी तक कोई साफ़ नुकसान नज़र नहीं आया
    PageSpeed Insights के हिसाब से Jampack से पहले mobile performance 52, accessibility 73, best practices 100, SEO 85 था, और desktop पर performance 90, accessibility 75, best practices 100, SEO 82 था
    लागू करने के बाद mobile performance 49, accessibility 80, best practices 100, SEO 92, और desktop performance 85, accessibility 82, best practices 100, SEO 91 आया

    • Lighthouse और PageSpeed Insights scores डगमगा सकते हैं। इस तरह के performance comparison में कई बार run करके median देखना बेहतर होता है
      इस बारे में एक reference भी है: “5 बार चलाए गए Lighthouse scores का median, 1 बार चलाने की तुलना में दोगुना स्थिर होता है”: https://developers.google.com/web/tools/lighthouse/variabili...
    • अच्छा लगा कि आपको यह पसंद आया। हालांकि performance metrics के बेहतर होने की उम्मीद थी। अगर ठीक लगे तो Jampack लागू करने से पहले static site का output share करें, मैं देखना चाहूँगा
      georges [at] divriots [dot] com

  • इससे Apache और Nginx के लिए PageSpeed module याद आता है: https://developers.google.com/speed/pagespeed/module

    • जहाँ तक मुझे पता है, उस project का अब maintenance नहीं हो रहा
      GitHub repository भी archive हो चुकी है: https://github.com/apache/incubator-pagespeed-ngx
      क्या यह कहीं और move हुआ है?

  • वाह, यह मुझे काफ़ी पसंद आया। इसे try करने वाला हूँ
    अगर किसी को यह बेकार लगा हो तो वह flaws बताना चाहेगा। मुझे यह कुछ वैसा लगता है जैसे C को highly optimized assembly में compile करना, और ऐसा tool जो पक्का उन कामों को संभाल लेता है जिन्हें मैं खुद नहीं करना चाहता

    • अगर हमें HTML और CSS में highly optimized assembly जैसी चीज़ deploy करनी पड़ रही है, तो पता नहीं हम सही दिशा में जा रहे हैं या नहीं
      मेरा मानना है कि सबसे simple और intuitive HTML और CSS लिखो, और हर device का browser उसे बस सही render कर दे
      अगर सच में हमें उस स्तर का optimized output deploy करना पड़ रहा है, तो HTML और CSS को ही छोड़ देना चाहिए और सीधे highly optimized WebAssembly deploy करने देना चाहिए, ताकि developer अपनी मनचाही language इस्तेमाल कर सके

  • अच्छा होगा अगर SSG output की Unicode ranges के आधार पर fonts को subset किया जा सके, और CSS में defined font-feature-settings के आधार पर OpenType axes को freeze किया जा सके

    • सही कहा, fonts के मामले में बहुत कुछ शानदार किया जा सकता है। TODO में system font fallback को सही metrics के साथ अपने-आप जोड़ने का काम है, ताकि CLS अपने-आप बेहतर हो
      मैं जानना चाहता हूँ कि क्या आपका मतलब इसी “font-feature-settings के आधार पर OpenType axes freeze करना” से है, या कुछ और
      font subsetting optimization भी करना चाहता हूँ, लेकिन इससे improvement कितनी होगी, अभी ठीक से नहीं पता। क्या आपने इसे manually करके देखा है?
    • अगर browser/system fonts इस्तेमाल करें, तो font size 0 तक optimize किया जा सकता है, तो फिर इसकी ज़रूरत ही क्या है?

  • यह विचार दिलचस्प है कि कौन-सा critical CSS अलग stylesheet में रखने के बजाय inline होना चाहिए, इसकी पहचान की जाए
    उम्मीद थी कि critical और non-critical CSS को सिद्धांत के आधार पर अलग करने का कोई तरीका होगा। जैसे :hover जैसी user interaction effects को हमेशा non-critical माना जाए
    लेकिन जो library इस्तेमाल हो रही है, वह page को render करके best guess लगाती है कि कौन-से rules critical हैं, यह थोड़ा निराशाजनक है: https://github.com/GoogleChromeLabs/critters

    • अगर CSS 50KB से कम है, तो बस उसे inline कर दो। अगर CSS 50KB से ज़्यादा है, तो शायद आप कुछ ग़लत कर रहे हैं
      हाँ, अगर fonts भी inline कर रहे हैं तो बात समझ आती है, लेकिन सिर्फ styles ही 50KB से ऊपर जा रहे हैं तो आमतौर पर दिशा ग़लत है
      गंभीरता से कहूँ तो inline करना, warm cache की तुलना में भी performance के लिए बहुत अच्छा है, और वह threshold जहाँ external stylesheet या script बेहतर होने लगती है, लोगों के सोचे से काफ़ी ऊँची है — आम market मानकों में यह कई सौ KB तक जा सकती है
      critical CSS का विचार मुझे मूल समस्या ठीक करने के बजाय बर्बाद हुई performance को थोड़ा वापस पाने की defeatist approach जैसा लगता है
      हालाँकि यह कोई व्यवस्थित technique नहीं, बल्कि हल्के अनुभव और observations पर आधारित राय है। अच्छा होगा अगर कोई इसे ठीक से measure करे, लेकिन शायद वह मैं नहीं होने वाला

  • यह उन कई उपयोगों को cover करता दिखता है जिनके लिए लोग शुरू से SSG और plugins चुनते हैं। खासकर अगर Astro या Eleventy चुना गया हो तो और भी
    क्या इसे अलग post-build step के रूप में पसंद करने की कोई वजह है? development के दौरान rebuild तेज़ हो सकती है, लेकिन image width declaration जैसी चीज़ें जोड़ते समय पैदा होने वाले subtle bugs छूट जाने का एक trade-off भी लगता है

  • जो लोग web page layout का काम नापसंद करते हैं और सीखना भी नहीं चाहते, लेकिन कभी-कभी करना पड़ता है, उनके लिए यह tool बहुत अच्छा लगता है

  • अच्छा लग रहा है। लेकिन निजी तौर पर मुझे यह पसंद नहीं कि page को first viewport के नीचे scroll करने पर images का इंतज़ार करना पड़े
    क्या default behavior में first viewport content खत्म होते ही नीचे की बाकी content को background में load किया जाता है?

    • नहीं। यह browser की native lazy loading का इस्तेमाल करता है। बड़े browsers loading="lazy" attribute को इस अर्थ में लेते हैं कि “इस image/iframe को तब तक load मत करो जब तक यह लगभग दिखाई न देने लगे”: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
      हालाँकि aspect ratio inline डाल दिया जाता है, इसलिए load होने के बाद layout shift नहीं होता। यानी lazy loading की सबसे बड़ी बुराई से बचा जाता है
    • जैसा @lelandfe ने बताया, Jampack browser-native loading="lazy" का उपयोग करता है
      अभी इस behavior को बदलने का कोई तरीका नहीं है, लेकिन page पूरी तरह load होने के बाद first viewport के नीचे की images को background में preload करने का option जोड़ा जा सकता है। यह काफ़ी अच्छा idea है
      बस चिंता यह है कि page के निचले हिस्से की अनावश्यक images भी load न हो जाएँ। अगर यह option हो, तो हर कोई इसे अपनी ज़रूरत के हिसाब से on/off कर सकता है

  • production environment में इस्तेमाल होने वाले static site generators कौन-कौन से हैं? लगता है इस tool से उनके output को और optimize किया जा सकता है
    उदाहरण के लिए, कल मैंने एक Divjoy React website को साधारण HTML में बदलकर S3 bucket से serve करने की कोशिश में examples follow करते-करते पूरा दिन बिता दिया। सोचा नहीं था कि यह इतना मुश्किल होगा, और अभी भी उलझा हुआ हूँ
    आदर्श रूप से, ऐसा कुछ हो जो S3 bucket में auto-deploy भी कर दे और domain भी connect कर दे। पैसे दे चुका हूँ, लेकिन developer गायब हो गया और Discord भी छोड़ दिया गया है। इसलिए मैं हमेशा FOSS को ज़्यादा पसंद करता हूँ

    • Hugo, Zola, Jekyll जैसे विकल्प हैं
      कुछ हद तक इनमें ऐसी functionality का एक हिस्सा मौजूद है

  • मेरी एक project में कोई बड़ा बदलाव नहीं दिखा। उदाहरण के लिए, कुल bundle size तो कम हुई, लेकिन gzip size बढ़ गई, इसलिए वास्तव में यह मेरे लिए net loss था
    फिर भी CSS improvements ने शायद सचमुच मदद की
    idea शानदार लगता है, और अगर project में images होतीं तो शायद यह और मददगार होता

    • अगर images नहीं हैं तो लाभ सीमित होना स्वाभाविक है। और यह browser compatibility को अपने-आप बेहतर बनाता है, इसलिए अंतिम CSS size बढ़ भी सकती है
      browserlist को empty string पर सेट करके इस feature को बंद किया जा सकता है: https://jampack.divriots.com/features/browser-compatibility/