15kB पेज की तुलना में 14kB पेज बहुत तेज़ लोड हो सकता है (2022)

 (endtimes.dev)
2 पॉइंट द्वारा GN⁺ 2025-07-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेबसाइट का आकार 14kB या उससे कम रखने पर 15kB होने की तुलना में लोडिंग स्पीड को काफ़ी कम किया जा सकता है
  • यह घटना TCP slow start algorithm की वजह से होती है, जहाँ शुरुआती डेटा ट्रांसफर सीमा के कारण महसूस होने वाली स्पीड में फ़र्क आता है
  • 14kB आम तौर पर सर्वर द्वारा शुरुआत में भेजे जाने वाले 10 TCP packets की क्षमता के बराबर होता है
  • सैटेलाइट इंटरनेट जैसी उच्च latency वाली परिस्थितियों में एक अतिरिक्त round trip (RTT) से 612ms या उससे अधिक की देरी हो सकती है
  • व्यवहार में, मुख्य कंटेंट को 14kB से कम में रखना या पहले 14kB के भीतर महत्वपूर्ण resources को रखना वेब परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के लिए प्रभावी है

अवलोकन और मुख्य सिद्धांत

  • वेबसाइट का आकार जितना छोटा होगा, वह उतनी जल्दी लोड होगी — यह एक अच्छी तरह ज्ञात तथ्य है
  • लेकिन 14kB से 15kB पर जाते ही पहली response speed में नाटकीय अंतर आना अपेक्षा से बाहर की बात है
  • 15kB और 16kB पेज के बीच स्पीड का अंतर मामूली होता है, लेकिन 14kB और 15kB के बीच अधिकतम 612ms का अंतर हो सकता है

TCP क्या है

  • Transmission Control Protocol (TCP), IP (Internet Protocol) के ऊपर काम करता है और packets की विश्वसनीय डिलीवरी सुनिश्चित करता है
  • वेब ब्राउज़र HTTP request के समय कई TCP packets भेजता है
  • केवल IP इस्तेमाल करने पर यह पता नहीं चलता कि packet पहुँचा या नहीं, इसलिए TCP packet receipt confirmation (ACK) की सुविधा देता है
  • सर्वर पहले थोड़ी संख्या में packets भेजता है, और ब्राउज़र से ACK मिलने पर अतिरिक्त packets भेजता है
  • ACK न मिलने पर packet retransmission प्रक्रिया शुरू होती है

TCP slow start क्या है

  • TCP slow start एक algorithm है जिसमें सर्वर नेटवर्क कनेक्शन की गुणवत्ता (bandwidth) समझने के लिए चरणबद्ध तरीके से packet ट्रांसमिशन बढ़ाता है
  • कनेक्शन की शुरुआत में सर्वर केवल थोड़ी संख्या में packets भेजता है, आम तौर पर 10
  • विज़िटर के कंप्यूटर से ACK सही तरह आने पर packet ट्रांसमिशन की मात्रा दोगुनी कर दी जाती है
  • अगर ACK छूट जाए, तो उसके बाद packets धीमी गति से भेजे जाते हैं
  • वास्तविक algorithm के विवरण implementation के हिसाब से अलग हो सकते हैं, लेकिन मूल विचार एक ही है

14kB सीमा का आधार

  • ज़्यादातर सर्वर slow start में 10 TCP packets एक साथ भेजते हैं
  • TCP packet का अधिकतम आकार 1500 bytes होता है, लेकिन header (40 bytes) हटाने पर 1460 bytes वास्तविक डेटा के लिए बचते हैं
  • इसलिए 10 x 1460 = 14600 bytes (लगभग 14kB) पहली ट्रांसमिशन की ऊपरी सीमा है
  • अगर वेबसाइट या महत्वपूर्ण resources को 14kB या उससे कम में रखा जाए, तो शुरुआत में अतिरिक्त round trip delay के बिना दिखाया जा सकता है

एक round trip कितनी बड़ी देरी पैदा कर सकता है

