ऐसा लगता है कि लाइटहाउस 6 कुछ नए मेट्रिक्स का परिचय देता है और कुछ अन्य को वी 5 से हटाता है इसलिए स्कोर में बदलाव निश्चित रूप से होने की संभावना है। यह लेख बताता है कि क्या बदल गया है:

https://web.dev/lighthouse-whats-new-6.0/

स्कोर कैलकुलेटर के अंत में एक लिंक भी है जो स्कोर को तोड़ने और यह समझने के लिए उपयोगी है कि कौन से कारक सबसे अधिक योगदान दे रहे हैं।

https://googlechrome.github.io/lighthouse/scorecalc

मुझे लगता है कि वहाँ v6 में मुख्य धागा अन्तरक्रियाशीलता पर अधिक ध्यान केंद्रित है, इसलिए यदि आपकी साइट में बड़े जेएस बंडल शामिल हैं, तो संभवतः एक महत्वपूर्ण कारक है।

Yes @shanekenney , मैं जागरूक हूं, लेकिन वास्तव में यह नहीं जानता कि साइट के कुछ हिस्सों को हटाने के अलावा इसे कैसे कम किया जाए।

क्या आप भी gaysbyjs और विषय-यूआई साइटों पर प्रभाव देखते हैं? मैं यह जानने के लिए उत्सुक हूं / जानना चाहूंगा कि उनकी साइट पर वे कौन से अनुकूलन कर रहे हैं जिनके बारे में वे सोच रहे हैं, या यदि उन्होंने कुछ विशिष्ट कारण बताए हैं

यह मुद्दा बहुत अच्छा है, इसलिए हम समग्र लाइटहाउस / पेजस्पीड इनसाइट्स स्कोर और संभावित प्रतिगमन पर चर्चा कर सकते हैं जो हम v6 के साथ देख रहे हैं।

@kuworking ध्यान देने योग्य एक बात यह है कि lighthouse-metrics.com का उपयोग प्रतीत होता है _ "5.6 के लिए नेक्सस 5X" _ और 6.0 के लिए _ "एमुलेटेड मोटो जी 4" _ जो तुलना के लिए कुछ शोर भी जोड़ सकता है।

922 से अधिक साइटों का यह बेंचमार्क v5 में Gatsby साइट के लिए औसत प्रदर्शन स्कोर 75 है । मैं अपने स्थानीय नेटवर्क को अभी तक एक और परिवर्तनशीलता कारक बनने से रोकने के लिए होस्ट किए गए समाधानों का उपयोग करके एक त्वरित दृश्य करने की कोशिश करूंगा।

वर्तमान में (लाइटहाउस v5.6 / पेजस्पीड इनसाइट्स के साथ)

पीएसआई "फास्ट 3 जी" पर एक मोटो जी 4 पर चलता है। स्रोत

गैट्सबी का उपयोग करके बनाए गए कुछ "फ्लैग" साइट वास्तव में पेजस्पीड इनसाइट्स पर शानदार प्रदर्शन नहीं कर रहे हैं (जो अभी भी लाइटहाउस v5.6 का उपयोग कर रहा है। मैं मानता हूं - हर रन पर मानक परिवर्तनशीलता के अधीन, संभवतः 3x या 5x चल रहा है और औसत से अधिक मैट्रिक्स में वजन होगा ) ।

• gatsbyjs.org (मोबाइल 72/100, टीटीआई 9 एस) स्रोत
• reactjs.org (मोबाइल 62/100, टीटीआई 9.5s) स्रोत
• gatsbyjs.com (मोबाइल 77/100, टीटीआई 6.6) स्रोत

हालाँकि कुछ अन्य साइटें (और अधिकांश शुरुआत) पेजस्पीड इनसाइट्स पर बहुत अच्छा प्रदर्शन कर रही हैं:

• store.gatsbyjs.org (मोबाइल 99/100, TTI 2.5s) स्रोत
• thirdandgrove.com (मोबाइल 91/100, टीटीआई 4.0s) स्रोत

औसत टीटीआई ध्यान देने योग्य है - और जबकि वी 6 ने टीटीआई के समग्र वजन को 33% से 15% तक बदल दिया है और फर्स्ट सीपीयू आइडल गिरा दिया है, यह टीबीटी को 25% वजन के साथ जोड़ता है जो संभवतः स्कोर के एक प्रतिगमन को समझा सकता है जो आमतौर पर सिर्फ बोलने के कारण होता है समग्र जेएस पार्सिंग और निष्पादन।

लाइटहाउस v6 ( WebPageTest.org के साथ)

• यह _Moto G (gen 4), Moto G4 - Chrome_ पर WPT को _3G फास्ट (1.6mbps / 768kbps 150ms RTT) _ के कनेक्शन के साथ चलाता है। यह डिवाइस / नेटवर्क के एक मैच के जितना कि हम पीएसआई द्वारा उनके अंतर्निहित लाइटहाउस संस्करण को अपडेट करने से पहले प्राप्त कर सकते हैं।
• _Cromure Lighthouse Report_ को _Chromium_ के तहत जाँचना सुनिश्चित करें। मैंने पहली बार आगंतुक, पृष्ठ के पहले लोड पर गुंजाइश रखने के लिए बार-बार देखने को अक्षम किया है।

यहां परिणाम हैं, आप इसकी संख्या पर क्लिक करके लाइटहाउस रिपोर्ट देख सकते हैं। मैं उस रिपोर्ट से मान निकाल रहा हूं।

• gatsbyjs.org (72 -> 67/100, TTI 7.5s, TBT 2150ms) स्रोत
• reactjs.org (62 -> 66/100, टीटीआई 7.8s, टीबीटी 3520ms) स्रोत
• gatsbyjs.com (77 -> 66/100, टीटीआई 8.4s, टीबीटी 2440ms) स्रोत

हालांकि, निम्नलिखित दो साइटों पर प्रतिगमन को नोटिस करें:

• store.gatsbyjs.org ( 99 -> 54/100 , TTI 6.8s, TBT 1300ms) स्रोत
• thirdandgrove.com ( 91 -> 63/100 , टीटीआई 14s!, टीबीटी 1330ms) स्रोत

कुछ खुले प्रश्न मेरे पास हैं।

1. समग्र टीटीआई (और टीबीटी) को जेएस पार्सिंग + निष्पादन द्वारा समझाया गया है, या अन्य कारक हैं जो अन्तरक्रियाशीलता को नुकसान पहुंचा रहे हैं?
2. यदि ऐसा है, तो हम और अधिक आक्रामक हो सकते हैं (या तो डिफ़ॉल्ट रूप से गैट्सबी पर जैसे कि नवीनतम परिवर्तन जैसे कि दानेदार चंक्स को सक्षम करना , या कुछ प्रयोगात्मक झंडे के तहत) जब चोंच को बिल्डिंग किया जाए तो _only_ भेजें जो पहले लोड की जरूरत है (यानी ऐप को रोकें- [.h]] अतिरिक्त होने से .js)? यह भी अधिक मार्गदर्शन के साथ वेबपैक कॉन्फिगरेशन के साथ खेलने के तरीकों को प्रलेखित कर सकता है।
3. क्या मॉड्यूल / नामोड जैसे पैटर्न घटते आंशिक निर्जलीकरण ?
4. यह उच्च स्कोर को आगे बढ़ाने की दिशा में एक दूसरा कदम हो सकता है, लेकिन चूंकि FMP अब कोई कारक नहीं है, क्या LCP पर gatsby-image मदद या हानि हो रही है? ऊपर के रन पर store.gatsby.org का LCP 4.7 था!

(मैं उदाहरण के रूप में ऊपर दिए गए लिंक का उपयोग कर रहा हूं - अगर किसी को हटाए गए एक निश्चित लिंक को पसंद करेंगे तो मैं खुशी से संदेश को संपादित कर सकता हूं)

