Next.js में मजबूत इमेज राय होती है, और कार साइट्स हर एक का परीक्षण करती हैं: हर पेज पर सैकड़ों रिमोट इमेज, एस्पेक्ट रेशियो जो शिफ्ट नहीं होनी चाहिए, और एक CDN जो पहले से ही एसेट्स के सामने बैठा हुआ है। अच्छी तरह से उपयोग किया जाए, तो फ्रेमवर्क और एक वाहन इमेज API एक दूसरे को मजबूत बनाते हैं। नायव रूप से उपयोग किया जाए, तो वे एक ही बाइट्स को दो बार ऑप्टिमाइज़ करते हैं और इसके लिए बिल देती हैं। यह सेटअप है जो प्रोडक्शन में काम करता है।
एक ऑप्टिमाइज़र को जीतने दीजिए
Image component हर चीज को अपने पाइपलाइन के माध्यम से रीसाइज़ और रीएन्कोड करना चाहता है। एक पैरामीटराइज़्ड API से वाहन इमेज पहले से ही साइज्ड और पहले से ही WebP आती है, इसलिए डबल ऑप्टिमाइज़ेशन लेटेंसी और कंप्यूट जोड़ता है बिना किसी फायदे के। साफ पैटर्न: एपीआई से एक्सैक्ट वIDTH का अनुरोध करें, और लेआउट, लेजी लोडिंग और प्राथमिकता को रीप्रोसेसिंग के बिना हैंडल करने दें, या अपने रिमोट पैटर्न को संकुचित करें और जो पहले से ही ऑप्टिमल है उसे पास करें।
- एपीआई से हर ब्रेकपॉइंट के लिए रेंडर्ड वIDTH का अनुरोध करें
- इमेज होस्ट के लिए रिमोट पैटर्न एक बार सटीक रूप से कॉन्फ़िगर करें
- फिल या स्पष्ट डाइमेंशन का उपयोग करके एस्पेक्ट रेशियो बॉक्स को लॉक करें
- अबोव द फोल्ड हीरो के लिए प्राथमिकता रिजर्व करें, अन्य किसी के लिए नहीं
पेज टाइप के अनुसार रेंडरिंग रणनीति
कार साइटें डेटा ताज़गी के साथ स्वाभाविक रूप से विभाजित होती हैं। लाइव इन्वेंटरी के डिटेल पेज सर्वर रेंडरिंग चाहते हैं जिसमें कम रीवैलिडेशन, ताकि कीमत और उपलब्धता सच्ची रहे। कैटेगरी और लैंडिंग पेज लंबे स्टैटिक जीवन को सहन करते हैं, और उनके इमेज URL, जो स्थिर और पैरामीटराइज़्ड हैं, हर परत पर पूरी तरह से कैश होते हैं। इमेज सिस्टम रणनीतियों के बीच समान रहता है; केवल रीवैलिडेशन विंडो अलग होते हैं, जिससे मानसिक मॉडल छोटा रहता है।
गैलरी, ग्रिड और फोल्ड
तीन कार साइट सतहें फ्रेमवर्क प्राइमिटिव्स पर साफ़ मापती हैं। सर्च ग्रिड फिक्स्ड रेशियो सेल्स का उपयोग करता है जिसमें फोल्ड के नीचे लेज़ी लोडिंग, ठीक वैसा ही जैसा कि सर्च गाइड निर्देश देता है। डिटेल गैलरी अपनी पहली छवि को प्रायोरिटी के साथ प्रीलोड करता है और एंगल सेट को इंटरैक्शन तक टालता है। कंपेरिसन व्यू API से समान फ्रेमिंग पर भरोसा करता है, इसलिए बराबर साइज़ के सेल्स को प्रति छवि फिडलिंग की ज़रूरत नहीं है। यह कुछ भी चतुर नहीं है। यह सब एक बार निर्णय लेना और निर्णय को कंपोनेंट्स में एन्कोड करना है।
एक VehicleImage घटक जो होना चाहिए
फ्रेमवर्क के Image को एक बार ही लपेटें: स्थिर वाहन आईडी, एंगल, विड्थ हिंट और अल्ट टेक्स्ट के लिए प्रॉप्स, URL निर्माण अंदर, साइज़िंग और लोडिंग डिफ़ॉल्ट्स लागू। फिर हर सतह एक ही कंपोनेंट के माध्यम से वाहन रेंडर करती है, और जब आप एक पैरामीटर कन्वेंशन बदलते हैं, तो एक फ़ाइल बदलती है। एक फिक्स्ड रेशियो स्केलेटन और ब्रांडेड फॉलबैक मिस के लिए जोड़ें, और एज केस डिज़ाइन किए जाते हैं, न कि खोजे जाते हैं।
फ्रेमवर्क उन टीमों को पुरस्कृत करते हैं जो एक बार इमेज पॉलिसी निर्धारित करते हैं और इसे एन्कोड करते हैं, और उन टीमों को दंड देते हैं जो हर पेज के लिए इसे निर्धारित करते हैं।
नीचे के कैशिंग आर्किटेक्चर के लिए, कैशिंग रणनीति इस सेटअप के साथ सीधे जोड़ी जाती है, और React और Vue गाइड Next के अलावा स्टैक के लिए घटक पैटर्न को कवर करता है।
डिप्लॉय, कैश और स्थिर URL लाभ
एक अंतिम उत्पाद नोट: क्योंकि API के URL स्थिर और पैरामीटराइज़्ड हैं, वे आपके डिप्लॉय के बिना अपरिवर्तित रहते हैं, जिससे रिलीज़ के बीच CDN के कैश गर्म रहते हैं और फ्रेमवर्क के ऑप्टिमाइज़र को एक ऐसे कैटलॉग को पुनः प्रोसेस करने से बचाया जाता है जो परिवर्तित नहीं हुआ है। स्थानीय रूप से संग्रहीत संपत्तियों से माइग्रेट करने वाले टीम पहले डिप्लॉय के बाद अंतर देखते हैं: इमेज लेयर अब रिलीज़ का हिस्सा नहीं है, और बिल्ड टाइम और कैश हिट रेट दोनों इसे दर्शाते हैं।
