हमारे Next.js पेज Bing के लिए बहुत बड़े थे। RSC पेलोड HTML का 58% था

Katto एक AI वीडियो क्लिपिंग टूल है। आप इसे एक लंबा वीडियो देते हैं, यह सबसे अच्छे पल ढूँढ़कर उन्हें कैप्शन वाले वर्टिकल क्लिप में काट देता है। मैं इसे अकेले बनाता हूँ, सार्वजनिक रूप से, Next.js और App Router पर। यह लेख एक ऐसी माप के बारे में है जिसने पेज लिखने का मेरा तरीका बदल दिया, एक ऐसे आँकड़े के बारे में जो मैंने सबके सामने भरोसे से कहा और वह गलत निकला, और अपनी एक परिकल्पना के बारे में जिसकी कीमत 108 बाइट निकली।

लक्षण

Bing Webmaster Tools हमारे कई पेज को «खोजा गया पर क्रॉल नहीं हुआ» दिखा रहा था। न robots.txt से रोके गए, न noindex, न धीमे, न रीडायरेक्ट। खोजे गए, फिर छोड़ दिए गए। Google उन्हें इंडेक्स कर रहा था। हमारे साइटमैप में वे थे। जो भी माँगे, उसे 200 लौटाते थे।

जिन पेजों को वह ठुकरा रहा था, उनमें एक बात समान थी, और वह उनका कंटेंट नहीं थी।

सीमा, और हम उसे कितना कम जानते हैं

Microsoft यह नहीं बताता कि किस आकार पर उसका क्रॉलर हार मान लेता है। हमारे पास अपने ही पेज हैं, हर एक की स्थिति Bing Webmaster Tools में पढ़ी गई और उसी दिन bingbot के यूज़र एजेंट से, बिना कंप्रेशन के मापी गई सर्व्ड साइज़ के साथ:

/contact, 46,111 बाइट: इंडेक्स्ड।
/changelog, 103,058 बाइट: इंडेक्स्ड।
/roadmap, 116,239 बाइट: इंडेक्स्ड।
/compare/opusclip, 127,182 बाइट: इंडेक्स्ड।
/compare/ai-video-clippers, 127,951 बाइट: इंडेक्स्ड।
/compare/, 140,686 बाइट: खोजा गया पर क्रॉल नहीं हुआ।

रेखा के उस पार सिर्फ़ एक पेज होना कोई नियम नहीं बनाता। पर इस सूची में एक अवलोकन ऐसा है जो बाकी सब से ज़्यादा कीमती है, क्योंकि यह एक ही URL दो बार है। /compare/ai-video-clippers 172,295 बाइट सर्व करता था और हफ़्तों तक «खोजा गया पर क्रॉल नहीं हुआ» पर अटका रहा। हमने उसे लगभग 124 KB तक छोटा किया। आज वह इंडेक्स्ड है, 127,951 बाइट पर। वही URL, वही टेम्पलेट, वैसा ही कंटेंट: पहले बहुत बड़ा, फिर काफ़ी छोटा।

एक हफ़्ता पहले मैं आपको दूसरा आँकड़ा देता, और वह गलत होता। मेरे पास तीन स्थिति-पाठ थे और हमारे पेज आकारों के वितरण में एक साफ़ दिखता खाली हिस्सा, और मैंने उसमें 125 KB के आसपास की सीमा पढ़ ली। उनमें से दो पेज तब से 128 KB से थोड़ा कम पर इंडेक्स हो चुके हैं। हमारी अपनी साइट असल में इतना ही कह सकती है कि रेखा 128 और 140 KB के बीच है, और उसका दूसरा किनारा आज भी ठीक एक पेज चौड़ा है।

अगर आप कोई आँकड़ा लेने आए थे, तो ईमानदार जवाब है: अपना खुद मापिए। जो दावा मैं बचा सकता हूँ वह वैसे भी ज़्यादा सँकरा और ज़्यादा काम का है: «खोजा गया» पर अटका पेज दोबारा लिखने से पहले तौलने लायक है, और जो पेज छोटा करने के बाद क्रॉल होने लगे, वही असल में गिनने वाला इकलौता सबूत है।

सोर्स फ़ाइल तौलने से कुछ पता नहीं चलता

यह हिस्सा React Server Components के लिए खास है। App Router रेंडर किए गए ट्री को उसी HTML दस्तावेज़ के भीतर self.__next_f.push(...) स्क्रिप्ट टैग की एक कड़ी के रूप में सीरियलाइज़ करता है, ताकि क्लाइंट-साइड नेविगेशन बिना एक और राउंड ट्रिप के आगे बढ़ सके। यह पेलोड कोई अलग अनुरोध नहीं है जिसे क्रॉलर छोड़ सके। यह दस्तावेज़ के भीतर है।

हमारे एक पेज पर मापा गया: 125,981 बाइट सर्व हुए, जिनमें से 73,571 यही पेलोड है। दस्तावेज़ का अट्ठावन प्रतिशत उसी बात की सीरियलाइज़ प्रति है जो बाकी बयालीस प्रतिशत पहले ही कह रहा है।