मेरी साइट (https://matthewmiller.dev/) बेहतर (~ 92 से ~ 95) प्राप्त हुई प्रतीत होती है, लेकिन कुछ नए परीक्षणों से कुछ चीजें सामने आती हैं जो शायद बेहतर हो सकती हैं।

उदाहरण के लिए अनावश्यक जावास्क्रिप्ट परीक्षण,
(पहला कॉलम आकार है, दूसरा कॉलम वह राशि है जो अनावश्यक है)

मुझे लगता है कि यह अन्य पृष्ठों के लिए आवश्यक वस्तुओं के कारण यहां शामिल है, इसलिए लोड करने योग्य-घटकों जैसी किसी चीज़ का उपयोग करने से थोड़ी मदद मिल सकती है।

मेरे लिए मुझे Largest Contentful Paint को समझने में बड़ी कठिनाइयां हो रही हैं, इस अर्थ में कि मुझे बिना जाने क्यों बहुत बड़े मूल्य मिल रहे हैं, और रिपोर्ट में मूल्य के बीच एक विसंगति देखकर (उदाहरण के लिए 7.4 s, और LCP लेबल जो Performance - ViewTrace टैब (~ 800%) में प्रकट होता है

मैं देख सकता हूं कि स्टार्टर में कुछ ऐसा ही लगता है https://parmsang.github.io/gatsby-starter-ecommerce/

अपडेट के रूप में - ऐसा लगता है कि पेजस्पीड इनसाइट्स ने लाइटहाउस V6 को चलाने के लिए अपडेट को नरम कर दिया है (यह अभी तक नहीं हो सकता है)।

Https://gatsbyjs.org/ टेस्ट करने के लिए लिंक । वर्तमान में परिणाम 60 के दशक से लेकर 80 के दशक के मध्य तक भिन्न हो रहे हैं, मुख्य रूप से टीबीटी और टीटीआई के मूल्यों पर निर्भर करता है।

@ व्यवसायिक लाइटहाउस v6 के साथ एक मुद्दा हो सकता है जो कि गैट्सबी-छवि को पहचानता है।

वेबदेव के अनुसार

छवि तत्वों के लिए जिन्हें उनके आंतरिक आकार से आकार दिया गया है, जो आकार रिपोर्ट किया जाता है वह या तो दृश्य आकार या आंतरिक आकार है, जो भी छोटा है।

मेरे मामले में, मुझे लगता है कि प्रकाशस्तंभ दृश्य आकार का सम्मान नहीं कर रहा है।

और यहां प्रश्न में छवि है

यह आंतरिक आकार के लिए लेखांकन हो सकता है जो कि 3000 पिक्सेल है इसलिए मेरे लिए 13s LCP है।

@ daydream05 मेरे पास समान सिद्धांत और निष्कर्ष थे और इसलिए मैंने छवियों के बिना अपने पृष्ठों का परीक्षण किया और अभी भी एक पागल लंबे एलसीपी (10-12 सेकेंड) था। मेरे पास अपने प्रोजेक्ट में बहुत कुछ चल रहा है इसलिए यह अन्य चर भी हो सकता है, लेकिन मैं उत्सुक हूं यदि आपने किसी पाठ सामग्री के साथ पृष्ठ का परीक्षण किया है और अभी तक कोई चित्र नहीं है।

हाल ही में एक 100 से 79 ~ https://dougsilkstone.com/ से गिरा दिया गया। 90 टैग Google टैग प्रबंधक (और Google Analytics) तक के जंप हटा दिए जाते हैं।

मैं और अधिक निष्कर्षों पर रिपोर्ट करूंगा क्योंकि मैं चीजों का परीक्षण करता हूं।

संपादित करें: जब गैट्सबी-प्लगइन-वेब-फॉन्ट-लोडर (प्रीलोड-फॉन्ट कैश का उपयोग करके) से टाइपकाट लोड किए गए फ़ॉन्ट को हटाते समय 100 हिट करें।

जीटीएम पूरी तरह से मेरी परियोजना को प्रभावित कर रहा है, लेकिन जब मैं इसे हटाता हूं तो यह बदलाव का इतना कठोर नहीं है (एलएच 6 के बाद उप 50s स्कोर पर 5-10 अंक)। मुझे अभी भी और परीक्षण करने की जरूरत है लेकिन मैं इसे वहां से बाहर फेंकना चाहता था।

@ जिमीडालसेलेवेलैंड दिलचस्प! मेरे पास एक अन्य साइट भी है जहां स्क्रीन आई जस्ट टेक्स्ट है और यह LCP के मुख्य कारण के रूप में हीरो टेक्स्ट को दोष दे रहा है। और एलसीपी केवल जो कुछ भी देखने के लिए है, जिसका कोई मतलब नहीं है। कैसे एक पाठ एक समस्या का बड़ा हो सकता है।

@dougwithseismic मैं

मुझे लगता है कि जेएस फ्रेमवर्क पर लाइटहाउस वी 6 वास्तव में कठिन है क्योंकि इस आधार पर कि उन्होंने स्कोर का भार कैसे बदला। (अवरुद्ध समय पर अधिक ध्यान केंद्रित) और Gatsby साइटों में पुनर्जलीकरण और अन्य चीजों के कारण ऐतिहासिक रूप से कम स्क्रिप्ट मूल्यांकन / मुख्य धागा स्कोर हैं।

@dougwithseismic आपने स्टाइलशीट का उपयोग किए बिना टाइपकाइट फ़ॉन्ट कैसे लिंक किया?

मुझे एक समान अनुभव हो रहा है, लाइटहाउस 5.7 के साथ मेरा प्रदर्शन स्कोर लगभग 91 था, हालांकि लाइटहाउस 6 ने नाटकीय रूप से मेरा प्रदर्शन स्कोर लगभग 60 पर गिरा दिया है।

हाल ही में एक 100 से 79 ~ https://dougsilkstone.com/ से गिरा दिया गया। 90 टैग Google टैग प्रबंधक (और Google Analytics) तक के जंप हटा दिए जाते हैं।

मैं और अधिक निष्कर्षों पर रिपोर्ट करूंगा क्योंकि मैं चीजों का परीक्षण करता हूं।

संपादित करें: जब गैट्सबी-प्लगइन-वेब-फॉन्ट-लोडर (प्रीलोड-फॉन्ट कैश का उपयोग करके) से टाइपकाट लोड किए गए फ़ॉन्ट को हटाते समय 100 हिट करें।

मेरे पास ये प्लगइन्स भी स्थापित नहीं हैं, लेकिन मेरा मोबाइल स्कोर 90+ से गिरकर 60 ~ 70+ हो गया है

मुझे भी। कई साइटों पर 90ish से 60ish तक भारी गिरावट।

लगभग 30+ अंकों का +1 ड्रॉप

क्या कोई इसे संबोधित कर रहा है? ऐसा लगता है कि अगर यह बेहतर स्कोर आउट-द-बॉक्स वितरित नहीं करता है तो अगले पर गैट्सबी का उपयोग करने का कोई मतलब नहीं है।

क्या कोई इसे संबोधित कर रहा है? ऐसा लगता है कि अगर यह बेहतर स्कोर आउट-द-बॉक्स वितरित नहीं करता है तो अगले पर गैट्सबी का उपयोग करने का कोई मतलब नहीं है।

क्या आपके पास नेक्स्ट से कोई नंबर है?

मुझे आश्चर्य हो रहा है कि क्या ये स्कोर तेज जाले के लिए नए सामान्य हैं (जो स्थिर नहीं हैं, जेएस-मुक्त और संभावना भी छवि-मुक्त हैं)

क्या आपके पास नेक्स्ट से कोई नंबर है?

https://nextjs.org/ का स्कोर 85 है, जिसमें सबसे बड़ा कंटेंटफुल पेंट (3.8) और फर्स्ट कंटेंटफुल पेंट (2.8) दोनों मुख्य अपराधी हैं। इसमें "अप्रयुक्त जेएस" का एक गुच्छा भी है। यह लाइटहाउस 5.7.1 में ~ 95 से नीचे है। यह "केवल" लगभग 10 अंकों की एक बूंद है, जबकि गैट्सबी साइटों को कई बिंदुओं से दो बार खोना लगता है।

मैं इस दुनिया के लिए काफी नया हूं, लेकिन मेरी गैट्सबी साइट के लगभग 25 अंक खोने के बाद मैं इस मुद्दे का अनुसरण कर रहा हूं जब npm के साथ लाइटहाउस 6.0.0 के साथ परीक्षण किया गया। दिलचस्प बात यह है कि अगर मैं npm लाइटहाउस के बजाय पेजस्पीड अंतर्दृष्टि का उपयोग कर रहा हूं, तो मेरी साइट लगभग ~ 99 पर वापस आ जाती है। जबकि gatsbyjs.org को पेजस्पीड इनसाइट्स पर ~ 70 मिलता है, लेकिन npm लाइटहाउस के साथ ~ 84। मुझे लगता है कि कहीं न कहीं कुछ ट्विक किया जा रहा है? उन सभी को 'अप्रयुक्त जेएस' चेतावनियाँ मिल रही हैं

क्या कोई इसे संबोधित कर रहा है? ऐसा लगता है कि अगर यह बेहतर स्कोर आउट-द-बॉक्स वितरित नहीं करता है तो अगले पर गैट्सबी का उपयोग करने का कोई मतलब नहीं है।

क्या आपके पास नेक्स्ट से कोई नंबर है?
मुझे आश्चर्य हो रहा है कि क्या ये स्कोर तेज जाले के लिए नए सामान्य हैं (जो स्थिर नहीं हैं, जेएस-मुक्त और संभावना भी छवि-मुक्त हैं)

एक Next.js वेबसाइट -> https://masteringnextjs.com/ 77 मोबाइल स्कोर। बहुत सारे "अप्रयुक्त जेएस"।

मुझे लाइटहाउस-मेट्रिक्स https://lIIIouse-metrics.com/one-time-tests/5edfbb1cf858500080125f7 के साथ बेहतर स्कोर दिखाई देता है

लेकिन मुझे वहां छवियां दिखाई नहीं देती हैं, और मेरे अनुभव में छवियों को एक उच्च (और वैध आईएमओ) प्रभाव पड़ता है

फिर भी, gatsbyjs.org के पास न तो चित्र हैं और इसका स्कोर (अपेक्षाकृत) खराब https://lIIIouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff ( @cbbp उदाहरण के साथ तुलना में) है

आइए देखें कि गैट्सबी देव इस बारे में क्या सोचते हैं

कुछ मोड़ के साथ, साइट शीर्ष स्कोर पर वापस आ गई है।

मुझे ऐसा लगता है कि Google का लक्ष्य गोल पोस्ट को और अधिक बढ़ाना है
प्रदर्शन के बारे में सख्त - विशेष रूप से FCP।

हमारी साइटें किसी भी तरह से धीमी नहीं हैं, मोर्सो को केवल अलग-अलग के साथ आंका जा रहा है
मानदंड। मैं इस पर एक one मदद करूंगा

Tue पर, 9 जून 2020, 18:48 kuworking, सूचनाएं @github.com ने लिखा:

क्या कोई इसे संबोधित कर रहा है? लगता है जैसे गैट्सबी ओवर का उपयोग करने का कोई मतलब नहीं है
अगर यह बेहतर स्कोर आउट-द-बॉक्स वितरित नहीं करता है तो अगला।

क्या आपके पास नेक्स्ट से कोई नंबर है?
मैं सोच रहा हूं कि क्या ये स्कोर फास्ट वेब्स (कि) के लिए नया सामान्य है
स्थिर नहीं हैं, JS-free और संभवतः छवि-मुक्त भी हैं)

एक Next.js वेबसाइट -> https://masteringnextjs.com/ 77 मोबाइल स्कोर। बहुत
"अप्रयुक्त जेएस"।

मैं लाइटहाउस-मेट्रिक्स के साथ बेहतर स्कोर देखता हूं
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

लेकिन मुझे वहां भी चित्र नहीं दिखते हैं, और मेरे अनुभव में छवियां लगती हैं
एक उच्च (और वैध IMO) प्रभाव है

फिर भी, gatsbyjs.org के पास न तो चित्र हैं और इसका स्कोर (अपेक्षाकृत) खराब है
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
( @cbdp https://github.com/cbdp उदाहरण के साथ तुलना में)

आइए देखें कि गैट्सबी देव इस बारे में क्या सोचते हैं

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-64142846463 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
।

V6 से परिणाम की तुलना करने के लिए बस इस उपयोगी कैलकुलेटर को ड्रॉप करना चाहता था: https://googlechrome.github.io/lighthouse/scorecalc/

पेजस्पीड इनसाइट्स के माध्यम से उपयोग करने पर भी लाइटहाउस स्कोर आम तौर पर बहुत भिन्न होता है। उदाहरण के लिए, https://www.gatsbyjs.org/ के लिए मुझे 5 रनों के बाद 64 से 88 मोबाइल प्रदर्शन से सब कुछ प्राप्त हुआ। इसलिए, इस समस्या को ट्रैक करने के लिए कैलकुलेटर एक ही रन पर अलग-अलग भार के परिणामों को देखने के लिए उपयोगी हो सकता है (नोट: जैसा कि मैट्रिक्स थोड़ा अलग हैं, एफएमपी जैसे कुछ मूल्यों को पूर्व माप का उपयोग करके ग्रहण किया जाना चाहिए)।

पुनश्च: यहाँ मेरे पास gatsbyjs.org के लिए पेजस्पीड इनसाइट्स से दो रन की तुलना है:
रन 1 - वी 6: 67 - वी 5: 85
रन 2 - वी 6: 78 - वी 5: 87
सबसे बड़ा प्रभाव नए मीट्रिक "टोटल ब्लॉकिंग टाइम" के कारण होता है, जो दोनों रन में 70 के स्कोर से नीचे है और 25% वजन भी है।

हां, @Pyrax : LCP (सबसे बड़ा कंटेंटफुल पेंट) और TBT को जोड़ने के लिए Lighthouse v6 में प्रत्येक का वजन 25% है । इसलिए हमने उन लोगों को संबोधित करने के प्रयासों पर ध्यान केंद्रित किया। हमें मिला:

LCP

• लोड पर ट्रिगर हो सकने वाले किसी भी एनिमेशन को हटाना (जैसे कुकी। बैनर)।
• Gatsby-img के tracedSVG बदलने से हमें थोड़ी मदद मिली, क्योंकि हमारे पास अधिकांश पृष्ठों पर बड़े नायक चित्र हैं। (यह निश्चित नहीं है कि वास्तव में, आगे की जांच के बिना। UX थोड़ा बहुत सुधार कैसे करता है।)

TBT

• एक लंबे शॉट से, Gatsby के बंडलिंग से Unused JS लंबे शॉट से सबसे बड़ा कपल ( वेबडायड के डॉक्स समर्थित) लगता है। पृष्ठ-स्तरीय वृक्षारोपण निश्चित रूप से यहां सुधारा जा सकता है?

लगता है कि हाल ही में किए गए इस लाइटहाउस अपडेट में सभी के पूर्ण स्कोर खराब हो गए हैं, जिसमें उनका अपना भी शामिल है:

मेरा एकमात्र गैट्सबी साइट जो वास्तव में तिरोहित नहीं किया गया है वह एक साइट है जो मूल रूप से एक सिंगल पेज है और 99% html की तरह है। लेकिन यहां तक ​​कि एक 5-10 5-10 के बारे में गिरा दिया।

मैं हालांकि अधिकांश लोगों का उलटा देख रहा हूं, यानी क्रोम ब्राउज़र में लाइटहाउस अभी भी मेरी साइट के लिए अच्छा स्कोर दिखा रहा है, लेकिन जब पेजस्पीड इनसाइट्स पर चला गया तो यह सही स्कोर 20-30 अंक हो गया ... शायद मेरा क्रोम लाइटहाउस संस्करण पीछे है? Chrome नवीनतम है, यह सुनिश्चित नहीं है कि अंतर्निहित लाइटहाउस संस्करण की जांच कैसे करें ...

लगता है कि हाल ही में किए गए इस लाइटहाउस अपडेट में सभी के पूर्ण स्कोर खराब हो गए हैं, जिसमें उनका अपना भी शामिल है:

मेरा एकमात्र गैट्सबी साइट जो वास्तव में तिरोहित नहीं किया गया है वह एक साइट है जो मूल रूप से एक सिंगल पेज है और 99% html की तरह है। लेकिन यहां तक ​​कि एक 5-10 5-10 के बारे में गिरा दिया।

मैं हालांकि अधिकांश लोगों का उलटा देख रहा हूं, यानी क्रोम ब्राउज़र में लाइटहाउस अभी भी मेरी साइट के लिए अच्छा स्कोर दिखा रहा है, लेकिन जब पेजस्पीड इनसाइट्स पर चला गया तो यह सही स्कोर 20-30 अंक हो गया ... शायद मेरा क्रोम लाइटहाउस संस्करण पीछे है? Chrome नवीनतम है, यह सुनिश्चित नहीं है कि अंतर्निहित लाइटहाउस संस्करण की जांच कैसे करें ...

ऑडिट के निचले भाग में लाइटहाउस संस्करण दिखाया गया है।

@dylanblokhuis आह, हाँ वहाँ है। मैं 5.7.1 पर हूं, क्या v6 को अभी तक क्रोम में शिप नहीं किया गया है?

@dylanblokhuis आह, हाँ वहाँ है। मैं 5.7.1 पर हूं, क्या v6 को अभी तक क्रोम में शिप नहीं किया गया है?

यह नहीं। वैसे भी अब तक नहीं। यदि आप नवीनतम चाहते हैं, तो आप इसे npm से इंस्टॉल कर सकते हैं और फिर lighthouse https://yoursite.com --view और आपको अपना स्कोर उसी स्वरूप में प्राप्त होगा जैसे आप Chrome ऑडिट के साथ उपयोग करते हैं :)

किसी और के लिए, जिसने स्कोर में एक बड़ा हिट लिया, # 24866 भी प्रासंगिक हो सकता है। इसमें एक उल्लेखनीय रूप से बहुत महत्वपूर्ण बदलाव किया गया है कि कैसे गैट्सबी चैंकिंग सौंप रहा है। जबकि परिवर्तन निश्चित रूप से बहुत कुछ समझ में आता है, हमारे लिए कम से कम, इस बदलाव के परिणामस्वरूप कोड है जो कि commons और app chunks में केंद्रित किए जा रहे हैं। मतलब एक काफी बड़ा js लोड / पार्स।

यहां सबसे संबंधित बात यह है कि ये मैट्रिक्स पेज रैंक को अपेक्षाकृत जल्द ही प्रभावित करने जा रहे हैं।

मैंने सभी तृतीय-पक्ष अनुरोध (टैग प्रबंधक / टाइपेकिट / पिक्सेल / एनालिटिक्स / ReCaptcha) छीन लिए हैं और यह केवल अपेक्षाकृत छोटे स्कोर को बढ़ावा दे रहा है, इसलिए कुछ और खेल में है।

इसके अलावा, जो कोई भी लाइटहाउस 6 को स्थानीय रूप से चलाना चाहता है, वह अभी क्रोम कैनरी में उपलब्ध है और जुलाई में कुछ समय के लिए क्रोम में शिप किया जाता है।

पहला: मैं एक Google इंजीनियर के साथ संपर्क में आया जो web.dev पर काम कर रहा है और इस बारे में पूछा। यकीन नहीं है कि अगर किसी भी अधिक स्पष्टीकरण के लिए नेतृत्व करेंगे, लेकिन वे मदद करने के इरादे से लग रहे हैं। जब मैंने उनके साथ चैट करने में कामयाबी हासिल की, तो मैं उसका अनुसरण करूंगा

मेरा प्रदर्शन स्कोर 94-99 से बढ़कर 40-55 हो गया। 😢

मेरी वेबसाइट के लिए सबसे बड़ा विवादास्पद पेंट ज्यादातर बड़ी छवियों वाले पृष्ठों पर लागू होता है। किसी कारण के लिए, यह कह रहा है कि छवियों को लोड होने में 14 सेकंड लग रहे हैं।

यदि आप कम से कम गैट्सबी स्टार्टर साइटों को खोलते

यहाँ पहले दो शुरुआत हैं जिन्हें मैंने कई छवियों के साथ देखा है:

ghost.gatsby.org :

gcn.netlify.app :

हालांकि, गैट्सबी स्टार्टर ब्लॉग में 98 प्रदर्शन हैं (दी गई है, यह सिर्फ कुछ पाठ के साथ एक सुपर न्यूनतम पृष्ठ है):

gatsbyjs.com :

Chrome में पुराने स्कोर की तुलना नए स्कोर से करें

आप अभी भी CLI का उपयोग किए बिना पुराने बनाम नए लाइटहाउस विधि स्कोर की तुलना कर सकते हैं। मुझे यह देखने के लिए उपयोगी है कि क्या बदल गया है।

पुराने लाइटहाउस परीक्षण देखें

पुराने लाइटहाउस स्कोर देखने के लिए, ब्राउज़र टूलबार के बजाय अपने क्रोम डेवलपर टूल से लाइटहाउस क्रोम एक्सटेंशन चलाएं।

नए लाइटहाउस परीक्षण देखें

अपने क्रोम एक्सटेंशन बार से आइकन पर क्लिक करें।

मेरा पेज बदल जाता है

ये वही दो पृष्ठ हैं जिनके सटीक पृष्ठ मेरे पास हैं:

पुराना लाइटहाउस (क्रोम देव टूल्स के माध्यम से)

नया प्रकाश स्तंभ (एड्रेस बार पर क्रोम एक्सटेंशन के माध्यम से)

🤷♂️

@nandorojo छवियों के साथ मेरी धारणा यह है कि अनुकरण वास्तव में धीमी गति से किया जाता है और वहाँ, छवियों को प्रस्तुत होने में लंबा समय लगता है

चूंकि छवियों को हटाने का विकल्प हमेशा संभव नहीं होता है, शायद इस प्रकार के पृष्ठों के लिए ये 70 के स्कोर सामान्य हैं

और, उनके लोडिंग में देरी करने का विकल्प ताकि उपयोगकर्ता अपनी बातचीत जल्द ही शुरू कर सके, ट्रिक (मेरे मामले में) नहीं लगती है

अरे, देर से जवाब के लिए खेद है। मैंने लाइटहाउस पर काम किया है, मैं जितना अच्छा कर सकता हूं समझाने की कोशिश करूंगा।

क्रोम देवों ने "वेब विटल्स" प्रकाशित किया है, एक स्वस्थ साइट के लिए आवश्यक मीट्रिक। इसमें कई मेट्रिक्स होते हैं लेकिन कोर सबसे बड़े कंटेंटफुल पेंट (LCP) , फर्स्ट इनपुट देरी (FID) और कम्युलेटिव लेआउट शिफ्ट (CLS) होते हैं । लाइटहाउस एफआईडी जैसे उपकरणों के लिए कुल अवरोधक समय (टीबीटी) के साथ स्वैप किया जाता है।

लाइटहाउस v6 भी इन मैट्रिक्स को ध्यान में रखता है और स्थानांतरित हो गया है। इसका मतलब यह नहीं है कि Gatsby धीमा है। यह हो सकता है कि कुछ अलग अनुकूलन आवश्यक हैं।

इस तरह से चीजें बदलीं:

यदि आप LCP के बारे में अधिक जानना चाहते हैं तो आपको https://www.youtube.com/watch?v=diAc65p15ag चेकआउट करना चाहिए

तो चलिए बात करते हैं गैट्सबी की। गैट्सबी खुद अभी भी बहुत तेज है और हम इसे और भी बेहतर बना रहे हैं। हम नए एपीआई के एमडीए, कंटेंटफुल के समृद्ध पाठ जैसे पेज बिल्डरों का निर्माण कर रहे हैं, ... बंडल को भी अनुकूलित कर सकते हैं। आपके LCP को अनुकूलित करके बहुत कुछ किया जा सकता है। सुनिश्चित करें कि फोंट और चित्रों का उपयोग करते समय, वे आलसी लोड नहीं किए जाते हैं और जितनी जल्दी हो सके लोड होते हैं। इन परिसंपत्तियों को आपकी साइट के समान मूल से लोड किया जाना चाहिए, उन्हें सीडीएन से लोड नहीं किया जाना चाहिए।

अफसोस की बात है कि टीबीटी हल करने के लिए एक कठिन समस्या है और ऐसा कुछ है जिसके लिए रिएक्ट अनुकूलन नहीं करता है। यदि आप टीबीटी को छोड़ना चाहते हैं, तो आपको चेकआउट उपदेश देना चाहिए। Preact के पास React के समान API है लेकिन एक छोटा जावास्क्रिप्ट पदचिह्न है। वे चीजों को अलग तरह से करते हैं लेकिन रिएक्ट घटक संगत हैं। आप इसे gatsby recipes preact चलाकर इंस्टॉल करते हैं।

Somethings मैंने देखा जब gatsbyjs.com और gatsbyjs.org को प्रोफाइल कर रहा है, तो यह है कि हमें Google एनालिटिक्स को लोड करना चाहिए, आदि कुछ समय बाद हम अब यह सुनिश्चित करने के लिए करते हैं कि यह टीबीटी का हिस्सा न बने।

यदि हम एनालिटिक्स और जीटीएम को स्थगित करके और निश्चित रूप से फोंट लोड करके .com पर देखते हैं तो हम पहले से ही +17 का सुधार देख सकते हैं। यदि हम मिश्रण में उपदेश जोड़ते हैं तो हम +6 देखते हैं।

हम .org के लिए भी ऐसा कर सकते हैं, हम 63 के स्कोर पर शुरू करते हैं। LCP और TBT के कुछ अनुकूलन के साथ हम 75 तक पहुँच सकते हैं।

मुझे यकीन नहीं है कि हमें इस मुद्दे पर क्या करना चाहिए। मुझे लगता है कि हम इसे बंद कर सकते हैं क्योंकि हमारे यहां और बहुत कुछ नहीं है। आप सब क्या सोचते हैं?

अतिरिक्त जानकारी के लिए @wardpeet Ty।

हम इस मामले में एक बड़े गैट्सबी प्रोजेक्ट पर खुदाई कर रहे हैं जो हमारे पास कंटेंटफुल का उपयोग करता है और हमारे लिए कई साइटों पर उपयोग किया जाएगा (गैट्सबी थीम बहुत बढ़िया हैं)। मैं इस मामले में कुछ निष्कर्षों को साझा करूंगा जो किसी और के लिए उपयोगी हैं।

1. हमारे पास एक ऐसी स्थिति है जो सुपर कॉमन नहीं हो सकती है, लेकिन मैंने यह विश्वास करने के लिए पर्याप्त देखा है कि यह या तो अद्वितीय नहीं है, जहां हमें कंटेंटफुल और .find से आने वाली छवियों को हथियाने के लिए useStaticQuery का उपयोग करना पड़ा। पहचानकर्ता द्वारा .find एक। हम हमेशा से जानते थे कि यह गलत था, लेकिन इसके लिए विशेष रूप से दंडित नहीं किया गया था जब तक कि साइट के पैमाने में 300+ चित्र नहीं बढ़े और एलएच 6 के बारे में आया और हमें स्मैक दिया।

इसका कारण यह है क्योंकि छवियां रिच टेक्स्ट एम्बेड का हिस्सा हैं, और हम पृष्ठ क्वेरी स्तर पर उनके लिए रेखांकन नहीं कर सकते हैं (यह अनिवार्य रूप से एक जसन फ़ील्ड है जिसमें सामग्री को पार्स करने के लिए पैकेज हैं)। वेबपैक बंडल एनालाइज़र का उपयोग करते समय, हमने एक विशाल JSON फ़ाइल (लगभग 720 KB) पर ध्यान दिया और इसे उस क्वेरी से डेटा होने के लिए नीचे ट्रैक किया, जिसे एक टेम्पलेट में समूहीकृत किया गया था जिसे हम वेबपैक द्वारा अधिकांश पृष्ठों के लिए उपयोग करते हैं। इसका मतलब यह था कि हमारी साइट पर आने वाला प्रत्येक उपयोगकर्ता इसे पूरे पृष्ठ टेम्पलेट के लिए चंक के हिस्से के रूप

हमारे हिस्से में बड़े वूशी, लेकिन अगर कोई और बड़े स्थिर प्रश्न कर रहा है (जो कि आप निश्चित रूप से आकार को सिकोड़ने के लिए मापदंडों को पारित नहीं कर सकते हैं) सुनिश्चित करें कि आप उन स्थितियों के लिए बाहर देखते हैं और अपने बंडल विखंडू पर नजर रखते हैं।

1. हम आज की तारीख में loading का उपयोग करके उन छवियों पर Gatsby छवि के लिए कुछ सफलता प्राप्त कर चुके हैं जो कि गुना से ऊपर हैं (हमारे लिए हीरो चित्र)। हम सबसे बड़े कंटेंटफुल पेंट पर काम करने की कोशिश कर रहे हैं और इससे कुछ शुरुआती परीक्षणों में अच्छे परिणाम मिले हैं। एक महत्वपूर्ण हिस्सा है जो मुझे लगभग याद आ गया है: यदि आप अपनी सर्वोच्च छवि के लिए loading="eager" सेट करते हैं, तो आप fadeIn={false} उस छवि के लिए सेट करना चाह सकते हैं क्योंकि बेस 64 और पूरी तरह से लोड के बीच संक्रमण छवि में समय लगता है जो LCP को विलंबित करता है।

यहाँ प्रॉप्स का दस्तावेज़ीकरण किया जा रहा है और मैं fadeIn बारे में नोट कर रहा हूँ, नीचे है: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

मैं स्क्रीनशॉट साझा करना चाहता हूं, लेकिन मुझे नहीं पता कि मुझे क्षमा करने की अनुमति है या नहीं। यदि आप क्रोम devtools का उपयोग करते हैं और प्रदर्शन पैनल को देखते हैं, तो आपको FP, FCP, FMP और LCP के लिए "टाइमिंग" पंक्ति के तहत अच्छे छोटे टैग दिए जाते हैं। जब हमने पहली छवि को गंभीर रूप से लोड करने के लिए स्विच किया, तो हमने न केवल ~ 8-10 प्रदर्शन स्कोर में वृद्धि देखी, बल्कि आप एफएमसीपी के तुरंत बाद एक या इसके बाद मेरे मामले में LCP टैग लोड देख सकते हैं।

आशा है कि किसी को भी इस समस्या निवारण में मदद करता है, और सभी को धन्यवाद जो अब तक जवाब दिया है।

Somethings मैंने देखा जब gilingbyjs.com और gatsbyjs.org को प्रोफाइल कर रहा है, तो हमें Google एनालिटिक्स को लोड करना चाहिए, आदि कुछ समय बाद हम यह सुनिश्चित करने के लिए जानते हैं कि यह टीबीटी का हिस्सा नहीं है।

@wardpeet आप एनालिटिक्स और GTM को कैसे स्थगित कर रहे हैं?

आपके जवाब के लिए @wardpeet धन्यवाद। यह उपयोगी है। शायद इस मुद्दे से सबसे अच्छा आउटपुट कुछ दस्तावेज होगा जो यह बताता है कि नए लाइटहाउस में प्रत्येक मैट्रिक्स के लिए कैसे अनुकूलित किया जाए। मुझे विश्वास है कि हमारी साइट उपयोगकर्ताओं के लिए तेजी से महसूस करती है और यह कि गैट्सबी खुद वास्तविक उपयोगकर्ताओं के लिए साइट का अनुकूलन करने का एक बड़ा काम कर रहा है। हालाँकि, यदि Google के वेब फ़ाइनल पेज रैंक को सूचित करना शुरू करने जा रहे हैं, तो एक अच्छा लाइटहाउस स्कोर प्राप्त करना अधिकांश साइटों के लिए महत्वपूर्ण हो जाता है।

@ जिमीडालेक्लेवलैंड में हमें एक समान समस्या थी जहाँ हमें एक संसाधन के सभी मदों में लोड करने की आवश्यकता थी ताकि हम एक फिल्मकार को कॉन्फ़िगर करने के लिए मार्कडाउन के भीतर से डेटा का उपयोग कर सकें (यानी हम ग्राफक्यूएल का उपयोग करके फ़िल्टर नहीं कर सके) और विभिन्न प्रस्तुतियों का उपयोग करके अनुकूलित किया गया ( फ़िल्टरिंग के लिए सभी संसाधनों को लोड करते समय एक पूर्ण संसाधन बनाम लोड करते समय बहुत छोटे क्षेत्र)। यह JSON द्वारा हमारे बहुत कम कर दिया और इसलिए हमारे बंडल का आकार।

@ शैलियों को आपको Analytics के लोड में देरी से सावधान रहने की आवश्यकता है क्योंकि इसका मतलब यह हो सकता है कि आपके आँकड़े अधूरे हैं। उदाहरण के लिए इसका मतलब यह हो सकता है कि आपकी रिपोर्ट की गई उछाल-दर सटीक नहीं है। कुछ स्क्रिप्ट्स हैं जो मार्केटिंग हमें देरी नहीं करने देंगी (पिक्सेल, एनालिटिक्स, हॉटज़र और इसलिए टैग मैनेजर), लेकिन अन्य, जैसे कि इंटरकॉम ठीक हैं और एक सार्थक अनुकूलन हैं। इन लिपियों में देरी करने के संदर्भ में, तीसरे पक्ष द्वारा आपूर्ति की जाने वाली स्क्रिप्ट आमतौर पर एसिंक्स को लोड करती है, लेकिन यह अकेले पर्याप्त नहीं है। आपको संभवतः इन लिपियों को अपने साथ बदलने की आवश्यकता होगी। Window.load के लिए सुनो, फिर डाउनलोड को ट्रिगर करें। आपको सावधानी बरतने की ज़रूरत है क्योंकि कुछ स्क्रिप्ट विंडो.लोड पर निर्भर करती हैं, और यदि आपने इसे स्क्रिप्ट को लोड करने के लिए उपयोग किया है, तो यह फिर से फायर नहीं करेगा, इसलिए आपको इन्हें मैन्युअल रूप से इनिशियलाइज़ करना होगा। इंटरकॉम उदाहरण के लिए हम:

• इंटरकॉम द्वारा आपूर्ति की गई <script>...</script> की डिगॉल्ट को हटा दिया गया।
• window.load लिए एक श्रोता जोड़ा
• इस श्रोता के भीतर एक संक्षिप्त विलंब जोड़ा
• एक संशोधित संस्करण इंटरकॉम की डिफ़ॉल्ट स्क्रिप्ट को ट्रिगर किया गया है जो उनके काम को पूरा करता है।
• जब स्क्रिप्ट भरी हुई थी तब देखने के लिए मतदान हुआ (इंटरकॉम एक विश्वसनीय घटना प्रदान नहीं करता है)
• मैन्युअल रूप से उनकी स्क्रिप्ट को इनिशियलाइज़ किया गया है (जो कि उनके डिफ़ॉल्ट स्क्रिप्ट द्वारा page.load पर किया गया था)।

बहुत उपयोगी अंतर्दृष्टि के लिए @wardpeet धन्यवाद!

इस समाधान के बारे में:

सुनिश्चित करें कि फोंट और चित्रों का उपयोग करते समय, वे आलसी लोड नहीं किए जाते हैं और जितनी जल्दी हो सके लोड होते हैं। इन परिसंपत्तियों को आपकी साइट के समान मूल से लोड किया जाना चाहिए, उन्हें सीडीएन से लोड नहीं किया जाना चाहिए।

यह कैसे gatsby छवि के खिलाफ काम नहीं करेगा? इसके अलावा, अधिकांश सीएमएस सर्वर पर छवि परिवर्तन को संभालते हैं और अपने स्वयं के सीडीएन में होस्ट किए जाते हैं। (जो एक अच्छी बात है, imo)। लेकिन अगर हम इसे अपनी साइट में होस्ट करते हैं, तो क्या यह भी प्रतिकूल नहीं होगा?

@Undistraction ने जो कहा, उसे पेज रैंकिंग अपडेट में इसे शामिल कर रहे हैं।

@ जिमीडलसेलवेलैंड मुझे उस क्वेरी हैक के बिना विवादास्पद समृद्ध पाठ के अंदर गैट्सबी छवि के साथ काम करने का एक तरीका मिला! यहां जिन्न है । कोड को gatsby-source-contentful से चिपकाया गया था। मूल रूप से आप GQL के बाहर विवादास्पद तरल पदार्थ या निश्चित प्रॉप्स उत्पन्न कर सकते हैं। जो विवादास्पद समृद्ध पाठ के लिए एकदम सही है।

मैंने एक पुल अनुरोध भी बनाया है ताकि हम gatsby-source-contentful से सीधे API तक पहुंच सकें।

कुछ बस मेरे लिए जोड़ नहीं है। मैंने प्रति पृष्ठ एक छवि के बारे में एक बहुत ही सरलीकृत वेबसाइट का निर्माण किया है, Im gatsby- छवि के बिना छवियों के लिए एसवीजी का उपयोग करते हुए, मैंने Google विश्लेषिकी को हटाने की भी कोशिश की और इससे बहुत अंतर नहीं पड़ा, मेरा स्कोर प्रदर्शन के लिए लगभग 50 - 60 था।

मेरे लिए वास्तव में कुछ हैरान करने वाला है कि केवल होम पेज (index.js) को बहुत कम स्कोर मिल रहा है, जबकि अन्य पेज जैसे कि सर्विस पेज या कॉन्टैक्ट पेज को ~ 80 का स्कोर मिल रहा है। मैंने इस साइट को काफी सुसंगत बनाया है और इसलिए पृष्ठों में बहुत अधिक अंतर नहीं है और फिर भी किसी कारण से होम पेज का स्कोर ~ 50 है जबकि सेवाओं के पृष्ठों का स्कोर ~ 80 है।

जैसा कि मैंने पहले उल्लेख किया है, लाइटहाउस v5 के साथ, स्कोर ~ 90 था, यह अभी बिल्कुल भी समझ में नहीं आता है कि इस तरह की एक साधारण साइट पर अब ~ 50 का कम स्कोर होगा।

Btw, क्या आपमें से किसी ने उपरोक्त छवि को eager रूप में स्थापित करने की कोशिश की है?
यह आलसी लोडिंग को अक्षम करता है और स्कोर बढ़ा सकता है। धब्बा या svg
लोडिंग प्रभाव प्रकाशस्तंभ को भ्रमित कर सकता है (यदि ऐसा है तो मामला है
उनके एल्गोरिथ्म में एक दोष)।

Sat, Jun 13, 2020, 10:48 AM t2ca नोटिफिकेशन @github.com पर लिखा:

कुछ बस मेरे लिए जोड़ नहीं है। मैंने एक बहुत ही सरल वेबसाइट बनाई है
प्रति पृष्ठ छवि के बारे में, Im gatsby- छवि के बिना छवियों के लिए SVG का उपयोग कर रहा है,
मैंने गूगल एनालिटिक्स को हटाने की भी कोशिश की और इससे ज्यादा फायदा नहीं हुआ
अंतर, मेरा स्कोर प्रदर्शन के लिए लगभग 50 - 60 था।

कुछ ऐसा है जो वास्तव में मेरे लिए हैरान करने वाला है, वह है केवल होम पेज
(index.js) बहुत कम स्कोर प्राप्त कर रहा है, जबकि अन्य पेज जैसे
सेवाओं का पेज या संपर्क पृष्ठ ~ 80 का स्कोर प्राप्त कर रहे हैं। मैंने इसका निर्माण किया
साइट काफी सुसंगत है और इसलिए इसमें कोई बहुत अंतर नहीं है
पृष्ठों और अभी तक किसी कारण के लिए होम पेज का स्कोर ~ 50 है जबकि
सेवाओं के पृष्ठों का स्कोर ~ 80 है।

जैसा कि मैंने पहले उल्लेख किया है, लाइटहाउस v5 के साथ, स्कोर ~ 90 था, यह बस
कोई मतलब नहीं है कि इस तरह एक साधारण साइट अब एक कम होगा
~ ५० का स्कोर।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
।

@ KyleAMathews हमारे पास है, और इसने प्रदर्शन स्कोर और पहले पेंट्स में उल्लेखनीय वृद्धि की है। यह वह है जिसे मैंने अपनी लंबी टिप्पणी में बिंदु 2 के रूप में उल्लिखित किया है। fadeIn को रद्द करना आखिरकार LH को खुश कर गया।

संपादित करें : मैं, संभवतः अनभिज्ञता से, महसूस करता हूं कि एलसीपी पर ध्यान केंद्रित करना छवियों के लिए सार्वभौमिक रूप से चिंता करने के लिए सही दृष्टिकोण नहीं है। जाहिर तौर पर उपाख्यान, लेकिन मुझे लगता है कि एक वेबसाइट बहुत तेजी से महसूस करती है जब सभी सामग्री लोड होती है और छवियों को पासवर्ड में फीका कर दिया जाता है, जब तक कि छवि सामग्री के लिए महत्वपूर्ण न हो।

एक सामान्य उदाहरण एक मध्यम लेख होगा। निश्चित रूप से, आप कह सकते हैं कि यह एक डिज़ाइन दोष है, लेकिन अधिकांश मध्यम लेख (और कई अन्य ब्लॉग) शीर्ष पर एक बड़ी ol 'छवि के साथ शुरू होते हैं जो सिर्फ मूड निर्माण या दृश्यों के लिए है और मुझे परवाह नहीं है कि क्या यह आलसी लोड में है ।

Btw, क्या आपमें से किसी ने उपरोक्त छवि को eager रूप में स्थापित करने की कोशिश की है? यह आलसी लोडिंग को अक्षम करता है और स्कोर बढ़ा सकता है। धब्बा या svg लोडिंग प्रभाव लाइटहाउस को भ्रमित कर सकता है (जो कि यदि मामला उनके एल्गोरिथ्म में दोष है)।
...

मैं अब यही कोशिश करूँगा।

मुझे लगता है कि मैंने यहां कुछ अच्छी प्रगति की है। मैंने बहुत ही बुनियादी बदलावों के साथ 57 से 84 तक अपने स्कोर बनाए। मेरा LCP 12s से 2s गया ।

उस ने कहा, यह असंगत है। नीचे किए गए परिवर्तनों का वर्णन करने के बाद से, मेरा स्कोर 69 - 84 से भिन्न होता है। प्रदर्शन स्कोर में स्पष्ट रूप से कुछ यादृच्छिक बदलाव हैं।

TLDR

सबसे पहले, जैसे @Kyleamathews और @Jimmydalleleveland ने सुझाव दिया, मैंने अपने गैट्सबी इमेज घटकों पर loading="eager" और fadeIn={false} सेट करने की कोशिश की, जो ऊपर थे।

अगला, मैंने अपने प्रश्नों से base64 छुटकारा पा लिया।

इनसे बहुत फर्क पड़ा।

अच्छा

• मेरी छवि के टुकड़ों में _noBase64 जोड़ने से मेरा स्कोर 20 अंक ऊपर आ गया

  • ऐसा लगता है कि मोबाइल पर बेस 64 छवियां बहुत अधिक वजन जोड़ रही हैं। मैं localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 का उपयोग करके सामग्री से क्वेरी कर रहा हूँ।

• loading="eager" और fadeIn={false} ने मेरे सबसे बड़े विवादास्पद पेंट समय को लगभग 50% कम कर दिया!

  • मेरा वास्तविक प्रदर्शन स्कोर किसी कारण से केवल 6-7 अंक हो गया, लेकिन LCP निश्चित रूप से प्रगति कर रहा है ...

मेरी क्वेरी इस तरह दिखती है:

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

और मेरा gatsby-image इस तरह दिखता है:

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

कम अच्छा है

मेरी वेबसाइट पर मेरा UX अब बहुत खराब लग रहा है। बेस 64 + एक महान यूएक्स प्रदान करता है। अब, यह थोड़ा तड़का हुआ है। मुझे लगता है कि अब हमें इस पर विचार करना होगा?

eager & fadeIn={false} पहले और बाद में

यहां सटीक समान पृष्ठों की कुछ साइड-बाय-साइड तुलनाएं दी गई हैं। अंतर केवल इतना है कि दाईं ओर, चित्रों में loading="eager" और fadeIn={false} ।

1. होम पेज

49% नीचे LCP। प्रदर्शन 6 अंक।

2. उत्पाद पृष्ठ

46% नीचे LCP। प्रदर्शन 7 अंक रहा।

ऊपर दिए गए इस उदाहरण के बारे में क्या अजीब है: बाईं ओर के स्क्रीनशॉट में डिफ़ॉल्ट गैट्सबी-छवि व्यवहार है (वे फीका करते हैं और उनके पास eager है।) और फिर भी, हालांकि प्रदर्शन स्कोर कम है। नीचे की तरफ छोटे स्क्रीनशॉट देखने में ऐसा लगता है कि यह इमेज में दाईं ओर तेजी से लोड हो रहा है।

हो सकता है कि यह त्रुटि के मार्जिन के भीतर हो कि वे प्रदर्शन को कैसे आंकते हैं, या हो सकता है कि यह बग के प्रभाव से संबंधित उनके अंत पर एक बग हो, जैसा कि @KyleAMathews ने उल्लेख किया है।

छवि टुकड़ों में _noBase64 स्थापित करने के बाद

यहाँ ऊपर दिए गए उदाहरण के समान स्क्रीन हैं। उन सभी के पास Gatsby Image पर loading="eager" , fadeIn={false} प्रॉप्स हैं। इसके अलावा, graqhql में छवि के टुकड़े GatsbyImageSharpFluid_withWebp_noBase64

यह थोड़ा अकथनीय है, लेकिन मैं बार-बार एक ही पृष्ठ पर एक लाइटहाउस परीक्षण चला रहा हूं, और 84, 75 और 69 प्राप्त कर रहा हूं

अजीब अजीब, लेकिन किसी भी मामले में, यह मेरे स्कोर को ऊपर ले आया।

मुझे लगता है कि प्रकाशस्तंभ एल्गोरिथ्म यहाँ असामान्य रूप से उदार महसूस कर रहा था lol ^

आगे की जांच के बाद, मुझे पता चला कि प्रकाशस्तंभ एक विशिष्ट तत्व के बारे में शिकायत कर रहा था जो LCP स्कोर को प्रभावित कर रहा था।

मैंने केवल इस तत्व को स्थानांतरित किया था जो कि केवल एक पैराग्राफ है और मेरा स्कोर 80 से ऊपर कूद गया। जाओ आंकड़ा। यह निश्चित रूप से निश्चित नहीं है कि एक पैराग्राफ को स्थानांतरित करने से मेरा स्कोर ~ 50 से ~ 80 तक कैसे बढ़ गया।

@nandorojo पूरी तरह से लिखने के लिए धन्यवाद। हमने पूरी तरह से बेस 64 को हटाने की कोशिश नहीं की है, लेकिन अगर हमें करना है तो एक बुमेर होगा। हम केवल पृष्ठ की पहली छवि पर उत्सुक लोडिंग डालते हैं, इसलिए यदि आप पहले से ऐसा नहीं कर रहे हैं तो यह एक कोशिश के लायक है यदि आप इसे नियंत्रित कर सकते हैं।

आगे की जांच के बाद, मुझे पता चला कि प्रकाशस्तंभ एक विशिष्ट तत्व के बारे में शिकायत कर रहा था जो LCP स्कोर को प्रभावित कर रहा था।

मैंने केवल इस तत्व को स्थानांतरित किया था जो कि केवल एक पैराग्राफ है और मेरा स्कोर 80 से ऊपर कूद गया। जाओ आंकड़ा। यह निश्चित रूप से निश्चित नहीं है कि एक पैराग्राफ को स्थानांतरित करने से मेरा स्कोर ~ 50 से ~ 80 तक कैसे बढ़ गया।

@ t2ca यह वही है जो मुझे मिला (यद्यपि मेरा एक हैडर टैग था)। लेकिन आपने इसे कहां स्थानांतरित किया?

@ t2ca यह वही है जो मुझे मिला (यद्यपि मेरा एक हैडर टैग था)। लेकिन आपने इसे कहां स्थानांतरित किया?

@michaeljwright पहली चीज जो मैंने की वह थी पैराग्राफ को हटाना और लाइटहाउस स्कोर की जांच करना। जब मैंने पैराग्राफ हटा दिया तो मेरा स्कोर लगभग 20 अंक बढ़ गया। मैंने सिर्फ यह सुनिश्चित करने के लिए कई बार परीक्षण दोहराया। मैंने पैराग्राफ को भी वापस रख दिया और आगे के परीक्षण किए और मेरा दर्द एक बार फिर कम हुआ।

अंत में, मैंने एक पैराग्राफ के अंदर फ्रेमर-मोशन का उपयोग करते हुए इम, पैराग्राफ को स्थानांतरित करने का निर्णय लिया। यह मुझे उसी तरह का परिणाम देता है जैसे मैंने पैराग्राफ को डिलीट करते समय किया था।

@ t2ca मुझे लगता है कि LCP हमारे नायक पृष्ठों में किसी भी एनिमेशन को दंडित करता है जो कि एक bummer है।

यहाँ मेरा LCP स्कोर है जहाँ अनुच्छेद टैग LCP है

एनीमेशन के साथ:

एनीमेशन के बिना:

@ t2ca मुझे लगता है कि LCP हमारे नायक पृष्ठों में किसी भी एनिमेशन को दंडित करता है जो कि एक bummer है।

यहाँ मेरा LCP स्कोर है जहाँ अनुच्छेद टैग LCP है

एनीमेशन के साथ:

एनीमेशन के बिना:

@ daydream05 पुष्टि करने के लिए धन्यवाद!

@ daydream05

यह कैसे gatsby छवि के खिलाफ काम नहीं करेगा? इसके अलावा, अधिकांश सीएमएस सर्वर पर छवि परिवर्तन को संभालते हैं और अपने स्वयं के सीडीएन में होस्ट किए जाते हैं। (जो एक अच्छी बात है, imo)। लेकिन अगर हम इसे अपनी साइट में होस्ट करते हैं, तो क्या यह भी प्रतिकूल नहीं होगा?

नहीं, क्योंकि गैट्सबी-छवि स्थानीय छवियों के साथ भी काम करती है, इसे अलग सीडीएन पर होस्ट करने की आवश्यकता नहीं है। यह सब आपके पहले रेंडर (व्यूपोर्ट में क्या है) के अनुकूलन के लिए आता है। एक अलग डोमेन / सीडीएन पर इसे होस्ट करने का मतलब है कि आपको एक नया कनेक्शन खोलना है (डीएनएस संकल्प, टीएस हैंडशेक, ...) यह एक धीमी डिवाइस पर 300ms तक का समय ले सकता है और फिर आपको अभी भी अपनी छवि डाउनलोड करनी होगी।

@Undistraction ने जो कहा, उसे पेज रैंकिंग अपडेट में इसे शामिल कर रहे हैं।

हम यह सुनिश्चित करने के लिए कि हमारे उपयोगकर्ता 100 तक मुफ्त में प्राप्त कर सकते हैं, हम Gatsby का और अधिक अनुकूलन करेंगे।

@ t2ca मुझे लगता है कि LCP हमारे नायक पृष्ठों में किसी भी एनिमेशन को दंडित करता है जो कि एक bummer है।

यह अपेक्षित है क्योंकि आपकी स्क्रीन कभी पेंटिंग बंद नहीं करती है। आम तौर पर LCP को CSS एनिमेशन को अनदेखा करना चाहिए, लेकिन यह इस बात पर निर्भर करता है कि आप एनिमेशन कैसे करते हैं।

@ t2ca

यदि आप हमें साइट दिखा सकते हैं, तो हम यह पता लगाने में मदद कर सकते हैं कि इसे कैसे सुधारें, लेकिन यह शायद उत्सुकता के लिए छवि को स्थापित कर रहा है।

@nandorojo

बहुत बढ़िया राइटअप! किसी भी मौका आप हमें उन प्रकाशस्तंभ रिपोर्ट के लिए लिंक दे सकते हैं?

इसकी उम्मीद है क्योंकि आपकी स्क्रीन कभी पेंटिंग नहीं रोकती ...

@wardpeet क्या आप इस पर विस्तार करना चाहेंगे?

@ डैनीहिन्शॉ I को यह व्याख्या प्रकाशस्तंभ से प्राप्त हुई
"जो मुझे लगता है कि चल रहा है वह यह है कि एलसीपी छवियों के पूरी तरह से लोड होने के बारे में परवाह करता है और जिस समय की रिपोर्ट की जाती है वह तब होता है जब छवि पूरी तरह से लोड होती है और तब नहीं जब यह पहली बार दिखाई देती है। प्रगतिशील छवियों और पुनरावृत्तियों के कारण यह समय अलग हो सकता है। "

और फिर यह कड़ी, शायद मदद की
https://web.dev/lcp/#when -is-सबसे बड़ा-विवादास्पद-पेंट-रिपोर्ट किया गया

इस बीच आप जो कोशिश कर सकते हैं, वह आपके लार्जेस्ट कंटेंटफुल पेंट (LCP) को इमेज से टेक्स्ट (यदि आपके पास लग्जरी हो), प्रीलोडिंग / प्रीफेटिंग फॉन्ट और लेजी लोडिंग इमेज में बदल रहा है। मेरे मामले में मोबाइल पर नायक की छवि के आकार को कम करने का मतलब है जिसने हमारे स्कोर को ऊपरी 90 में वापस बढ़ाया है जबकि इस मुद्दे पर चर्चा की जा रही है।

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

इसकी उम्मीद है क्योंकि आपकी स्क्रीन कभी पेंटिंग नहीं रोकती ...

@wardpeet क्या आप इस पर विस्तार करना चाहेंगे?

निश्चित रूप से मुझे नहीं पता कि यह कौन सी साइट थी, मैंने इस धागे में URL खोजने की कोशिश की लेकिन यह कठिन था। LCP सीएसएस एनिमेशन (ट्रांज़िशन, एनिमेशन प्रॉप इन सीएसएस) को ध्यान में नहीं रखता है। हालाँकि, यदि आपके पास सेटटाइमआउट / सेटइंटरवल का उपयोग करने वाली सामग्री है जो प्रतिक्रिया घटक को स्विच करती है, तो यह इसे ध्यान में रखेगा। बाद का दृष्टिकोण आपको वास्तव में खराब सीएलएस स्कोर देगा।

इसलिए यदि आप अपने नायक पाठ / छवि को चेतन करना चाहते हैं। कृपया सीएसएस एनिमेशन का उपयोग करें।

नमस्ते,

मैंने यह जानने की कोशिश की कि मेरी परियोजना Google पेज स्पीड इनसाइट्स, Google लाइटहाउस ऑडिट और इतने पर क्यों स्कोर कर रही है।

स्क्रैच से शुरू होने का संक्षिप्त समय मुझे यकीन नहीं है कि समस्या क्या है। मैंने इस स्टार्टर / थीम का इस्तेमाल शुरू करने के लिए किया: https://github.com/alexislepresle/gatsby-shopify-tsee

मैं ज्यादातर चंगीब सीएसएस सामान की प्रक्रिया में हूं जैसे कि बुलमा से चक्र-उई की ओर बढ़ना।

यह मेरा रेपो है: https://github.com/Chizzah/genesis-style
मैंने सभी खाता सामान और गैट्सबी-प्लगइन-एपोलो-शॉपिफ़ सामान को हटाने की कोशिश की लेकिन यह चीजें नहीं बदलती हैं।

ये रहा लाइव लिंक: https://genesis-style.netlify.app

कुछ भी नहीं मैं चीजों को बदलने के लिए लगता है। मैं खरोंच से शुरू नहीं करना पसंद करूंगा। अगर कोई मुझे संकेत या कुछ दे सकता है तो मैं उसकी सराहना करूंगा।

मुझे लगता है कि मुझे भी Gatsby 90-100s मुफ्त देने की आदत है

इस सूत्र के लिए धन्यवाद कि अच्छे प्रकाशस्तंभ स्कोर प्राप्त करने पर चर्चा की आवश्यकता है। शानदार स्कोर वी 6 के साथ अधिक कठिन हो गया है, ज्यादातर नए एलसीपी मीट्रिक के कारण। मेरी साइट (https://www.jamify.org) लाइटहाउस v6 के साथ ~ 100 से ~ 70 तक गिर गई।

डेस्कटॉप पर इसे 100 पर वापस लाने के लिए, मुझे करना पड़ा

• एक पृष्ठभूमि छवि को हटा दें जिसकी आवश्यकता नहीं थी (क्योंकि इसे गलत तरीके से LCP के रूप में चुना गया था)
• छवियों का आकार अनुकूलित करें
• gatsby-image से loading="eager" और fadeIn=false
  (यह वास्तव में एक ब्लमर है जैसा कि मुझे ब्लर-अप प्रभाव पसंद है)

मोबाइल पर, मैं अभी भी 80 पर अटक गया हूं, फिर से 5 सेकंड के एलसीपी के कारण। यह मोबाइल के लिए विशेष रूप से छवियों को सही आकार देकर बेहतर बनाया जा सकता है:

कुल मिलाकर, ये अनुकूलन बहुत संभव हैं, हालांकि, मैं काफी दुखी हूं कि मुझे अब धब्बा-अप या अच्छे Lighhouse स्कोर के साथ आलसी-लोडिंग छवियों के बीच चयन करना है: roll_eyes:

क्या किसी ने अभी तक लाइटहाउस v6.1 पर कोई परीक्षण किया है? मैंने अपने प्रदर्शन स्कोर में सुधार देखा है।

Google से Addy को ब्ल्यू-अप LCP समस्या के बारे में पूछा गया और यह कुछ ऐसा है जिसे वे ठीक करने के लिए काम कर रहे हैं https://twitter.com/addyosmani/status/1277293541878673411

यहाँ पाठ नए पूर्ण स्कोर को अभी तक पूर्ण नहीं माना गया है - वे अभी भी किनारे के मामलों को परिष्कृत कर रहे हैं।

मेरा मानना ​​है कि यह मुद्दा लाइटहाउस 6.1 के साथ खराब हो जाता है। LCP के इर्द-गिर्द कुछ अच्छे सुझाव हैं लेकिन हम टीबीटी के बारे में इतना नहीं देख रहे हैं जो मुझे लगता है कि मोबाइल पर खराब स्कोर का सबसे बड़ा कारण है और हल करना सबसे मुश्किल है।

आप क्रोम कैनरी में लाइटहाउस 6.1 का परीक्षण कर सकते हैं। मैंने अपनी साइट की तुलना 6.0 और 6.1 के बीच की है, साथ ही कई अन्य का उल्लेख यहां किया है और टीबीटी में काफी वृद्धि हुई है। मेरे 6.1 परीक्षणों में उदाहरण के लिए:

• gatsbyjs.org TBT: 2550ms
• मेरी साइट TBT: 2200ms
• @styxlab साइट टीबीटी: 1250 एमएस

टीबीटी के लिए 600 से अधिक कुछ भी लाल है और कैलकुलेटर के अनुसार वजन 25% है। टीबीटी उन कार्यों के कारण होता है जो एफसी और एफएक्टिव के बीच 50 एम से अधिक समय तक निष्पादित होते हैं।

उपरोक्त स्क्रीनशॉट मेरी साइट से एक प्रोफ़ाइल है। यदि आप क्रोम में लाइटहाउस का उपयोग करते हैं, तो आप देखने के लिए प्रोफ़ाइल टैब में परिणाम लोड करने के लिए व्यू ट्रेस बटन पर क्लिक कर सकते हैं। किसी भी कार्य के बाद FCP कोने में एक लाल झंडे के साथ टीबीटी की ओर गिना जाता है। मुझे अभी तक यह पता नहीं चला है कि कार्य क्या हैं, इसलिए हो सकता है कि गैट्सबी के अधिक ज्ञान वाला कोई व्यक्ति इस क्षेत्र में सहायता कर सकता है और संभवतया

@IanLunn यह एक दिलचस्प ट्रेस है, क्या आप उन कार्यों के बारे में कुछ समझ पा रहे थे?

संभावना है कि प्रत्येक गैट्सबी साइट के जेएस के बीच सहसंबंध है और यह ब्राउज़र के मुख्य धागे पर कितना महंगा है। हालाँकि मुझे लगता है कि चर्चा के लिए खुला कमरा हो सकता है, क्या कोई रास्ता है जिससे गैट्सबी इस सवाल और लिपियों को पूरी तरह से प्रभावित करके "प्रभाव" को कम करने में मदद कर सकता है?

तीन क्षेत्र हैं जिन्हें मैं इस समय बेहतर समझने की कोशिश कर रहा हूं:

• Gatsby डिफ़ॉल्ट रूप से <link rel=preload/> प्रत्येक स्क्रिप्ट के लिए आवश्यक है ( PRPL पैटर्न के अनुसार) चाहे कितने भी हों। मैं मापा में कुछ मतभेदों पर ध्यान दिया है FCP (जो मैं बहुत आश्चर्यचकित था) लेकिन ज्यादातर के बीच अंतर में FCP / LCP जब इन (जो शायद यह एक उज्ज्वल विचार नहीं है अन्य परिवर्तनों के बिना करने के लिए)। प्रकाशस्तंभ पर यह मुद्दा बाद की चर्चा करता है।
• JSON (पेज-data.json और स्थिर प्रश्नों के लिए हैशेड) बनाने वाले प्रश्नों का अंत होता है, जिनका मूल्यांकन मुख्य सूत्र पर किया जाता है। Https://github.com/gatsbyjs/gatsby/issues/18787 देखें, लेकिन ऐसा प्रतीत नहीं होता कि हमने (या यदि कोई ऐसा विकल्प है) जो मुख्य सूत्र को अवरुद्ध न करे। बड़ा डेटा, एक प्रदर्शन हिट का अधिक ( क्वेरी आकार के लिए प्रदर्शन बजट निश्चित रूप से बहुत स्वागत होगा) - लेकिन डेटा वास्तव में पुनर्जलीकरण प्रक्रिया तक की आवश्यकता नहीं है, या यह है?
• वास्तविक मात्रा के रूप में जुड़ जाते हैं <script src=foo.js async /> के अंत में </body> । इसका मतलब यह है कि जैसे ही ब्राउज़र ने HTML को पार्स करना शुरू कर दिया (जो ट्रेस में बहुत जल्द होना चाहिए), यह उन स्क्रिप्ट्स को पार्स और निष्पादित करना शुरू कर देगा (जैसा कि वे पहले से ही लोड थे)। लंबे कार्य अनिवार्य रूप से उत्पन्न होंगे क्योंकि मुख्य धागा को उस सभी जावास्क्रिप्ट को पार्स और निष्पादित करने का अनुरोध किया गया है। क्या इसे संभालने का एक बेहतर तरीका है (कम से कम _when_ उन लिपियों को पार्स किया जाना शुरू हो रहा है) मुख्य धागे को अवरुद्ध करने से बचने के लिए? क्या वृद्धिशील छोटे कार्यों में ऐसा करने का कोई तरीका है (या तो पारिश्रमिक या निष्पादन) जो कि इनपुट फीडबैक में देरी नहीं करता (और इस तरह टीटीआई को नुकसान पहुँचाता है), और न ही मुख्य सूत्र को समय के चक्र में ब्लॉक करें (और इस तरह टीबीटी को नुकसान पहुंचाएं)?

इस समय यह सच है कि Gatsby साइटें LCP की वजह से थोड़ी दंडित की जा रही हैं, जो अभी तक gatsby-image से LQIP पैटर्न को नहीं पहचानती हैं - जब यह टीबीटी / टीटीआई से संबंधित किसी भी चीज़ की बात आती है (और संभवतः लागत की कीमत पर एक बड़ा दंड है प्रकाशस्तंभ v5 की तुलना में जावास्क्रिप्ट) मुझे नहीं लगता कि प्रकाशस्तंभ टीम के रोडमैप में कुछ भी है जहां चीजें वर्तमान स्कोर से बेहतर होंगी।

@juanferreras सबसे बड़ा कार्य पहले से ही तैयार / तैयार प्रतीत होता है। (तृतीय-पक्ष)। मुझे लग रहा है कि लाइटहाउस को दंड देने वाले जावास्क्रिप्ट के बारे में आपका कथन सही है और यद्यपि गैट्सबी में छोटी अनुकूलन संभव हो सकती है लेकिन यह कुछ ऐसा नहीं है जो हल करने योग्य हो।

यदि यह है कि यह लाइटहाउस में कैसे होने जा रहा है, तो मुझे कम से कम टीबीटी के वजन को कम करने या वांछित परीक्षण वातावरण स्थापित करने का विकल्प देने के लिए कहें। बजट फोन के आधार पर स्कोर प्रदान करना साइट के परीक्षण के लिए हमेशा उपयुक्त नहीं होता है। हमें मालिकों / ग्राहकों को यह दिखाने में सक्षम होना चाहिए कि हाँ, एक बजट फोन में 75 का स्कोर मिलता है, लेकिन एक उच्च-अंत वाला फोन जो हमारे 95% उपयोगकर्ताओं को उदाहरण के लिए 90 का स्कोर मिलता है।

• JSON (पेज-data.json और स्थिर प्रश्नों के लिए हैशेड) बनाने वाले प्रश्नों का अंत होता है, जिनका मूल्यांकन मुख्य सूत्र पर किया जाता है। # 18787 देखें, लेकिन ऐसा नहीं लगता कि हमने पाया है (या अगर वहाँ है) एक विकल्प जो मुख्य धागे को अवरुद्ध नहीं करता है। बड़ा डेटा, एक प्रदर्शन हिट का अधिक ( क्वेरी आकार के लिए प्रदर्शन बजट निश्चित रूप से बहुत स्वागत होगा) - लेकिन डेटा वास्तव में पुनर्जलीकरण प्रक्रिया तक की आवश्यकता नहीं है, या यह है?

@juanferreras , मेन थ्रेड पर

वेब वर्कर को प्रमुख ब्राउज़रों में सपोर्ट किया जाता है, जिनमें ie10 भी शामिल है।

... हम टीबीटी पर इतना नहीं देख रहे हैं जो मुझे लगता है कि मोबाइल पर खराब स्कोर का सबसे बड़ा कारण है और हल करना सबसे मुश्किल है।

मैं ऐसा कुछ जोड़ना चाहता हूं जो मुझे लगता है कि टोटल ब्लॉकिंग टाइम के लिए प्रासंगिक है। वेबपैक बंडल एनालाइज़र के साथ अपने बंडलों की समीक्षा करने के बाद, मैंने देखा कि स्टैटिक क्वेरीज़ के डेटा को जावास्क्रिप्ट बंडलों में शामिल किया गया है। मुझे यकीन है कि इसके लिए एक अच्छा कारण है, लेकिन यह कम टीबीटी के खिलाफ काम करता है।

टीबीटी विशेष रूप से हल करने के लिए एक कठिन समस्या है क्योंकि रिएक्ट इसके लिए नहीं बनाया गया है। प्रचार करना एक अच्छा पहला कदम है। हम आने वाले महीनों में अधिक से अधिक टीबीटी में सुधार करेंगे, हम चाहते हैं कि गैट्सबी के पास वास्तव में छोटे पदचिह्न हों।

गैट्सबी संस्करण> 2.24.0 में हमने बेहतर पॉलीफ़िल सपोर्ट भेज दिया ताकि हम केवल IE11 जैसे विरासत ब्राउज़रों पर पॉलीफ़िल लोड करें। हमने कुछ दिनों पहले (@MarkosKon) वेबपैक से स्थिर-प्रश्नों को भी हटा दिया है।

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

मैं क्रोम में लाइटहाउस (6.0) में निर्मित सब कुछ पर सिर्फ 100/100 प्राप्त कर रहा था और फिर web.dev संस्करण (6.1) का इस्तेमाल किया और यह 70 के दशक में LCP (लगभग 5-6 सेकंड) के कारण प्रदर्शन के साथ वापस आ गया 6.1, 6.0 में लगभग 0.5 सेकंड)। यह एक सजावटी हेडर इमेज (गैट्सबी-बैकग्राउंड-इमेज का उपयोग करके) है जिसके बारे में यह शिकायत कर रहा है।

मेरी अपनी वेबसाइट को देखते हुए, वेबपैक रनटाइम में जावास्क्रिप्ट निष्पादन समय की सबसे अधिक मात्रा है। जब तक उपयोगकर्ता पेज के साथ इंटरेक्ट करना शुरू नहीं करता, तब तक पेज की आवश्यकता भी नहीं होती।

Gatsby एक ही बार में इन सभी संसाधनों (हिस्सा) को लोड करने के लिए लगता है। Js फाइल अपने आप में बहुत छोटी है, यह एक लोडर है, आप देख सकते हैं कि फाइल को पास करने में सिर्फ 2ms का समय लगता है। लेकिन फ़ाइल ही चंक्स और टेम्पलेट फ़ाइलों को लोड करती है।

वास्तव में, जब मैं चंक फाइलों का निरीक्षण करता हूं, तो मुझे पता चलता है कि वे सभी गतिशील आयात हैं, जो, हम आशा करते हैं कि वे केवल तभी लोड होते हैं जब उन्हें जरूरत होती है, लेकिन नहीं, वे सभी डिफ़ॉल्ट रूप से लोड होते हैं। यह व्यवहार वह नहीं है जिसकी मैं अपेक्षा करता हूं।

हमारे हेडर छवि के अनुकूलन का एक अच्छा सा काम किया जैसे कि गैट्सबी-इमेज के बजाय सीधे एक इमेज का उपयोग करना और रेस और कम्प्रेशन को कम करना, और हमारा फेयर थोड़ा बेहतर है। केवल, मैंने अभी मुश्किल तरीका खोजा है कि सफारी वेबपी (जीआरआर) का समर्थन नहीं करती है। और यह जारी है कि लाइटहाउस का वेब संस्करण क्रोम में निर्मित एक से कम क्षमा करने वाला है, कम से कम हमारे "छिपे हुए" विकास स्थल के लिए। समय बताएगा कि क्या एकत्रित उपयोगकर्ता डेटा एक बार लाइव होने में मदद करता है - मुझे यकीन नहीं है कि वास्तविक दुनिया में Moto G5s का उपयोग करने वाले कई लोग हैं!

@derykmarl इसे जल्द ही समर्थित किया जाना चाहिए: https://www.macrumors.com/2020/06/22/webp-safaf-14/
मुझे नहीं लगता कि Apple को व्यापक छवि प्रारूप का समर्थन करने में इतना समय क्यों लगा ...

मैंने पढ़ा कि पेजपाइंडसाइट का अनुकरण करता है कि स्कोर की गणना कैसे की जाती है। ऐसा लगता है कि वे नेटवर्क को थ्रॉटल नहीं करते हैं ताकि आप अपनी रिपोर्ट तेजी से प्राप्त कर सकें। मैं व्यक्तिगत रूप से https://lighthouse-metrics.com/ का उपयोग करता हूं, लेकिन वे 6.1 का समर्थन नहीं कर रहे हैं।

प्रकाशस्तंभ 6.x के साथ मुद्दा यह है कि यह धारणा समय पर निर्भर करता है, आप एक ही परीक्षण 10 बार चला सकते हैं और आपके पास नेटवर्क स्थितियों के आधार पर समान परिणाम नहीं होंगे।

यह LCP के कारण 70 के दशक में प्रदर्शन के साथ वापस आया

मेरे पास एक एलसीपी था जो मेरी वेबसाइट के लिए पृष्ठभूमि की छवि थी, मैं छवि को 6 उप छवियों में विभाजित करके अपने एलसीपी को काफी कम करने में सक्षम था। मैंने इसे आसानी से करने के लिए एक पायथन स्क्रिप्ट बनाई, जब तक आप उस ऊँचाई को जानते हैं जो आप चाहते हैं कि आपका प्रत्येक खंड हो

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

मैंने इस छवि संपीड़न वेबसाइट को बहुत अधिक गुणवत्ता खोए बिना आपकी छवि के आकार को कम करने के लिए वास्तव में अच्छा काम किया। मैं आमतौर पर 20% -30% गुणवत्ता के निशान के नीचे जा सकता हूं और अपनी फ़ाइल का आकार काफी कम कर सकता हूं।

मैंने इस बारे में कुछ सवाल ऑनलाइन पूछे और कुछ लोगों ने सलाह दी कि मैं अपनी छवि को केवल 2 में विभाजित करूं, ऊपर और नीचे से ऊपर के लिए, लेकिन मुझे 6 में विभाजित करना बेहतर काम करने के लिए मिला।

टीबीटी / टीटीआई नोट पर @wardpeet , हम देख सकते हैं कि अन्य प्रतिक्रिया-आधारित साइटें अब ब्राउज़र के मुख्य-थ्रेड पर समग्र प्रभाव को कैसे कम कर रही हैं।

reactjs.org स्वयं (जो कि गैट्सबी के साथ भी बनाया गया है, जहां तक ​​मुझे पता है) लगता है कि नए gatsbyjs.com की तुलना में काफी छोटा TTI (7-8 ~ बनाम 12 ~) है (वैसे लॉन्च पर बधाई!) NextJS ने खुद को React-based होने के बावजूद TTI / TBT पर बहुत अच्छे नंबर बनाए हुए हैं (यह स्क्रिप्ट के सापेक्ष आकार के कारण भी हो सकता है - जहाँ gatsby.com के पास PSI, reatss.org 466.1kb के अनुसार स्क्रिप्ट की लगभग 628.3kb है। , और nextjs.org केवल 216.8kb)

(यह स्पष्ट रूप से एक ही रन है और इसे वास्तविक तुलना के रूप में इस्तेमाल नहीं किया जाना चाहिए, लेकिन यह प्रवृत्ति कई रनों के साथ काफी सुसंगत है)।

जावास्क्रिप्ट ™ की समग्र लागत के कारण स्कोर अंतर का बहुमत है? यदि गैट्सबी टीम किसी बिंदु पर नई वेबसाइट का अनुकूलन करती है, जो प्रक्रिया पर कुछ अंतर्दृष्टि साझा करने का एक बड़ा अवसर हो सकता है, बशर्ते कि वहाँ जोड़ने के लिए बहुत जादू नहीं बचा है कि कैसे गैट्सबी फ्रेमवर्क पहले से ही जावास्क्रिप्ट को आंतरिक रूप से संभालता है।

@juanferreras @wardpeet , कुछ ऐसा भी है जो मुझे अपने प्रोजेक्ट पर मिला। यदि आप स्टाइल-घटकों का उपयोग कर रहे हैं, तो कुछ कारणों से, शैलियों को जलयोजन के दौरान पुन: प्रतिष्ठित / पुनर्जीवित किया जाता है और ब्राउज़र में पुन: इंजेक्ट किया जाता है। यह मुख्य धागे का एक बहुत लेता है।

यह गैट्सबी में हाइड्रेशन के मुद्दों के कारण है। https://github.com/styled-components/styled-components/issues/2171

Gatsby विकास के दौरान ssr चलाने पर भी काम कर रही है, https://github.com/gatsbyjs/gatsby/issues/25729 , इससे मछलियों को इस तरह की प्रदर्शन परेशानियों से निजात मिलेगी। भी।

@teclone

https://github.com/styled-compenders/styled-compenders/issues/2171 समाधान की पेशकश नहीं करता है। आपने इसे अपनी परियोजना में कैसे तय किया?

@dfguo , अभी के लिए, इसके लिए कोई फिक्स नहीं है, क्योंकि कोई नहीं जानता कि वास्तव में क्यों शैलियों को पुनर्जलीकरण के दौरान पुनर्जीवित किया जाता है क्योंकि उत्पादन में गैट्सबी पुनर्जलीकरण त्रुटियों के साथ विकास मदद की पेशकश नहीं करता है।

यही है, रिहाइड्रेशन के दौरान रिएक्ट इंगित करने वाले मतभेदों से कोई कंसोल लॉग नहीं है क्योंकि यह गैट्सबी के उत्पादन निर्माण में अक्षम है।

# 25729 प्रगति पर इस कार्य का उद्देश्य विकास में सच्चा एसएसआर चलाना है, इसलिए हम यह देख पाएंगे कि क्यों। जिसमें गैट्सबी टीम भी शामिल है।

BTW, आप अपनी साइट w / का विकास संस्करण बनाने के लिए लॉग्स देखने के लिए gatsby build --no-uglify साथ एक गैट्सबी साइट बना सकते हैं। https://www.gatsbyjs.com/docs/gatsby-cli/#build

देव एसएसआर भविष्य में इस तरह से सामान के लिए सुपर सहायक होगा!

इसलिए, मैंने अपनी साइट को @emotion और theme-ui से linaria पर लागू करने का निर्णय लिया है, जबकि dark-light कस्टम css चर के साथ मोड लागू करते हुए

उद्देश्य अवरुद्ध समय / मुख्य थ्रेड / js से संबंधित css नहीं रह गया है रनटाइम पर मूल्यांकन किया जाता है, लेकिन निर्माण समय (कम से संकलित किए जाते हैं वास्तव में linaria और अधिक करने के लिए गठबंधन लगता है gatsby इस संदर्भ में @emotion में)

प्रक्रिया पूरी तरह से चिकनी नहीं है, ज्यादातर चीजें मैंने @emotion linaria साथ काम की हैं, लेकिन कुछ अन्य लोगों को नहीं है और आपको उन्हें फिर से लिखना होगा और / या कस्टम सीएसएस के माध्यम से उन्हें फिर से लागू करना होगा। चर

Gatsby के साथ DX का अनुभव __bad__ है, हॉट रीलोडिंग काम नहीं करता है (आपको ब्राउज़र को कनेक्शन खोने के बाद से किसी भी बदलाव पर फिर से शुरू करना और शुरू करना पड़ता है), लेकिन कुल मिलाकर प्रक्रिया अच्छी रही है क्योंकि यह आपको इस बारे में अधिक ईमानदार होने के लिए मजबूर करता है क्या आपको सचमुच @emotion रनटाइम क्षमताओं की आवश्यकता है

__ क्या कहा, लाइटहाउस मेट्रिक्स बहुत समान हैं__

मैं दो netlify deploys की तुलना कर सकता हूं और वास्तव में @emotion साइट में उच्च 70s है और linaria साइट में निम्न-मध्यम 70s हैं

कहने की जरूरत नहीं है, मैं बहुत उत्साहित नहीं हूं

बंडल का विश्लेषण:

• साइट दस्तावेज़ 14 Kb से बढ़कर 28 kb हो गया है
• फ्रेमवर्क स्क्रिप्ट 38.7 kb पर समान बनी हुई है
• ऐप की स्क्रिप्ट 58.2 केबी से घटकर 46.1 केबी रह गई है
• और एक चौथी लिपि ( component--content.. । तब, 20bae078.. अब) 44.2 kb से 46.8 kb हो गई है

इसलिए मुझे लगता है कि js में शैलियों को css में शैलियों में स्थानांतरित कर दिया गया है (और ~ 12 kb महत्वपूर्ण IMO हैं), लेकिन इससे लाइटहाउस मेट्रिक्स में कोई वास्तविक प्रभाव नहीं पड़ा (और यही बात मायने रखती है, है ना?)

इसलिए, मैं बिल्कुल नहीं कह रहा हूं कि linaria बढ़ने का कोई मतलब नहीं है, मुझे आश्चर्य नहीं होगा अगर कोई ऐसा ही करता है और उसके बेहतर परिणाम हैं (सिद्धांत रूप में यह मामला (?) होना चाहिए)? लेकिन मेरे हाथों में इस प्रक्रिया का मूल्य नहीं है

फिर भी, ऐप स्क्रिप्ट की खोज करके मैंने एक नया मुद्दा खोला है जो यह जानने की कोशिश कर रहा है कि js बंडल को कैसे कम किया जाए / gatsbyjs / issues

Gatsby के साथ DX का अनुभव खराब है , हॉट रीलोडिंग काम नहीं करता है (आपको ब्राउज़र को कनेक्शन खोने के बाद से किसी भी बदलाव पर फिर से रोकना और शुरू करना होगा), लेकिन कुल मिलाकर यह प्रक्रिया अच्छी रही है क्योंकि यह आपको इस बारे में अधिक ईमानदार होने के लिए मजबूर करता है क्या आपको वास्तव में @emotion रनटाइम क्षमताओं की आवश्यकता है

@ मैं एक समान मुद्दे का सामना कर रहा था, लेकिन यह केवल gatsby संस्करणों पर 2.24.9 तुलना में नया हुआ; सुनिश्चित नहीं है कि यदि कारण समान है, लेकिन मुझे लगा कि इससे किसी को यह जानने में मदद मिल सकती है कि लोग इसके बारे में # 26192 में बात कर रहे हैं ।

@ मैं एक समान मुद्दे का सामना कर रहा था, लेकिन यह केवल gatsby संस्करणों पर 2.24.9 तुलना में नया हुआ; सुनिश्चित नहीं है कि यदि कारण समान है, लेकिन मुझे लगा कि इससे किसी को यह जानने में मदद मिल सकती है कि लोग इसके बारे में # 26192 में बात कर रहे हैं ।

मैं कई हफ्तों के लिए "gatsby": "2.24.14" के साथ रहा हूं, जो मैं कहूंगा, और अब तक मैंने केवल linaria साथ यह अनुभव किया है
लेकिन यह जानने के बाद मैं इसे अपडेट नहीं करूंगा, जब तक कि यह पता नहीं चल जाता, धन्यवाद update

@ काम करने का मेरा मतलब यह है कि यदि आप 2.24.9 डाउनग्रेड करते हैं, तो विकास-सर्वर-स्टॉपिंग समस्या linaria साथ भी नहीं होगी; लेकिन यह सिर्फ एक विचार है। मुझे यह जानने की उत्सुकता होगी कि क्या ऐसा है।

Gatsby के साथ DX का अनुभव खराब है , हॉट रीलोडिंग काम नहीं करता है (आपको ब्राउज़र को कनेक्शन खोने के बाद से किसी भी बदलाव पर फिर से रोकना और शुरू करना होगा), लेकिन कुल मिलाकर यह प्रक्रिया अच्छी रही है क्योंकि यह आपको इस बारे में अधिक ईमानदार होने के लिए मजबूर करता है क्या आपको वास्तव में @emotion रनटाइम क्षमताओं की आवश्यकता है

क्या आपने तेजी से ताज़ा करने की कोशिश की है?

मैंने हाल ही में टीबीटी और एलसीपी में सुधार की आशा में प्रचार करने के लिए एक प्रोडक्शन गैट्सबी साइट (~ 120 पेज) पर माइग्रेट किया। हमारी साइट svg है, जो कि svgr के साथ उत्पन्न होने वाली प्रतिक्रिया svg घटकों का उपयोग करके भारी है और सामग्री-यूआई शैलियों का उपयोग करके स्टाइल की गई है। औसत प्रदर्शन परिणाम प्रारंभिक स्कोर के + -5 रेंज में थे (~ 45 मोबाइल प्रदर्शन ~ 85 से नीचे v6 से पहले) और हालांकि माइग्रेशन विषय का उपयोग करके अपेक्षाकृत दर्द रहित था, इसके लिए तेजी से ताज़ा करने के लिए माइग्रेशन की आवश्यकता थी जो था नहीं।

ईमानदारी से थोड़ा निराश हूं कि कोई भी अन्य अनुकूलन नहीं है जिसे मैं सामान्य "इसके अलावा अप्रयुक्त जावास्क्रिप्ट" लाइटहाउस चेतावनी को हटाने के अलावा बंद करने के लिए प्रयास करने के लिए या अधिक विस्तृत मीट्रिक ढूंढ सकता हूं।

स्पीड मुख्य कारणों में से एक है जिसे हमने गैट्सबी को चुना है और भले ही पेज अभी भी लोड करने में तेज़ हैं, यह एक एसईओ दृष्टिकोण से औचित्य साबित करना मुश्किल है जब आपका अंतर्दृष्टि स्कोर इतना बड़ा हिट लेता है ...

फुसफुसाते हुए: मैं नेक्स्टजेस पर स्विच किया और मुझे बेहतर अंक मिल रहे हैं switch

फुसफुसाते हुए: मैं नेक्स्टजेस पर स्विच किया और मुझे बेहतर अंक मिल रहे हैं switch

Svelte के बारे में क्या?

यह जानना अच्छा होगा कि क्या गैट्सबी देवता इसे रोडमैप (अपेक्षित एक के अलावा) में महत्व / प्राथमिकता के कुछ विशिष्ट अर्थ दे रहे हैं, क्योंकि मैं मानता हूं कि कोई तात्कालिक समाधान नहीं हैं, लेकिन शायद भविष्य की दिशाओं और कार्यान्वयन पर किसी तरह ध्यान केंद्रित किया गया है यह या वह

चूंकि गैट्सबी gatsby-node * के साथ कुछ संकलन करता है, मुझे आश्चर्य है कि अगर वे उस हिस्से को बढ़ाने के तरीके तलाश रहे हैं और ग्राहक भाग को हटा रहे हैं

* pageContext कम करने के लिए जो मैं उपयोग कर रहा था (सभी प्रकाशित पोस्टों के बारे में डेटा), मैं वर्तमान में ( gatsby-node माध्यम से) उस डेटा का अधिकांश भाग json फ़ाइलों में संग्रहीत कर रहा हूँ और साइट से ज़रूरत पड़ने पर उन्हें लाना, जो बंडल आकार को कम करता है, लेकिन अधिक तार्किक भी लगता है

प्रकाशस्तंभ के स्कोर पर बहुत ज्यादा मत लटकाओ - खासकर जब वे कर रहे हैं
एक बेंचमार्क बनाम अन्य साइटों के रूप में, और एक लक्ष्य नहीं है जहां हमें करना चाहिए
एक सही स्कोर हासिल करने का प्रयास करते हैं।

यह हाल ही में नहीं था जब तक कि gatsby शुद्ध 100s - निश्चित, वहाँ था
पता करने के लिए कुछ मुद्दे हैं, लेकिन अभी SEO गेम स्पीड प्लस कंटेंट है
प्लस लिंक, और हम इसे कवर किया है।

मेरे दो सेंट।

शुक्र पर, 28 अगस्त 2020, 16:57 kuworking, सूचनाएं @github.com ने लिखा:

फुसफुसाते हुए: मैं नेक्स्टजेस पर स्विच किया और मुझे बेहतर अंक मिल रहे हैं switch

Svelte के बारे में क्या?

यह जानना अच्छा होगा कि क्या गैट्सबी देव इसे कुछ विशिष्ट दे रहे हैं
रोडमैप में महत्व / प्राथमिकता की भावना (उम्मीद से इतर)
एक), चूंकि मैं मानता हूं कि कोई तत्काल समाधान नहीं हैं, लेकिन शायद कुछ
इस या उस पर केंद्रित भविष्य के दिशा-निर्देश और कार्यान्वयन

चूंकि गैट्सबी, गैट्सबी-नोड * के साथ कुछ संकलन करता है, मुझे आश्चर्य है कि अगर वे
उस भाग को बढ़ाने के तरीके खोज रहे हैं और ग्राहक भाग को हटा रहे हैं

* पेजकोटेक्स्ट को कम करने के लिए जो मैं उपयोग कर रहा था (सभी के बारे में डेटा
प्रकाशित पोस्ट), मैं वर्तमान में (गैट्सबी-नोड के माध्यम से) सबसे अधिक स्टोर कर रहा हूं
JSON फ़ाइलों में उस डेटा की और साइट से ज़रूरत पड़ने पर उन्हें लाने के लिए,
जो बंडल आकार को कम करता है, लेकिन अधिक तार्किक भी लगता है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
।

देर से प्रतिक्रिया के लिए क्षमा करें, बहुत कुछ है जो प्रदर्शन में जाता है और लोड मेट्रिक्स केवल पहेली का एक छोटा सा टुकड़ा है। हम इस तिमाही और Gatsby को छोटा बनाने और TBT को कम करने के लिए अगले में प्रेरित हैं। अभी सबसे बड़ी समस्याएं हैं रिएक्ट बंडल साइज़, एमडीएक्स, बड़े पृष्ठ (कंटेंट / स्टाइलिंग), ट्रैकिंग स्क्रिप्ट और फोंट / इमेज जो पहले लोड पर मुख्य सामग्री के रूप में हैं।

वर्तमान में मैं gatsby- छवि और एनालिटिक्स स्क्रिप्ट में देख रहा हूं कि हम लोड समय और पोस्टपोन एनालिटिक्स को कैसे सुधार सकते हैं।

अफसोस की बात है कि मैं कोई अनुमान नहीं दे सकता। हम अपनी .com साइट और अपने ग्राहकों को भी देख रहे हैं कि आम समस्याएं क्या हैं इसलिए हम इन अनुकूलन को gatsby या हमारे प्लग इन में सेंक सकते हैं।

संपादित करें:

मुझे आपके किसी भी स्रोत कोड को देखने में खुशी हो रही है कि आप जो भी देख रहे हैं उसमें और अधिक जानकारी प्राप्त करने के लिए कि हम कैसे सुधार कर सकते हैं।

मैंने एक रेडिट पोस्ट बनाया, जहां मैंने उन सभी सुधार युक्तियों को एकत्र करने की कोशिश की, जो मुझे मिल सकती हैं। यदि आप अधिक युक्तियों के साथ आ सकते हैं, तो कृपया उन्हें सूचीबद्ध करें

सिर्फ गैट्सबी-इमेज (होम हीरो इमेज और किसी भी बैकग्राउंड इमेज) को हटाने से मेरा स्कोर 10-20 अंकों से कहीं भी बेहतर हो जाता है।

हाल के कुछ परीक्षण में मैं कर रहा था कि मैंने पाया कि tracedSVG वास्तव में नाटकीय रूप से सबसे बड़े विवादास्पद पेंट के प्रदर्शन स्कोर में सुधार हुआ है। मुझे लगता है कि यह प्रकाशस्तंभ में तय किया जाएगा, लेकिन अब तक ऐसा होता है क्योंकि एसवीजी को पूर्ण रिज़ॉल्यूशन छवि के समान आयाम माना जाता है, इसलिए यह एसवीजी से कभी नहीं स्वैप होता है क्योंकि एलसीपी लक्ष्य से पूर्ण छवि तक पहुंचता है।

Base64 का उपयोग करते समय, छोटा रिज़ॉल्यूशन इसे LCP का उम्मीदवार नहीं बनाता है, इसलिए जब भी लोड होता है, तो लाइटहाउस पूर्ण रिज़ॉल्यूशन छवि का उपयोग करता है।

इसलिए यदि आपको पता नहीं है कि एसवीजी (मैं उन्हें व्यक्तिगत रूप से पसंद करता हूं) का पता नहीं लगाता हूं, तो आप कोशिश कर सकते हैं।

V6 की तुलना में v5 अधिक बेहतर परिणाम क्यों? मैं NextJS का उपयोग कर रहा हूं परिणाम हमेशा 60 से 85 में बदल जाता है।

+1

मैं एक गैट्सबी-छवि उत्तराधिकारी पर काम कर रहा हूं। यह अभी भी 100% नहीं है, फिर भी एक कंपोजेबल संस्करण लिखने की आवश्यकता है ताकि आप अपनी खुद की गैट्सबी-छवि स्वाद बना सकें लेकिन यह अधिकांश लाइटहाउस स्कोर को ठीक कर देगा।

आप पहले से ही इसका उपयोग कर सकते हैं लेकिन यह अभी तक युद्ध-परीक्षण नहीं है।
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

आप इसे npm install --save @wardpeet/gatsby-image-nextgen द्वारा स्थापित कर सकते हैं। गैट्सबी-छवि के वर्तमान उपयोगकर्ताओं के लिए एक

ऐसी चीजें जो अभी तक समर्थित नहीं हैं:

• ऑब्जेक्ट-फिट को घटक के बाहर सीएसएस द्वारा किया जाना चाहिए
• कला निर्देशन

वर्तमान गैट्सबी-छवि डेमो:
साइट: https://wardpeet-using-gatsby-image.netlify.app/
पेजस्पीड-इनसाइट्स: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

नया गैट्सबी-इमेज-नेक्स्टजेन डेमो:
साइट: https://gatsby-image-nextgen.netlify.app/
पेजस्पीड-इनसाइट्स: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%EF
webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet वर्तमान डेमो के लिए आपका पेजस्पीड-इनसाइट लिंक अगली बार जाता है, इसलिए वे समान स्कोर दिखाते हैं।
बहुत बढ़िया काम, बी.टी.वी. प्रगति को देखने के लिए वास्तव में रोमांचक है।

धन्यवाद तय!

इस अपडेट ने मुझे कुछ ऐसा बताया है, जिससे मैं पहले नहीं जुड़ा था, मैं gatsby-image का उपयोग नहीं कर रहा हूं, लेकिन वास्तव में gatsby-background-image जो जाहिर तौर पर gatsby-image हुड के तहत उपयोग नहीं करता है ... मुझे इस घटक को इस नए @wardpeet/gatsby-image-nextgen साथ फिर से लिखना पड़ सकता है यदि यह संभव है ...।

इस लेख में कुछ अतिरिक्त युक्तियों की सूची दी गई है https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/ हालांकि मुझे लगता है कि उनमें से कई पहले ही इस धागे में उल्लिखित किए जा चुके हैं ...

@DannyHinshaw जब प्लगइन पूर्ण सुविधा है। मैं उस प्लगइन पर एक नजर डालूंगा। मुझे टिप्पणी चित्रों को भी देखना है

मैंने @wardpeet/gatsby-image-nextgen - 0.0.2 का नया संस्करण प्रकाशित किया है।

1. html में css & js को छोटा करता है
2. केवल आवश्यक बिट्स को लोड करें, जब देशी छवि लोड करने में सक्षम है हम केवल 2kb (गैर gzipped) के बारे में लोड करते हैं।
3. सुनिश्चित करें कि प्लेसहोल्डर को केवल पहले लोड पर बुलाया जाता है, कैश्ड छवियों को तुरंत लोड किया जाता है
4. Async को डीकोड करके ब्लर-अप एनिमेशन को ठीक करें

मैं सोच रहा हूं कि आप में से कितने को एक कंपोजेबल इमेज कंपोनेंट की जरूरत है, जहां आप अपना रैपर बना सकें और आप में से कितने लोग वास्तव में आर्ट-डायरेक्शन का इस्तेमाल कर रहे हैं और चाहते हैं कि अंदर-अंदर गैट्सबी-इमेज डिफॉल्ट रूप से हो? मेरा पहला विचार कार्यक्षमता को अक्षम करना था, लेकिन इसे सक्षम गैट्सबी-छवि के साथ सक्षम करें ताकि आपको इसका समर्थन करने के लिए अपनी छवि घटक बनाना पड़े।

नवीनतम डेमो: https://gatsby-image-nextgen.netlify.app/

@wardpeet यह बहुत अच्छा है! मैं गट्सबी-इमेज की बिल्ड-इन आर्ट-डायरेक्शन पर बहुत भरोसा करता हूं। लेकिन मुझे लगता है कि एक उदाहरण / चिकनी उन्नयन पथ भी ठीक होगा!

मुझे हमेशा मोबाइल पर 99 अब 76 प्राप्त हुए। मेरे एलसीपी को छोड़कर सब कुछ बढ़िया है, यह 7.0 है और यह मेरे हीरो की छवि कहता है। कुछ समझ नहीं आया। जब मैं अपनी साइट को किसी भी मोबाइल फोन पर खींचता हूं तो यह तेजी से धधक रहा होता है। लोग चमत्कार तो जानते हैं? यह मुझे अपनी छवियों को वेबप या अन्य में डालने के लिए भी कहता है, लेकिन मैं पहले से ही हमारे लिए बचता हूं ISharp_withWebp ताकि मुझे यह प्राप्त न हो। मैं बात करने लगा हूं गैस्टबी इमेज और बैकग्राउंड-इमेज इस नए वर्जन के साथ लाइटहाउस और पेजस्पीडाइट पर काम नहीं कर रही है। मेरा दिमाग चकरा गया है। मैं गया और एनिमेशन को मार दिया, मेरी सभी छवियों को आधे से आकार दिया और यह एक बिंदु तक नहीं हिलता था। मैं इस के माध्यम से पढ़ रहा हूँ और मुझे मदद करने के लिए कुछ भी नहीं देख रहा हूँ .... ओह, मैंने अभी देखा ... II लगता है कि @wardpeet मेरे कुछ पर हो

@davidpaulsson मन एक उदाहरण साझा करने पर कि आप यह कैसे करते हैं? कारण कला-निर्देशन अभी भी नई गैट्सबी-छवि के साथ संभव है, आपको कुछ मैनुअल चरण करने होंगे।

@davidpaulsson मन एक उदाहरण साझा करने पर कि आप यह कैसे करते हैं? कारण कला-निर्देशन अभी भी नई गैट्सबी-छवि के साथ संभव है, आपको कुछ मैनुअल चरण करने होंगे।

ज़रूर! मैं इसे वर्तमान में इस तरह का उपयोग करता हूं

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet हाय वार्ड। क्या blha.sh gatsby की छवि के लिए उपयोगी हो सकता है?

@wardpeet मैंने आपकी gatsby-image-nextgen प्लगइन का उपयोग किया और इसने वास्तव में मेरे LCP समय में सुधार किया (इसे ~ 5s से ~ 1.5 s तक घटा दिया)। इसके लिए शुक्रिया!

हालाँकि, हम कला-निर्देशन का भी उपयोग कर रहे हैं, @davidpaulsson कैसे उपयोग कर रहा है, इसके समान है और मैं इसे काम करने के लिए प्राप्त नहीं कर सकता जैसा कि यह gatsby- छवि के साथ करता है।

क्या आप नेक्स्टजेन प्लगइन के साथ इसे संभव बनाने के लिए आवश्यक मैनुअल कदमों के बारे में विस्तार से बता सकते हैं? एक बार फिर धन्यवाद!

@ जिमीडालेक्लेवलैंड धन्यवाद जिमी! GatsbyImageSharpFluid_withWebp को GatsbyImageSharpFluid_withWebp_tracedSVG बदलने से मेरे नए गैट्सबी वेबिस्ट के प्रदर्शन स्कोर में सुधार हुआ। मुझे ५४% से अधिक नहीं मिल रहा था और अब ट्रैसेड वीजी के साथ मैं than०% से अधिक हो रहा हूं। यह एक बहुत बड़ा सुधार है

हाल के कुछ परीक्षण में मैं कर रहा था कि मैंने पाया कि tracedSVG वास्तव में नाटकीय रूप से सबसे बड़े विवादास्पद पेंट के प्रदर्शन स्कोर में सुधार हुआ है। मुझे लगता है कि यह प्रकाशस्तंभ में तय किया जाएगा, लेकिन अब तक ऐसा होता है क्योंकि एसवीजी को पूर्ण रिज़ॉल्यूशन छवि के समान आयाम माना जाता है, इसलिए यह एसवीजी से कभी नहीं स्वैप होता है क्योंकि एलसीपी लक्ष्य से पूर्ण छवि तक पहुंचता है।

Base64 का उपयोग करते समय, छोटा रिज़ॉल्यूशन इसे LCP का उम्मीदवार नहीं बनाता है, इसलिए जब भी लोड होता है, तो लाइटहाउस पूर्ण रिज़ॉल्यूशन छवि का उपयोग करता है।

इसलिए यदि आपको पता नहीं है कि एसवीजी (मैं उन्हें व्यक्तिगत रूप से पसंद करता हूं) का पता नहीं लगाता हूं, तो आप कोशिश कर सकते हैं।

@abdullahe हमने इसे पहले ही देख लिया है और इसमें कैनवास पर निर्भरता है और नोड-कैनवास सुपर विश्वसनीय नहीं है। या कम से कम यह अतीत में नहीं था। अगर हम इसे फिर से मानें तो आपको बता दूंगा :)