सैटेलाइट इंटरनेट उदाहरण

  • उच्च latency वाले माहौल का प्रतिनिधि उदाहरण सैटेलाइट इंटरनेट उपयोगकर्ता हैं, जैसे तेल ड्रिलिंग रिग या क्रूज़ शिप पर मौजूद लोग
  • मोबाइल फ़ोन से होमपेज request भेजने पर router → satellite antenna → space satellite → ground station → server तक हर चरण में दर्जनों से सैकड़ों ms लग सकते हैं
  • पूरे transmission round trip में दो बार अंतरिक्ष मार्ग, नेटवर्क खंडों की यात्रा और सर्वर प्रोसेसिंग शामिल होने से लगभग 612ms की अतिरिक्त देरी हो सकती है
  • HTTPS इस्तेमाल करने पर अतिरिक्त handshake के कारण यह 1836ms तक बढ़ सकता है

स्थलीय नेटवर्क की latency

  • 2G, 3G जैसे मोबाइल नेटवर्क में भी 100~1000ms तक latency हो सकती है
  • भीड़भाड़, सर्वर ओवरलोड, packet loss जैसी अलग-अलग परिस्थितियों में अतिरिक्त देरी हो सकती है

14kB नियम लागू करने की वेबसाइट ऑप्टिमाइज़ेशन रणनीति

  • वेबसाइट या पेज को जितना संभव हो उतना छोटा बनाना सबसे अहम है
  • आदर्श रूप से हर पेज का compressed transfer size 14kB या उससे कम होना चाहिए
    • compression लागू होने पर वास्तविक content ~50kB तक शामिल हो सकता है
  • autoplay video, popup, tracker, अनावश्यक JS/CSS जैसे अधिकांश गैर-ज़रूरी तत्वों को घटाकर यह आसानी से हासिल किया जा सकता है
  • अगर पूरे पेज को 14kB में समेटना मुश्किल हो, तो पहले 14kB में core resources और मुख्य content (CSS, JS, मुख्य text आदि) को प्राथमिकता से रखना महत्वपूर्ण है
  • HTTP headers (compress नहीं किए जा सकते), images (केवल ज़रूरी न्यूनतम/दिखने वाले हिस्से को लोड करना या placeholder लगाना) भी 14kB के भीतर गिने जाते हैं

14kB नियम के अपवाद और आधुनिक protocol मुद्दे

  • 14kB नियम बहुत अधिक सामान्यीकरण नहीं है, लेकिन कुछ अपवाद मौजूद हैं
    • कुछ सर्वर initial window को 30 packets तक बढ़ाते हैं
    • TLS handshake के ज़रिए बड़ा window स्वीकार करने की संभावना हो सकती है
    • route के हिसाब से भेजे जा सकने वाले packet count को cache करके अगली connection पर और अधिक भेजा जा सकता है
  • HTTP/2 में भी सर्वर का TCP slow start के साथ 10 packets से शुरू करना आम तौर पर नहीं बदला है
  • HTTP/3, QUIC में भी 14kB नियम आधिकारिक रूप से अनुशंसित है

सारांश और संदर्भ सामग्री

  • तकनीकी आधार और अतिरिक्त व्याख्या से जुड़ी सामग्री हर लिंक के ज़रिए देखी जा सकती है
  • पहली बार प्रकाशित: 2022-08-25, हाल में संशोधित: 2022-08-26, लेखक: Nathaniel, संबंधित टैग: वेब परफ़ॉर्मेंस, HTTP, TCP

संदर्भ लिंक

  • Ethernet frame और TCP header संरचना, latency और bandwidth से जुड़ी अतिरिक्त सामग्री, TCP/QUIC specification आदि

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