तो 24 पंक्तियों के लूप के अंदर एक बार लिखी गई यूटिलिटी क्लास 24 बार नहीं जाती। वह 48 बार जाती है।

जो देखने में मुझे सबसे ज़्यादा समय लगा

यह पेज को दोगुना नहीं करता। यह पेज जो-जो प्रस्तुतियाँ पहले से ढो रहा है, उनमें से हर एक को दोगुना करता है।

हमारा रोडमैप हर प्रविष्टि को जानबूझकर दो बार रेंडर करता था: एक बार दिखने वाले टेक्स्ट के रूप में, एक बार JSON-LD के ItemList ब्लॉक के भीतर, ताकि मशीन पाठकों को नाम, तारीख और स्थिति व्याख्या करने लायक गद्य की जगह डेटा के रूप में मिले। उचित है। फिर मैंने गिना कि एक प्रविष्टि का विवरण सर्व किए गए दस्तावेज़ में कितनी बार आता है, और वह चार बार निकला।

दो प्रस्तुतियाँ, हर एक दोगुनी। एक ही वाक्य की चार प्रतियाँ, और गिनने का ख़याल मुझे कभी नहीं आया था।

इलाज कंप्रेशन नहीं था। JSON-LD में एक description थी जो उसी भाषा में, तीस पंक्ति नीचे पाठक को दिखने वाले टेक्स्ट की हूबहू नकल थी। उससे कुछ नहीं मिलता था और वह चार में से दो प्रतियाँ खा रही थी। हटाने पर ब्लॉक में नाम, तारीख और स्थिति बचते हैं, यानी ठीक वही जो गद्य मशीन को स्पष्ट रूप से नहीं बताता। वह पेज 121,196 से 115,350 बाइट पर आ गया और कोई जानकारी बाहर नहीं गई। दोनों आँकड़े एक ही बिल्ड के हैं, उसी एक बदलाव से पहले और बाद में, और «पहले और बाद» का अर्थ निकलने का यही इकलौता तरीका है।

अगर यहाँ से एक आदत ले जानी हो: कुछ भी हल्का करने की कोशिश से पहले गिनिए कि आपके कंटेंट का एक वाक्य सर्व किए गए दस्तावेज़ में कितनी बार आता है। यह उस सवाल का जवाब देता है जिसका जवाब सेक्शन तौलने से नहीं मिलता।

दो बड़े लीवर

दोहराए गए class एट्रिब्यूट को स्टाइलशीट नियमों में। Tailwind की यूटिलिटी लिखने में बेहद सस्ती हैं, और वे हर एलिमेंट के साथ, दो बार जाती हैं। सबसे ज़्यादा दोहराई गई यूटिलिटी को @apply नियमों में ले जाने से हमारा प्राइसिंग इंडेक्स 172,295 बाइट से घटकर लगभग 142,000 पर आया। वे मार्कअप का करीब 51 प्रतिशत थीं।

गैर-इंटरैक्टिव ब्लॉक को सीरियलाइज़ ट्री से बाहर। सटीक कहूँ, क्योंकि यह मायने रखता है: ये Server Components हैं, इसलिए ये क्लाइंट पर कभी हाइड्रेट नहीं होते। लागत हाइड्रेशन की नहीं, सीरियलाइज़ेशन की है। हर एलिमेंट, हर prop और हर key फ़्लाइट पेलोड में लिखा जाता है ताकि क्लाइंट-साइड नेविगेशन बिना राउंड ट्रिप के ट्री दोबारा बना सके। बिना किसी क्लाइंट व्यवहार वाली स्थिर टेबल भी यह कीमत चुकाती है, और जब बाधा दस्तावेज़ का आकार हो तो उसके React एलिमेंट बने रहने का कोई कारण नहीं। अब हम ऐसे ब्लॉक उन्हीं डेटा से HTML स्ट्रिंग के रूप में बनाते हैं और dangerouslySetInnerHTML से रखते हैं, और बनाते समय हर इंटरपोलेट की गई वैल्यू को एस्केप करते हैं ताकि एस्केपिंग इस पर निर्भर न रहे कि डेटा कहाँ से आया। प्राइसिंग इंडेक्स पर 18 KB और। रोडमैप की 54 पंक्तियों वाली सूची इसी रास्ते 157,308 से 119,031 पर आई।

जो काम नहीं आया

इन सबसे पहले मुझे पक्का यकीन था कि समस्या कंपोनेंट की सीमाएँ हैं। एक सूची में चौवन next/link कंपोनेंट, हर एक अपना सीरियलाइज़ नाम, props और keys पेलोड में जोड़ता हुआ। मैंने चौवनों को सादे एंकर से बदल दिया।

157,200 में से 108 बाइट की बचत हुई।

Link सस्ता है। वह जो लपेटता है, वह सस्ता नहीं। अगर मैंने पहले और बाद में मापा न होता तो मैं उस सिद्धांत पर पूरा दिन कंपोनेंट दोबारा लिखने में लगा देता, और वह नकारात्मक नतीजा उस दिन का सबसे काम का आँकड़ा था।