@guydumais loading="eager" डालना सुनिश्चित करें, इससे आपका स्कोर भी बदल जाना चाहिए।

@BenjaminSnoha & @davidpaulsson मैं एक उदाहरण को थोड़ा सा साझा करूँगा। कला-दिशा के साथ सबसे बड़ा मुद्दा अगर छवियों के बीच का पहलू अनुपात बदलता है, जैसे क्षैतिज से ऊर्ध्वाधर।

@wardpeet @wardpeet/gatsby-image-nextgen साथ gatsby-remark-images @wardpeet/gatsby-image-nextgen उपयोग कैसे करेंगे? क्या यह gatsby-config.js में एक प्लगइन के रूप में इसे इंगित करने का मामला है, या क्या यह तब तक संभव नहीं है जब तक कि यह गैट्सबी मोनोरेपो में विलय नहीं हो जाता?

हालांकि यह प्रकाशस्तंभ के साथ कुछ भी नहीं कर सकता है, मैं सोच रहा हूँ कि क्यों gatsby पेज डेटा JSON फ़ाइलें सामग्री हैशिंग का समर्थन नहीं करती हैं, ठीक जेएस फाइलों की तरह।

मुझे पता है कि js फ़ाइलों के लिए सामग्री hashing वेबपैक द्वारा किया जाता है, लेकिन gatsby पेज डेटा JSON फ़ाइलों के लिए भी ऐसा कर सकता है। यह एक बहुत सीडीएन नेटवर्क अनुरोधों को बचा सकता है