1 टिप्पणियां

 
GN⁺ 2025-07-20
Hacker News राय

  • सॉफ़्टवेयर डेवलपर्स को मीडिया लेयर पर थोड़ा ज़्यादा ध्यान देने की ज़रूरत है, खासकर 3G/5G की reliability और latency के बारे में लेखक ने जो बात कही वह प्रभावशाली है। रेडियो में लगभग हमेशा retransmission होता है, और ज़्यादातर HTTP संचार में UI अपडेट होने के लिए packets का क्रम में पहुँचना ज़रूरी होता है। वास्तव में, एक अकेला REST request भी तभी सचमुच एक packet में संभलता है जब request और response दोनों 1400 bytes से कम हों। इससे बड़ा होने पर वह ‘single’ request असल में कई packets में बँट जाता है। इनमें से किसी एक में भी समस्या हुई तो स्क्रीन के सही तरह अपडेट होने के लिए सारे packets का क्रम में पहुँचना ज़रूरी हो जाता है। अगर इसे आज़माना हो तो Chrome DevTools में 3G mode और packet loss चालू करके टेस्ट करें; सिर्फ़ एक छोटी optimization से भी UI responsiveness में बड़ा सुधार दिखेगा। इसलिए API और UI को जितना संभव हो उतना छोटा रखने का एक ठोस कारण है

  • मेरे homepage का transfer size compression के बाद 7.0kB है

    • /
    • main.css
    • favicon.png
    • कुल 7.0kB ब्लॉग सूची और पूरी वेबसाइट मैंने अपने custom static site generator (public: site.lisp, Common Lisp इस्तेमाल किया है) से बनाई है। गणित से जुड़े posts में मैं client-side rendering के साथ KaTeX इस्तेमाल करता हूँ, और इस स्थिति में 347.5kB और जुड़ जाते हैं
    • katex.min.css 23.6kB
    • katex.min.js 277.0kB
    • auto-render.min.js 3.7kB
    • KaTeX_Main-Regular.woff2 26.5kB
    • KaTeX_Main-Italic.woff2 16.7kB
    • कुल अतिरिक्त 347.5kB कभी न कभी KaTeX को server-side rendering में बदलने के बारे में सोच रहा हूँ। यह ब्लॉग मेरे कॉलेज हॉस्टल के दिनों से चला आ रहा मेरा निजी passion project है। सारा HTML, templates और CSS तक मैंने खुद लिखा है, और हर page में सिर्फ़ वही चीज़ें रखी हैं जो सच में ज़रूरी हैं, इसलिए इसका आकार छोटा बना हुआ है
    • मेरा homepage
    • गणित posts का संग्रह
      • ऐसा नहीं कि हमेशा बेहतर तरीका न अपनाया जाए, लेकिन LaTeX expressions जैसे dynamic components लोड होने पर client-side rendering से जो delay आता है, वह आम उपयोगकर्ता को लगभग (या सचमुच) महसूस नहीं होता। over-optimization भी एक समस्या है। यह पूरा SEO-आधारित performance pursuit, अगर आपकी service पर millions of views का traffic नहीं है, तो समय के मुकाबले बहुत ज़्यादा फ़ायदा नहीं देता। यह ऐसा है जैसे समुद्र में ज्वार से चल रही बिना चालक वाली नाव को aerodynamics तक के हिसाब से ट्यून करना। सीमित resources के नज़रिये से total cost और benefit देखें तो optimization हमेशा सबसे अच्छा विकल्प नहीं होता
      • अगर गणित content कम है और फिर भी KaTeX इस्तेमाल करना है, तो विकल्प के तौर पर MathML(mathml-core) पर भी विचार किया जा सकता है
      • मुझे समझ नहीं आता कि गणितीय formulas या LaTeX expressions को client-side js से render करने की ज़रूरत क्यों है। इन्हें पहले से HTML/CSS में बदलकर prerendered रूप में क्यों नहीं रखा जाता?
      • भारी libraries को initial page render के बाद लोड करना, या केवल viewport में दिखने पर SVG के रूप में formula graphics मँगाना भी एक idea हो सकता है। मेरी राय है

  • 14kB का लक्ष्य थोड़ा चुनौतीपूर्ण है, लेकिन initial 10 packets के भीतर सीमित रखने का विचार भी दिलचस्प है। मेरी तरह वेबसाइट आकार पर ध्यान देने वाले projects में 512kb.club भी है। वहाँ sites के size की तुलना golf score की तरह होती है। मेरी site(anderegg.ca) में registration से पहले सभी resources जोड़कर 71kB आया था। इसी project की वजह से मुझे Cloudflare Radar के बारे में पता चला, जिसमें site analysis और page size मापने के लिए अच्छा tool है। इसका मुख्य उद्देश्य पूरे internet का dashboard है, लेकिन इसमें page size analysis tool भी शामिल है

    • एक उपयोगकर्ता के रूप में पूछना चाहता हूँ, बाकी बचे 500kB किस काम के लिए हैं? मुझे तो 90% सिर्फ़ text चाहिए, और बाकी भी vector graphics हों तो काफ़ी है। 14 kB में भी काफ़ी text और graphics आ सकते हैं, तो बाकी 500 किस पर खर्च हो रहे हैं?
    • 512kb एक व्यावहारिक सीमा है। मैं भी अपनी वेबसाइट पर यही मानक लागू करता हूँ। 14kb स्तर की वेबसाइटें तो वेब के सामान्य मानक से भी आगे निकल चुकी हैं
    • निजी वेबसाइट के लिए 512kb हासिल करना पूरी तरह संभव है। मेरा अगला लक्ष्य 99kb (100kb के अंदर) है। वीकेंड में कुछ बार समय देने से हो जाएगा। मेरी site 512kb पर Orange grade में है

  • अगर आप इसे थोड़ा और मज़ेदार प्रयोग बनाना चाहें, तो initial window (IW) size server side पर सेट की जा सकती है। उदाहरण के लिए इसे इस तरह बदला जा सकता है

    • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 खोजने पर पता चलता है कि अब कुछ CDN initial window को 30 packets (45kb) तक भी रखते हैं
    • 13 साल पहले 10 packets भी ‘cheating’ माने जाते थे। इसके बारे में यहाँ और Ben Strong ब्लॉग (archive) देखें
    • क्या किसी के पास इस बात का स्रोत है कि CDN की initial window 30 packets होती है?
    • चाहें तो इसे सीधे 1000 packets पर भी सेट कर सकते हैं, यानी एक तरह से ‘bad citizen’ बनकर... लेकिन नुकसान यह है कि किसी dial-up या bufferbloat वाले connection पर bottleneck पैदा हो सकता है

  • नीचे दिए गए लेख की बात भी यहाँ लागू होती है: Cloudflare ब्लॉग - रूस के ISP सिर्फ़ पहले 16KB तक अनुमति दे रहे हैं, जिससे सामान्य वेब ब्राउज़िंग लगभग असंभव हो गई. Cloudflare analysis के अनुसार, रूसी ISPs अपने देश के उपयोगकर्ताओं के लिए internet throttling करके हर web asset के सिर्फ़ पहले 16KB तक ही लोड होने दे रहे हैं

  • जो लोग TCP Slow Start नहीं जानते और जो लोग वेबसाइट लोडिंग latency के सूक्ष्म स्तर तक परवाह करते हैं, उनके बीच overlap बहुत कम है। startups को पहले startup पर ध्यान देना चाहिए, और सिर्फ़ बड़ी कंपनियों के पास ही ऐसी optimization पर अटकने की गुंजाइश होती है

    • अगर सोच यह हो कि "हम ज़रूरी चीज़ों पर ध्यान दे रहे हैं इसलिए performance optimization की फुर्सत नहीं है", तो फिर आप कभी उस पर ध्यान नहीं देंगे। यही वजह है कि आजकल ज़्यादातर apps और sites धीमे और ख़राब हैं
    • अगर यह सच होता, तो Microsoft जैसी कंपनी का software हमेशा पूरी तरह सर्वोत्तम efficiency पर चलना चाहिए था
    • अवधारणा के स्तर पर यह बात सही लगती है। लेकिन अगर Figma के Evan Wallace performance को लेकर जुनूनी न होते, तो Figma आज जैसा नहीं होता। कई बार 'performance' खुद product का मुख्य feature बन जाती है
    • इसे choice का मामला बनाने की ज़रूरत नहीं; इसे default में ही शामिल किया जा सकता है। मैंने 1 अरब cells और checkboxes demo[1] दोनों में datastar इस्तेमाल किया, और वे मुश्किल से 10kb से थोड़ा ऊपर हैं। mobile network और 3G पर फ़र्क़ साफ़ दिखता है। मेरे प्रयोग में 14kb पार करते ही ख़राब connections पर 3 सेकंड और लगते थे। datastar maintainer ने TCP slow start तक का ध्यान रखा, इसलिए बिना अतिरिक्त मेहनत के भी मुझे उसका फ़ायदा मिल गया
    • मुझे नहीं लगता कि कंपनी का आकार performance optimization से बहुत जुड़ा है। उल्टा, बड़ी कंपनियाँ अक्सर और भी धीमी होती हैं

  • मेरा homepage 17.2KB है! (dependencies छोड़कर) मैंने अपनी personal page पर वाकई बहुत optimization की और Lighthouse में 100 में 100 score भी हासिल किया। पहले लगा था यह नामुमकिन होगा, लेकिन हो गया। और हाँ, यह Rails में बना है। ऐसी optimization वास्तव में करने लायक है। बिना किसी sluggishness के बिजली की तरह खुलने वाले pages का अनुभव अपने आप में बहुत संतोषजनक है

    • news.ycombinator.com का तुरंत लोड होना मनोवैज्ञानिक रूप से भी इतना सुखद है कि ब्रेक के समय मैं उसे लगभग अपने आप खोल लेता हूँ
    • मैंने हज़ारों sites के लिए template code को बेहद optimize करके Lighthouse 100/100/100/100 score हासिल किए हैं। mobile पर भी पूरा 100। initial load 17.2kB से काफ़ी बड़ा, लगभग 120kB है, लेकिन तरकीब यह है कि सभी अनावश्यक HTTP requests हटा दो, सिर्फ़ "above-the-fold" हिस्से के लिए JS चलाओ, बाकी सब lazy eval, defer वगैरह से यथासंभव देर से लोड करो। JS/CSS को inline किया, और third-party widgets के लिए popup icon जैसी 'facade' पद्धति अपनाई ताकि असली request बाद में जाए। SSR backend ने भी बहुत मदद की। Vimeo background video के साथ भी 100 score आया, लेकिन Youtube के साथ यह संभव नहीं था। perfect score पाने का तरीका यह था कि Lighthouse results को समझकर codebase को ही पूरी तरह दोबारा लिखा जाए। इसकी वजह से speed को लेकर clients की complaints पूरी तरह बंद हो गईं, और SEO तथा वास्तविक scores दोनों में बड़ा competitive edge मिला
    • Rails का rendering optimization से सीधा संबंध नहीं है। perfect Lighthouse score के लिए बधाई

  • मुझे लगता है कि लेख में दो तार्किक कमज़ोरियाँ हैं

    1. satellite communication में एक packet भेजने में लगभग 1600ms लगने वाला जो सूत्र दिया गया है, वह 14kb rule का आधार बनने के लिए कमज़ोर है। बड़े websites से तुलना नहीं है, इसलिए यह नहीं दिखता कि 10 packets ≠ 16 seconds
    2. इसमें कहा गया कि webpage images भी 14kb rule में शामिल हैं, लेकिन images initial load में inline होने के मामले कितने हैं? वास्तविकता में यह बहुत दुर्लभ अपवाद है, इसलिए 99.9% मामलों में यह लागू नहीं होता—यह और स्पष्ट कहा जाना चाहिए - "<i>images inline होने के मामले?</i>" की बात करें तो, उदाहरण के लिए केवल initial screen पर दिखने वाले low-resolution thumbnails में CSS blur जोड़कर, और असली image को बाद में asynchronously fade in करने की तकनीक है। सही तरीके से करें तो सिर्फ़ 1~200 bytes का अतिरिक्त खर्च आता है। मैंने इसे अपने ब्लॉग में लगाया है, और Wordpress, Medium जैसे platforms भी इसे काफ़ी अपनाते हैं। यह मुख्य रूप से commercial frontend hyper-optimization की तरकीब है - मैं इस धारणा से भी सहमत नहीं कि अधिकांश उपयोगकर्ता low-latency satellite connection पर हैं, और इस वास्तविकता से भी नहीं कि जबकि सारी websites कई MB की हैं, सिर्फ़ मेरा page ही असहनीय साबित होगा

  • आज की पीढ़ी simple static websites भी Next.js जैसे frameworks से बनाती है। यह देखकर अफ़सोस होता है कि HTML+CSS+js का दौर जैसे ढल रहा है

    • सहमत हूँ। मैंने भी minimal resources, manual JavaScript optimization, 14kb rule वाली sites सब करके देखी हैं, लेकिन यह तरीका design और architecture constraints पैदा करता है। जैसे-जैसे features बढ़ते हैं, उस समय लिए गए सारे 'minimization' फ़ैसले technical debt बन जाते हैं। ज़्यादातर लोग 'framework-less pure web' को romanticize करते हैं, फिर किसी बिंदु पर वही और ज़्यादा कष्टदायक बन जाता है। लेकिन isomorphic JS frameworks इस्तेमाल करने पर आप static page से शुरू कर सकते हैं, ठीक-ठाक optimize कर सकते हैं, और ज़रूरत पड़ने पर thick client JS की ओर जा सकते हैं
    • trend पहले ही वापस मुड़ रहा है। आजकल के ज़्यादातर frameworks static sites को अच्छी तरह support करते हैं। Astro जैसी चीज़ तो शुरू से ही static sites के लिए बनी थी
    • अब पता चला? असल में यह तो 2010 में jQuery की लोकप्रियता तेज़ होने से पहले से ही होता आया है
    • Next.js bundle code को बहुत आक्रामक रूप से optimize करता है, इसलिए lambda या छोटे servers पर launch के लिए अच्छा है। Next से बनी static sites भी काफ़ी छोटे bundles बना सकती हैं

  • latency ही नहीं, resource consumption को कम करना भी टिकाऊ भविष्य के लिए ज़रूरी शर्त है। network का पर्यावरण पर प्रभाव भी बिल्कुल छोटा नहीं है। टिप्पणियों का व्यंग्यात्मक माहौल थोड़ा निराशाजनक लगा। यह optimization कोई अंतिम समाधान का युग नहीं है, लेकिन energy usage में कमी के असर पर और ज़ोर होना चाहिए

    • ज़्यादातर internet traffic video streaming है। webpages में कुछ MB optimize करने से बहुत फ़र्क़ नहीं पड़ेगा। efficiency पर चर्चा ज़रूरी है, लेकिन हर जगह optimization में प्रयास लगाने से उन क्षेत्रों से resources हट सकते हैं जहाँ इसकी सचमुच ज़्यादा ज़रूरत है
    • यह तो low-hanging fruit भी नहीं है। webpage में 1~2mWh बचाने के लिए optimization करते समय, एक search engine query 100 गुना और एक chatbot interaction 10,000 गुना ज़्यादा खर्च कर देता है। caching और lazy loading से काफ़ी हद तक इसे कम किया जा रहा है
    • page size घटाने की चिंता लगभग बेकार काम है। साल भर की web browsing में लगने वाली बिजली, सुरक्षा की दृष्टि से 10 गुना मान लें तब भी, एक hamburger बनाने में लगने वाली energy से बहुत कम है। उल्टा, अगर कोई developer optimization करने की बजाय एक हफ़्ते तक एक salad meal खा ले, तो पर्यावरणीय असर उससे बड़ा होगा
    • पूरी तरह सहमत। मैं पहले BBC गया था और यह देखकर चौंक गया कि एक छोटे text article के लिए cache में 120MB तक store हो रहा था। यह बेवजह ऊर्जा और अपव्यय की संस्कृति को बढ़ावा देता है। मैंने भी अपनी website को जितना हो सके minimalist रखा है, और YouTube uploads भी 4K की बजाय सिर्फ़ 1080P में करता हूँ। 4K, 8K का अस्तित्व ही ज़रूरी नहीं लगता। लोग अक्सर सिर्फ़ कुछ MW solar और जोड़ने की बात करते हैं, लेकिन असल में 'कम उत्पादन' कितना अच्छा हो सकता है, इसकी कल्पना करनी चाहिए। 56K modem के दौर का छोटा web याद आता है; कहीं न कहीं एक मध्य बिंदु था, लेकिन अब हम उससे बहुत आगे निकल चुके हैं
    • लोग तभी ध्यान देते हैं जब असर सीधे उन पर पड़ने लगता है। मैं भी पर्यावरण की परवाह करता हूँ। AI के और बुरा होने वाली दलील भी आती है, लेकिन सच यह है कि AI भी ऐसे भारी pages को crawl करता है। और 14kb का मानक mobile के औसत page payload के 1% से भी कम है