एक फ़र्श है, और वह नीचा नहीं है

हमारा सबसे हल्का असली पेज /contact सिर्फ़ एक शीर्षक, एक छोटा फ़ॉर्म और कुछ सवाल लिए हुए भी 46,111 बाइट सर्व करता है। बाकी सब नेविगेशन, फ़ुटर, एनालिटिक्स और फ़ॉन्ट है। इस आँकड़े से नीचे पेज-दर-पेज कुछ पाने को नहीं बचता; वह पेज का नहीं, ढाँचे का काम होगा। फ़र्श जानना बताता है कि कब रुकना है।

अनुवाद की कीमत बाइट में है, शब्दों में नहीं

हमने वह रोडमैप दस भाषाओं में किया। वही मार्कअप, वही संरचना, वही जानकारी। अंग्रेज़ी पेज 116,239 बाइट सर्व करता है, फ़्रेंच 119,838, जापानी 122,155 और हिंदी 135,379।

देवनागरी UTF-8 में प्रति अक्षर तीन बाइट लेती है जहाँ लैटिन टेक्स्ट एक लेता है, और पेलोड उसे दूसरी बार चुकाता है। पेज स्तर की कोई तकनीक इसे नहीं छूती: वही मार्कअप, वही जानकारी, उन्नीस किलोबाइट का फ़र्क।

दिलचस्प पेज हिंदी वाला है, क्योंकि 135,379 बाइट पर वह ठीक उसी पट्टी के भीतर गिरता है जिसे हम सुलझा नहीं पा रहे। Bing उसे प्रोसेस करता है या नहीं, यह हमारे पास उपलब्ध सबसे सस्ता प्रयोग है, और उसकी कीमत एक URL निरीक्षण है।

यहाँ मैंने एक पैराग्राफ़ लिखा था जो कहता था कि यह अतिरिक्त आकार बहुत मायने नहीं रखता, क्योंकि वह दस्तावेज़ के अंत में पड़ता है और उस पेज का अंत एक सूची है जिसके शीर्षक वैसे भी अंग्रेज़ी में रहते हैं। मैंने उसे काट दिया, क्योंकि वह मान लेता है कि क्रॉलर अपना बजट ख़त्म होने तक पढ़ता है और फिर रुक जाता है। मैंने वास्तव में जो देखा है वह सिर्फ़ इतना कहता है कि एक आकार से ऊपर के पेज प्रोसेस नहीं होते। अगर दस्तावेज़ पूरा का पूरा ठुकराया जाता है तो उसका क्रम कुछ नहीं ख़रीदता, और मेरे पास किसी भी दिशा का सबूत नहीं है। यह अपने ही पेज के बारे में एक आरामदेह सिद्धांत है, और ऐसे ही सिद्धांत सबसे पहले मिटाने लायक होते हैं।

यह बजट है, मरम्मत नहीं

जिस प्राइसिंग इंडेक्स को मैं 172,295 से 124,202 बाइट पर लाया था, वह आज 127,951 पर है, क्योंकि हम उसमें जोड़ते गए: और टूल, और कॉलम, दस अनुवाद। वह अब भी इंडेक्स्ड है, और यही पूरी बात है, और साथ ही वह रेखा से कुछ ही किलोबाइट दूर लौट आया है। कुछ गलत नहीं हुआ। हमने बस बिना नज़र रखे बजट दोबारा खर्च कर दिया।

असली निष्कर्ष यही है। जो फ़्रेमवर्क अपना ही आउटपुट सीरियलाइज़ करता है, उसमें पेज का वज़न एक बार कर लेने वाली सफ़ाई नहीं है। यह एक ऐसा आँकड़ा है जो हर बार किसी के अच्छा काम करने पर ऊपर जाता है, और इसका इकलौता बचाव है सोर्स की जगह सर्व किए गए दस्तावेज़ को, एक बार में एक बदलाव, मापना।

अपने पेज कैसे मापें

URL माँगिए और रेस्पॉन्स बॉडी के बाइट गिनिए, बिना कंप्रेशन। क्रॉलर यही पाता है, और यह वह नहीं है जो आपकी सोर्स फ़ाइल से लगता है।
उस बॉडी में अपने कंटेंट के एक खास वाक्य की उपस्थिति गिनिए। एक से ज़्यादा का मतलब है कि आप उसकी कीमत एक से ज़्यादा बार चुका रहे हैं, और वह बता देता है कि नकल कहाँ है।
हर एक बदलाव के बाद अलग-अलग दोबारा मापिए। दो बदलाव एक साथ उस बदलाव को छिपा देते हैं जिसने कुछ नहीं किया।
फिर उसी URL की स्थिति Bing Webmaster Tools में दोबारा पढ़िए। दूसरों के पेज से निकाली गई सीमा एक अनुमान है। आपका अपना पेज, जो छोटा करने के बाद क्रॉल होने लगे, एक माप है।