@teclone पेज-data.json फ़ाइलों पर डाउनलोड नहीं किया जाना चाहिए और पर अपने कैशिंग सही ढंग से सेटअप है यदि। वे एक बार लोड करेंगे और फिर ब्राउज़र उन्हें फिर से अमान्य करेगा। पृष्ठ डेटा (बनाम JS / CSS फ़ाइलों) के लिए सामग्री हैशिंग के साथ समस्या सिर्फ इतनी है कि उनमें से बहुत सारे हैं। सामग्री हैशिंग के साथ, इससे पहले कि आप किसी फ़ाइल को लोड कर सकें, आपको एक प्रकट लोड करने की आवश्यकता है जो x से x.LONG_HASH हैश के रूप में अनुमानित नहीं है। जेएस / सीएसएस के साथ, एक मैनिफ़ेस्ट लोड करना उचित है क्योंकि बहुत बड़ी साइटों पर भी केवल इतनी जेएस फाइलें हैं। लेकिन पेज डेटा के साथ, प्रति पृष्ठ एक है, इसलिए मेनिफ़ेस्ट काफी बड़ा हो सकता है। हम ऐसा करते थे और हमें एक 10k पेज साइट पर मिला, पहले से ही ~ 500k संपीड़ित था। https://github.com/gatsbyjs/gatsby/pull/13004

यदि आप पृष्ठ-data.json फ़ाइलों को बार-बार डाउनलोड करते देखते हैं - तो आपने अपने devtools में कैशिंग को अक्षम नहीं किया है और https://www.npmjs.com/package/check-gatsby-caching के साथ अपने कैशिंग हेडर की जाँच

@KyleAMathews , यह स्पष्ट करने के लिए धन्यवाद। यह एक बहुत ही समझदार दृष्टिकोण है

@wardpeet यह सच है कि छवि-नेगन fadeIn="false" या fadeIn="{false}" समर्थन नहीं करती है

यह बहुत बेहतर काम करता है, हालांकि ~ 80 से ~ 95 तक चला गया

@MelleNi ऐसा नहीं है, मुझे नहीं लगता कि यह आवश्यक है लेकिन हम इस पर विचार करके खुश हैं।

आप यह देखने के लिए https://github.com/gatsbyjs/gatsby/discussions/27950 पर नज़र डाल सकते हैं कि हम क्या कर रहे हैं।

@wardpeet @wardpeet/gatsby-image-nextgen साथ gatsby-remark-images @wardpeet/gatsby-image-nextgen उपयोग कैसे करेंगे? क्या यह gatsby-config.js में एक प्लगइन के रूप में इसे इंगित करने का मामला है, या क्या यह तब तक संभव नहीं है जब तक कि यह गैट्सबी मोनोरेपो में विलय नहीं हो जाता?

हम इस प्लगइन के साथ टिप्पणी करने जा रहे हैं :)

@MelleNi ऐसा नहीं है, मुझे नहीं लगता कि यह आवश्यक है लेकिन हम इस पर विचार करके खुश हैं।

आप # 27950 पर एक नज़र डाल सकते हैं कि हम क्या शिपिंग कर रहे हैं।

@wardpeet @wardpeet/gatsby-image-nextgen साथ gatsby-remark-images @wardpeet/gatsby-image-nextgen उपयोग कैसे करेंगे? क्या यह gatsby-config.js में एक प्लगइन के रूप में इसे इंगित करने का मामला है, या क्या यह तब तक संभव नहीं है जब तक कि यह गैट्सबी मोनोरेपो में विलय नहीं हो जाता?

हम इस प्लगइन के साथ टिप्पणी करने जा रहे हैं :)

टिप्पणी के बारे में सुनकर बहुत अच्छा लगा, क्योंकि मैंने गति में बहुत सुधार देखा।

हालाँकि, मैंने देखा कि मैं गैट्सबी की जावास्क्रिप्ट (और मैन्युअल रूप से विशेष कार्यक्षमता को फिर से एकीकृत करने) को अक्षम किए बिना 99-100 प्राप्त नहीं कर सका। मैं जावास्क्रिप्ट के बिना काम करने के लिए पुरानी Gatsby छवि प्राप्त कर सकता हूं, fadeIn={false} का उपयोग करके, लेकिन छवि-नेगेन नहीं। (शायद मुझे कुछ याद आ रहा है, और यह बिल्कुल संभव है?) अब जावास्क्रिप्ट के बिना मैं अगली पीढ़ी के बिना 99 से नीचे कभी नहीं गिर सकता।

मैं समझता हूं कि जावास्क्रिप्ट प्रकार को पराजित करने की जावास्क्रिप्ट को निष्क्रिय करना गैट्सबी के विचार को दर्शाता है, लेकिन अच्छी तरह से।

दिलचस्प है, मैंने मोबाइल प्रदर्शन स्कोर (~ 70 से ~ 90) पर सुधार देखा जब मैंने स्वयं-होस्ट किए गए फोंट (फोंटसोर्स) का उपयोग करना बंद कर दिया और "सिस्टम" फोंट पर स्विच किया।

@wardpeet कोई भी मौका आप एक उदाहरण साझा कर सकते हैं कि कला निर्देशन के साथ एक कंपोजेबल छवि घटक कैसे बनाया जाए? मैं @BenjaminSnoha & @davidpaulsson के रूप में एक ही नाव में कंपोजेबल कंपोनेंट बनाने में कोई आपत्ति नहीं है।

मैं जो सबसे बड़ा मुद्दा देख रहा हूं वह मीडिया के सवालों और SSR से निपट रहा है। जैसे पुस्तकालय Fresnel काम है, लेकिन प्रदर्शन में भुगतना क्योंकि वे सभी घटकों को लोड करते हैं, तो डोम को साफ करने के बाद window घटक उपलब्ध हो जाता है।

मेरी वेबसाइट पर ऐसा लगता है कि createPage के साथ बनाए गए सभी पृष्ठों में स्रोत कोड (मार्कटैड के अंदर मार्कडाउन और मार्कडाउन रिएक्शन घटक) है, जो पेजपीड हैवी जावास्क्रिप्ट (अप्रयुक्त जावास्क्रिप्ट हटाएं) में है।

मैंने अभी-अभी प्लासीहोल्डर लॉन्च किया है जिसका उपयोग शुद्ध सीएसएस धुंधला प्लेसहोल्डर्स बनाने के लिए किया जा सकता है। शायद यह ब्याज की होगी? आगे की विकल्पों के बारे में किसी भी कोर टीम के साथ चैट करने के लिए खुश से अधिक

मैंने Jamify Blog Starter का एक Next.js संस्करण बनाया है जो नवीनतम L लाइटहाउस 6.4.0 के साथ स्कोर करता है:

आप next.jamify.org पर डेमो साइट का निरीक्षण कर सकते हैं।

मैं यहां यह पोस्ट कर रहा हूं, यह सुझाव देने के लिए नहीं कि आप Next.js. पर स्विच करें बल्कि, यह जानने के लिए

• अत्यधिक अनुकूलित छवियां (अगला इसे लैम्ब्डा ऑप्टिमाइज़र के साथ प्राप्त करता है, लेकिन यह गैट्सबी-प्लगइन-तेज के साथ भी किया जा सकता है)।
• एक साधारण प्लेसहोल्डर svg (धुंधला जैसा अच्छा प्रभाव पृष्ठ को धीमा कर देगा)।
• देखने में केवल छवियों को दिखाने के लिए प्रतिच्छेदन पर्यवेक्षक का उपयोग (अगले / चित्र देखें)।
• छवियों की आलसी लोडिंग सुनिश्चित करें।
• छोटे बंडल आकार।

यदि आप इस पर आगे चर्चा करना चाहते हैं, तो आप मुझे ट्विटर पर पहुंचा सकते

@styxlab मुझे

लेकिन पोस्ट परिणामों में बेहतर, निश्चित रूप से किसी भी मामले में बहुत अच्छे मूल्य और स्पष्ट रूप से gatsby संस्करण से अलग https://demo.jify.org/

मैं यह भी पोस्ट करूंगा कि एक साइट में मैंने gatsby 11ty लिए बदला है, और प्रदर्शन में सुधार हुआ है लेकिन नाटकीय रूप से नहीं

(Gatsby)

(अलग डिजाइन, अनिवार्य रूप से एक ही सामग्री, 11 मात्रा)

या एक समान पृष्ठ में, इस बार एक छवि के साथ

(Gatsby)

(अलग डिजाइन, अनिवार्य रूप से एक ही सामग्री, 11 मात्रा)

मैं यह कहूंगा कि 11 वें डेवलपर का अनुभव बहुत अच्छा है (आप भी --experimentally jsx और styled-components ) का उपयोग कर सकते हैं, लेकिन ग्राहक पक्ष पर कोई js खो जाता है (आप इसे सम्मिलित कर सकते हैं और वेबपैक के साथ लड़ सकते हैं, यह वह क्षण है जहाँ आप गैट्सबी को याद करते हैं)

जब मैं 11ty का उपयोग कर रहा था, मैं यह भी सोच रहा था कि यह कितना अच्छा होगा कि gatsby ने किसी प्रकार की 11ty रेंडर रणनीति को सक्षम किया ताकि एक मिश्रित प्रतिक्रिया और प्रतिक्रिया रहित स्थिर पृष्ठों को एक फ्रेमवर्क में तैनात किया जा सके ...

इस पर कोई अद्यतन? मेरे पास कोई चित्र नहीं है और मुझे कुल अवरुद्ध समय के कारण प्रदर्शन पर 76 मिले