يبدو أن Lighthouse 6 تقدم بعض المقاييس الجديدة وتزيل بعض المقاييس الأخرى من الإصدار 5 ، لذلك من المحتمل بالتأكيد حدوث تغيير في النتيجة. تشرح هذه المقالة ما تغير:

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

يوجد أيضًا رابط في النهاية لآلة حاسبة للنتيجة وهو مفيد حقًا لتقسيم النتيجة وفهم العوامل التي تساهم أكثر من غيرها.

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

لدي انطباع بأن هناك تركيزًا أكبر على تفاعل الخيط الرئيسي في الإصدار 6 لذا إذا كان موقعك يتضمن حزم JS كبيرة ، فمن المحتمل أن يكون ذلك عاملاً مهمًا.

نعم shanekenney ، أعلم ، لكن لا أعرف حقًا كيفية تقليله باستثناء إزالة أجزاء من الموقع لمعرفة الأجزاء التي تثير هذا

هل ترى أيضًا التأثير على gaysbyjs ومواقع واجهة المستخدم الخاصة بالموضوع؟ لدي فضول / أرغب في معرفة التحسينات التي قد يفكرون فيها على موقعهم ، أو إذا اكتشفوا سببًا معينًا

هذه المشكلة رائعة حتى نتمكن من مناقشة النتائج الشاملة لإحصاءات Lighthouse / PageSpeed ​​والانحدارات المحتملة التي نراها مع الإصدار 6.

kuworking شيء واحد جدير بالملاحظة هو أن lighthouse-metrics.com يبدو أنه يستخدم _ "Emulated Nexus 5X" _ لـ 5.6 و _ "Emulated Moto G4" _ لـ 6.0 مما قد يضيف أيضًا بعض الضوضاء إلى المقارنة.

يزعم هذا المعيار الذي يزيد عن 922 موقعًا في الإصدار الخامس أن متوسط ​​درجة الأداء لموقع Gatsby هو 75 . سأحاول القيام برؤية سريعة باستخدام الحلول المستضافة لمنع شبكتي المحلية من أن تكون عامل تباين آخر.

حاليًا (مع Lighthouse v5.6 / PageSpeed ​​Insights)

يعمل PSI على Moto G4 على "Fast 3G". مصدر

بعض مواقع "العلامات" التي تم إنشاؤها باستخدام Gatsby لا تحقق أداءً رائعًا حقًا على PageSpeed ​​Insights (التي لا تزال تستخدم Lighthouse v5.6 أفترض - تخضع للتنوع القياسي في كل تشغيل ، ربما تعمل 3x أو 5x وسيؤثر المتوسط ​​في المقاييس الأكثر موثوقية ) .

• gatsbyjs.org (الجوال 72/100 ، TTI 9s) المصدر
• رد فعل (Mobile 62/100 ، TTI 9.5s) المصدر
• gatsbyjs.com (Mobile 77/100 ، TTI 6.6s) المصدر

ومع ذلك ، فإن بعض المواقع الأخرى (ومعظم المواقع المبتدئة) تحقق أداءً جيدًا على PageSpeed ​​Insights:

• store.gatsbyjs.org (الهاتف المحمول 99/100 ، TTI 2.5s) المصدر
• Thirdandgrove.com (Mobile 91/100، TTI 4.0s) المصدر

يُلاحظ متوسط ​​TTI - وبينما يغير v6 الوزن الإجمالي لـ TTI من 33٪ إلى 15٪ ويقلل من أول CPU Idle ، فإنه يضيف TBT بوزن 25٪ مما قد يفسر تراجع النتائج بشكل عام فقط بسبب التحليل الشامل والتنفيذ لـ JS.

Lighthouse v6 (مع WebPageTest.org )

• تم تشغيل WPT على _Moto G (الجيل 4) ، Moto G4 - Chrome_ باتصال _3G Fast (1.6 ميجا بت في الثانية / 768 كيلو بت في الثانية 150 مللي ثانية RTT) _. يبدو أن هذا أقرب ما يكون إلى تطابق الجهاز / الشبكة كما يمكننا الحصول عليه قبل أن تقوم PSI بتحديث إصدار المنارة الأساسي الخاص بها.
• تأكد من تحديد _Capture Lighthouse Report_ ضمن _Chromium_. لقد عطلت العرض المتكرر للحفاظ على النطاق عند الزائر لأول مرة ، أول تحميل للصفحة.

فيما يلي النتائج ، يمكنك مشاهدة تقرير المنارة من خلال النقر على رقمه. أنا أستخرج القيم من هذا التقرير.

• gatsbyjs.org (72 -> 67/100، TTI 7.5s، TBT 2150ms) المصدر
• رد فعل (62 -> 66/100 ، TTI 7.8s ، TBT 3520ms) المصدر
• gatsbyjs.com (77 -> 66/100 ، TTI 8.4s ، TBT 2440ms) المصدر

ومع ذلك ، لاحظ الانحدار في الموقعين التاليين:

• store.gatsbyjs.org ( 99 -> 54/100 ، TTI 6.8s ، TBT 1300ms) المصدر
• Thirdandgrove.com ( 91 -> 63/100 ، TTI 14s !، TBT 1330ms) المصدر

لدي بعض الأسئلة المفتوحة.

1. هل تم شرح TTI (و TBT) بشكل عام بواسطة تحليل JS + تنفيذ ، أم أن هناك عوامل أخرى تضر بالتفاعل؟
2. إذا كان الأمر كذلك ، فهل يمكننا أن نكون أكثر عدوانية (إما على Gatsby افتراضيًا مثل أحدث التغييرات مثل تمكين القطع الحبيبية ، أو تحت بعض العلامات التجريبية) عند إنشاء الأجزاء _ فقط_ لإرسال ما يحتاجه هذا التحميل الأول (أي منع التطبيق- [التجزئة] .js من وجود فائض)؟ يمكن أيضًا أن يكون مجرد توثيق طرق للعب مع توسيع تكوين حزمة الويب بمزيد من الإرشادات.
3. هل يمكن أن تساعد أنماط مثل الوحدة النمطية / الوحدة النمطية في تقليل معالجة الجفاف الجزئي ؟
4. قد تكون هذه الخطوة الثانية نحو تحقيق أعلى الدرجات ، ولكن نظرًا لأن FMP لم يعد عاملاً ، فهل LQIP على gatsby-image يساعد أو يضر عندما يتعلق الأمر بـ LCP؟ كان LCP الخاص بـ store.gatsby.org أثناء التشغيل أعلاه 4.7 ثانية!

(أنا أستخدم الروابط أعلاه فقط كأمثلة - إذا رغب أي شخص في إزالة رابط معين ، يمكنني تعديل الرسالة بكل سرور)

يبدو أن موقعي (https://matthewmiller.dev/) قد تحسن (~ 92 إلى ~ 95) ، لكن بعض الاختبارات الجديدة تكشف عن بعض الأشياء التي ربما يمكن تحسينها.

اختبار JavaScript غير الضروري على سبيل المثال ،
(العمود الأول الحجم ، والعمود الثاني هو المبلغ غير الضروري)

أفترض أن هذا يرجع إلى العناصر المطلوبة لصفحات أخرى يتم تضمينها هنا ، لذا فإن استخدام شيء مثل المكونات القابلة للتحميل قد يساعد قليلاً.

بالنسبة لي ، أواجه صعوبات كبيرة في فهم Largest Contentful Paint ، بمعنى أنني أحصل على قيم كبيرة جدًا دون معرفة السبب ، وألاحظ تباينًا بين القيمة الواردة في التقرير (على سبيل المثال 7.4 ثانية ، و التصنيف LCP الذي يظهر في علامة التبويب Performance - ViewTrace (800 مللي ثانية تقريبًا)

أستطيع أن أرى أن شيئًا مشابهًا يبدو أنه يحدث في البداية https://parmsang.github.io/gatsby-starter-ecommerce/

كتحديث - يبدو أن PageSpeed ​​Insights قد أطلقت التحديث لتشغيل Lighthouse v6 (قد لا يتوفر في جميع المناطق حتى الآن).

رابط للاختبار https://gatsbyjs.org/ . تحصل حاليًا على نتائج تتراوح من 60 إلى منتصف الثمانينيات ، اعتمادًا بشكل أساسي على قيم TBT و TTI.

kuworking قد تكون هناك مشكلة مع Lighthouse v6 في التعرف على gatsby-image.

وفقا لويبديف

بالنسبة لعناصر الصورة التي تم تغيير حجمها من حجمها الداخلي ، فإن الحجم الذي يتم الإبلاغ عنه هو إما الحجم المرئي أو الحجم الداخلي ، أيهما أصغر.

في حالتي ، أعتقد أن Lighthouse لا تحترم حجم العرض.

وهذه هي الصورة المعنية

قد يكون حسابًا للحجم الجوهري وهو 3000 بكسل ، ومن ثم 13s LCP بالنسبة لي.

@ daydream05 كان لدي نظريات ونتائج متشابهة أيضًا ، لذا اختبرت صفحاتي بدون صور وما زلت أمتلك LCP طويل مجنون (10-12 ثانية). لدي الكثير مما يجري في مشروعي ، لذا قد يكون متغيرات أخرى أيضًا ، لكنني أشعر بالفضول إذا كنت قد اختبرت صفحة بها محتوى نصي ولا توجد صور حتى الآن.

تم إسقاطه من 100 إلى 79 ~ https://dougsilkstone.com/ مؤخرًا. يقفز حتى 90 عند إزالة Google Tag Manager (و Google Analytics).

سأقدم تقريرًا عن المزيد من النتائج أثناء اختبار الأشياء.

تحرير: اضغط على 100 عند إزالة الخط الذي تم تحميله من النوع gatsby-plugin-web-font-loader (أيضًا باستخدام ذاكرة التخزين المؤقت للتحميل المسبق للخطوط).

يؤثر GTM بشكل عام على مشروعي ، لكنه ليس تغييرًا جذريًا عندما أزلته (5-10 نقاط تتصدر درجات الخمسينيات الفرعية بعد LH6). ما زلت بحاجة إلى إجراء المزيد من الاختبارات ولكني أردت فقط التخلص من ذلك.

Jimmydalecleveland مثيرة للاهتمام! لدي أيضًا موقع آخر حيث تكون الشاشة هي مجرد نص وهو يلوم النص البطل باعتباره السبب الرئيسي لـ LCP. ولا يراعي LCP سوى كل ما هو معروض ، وهو أمر غير منطقي. كيف يمكن أن يكون نصًا بهذه المشكلة.

dougwithseismic أستخدم أيضًا typekit وهو أحد الجناة الرئيسيين للحصول على درجات أقل من المنارة. أتمنى أن تكون هناك طريقة لإصلاح typekit لأنها لا تدعم عرض الخطوط

أعتقد أن Lighthouse v6 صعب حقًا على أطر عمل JS نظرًا لكيفية تغييرهم لترجيح الدرجات. (مزيد من التركيز على حظر الوقت) ومواقع غاتسبي لها تاريخياً تقييم منخفض للنصوص / درجات سلسلة رئيسية بسبب الجفاف وأشياء أخرى.

dougwithseismic كيف ربطت خط typekit دون استخدام ورقة الأنماط؟

لدي تجربة مماثلة ، مع Lighthouse 5.7.1 ، كانت درجة أدائي حوالي 91 ، ولكن Lighthouse 6 قد خفضت درجة أدائي بشكل كبير إلى حوالي 60.

تم إسقاطه من 100 إلى 79 ~ https://dougsilkstone.com/ مؤخرًا. يقفز حتى 90 عند إزالة Google Tag Manager (و Google Analytics).

سأقدم تقريرًا عن المزيد من النتائج أثناء اختبار الأشياء.

تحرير: اضغط على 100 عند إزالة الخط الذي تم تحميله من النوع gatsby-plugin-web-font-loader (أيضًا باستخدام ذاكرة التخزين المؤقت للتحميل المسبق للخطوط).

ليس لدي حتى هذه المكونات الإضافية مثبتة ، لكن نقاط هاتفي المحمول انخفضت من 90+ إلى 60 ~ 70+

كذلك هنا. انخفاض هائل من 90 إلى 60 في مواقع متعددة.

+1 نقطة انخفاض تزيد عن 30 نقطة

هل هناك من يخاطب هذا؟ يبدو أنه لا فائدة من استخدام Gatsby على Next إذا لم يقدم نتائج أفضل خارج الصندوق.

هل هناك من يخاطب هذا؟ يبدو أنه لا فائدة من استخدام Gatsby على Next إذا لم يقدم نتائج أفضل خارج الصندوق.

هل لديك أي أرقام من Next؟

أتساءل عما إذا كانت هذه الدرجات هي الوضع الطبيعي الجديد للشبكات السريعة (التي ليست ثابتة وخالية من JS ومن المحتمل أيضًا أنها خالية من الصور)

هل لديك أي أرقام من Next؟

https://nextjs.org/ حصل على 85 درجة ، مع كون كل من Largest Contentful Paint (3.8) و First Contentful Paint (2.8) هما المخالفان الرئيسيان. كما أن لديها مجموعة من "JS غير المستخدمة". هذا أقل من 95 تقريبًا في Lighthouse 5.7.1. إنه انخفاض "فقط" بنحو 10 نقاط ، بينما يبدو أن مواقع غاتسبي تخسر ضعف عدد النقاط.

أنا جديد تمامًا على هذا العالم ، لكني أتابع هذه المشكلة بعد أن فقد موقع gatsby حوالي 25 نقطة عند اختباره باستخدام lighthouse 6.0.0 من npm. ومن المثير للاهتمام ، إذا كنت أستخدم رؤى Pagespeed بدلاً من منارة npm ، فإن موقعي يعود إلى حوالي 99 تقريبًا. في حين أن gatsbyjs.org تحصل على 70 تقريبًا في إحصاءات سرعة الصفحات ، ولكن ~ 84 مع منارة نانومتر في الدقيقة. ربما يتم تعديل شيء ما في مكان ما ، على ما أعتقد؟ كل منهم يتلقون تحذيرات "JS غير المستخدمة"

هل هناك من يخاطب هذا؟ يبدو أنه لا فائدة من استخدام Gatsby على Next إذا لم يقدم نتائج أفضل خارج الصندوق.

هل لديك أي أرقام من Next؟
أتساءل عما إذا كانت هذه الدرجات هي الوضع الطبيعي الجديد للشبكات السريعة (التي ليست ثابتة وخالية من JS ومن المحتمل أيضًا أنها خالية من الصور)

موقع ويب Next.js -> https://masteringnextjs.com/ 77 درجة المحمول. الكثير من "JS غير المستخدمة".

أرى نتائج أفضل باستخدام مقاييس المنارة https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

لكنني أيضًا لا أرى الصور هناك ، ومن واقع خبرتي ، يبدو أن الصور لها تأثير كبير (ومشروع في IMO)

ومع ذلك ، لا يحتوي موقع gatsbyjs.org على صور وكانت نتيجته سيئة (نسبيًا) https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (مقارنة بمثالcbdp )

دعونا نرى ما يعتقده مطورو غاتسبي حول هذا الأمر

مع بعض التعديلات ، يعود الموقع إلى أعلى النتائج.

يبدو لي مثل حالة Google التي تحركت منشورات الهدف لتكون أكثر
صارم بشأن الأداء - ولا سيما FCP.

مواقعنا ليست بطيئة بأي حال من الأحوال ، بل يتم الحكم عليها بشكل مختلف
المعايير. سأساعد في هذا

في الثلاثاء ، 9 حزيران (يونيو) 2020 ، الساعة 18:48 مساءً ، كتب [email protected] :

هل هناك من يخاطب هذا؟ يبدو أنه لا جدوى من استخدام غاتسبي
بعد ذلك ، إذا لم تقدم نتائج أفضل خارج الصندوق.

هل لديك أي أرقام من Next؟
أتساءل عما إذا كانت هذه الدرجات هي الوضع الطبيعي الجديد للشبكات السريعة (أي
ليست ثابتة وخالية من JS ومن المحتمل أيضًا أنها خالية من الصور)

موقع ويب Next.js -> https://masteringnextjs.com/ 77 درجة المحمول. كثير
من "JS غير المستخدمة".

أرى نتائج أفضل باستخدام مقاييس المنارة
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

لكنني أيضًا لا أرى الصور هناك ، ويبدو أن الصور من تجربتي
لها تأثير كبير (ومشروع في المنظمة البحرية الدولية)

ومع ذلك ، لا يحتوي موقع gatsbyjs.org على صور كما أن نتيجته سيئة (نسبيًا)
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(بالمقارنة مع cbdp https://github.com/cbdp مثال)

دعونا نرى ما يعتقده مطورو غاتسبي حول هذا الأمر

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

أردت فقط إسقاط هذه الآلة الحاسبة المفيدة لمقارنة النتائج من v6 مع v5: https://googlechrome.github.io/lighthouse/scorecalc/

تختلف درجات Lighthouse بشكل عام كثيرًا ، حتى عند استخدامها من خلال PageSpeed ​​Insights. على سبيل المثال ، بالنسبة إلى https://www.gatsbyjs.org/ ، تلقيت كل شيء من 64 إلى 88 أداء للهاتف المحمول بعد 5 دورات. ومن ثم ، لتتبع هذه المشكلة ، قد تكون الآلة الحاسبة مفيدة لمعرفة عواقب الأوزان المختلفة على نفس المدى (ملاحظة: نظرًا لأن المقاييس مختلفة قليلاً ، يجب افتراض بعض القيم مثل FMP باستخدام القياسات السابقة).

ملاحظة: لدي هنا مقارنة بين مرحلتين من PageSpeed ​​Insights لـ gatsbyjs.org:
تشغيل 1 - v6: 67 - v5: 85
تشغيل 2 - v6: 78 - v5: 87
أكبر تأثير ناتج عن المقياس الجديد "إجمالي وقت الحظر" الذي يقل عن 70 درجة في كلا المرحلتين وله أيضًا وزن 25٪.

نعم ، للإضافة إلى Pyrax : 25٪ لكل منهما في Lighthouse v6.2. لذلك ركزنا جهودنا على معالجة هؤلاء. وجدنا:

LCP

• إزالة أي رسوم متحركة قد يتم تشغيلها عند التحميل (مثل ملف تعريف الارتباط 💩 بانر).
• يبدو أن التبديل إلى gatsby-img tracedSVG يساعد قليلاً ، نظرًا لأن لدينا صور أبطال كبيرة في معظم الصفحات. (لست متأكدًا من السبب حقًا ، بدون مزيد من التحقيق. تتحسن تجربة المستخدم قليلاً أيضًا.)

TBT

• من خلال لقطة طويلة ، يبدو أن Unused JS من تجميع Gatsby هو أكبر cuplrit (نسخة احتياطية من مستندات web.dev ) ، من خلال لقطة طويلة. هل يمكن بالتأكيد تحسين اهتزاز الأشجار على مستوى الصفحة هنا؟

يبدو أن تحديث Lighthouse الأخير قد أفسد للتو درجات أداء الجميع ، بما في ذلك نتائجهم:

موقع gatsby الوحيد الذي لم يتم طمسه حقًا هو موقع يتكون أساسًا من صفحة واحدة ويشبه 99٪ html. ولكن حتى هذا انخفض بحوالي 5-10 نقاط.

أرى عكس معظم الأشخاص ، أي أن Lighthouse في متصفح Chrome لا يزال يعرض نتائج جيدة لموقعي ، ولكن عندما يتم تشغيله على PageSpeed ​​Insights ، فإنه يسقط درجة الكمال من 20 إلى 30 نقطة ... ربما إصدار Chrome Lighthouse الخاص بي هو خلف؟ Chrome هو الأحدث ، لست متأكدًا من كيفية التحقق من إصدار Lighthouse المدمج ...

يبدو أن تحديث Lighthouse الأخير قد أفسد للتو درجات أداء الجميع ، بما في ذلك نتائجهم:

موقع gatsby الوحيد الذي لم يتم طمسه حقًا هو موقع يتكون أساسًا من صفحة واحدة ويشبه 99٪ html. ولكن حتى هذا انخفض بحوالي 5-10 نقاط.

أرى عكس معظم الأشخاص ، أي أن Lighthouse في متصفح Chrome لا يزال يعرض نتائج جيدة لموقعي ، ولكن عندما يتم تشغيله على PageSpeed ​​Insights ، فإنه يسقط درجة الكمال من 20 إلى 30 نقطة ... ربما إصدار Chrome Lighthouse الخاص بي هو خلف؟ Chrome هو الأحدث ، لست متأكدًا من كيفية التحقق من إصدار Lighthouse المدمج ...

يتم عرض إصدار Lighthouse في الجزء السفلي من التدقيق.

dylanblokhuis آه ، نعم هناك. أنا أستخدم 5.7.1 ، هل لم يتم شحن الإصدار السادس من الإصدار السادس بعد في Chrome؟

dylanblokhuis آه ، نعم هناك. أنا أستخدم 5.7.1 ، هل لم يتم شحن الإصدار السادس من الإصدار السادس بعد في Chrome؟

ليس. ليس الان على اي حال. إذا كنت تريد الأحدث ، فيمكنك تثبيته من npm ثم تشغيل lighthouse https://yoursite.com --view وستحصل على درجاتك بنفس التنسيق الذي اعتدت عليه مع تدقيق Chrome :)

بالنسبة لأي شخص آخر حقق نجاحًا كبيرًا في النتائج ، قد يكون # 24866 مناسبًا أيضًا. كان هناك تغيير مهم على ما يبدو في كيفية تعامل Gatsby مع التقسيم. في حين أن التغيير يبدو بالتأكيد منطقيًا إلى حد كبير ، بالنسبة لنا على الأقل ، فقد أدى هذا التغيير إلى أن الكود الذي تم توزيعه عبر أجزاء مركزة في commons و app القطع. وهذا يعني تحميل / تحليل js أكبر بكثير.

الشيء الأكثر إثارة للقلق هنا هو أن هذه المقاييس ستبدأ في التأثير على تصنيف الصفحة قريبًا نسبيًا.

لقد قمت بتجريد جميع طلبات الجهات الخارجية (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) وهذا فقط يعطي دفعة صغيرة نسبيًا ، لذلك هناك شيء آخر قيد التشغيل.

أيضًا ، لأي شخص يتطلع إلى تشغيل Lighthouse 6 محليًا ، فهو متاح الآن في Chrome Canary ومن المقرر شحنه إلى Chrome في يوليو في بعض الوقت.

أولاً: لقد تواصلت مع أحد مهندسي Google الذي يعمل على web.dev وسألته عن ذلك. لست متأكدًا مما إذا كان ذلك سيؤدي إلى أي تفسير أكبر ، لكن يبدو أنهم عازمون على المساعدة. سأتابع عندما تمكنت من الدردشة معهم.

ارتفعت درجات أدائي من 94-99 إلى 40-55. 😢

يتم تطبيق Largest Contentful Paint لموقع الويب الخاص بي في الغالب على الصفحات ذات الصور الكبيرة. لسبب ما ، يقول أن الصور تستغرق 14 ثانية للتحميل.

إذا فتحت أيًا من مواقع بدء تشغيل Gatsby ، فإن أي صفحات بها صور تبدو في السبعينيات كحد أقصى.

إليكم أول بادئين رأيتهم مع العديد من الصور:

ghost.gatsby.org :

gcn.netlify.app :

ومع ذلك ، فإن مدونة Gatsby للمبتدئين لديها 98 أداء (ممنوح ، إنها صفحة بسيطة للغاية تحتوي على بعض النصوص فقط):

gatsbyjs.com :

قارن النتائج القديمة بالنتائج الجديدة في Chrome

لا يزال بإمكانك مقارنة نتائج طريقة Lighthouse القديمة مقابل الجديدة بدون استخدام CLI. أجد أنه من المفيد رؤية ما تغير.

اعرض اختبارات Lighthouse القديمة

لعرض نتائج Lighthouse القديمة ، قم بتشغيل ملحق Lighthouse chrome من أدوات مطور Chrome ، بدلاً من شريط أدوات المتصفح.

عرض اختبارات Lighthouse الجديدة

انقر فوق الرمز من شريط ملحقات الكروم الخاص بك.

تتغير صفحتي

هذان هما الدرجتان اللتان لديّهما لنفس الصفحة بالضبط:

منارة قديمة (عبر أدوات تطوير Chrome)

منارة جديدة (عبر امتداد Chrome على شريط العناوين)

🤷‍♂️

nandorojo انطباعي عن الصور هو أن المحاكاة تتم باتصال بطيء حقًا وهناك ، تستغرق الصور وقتًا طويلاً ليتم عرضها

نظرًا لأن خيار إزالة الصور ليس ممكنًا دائمًا ، فربما تكون درجات السبعينيات هذه هي النتائج العادية لهذا النوع من الصفحات

ولا يبدو أن خيار تأخير تحميلها حتى يتمكن المستخدم من بدء تفاعله في وقت أقرب هو الحل (في حالتي)

مرحبًا ، آسف على الرد المتأخر. لقد عملت في Lighthouse ، سأحاول أن أشرح بقدر ما أستطيع.

نشر مطورو Chrome "مؤشرات الويب الحيوية" ، وهي مقاييس أساسية لموقع سليم. يحتوي على العديد من المقاييس ولكن الأساسي منها هو أكبر رسم محتوى (LCP) وتأخير الإدخال الأول (FID) وتحويل التخطيط التراكمي (CLS) . بالنسبة لأدوات مثل Lighthouse FID ، يتم تبديله بـ Total Blocking Time (TBT) .

يأخذ Lighthouse v6 أيضًا هذه المقاييس في الاعتبار وقد تغير. هذا لا يعني أن غاتسبي بطيء. قد تكون بعض التحسينات المختلفة ضرورية.

هكذا تغيرت الأمور:

إذا كنت تريد معرفة المزيد عن LCP ، فيجب عليك التحقق من https://www.youtube.com/watch؟v=diAc65p15ag.

فلنتحدث عن غاتسبي. لا يزال Gatsby نفسه سريعًا جدًا ونعمل على تحسينه أكثر. نحن نقوم بإنشاء واجهة برمجة تطبيقات جديدة بحيث يمكن لمنشئي الصفحات مثل MDX ، النص المنسق لـ Contentful ، ... تحسين الحزمة أيضًا. يمكن فعل الكثير من خلال تحسين LCP الخاص بك. تأكد عند استخدام الخطوط والصور ، أنها لا يتم تحميلها بشكل كسول ويتم تحميلها في أسرع وقت ممكن. يجب تحميل هذه الأصول من نفس مصدر موقعك ، ولا ينبغي تحميلها من CDN.

للأسف ، تعد TBT مشكلة يصعب حلها وهي شيء لا تعمل React على تحسينه. إذا كنت ترغب في إسقاط TBT ، فيجب عليك الخروج مسبقًا . يحتوي Preact على نفس واجهة برمجة التطبيقات مثل React لكن بصمة جافا سكريبت أصغر. يفعلون الأشياء بشكل مختلف ولكن مكونات React متوافقة. يمكنك تثبيته بتشغيل gatsby recipes preact .

بعض الأشياء التي لاحظتها عند إنشاء ملف تعريف gatsbyjs.com & gatsbyjs.org هي أنه يجب علينا تحميل تحليلات google ، وما إلى ذلك بعد وقت قصير مما نفعله الآن للتأكد من أنها لا تصبح جزءًا من TBT.

إذا نظرنا إلى .com عن طريق تأجيل analytics و GTM والتأكد من تحميل الخطوط بشكل أسرع ، يمكننا بالفعل رؤية تحسن +17. إذا أضفنا preact إلى المزيج ، سنرى +6.

يمكننا أن نفعل الشيء نفسه مع .org ، نبدأ من درجة 63. مع بعض التحسين في LCP و TBT يمكننا الوصول إلى 75.

لست متأكدًا مما يجب أن نفعله بهذه المشكلة. أشعر أنه يمكننا إغلاقها حيث لا يوجد الكثير مما يمكننا القيام به هنا. ماذا عن رأيك؟

wardpeet Ty لمزيد من البصيرة.

لقد بحثنا كثيرًا في هذا الأمر في مشروع Gatsby الكبير لدينا والذي يستخدم Contentful وسيتم استخدامه عبر مواقع متعددة بالنسبة لنا (سمات Gatsby رائعة). سأشارك بعض النتائج في حال كانت مفيدة لأي شخص آخر يبحث في هذا.

1. لدينا موقف قد لا يكون شائعًا للغاية ، لكنني رأيته بما يكفي للاعتقاد بأنه ليس فريدًا أيضًا ، حيث كان علينا استخدام useStaticQuery لالتقاط الصور القادمة من Contentful و .find one بالمعرف. كنا نعلم دائمًا أن هذا كان خطأ ولكن لم نعاقب عليه بشكل ملحوظ حتى نما حجم الموقع ليضم أكثر من 300 صورة وظهر LH6 وضربنا.

والسبب في ذلك هو أن الصور هي جزء من عمليات تضمين النص المنسق ، ولا يمكننا الرسم البياني لها على مستوى استعلام الصفحة (إنه في الأساس حقل json يحتوي Contentful على حزم لتحليلها). عند استخدام محلل حزمة Webpack ، لاحظنا وجود ملف JSON ضخم (حوالي 720 كيلوبايت) وقمنا بتتبعه ليكون البيانات من هذا الاستعلام ، والذي تم تجميعه في قالب نستخدمه لمعظم الصفحات بواسطة Webpack. هذا يعني أن كل مستخدم يزور موقعنا كان يقوم بتنزيله كجزء من مقطع قالب الصفحة بالكامل ، بغض النظر عن الصفحة التي تستخدم أي صور أم لا.

كبير woopsie من جانبنا ، ولكن إذا قام أي شخص آخر بإجراء استعلامات ثابتة كبيرة (والتي لا يمكنك بالطبع تمرير المعلمات إليها لتقليص الحجم) ، فتأكد من الانتباه لهذه المواقف ومتابعة أجزاء الحزمة الخاصة بك.

1. لقد حققنا بعض النجاح اليوم فقط باستخدام خاصية loading لصورة Gatsby على الصور الموجودة في الجزء المرئي من الصفحة (صور Hero بالنسبة لنا). كنا نحاول العمل على أكبر رسم للمحتوى وقد أسفر ذلك عن نتائج جيدة في بعض الاختبارات الأولية. هناك جزء مهم فاتني تقريبًا لهذا: إذا قمت بتعيين loading="eager" للصورة العليا ، فقد ترغب في تعيين fadeIn={false} أيضًا لتلك الصورة لأن الانتقال بين base64 وتحميله بالكامل تستغرق الصورة وقتًا مما يؤخر LCP.

هنا وثائق الدعائم التي أشير إليها والملاحظة حول fadeIn في الأسفل: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

أرغب في مشاركة لقطات الشاشة ولكن لا أعرف ما إذا كان مسموحًا لي بذلك أم لا. إذا كنت تستخدم Chrome devtools ونظرت إلى لوحة الأداء ، فسيتم منحك علامات صغيرة لطيفة ضمن صف "التوقيتات" لـ FP و FCP و FMP و LCP. عندما قمنا بالتبديل إلى تحميل الصورة الأولى بشكل حاسم ، لم نشهد فقط زيادة ~ 8-10 في درجات الأداء ولكن يمكنك رؤية تحميل علامة LCP مباشرة بعد FMP بدلاً من ثانية أو أكثر في حالتي.

أتمنى أن يساعد ذلك أي شخص في حل هذه المشكلة ، وبفضل كل من استجاب حتى الآن.

بعض الأشياء التي لاحظتها عند إنشاء ملف تعريف gatsbyjs.com & gatsbyjs.org هي أنه يجب علينا تحميل تحليلات google ، وما إلى ذلك بعد وقت قصير مما نعرفه للتأكد من أنها لا تصبح جزءًا من TBT.

wardpeet كيف يتم تأجيل Analytics و GTM؟

wardpeet شكرا

Jimmydalecleveland كانت لدينا مشكلة مماثلة حيث كنا بحاجة إلى تحميل جميع عناصر أحد الموارد حتى نتمكن من استخدام البيانات من داخل markdown لتكوين filtwr (على سبيل المثال ، لم نتمكن من التصفية باستخدام GraphQL) وتحسينها باستخدام أجزاء مختلفة (a مجموعة فرعية أصغر كثيرًا من الحقول) عند تحميل مورد كامل مقابل عند تحميل جميع الموارد للتصفية. هذا قلل بشكل كبير من JSON وبالتالي حجم الحزمة لدينا.

treyles ، يجب أن تكون حريصًا في تأخير تحميل Analytics لأنه قد يعني أن إحصاءاتك غير مكتملة. على سبيل المثال ، قد يعني ذلك أن معدل الارتداد المبلغ عنه غير دقيق. هناك بعض البرامج النصية التي لن يسمح لنا التسويق بتأخيرها (البكسل ، التحليلات ، hotjar ، وبالتالي مدير العلامات) ، لكن البعض الآخر ، على سبيل المثال ، Intercom جيد ويُعد تحسينًا مفيدًا. فيما يتعلق بكيفية تأخير هذه البرامج النصية ، عادةً ما يتم تحميل البرامج النصية التي توفرها جهات خارجية غير متزامنة ، ولكن هذا وحده لا يكفي. ما ستحتاج إلى القيام به على الأرجح هو استبدال هذه البرامج النصية بأخرى خاصة بك. استمع إلى window.load ، ثم ابدأ التنزيل. يجب أن تكون حريصًا على الرغم من أن بعض البرامج النصية تعتمد على window.load للتهيئة ، وإذا كنت قد استخدمتها لتحميل البرنامج النصي ، فلن يتم إطلاقه مرة أخرى ، لذلك تحتاج إلى تهيئتها يدويًا. على سبيل المثال مع الاتصال الداخلي نحن:

• أزال degault <script>...</script> المقدم من Intercom.
• أضاف مستمعًا لـ window.load
• أضاف تأخيرًا قصيرًا داخل هذا المستمع
• أطلق البرنامج النصي الافتراضي لـ Intercom لنسخة معدلة والذي قام بتحميل lib async.
• استقصاء لمعرفة متى تم تحميل البرنامج النصي (لا يوفر الاتصال الداخلي حدثًا موثوقًا به)
• تهيئة البرنامج النصي يدويًا (والذي تم إجراؤه على page.load بواسطة البرنامج النصي الافتراضي).

wardpeet شكرا على البصيرة المفيدة جدا!

بخصوص هذا الحل:

تأكد عند استخدام الخطوط والصور ، أنها لا يتم تحميلها بشكل كسول ويتم تحميلها في أسرع وقت ممكن. يجب تحميل هذه الأصول من نفس مصدر موقعك ، ولا ينبغي تحميلها من CDN.

ألن يتعارض هذا مع طريقة عمل صورة غاتسبي؟ أيضًا ، تتعامل معظم أنظمة إدارة المحتوى مع تحويل الصورة على الخادم ويتم استضافتها في شبكة CDN الخاصة بها. (وهو أمر جيد ، المنظمة البحرية الدولية). ولكن إذا قمنا باستضافته في موقعنا الخاص ، ألن يؤدي ذلك إلى نتائج عكسية أيضًا؟

إضافة إلى ما قاله Undistraction ، فإن Gatsby سريع ولكن إذا لم يكن سريعًا وفقًا لعيون Google ، فسيصبح مشكلة. خاصة وأنهم يدرجون هذا في تحديث ترتيب الصفحة العام المقبل.

Jimmydalecleveland لقد وجدت طريقة للعمل مع صورة gatsby داخل النص المنسق الجوهر . تم نسخ الكود ولصقه من gatsby-source-contentful . في الأساس ، يمكنك إنشاء السائل المليء بالمحتوى أو الدعائم الثابتة خارج GQL. وهو مثالي للنص الغني للمحتوى.

لقد أنشأت أيضًا طلب سحب حتى نتمكن من الوصول إلى واجهات برمجة التطبيقات مباشرة من gatsby-source-contentful .

شيء ما فقط لا يضيف لي. لقد أنشأت موقعًا مبسطًا للغاية يحتوي على صورة لكل صفحة ، وأنا أستخدم SVG للصور بدون gatsby-image ، كما حاولت إزالة تحليلات google وهذا لم يحدث فرقًا كبيرًا ، وكانت درجتي حوالي 50-60 للأداء.

الشيء المحير حقًا بالنسبة لي هو أن الصفحة الرئيسية فقط (index.js) تحصل على درجة منخفضة جدًا ، بينما تحصل الصفحات الأخرى مثل صفحة الخدمات أو صفحة الاتصال على درجة ~ 80. لقد قمت ببناء هذا الموقع بشكل متسق إلى حد ما وبالتالي لا يوجد فرق هائل بين الصفحات ومع ذلك ، لسبب ما ، حصلت الصفحة الرئيسية على درجة ~ 50 بينما حصلت صفحات الخدمات على درجة ~ 80.

كما ذكرت سابقًا ، مع lighthouse v5 ، كانت النتيجة ~ 90 ، فليس من المنطقي على الإطلاق أن يكون موقعًا بسيطًا مثل هذا الآن درجة منخفضة تصل إلى ~ 50.

راجع للشغل ، هل حاول أي منكم تعيين الصورة في الجزء المرئي من الصفحة على أنها eager ؟
يؤدي هذا إلى تعطيل التحميل البطيء وقد يؤدي إلى زيادة النتيجة. تمويه أو svg
قد تؤدي تأثيرات التحميل إلى إرباك Lighthouse (إذا كان الأمر كذلك
عيب في الخوارزمية الخاصة بهم).

في يوم السبت 13 يونيو 2020 الساعة 10:48 صباحًا كتب t2ca [email protected] :

شيء ما فقط لا يضيف لي. لقد أنشأت موقعًا بسيطًا للغاية
مع صورة لكل صفحة تقريبًا ، فأنا أستخدم SVG للصور بدون gatsby-image ،
لقد حاولت أيضًا إزالة تحليلات google ولم يحقق ذلك الكثير
الاختلاف ، كانت نتيجتي حوالي 50-60 للأداء.

الشيء الذي يحيرني حقًا هو أن الصفحة الرئيسية فقط
(index.js) تحصل على درجة منخفضة جدًا ، بينما تحصل الصفحات الأخرى مثل
تحصل صفحة الخدمات أو صفحة الاتصال على درجة ~ 80. لقد بنيت هذا
موقع متسق إلى حد ما ، وبالتالي لا يوجد فرق كبير بين
الصفحات ومع ذلك ، لسبب ما ، حصلت الصفحة الرئيسية على درجة ~ 50 في حين أن
تحتوي صفحات الخدمات على نقاط ~ 80.

كما ذكرت سابقًا ، مع lighthouse v5 ، كانت النتيجة ~ 90 ، فقط
لا معنى على الإطلاق أن موقعًا بسيطًا مثل هذا سيكون له الآن قيمة منخفضة
درجة ~ 50.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

KyleAMathews لدينا ، وقد حقق زيادة كبيرة في درجات الأداء والدهانات الأولى. هذا ما أشرت إليه في النقطة 2 في تعليقي المطول أعلاه. إن إلغاء fadeIn هو ما جعل LH سعيدًا في النهاية.

تحرير : أنا ، عن جهل على الأرجح ، أشعر أن التركيز على LCP ليس هو النهج الصحيح الذي يجب اتباعه عالميًا مع الاهتمام بالصور. من الواضح أنه قصصية ، لكنني أشعر أن موقع الويب يشعر بأنه أسرع بكثير عندما يتم تحميل كل المحتوى وتتلاشى الصور في الكلمات اللاحقة ، ما لم تكن الصورة مهمة للمحتوى.

قد يكون أحد الأمثلة الشائعة هو مقالة متوسطة. بالتأكيد ، يمكنك القول أن هذا عيب في التصميم ، ولكن معظم المقالات المتوسطة (والعديد من المدونات الأخرى) تبدأ بصورة كبيرة في الجزء العلوي مخصصة فقط لإنشاء الحالة المزاجية أو المناظر الطبيعية ولا يهمني إذا كان التحميل كسولًا .

راجع للشغل ، هل حاول أي منكم تعيين الصورة في الجزء المرئي من الصفحة على أنها eager ؟ يؤدي هذا إلى تعطيل التحميل البطيء وقد يؤدي إلى زيادة النتيجة. قد تكون تأثيرات التحميل الضبابي أو svg مربكة لـ Lighthouse (إذا كان هذا هو الحال فهو خلل في الخوارزمية).
...

سأحاول هذا الآن.

أعتقد أنني أحرزت بعض التقدم الجيد هنا. حصلت على درجات من 57 إلى 84 مع تغييرات أساسية للغاية. انتقل LCP الخاص بي من 12 ثانية إلى 2 ثانية .

ومع ذلك ، فهو غير متسق. منذ إجراء التغييرات التي سأصفها أدناه ، تتراوح درجاتي من 69 إلى 84. من الواضح أن هناك بعض التباين العشوائي في درجات الأداء.

TLDR

أولا، مثلKyleAMathews وJimmydalecleveland المقترحة، حاولت وضع loading="eager" و fadeIn={false} على بلدي مكونات الصورة غاتسبي التي كانت فوق أضعاف.

بعد ذلك ، تخلصت من base64 من استفساراتي.

هذه أحدثت فرقا كبيرا.

الخير

• أدت إضافة _noBase64 إلى أجزاء الصورة إلى زيادة نتيجتي بمقدار 20 نقطة!

  • يبدو أن صور base64 تضيف الكثير من الوزن على الهاتف المحمول. أنا أستعلم عن الصور من المحتوى باستخدام 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 الخاص بي على موقع الويب الخاص بي يبدو الآن أسوأ بكثير. تتلاشى base64 + في توفير تجربة مستخدم رائعة. الآن ، إنه متقطع بعض الشيء. أعتقد أن هذه مقايضة علينا التفكير فيها الآن؟

قبل وبعد eager و fadeIn={false}

فيما يلي بعض المقارنات جنبًا إلى جنب لنفس الصفحات بالضبط. الفرق الوحيد هو أنه على اليمين ، الصور بها loading="eager" و fadeIn={false} .

1. الصفحة الرئيسية

LCP انخفض بنسبة 49٪. نقاط الأداء تصل 6 نقاط.

2. صفحة المنتج

LCP انخفض بنسبة 46٪. نقاط الأداء تصل 7 نقاط.

الغريب في هذا المثال أعلاه: لقطات الشاشة على اليسار لها سلوك gatsby-image الافتراضي (إنها تتلاشى ، وليس لديها eager on.) ومع ذلك ، على الرغم من أن درجة الأداء أقل ، فإن لقطات الشاشة الصغيرة في الأسفل تجعلها تبدو وكأنها يتم تحميلها أسرع من الصورة الموجودة على اليمين.

ربما يكون ذلك ضمن هامش الخطأ بالنسبة لكيفية حكمهم على الأداء ، أو ربما يكون خطأ في نهايتهم يتعلق بالتلاشي في الواقع ، كما ذكر KyleAMathews .

بعد تعيين _noBase64 في أجزاء الصورة

هذه هي نفس الشاشات مثل المثال أعلاه. جميعهم لديهم دعائم loading="eager" و fadeIn={false} على صورة Gatsby كما أن أجزاء الصورة في graqhql هي GatsbyImageSharpFluid_withWebp_noBase64

إنه أمر لا يمكن تفسيره بعض الشيء ، لكنني أجري اختبار المنارة على نفس الصفحة مرارًا وتكرارًا ، وحصلت على 84 و 75 و 69.

كندة غريبة ، لكن على أي حال ، فقد رفعت درجاتي.

أعتقد أن خوارزمية Lighthouse كانت تشعر بسخاء غير عادي هنا lol ^

بعد مزيد من التحقيق ، اكتشفت أن Lighthouse كانت تشكو من عنصر معين كان يؤثر على درجة LCP.

كل ما فعلته هو مجرد تحريك هذا العنصر الذي هو مجرد فقرة وقفزت درجتي فوق 80. اذهب الرقم. لست متأكدًا تمامًا من سبب نقل فقرة إلى زيادة درجاتي من ~ 50 إلى ~ 80.

nandorojo شكرًا على الكتابة الشاملة. لم نحاول إزالة base64 تمامًا ، لكننا سنكون مصدر إزعاج إذا اضطررنا لذلك. نحن أيضًا نضع تحميلًا شديدًا على الصورة الأولى للصفحة فقط ، لذلك إذا لم تكن تفعل ذلك بالفعل ، فإن الأمر يستحق المحاولة إذا كان بإمكانك التحكم في ذلك.

بعد مزيد من التحقيق ، اكتشفت أن Lighthouse كانت تشكو من عنصر معين كان يؤثر على درجة LCP.

كل ما فعلته هو مجرد تحريك هذا العنصر الذي هو مجرد فقرة وقفزت درجتي فوق 80. اذهب الرقم. لست متأكدًا تمامًا من سبب نقل فقرة إلى زيادة درجاتي من ~ 50 إلى ~ 80.

@ t2ca هذا ما حصلت عليه (وإن كان لي كان علامة رأس). ولكن إلى أين نقلته؟

@ t2ca هذا ما حصلت عليه (وإن كان لي كان علامة رأس). ولكن إلى أين نقلته؟

michaeljwright أول شيء فعلته هو حذف الفقرة والتحقق من نتيجة المنارة. بعد أن حذفت الفقرة ، زادت نتيجتي بنحو 20 نقطة. كررت الاختبار عدة مرات فقط للتأكد. لقد أعيدت أيضًا الفقرة إلى الوراء وقمت بإجراء مزيد من الاختبارات وكان قرحي منخفضًا مرة أخرى.

أخيرًا ، قررت فقط نقل الفقرة ، Im باستخدام Framer-motion داخل div وقمت بنقل الفقرة خارج div. هذا يعطيني نفس النتيجة مثلما قمت بحذف الفقرة.

@ t2ca أعتقد أن LCP تعاقب أي رسوم متحركة في صفحات الأبطال لدينا والتي تعتبر مشكلة.

إليك درجات LCP الخاصة بي حيث تكون علامة الفقرة هي LCP

مع الرسوم المتحركة:

بدون رسوم متحركة:

@ t2ca أعتقد أن LCP تعاقب أي رسوم متحركة في صفحات الأبطال لدينا والتي تعتبر مشكلة.

إليك درجات LCP الخاصة بي حيث تكون علامة الفقرة هي LCP

مع الرسوم المتحركة:

بدون رسوم متحركة:

@ daydream05 شكرًا لك على التأكيد!

ههههههههههه

ألن يتعارض هذا مع طريقة عمل صورة غاتسبي؟ أيضًا ، تتعامل معظم أنظمة إدارة المحتوى مع تحويل الصورة على الخادم ويتم استضافتها في شبكة CDN الخاصة بها. (وهو أمر جيد ، المنظمة البحرية الدولية). ولكن إذا قمنا باستضافته في موقعنا الخاص ، ألن يؤدي ذلك إلى نتائج عكسية أيضًا؟

لا ، لأن gatsby-image تعمل مع الصور المحلية أيضًا ، فلا داعي لاستضافتها على شبكة توصيل محتوى مختلفة. يعود الأمر كله إلى تحسين العرض الأول (ما هو موجود في منفذ العرض). تعني استضافته على مجال / CDN مختلف أنه يتعين عليك فتح اتصال جديد (حل نظام أسماء النطاقات ، مصافحة tls ، ...) يمكن أن يستغرق هذا ما يصل إلى 300 مللي ثانية على جهاز بطيء ثم لا يزال يتعين عليك تنزيل صورتك.

إضافة إلى ما قاله Undistraction ، فإن Gatsby سريع ولكن إذا لم يكن سريعًا وفقًا لعيون Google ، فسيصبح مشكلة. خاصة وأنهم يدرجون هذا في تحديث ترتيب الصفحة العام المقبل.

سنعمل على تحسين Gatsby بشكل أكبر للتأكد من أن مستخدمينا يمكنهم الحصول على 100 مجانًا.

@ t2ca أعتقد أن LCP تعاقب أي رسوم متحركة في صفحات الأبطال لدينا والتي تعتبر مشكلة.

هذا متوقع لأن شاشتك لا تتوقف أبدًا عن الرسم. عادةً يجب أن يتجاهل LCP الرسوم المتحركة لـ CSS ، لكن ذلك يعتمد على كيفية قيامك بالرسوم المتحركة.

@ t2ca

إذا كان بإمكانك أن تبين لنا الموقع ، فيمكننا المساعدة في معرفة كيفية تحسينه ، ولكن من المحتمل أن يكون ذلك هو وضع الصورة على نحو شغوف.

تضمين التغريدة

رائع الكتابة! هل هناك أي فرصة لتزويدنا بروابط لتقارير المنارة تلك؟

هذا متوقع لأن شاشتك لا تتوقف عن الرسم ...

wardpeet هل تمانع في التوسع في هذا من فضلك؟

DannyHinshaw تلقيت هذا الشرح من المنارة
"ما أعتقد أنه يحدث هو أن LCP يهتم بتحميل الصور بالكامل والوقت الذي يتم الإبلاغ عنه هو عندما يتم تحميل الصورة بالكامل وليس عندما تكون مرئية لأول مرة. يمكن أن تختلف هذه المرة بسبب الصور التقدمية والدهانات التكرارية. "

ثم هذا الرابط ، ربما يساعد
https://web.dev/lcp/#when -is- أكبر- محتوى- رسم- ذكرت

في هذه الأثناء ، ما يمكنك تجربته أيضًا هو تغيير Largest Contentful Paint (LCP) من صورة إلى نص (إذا كان لديك الرفاهية) ، والتحميل المسبق / الجلب المسبق للخطوط وتحميل الصور كسول. في حالتي ، كان هذا يعني تقليل حجم صورة البطل على الهاتف المحمول مما عزز درجاتنا مرة أخرى في التسعينيات العليا أثناء مناقشة المشكلة.

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 في الحسبان رسوم CSS المتحركة (الانتقال ، دعائم الرسوم المتحركة في css). ومع ذلك ، إذا كان لديك محتوى يستخدم setTimeout / setInterval يقوم بتبديل مكون التفاعل ، فسيأخذ ذلك في الاعتبار. سوف يمنحك النهج الأخير درجات CLS سيئة حقًا.

لذلك إذا كنت تريد تحريك نص / صورة بطلك. الرجاء استخدام الرسوم المتحركة css.

مرحبا،

حاولت معرفة سبب تسجيل مشروعي منخفضًا جدًا في Google Page Speed ​​Insights ومراجعة Google Lighthouse والمزيد.

بعيدًا عن البدء من نقطة الصفر ، لست متأكدًا من المشكلة. لقد استخدمت هذا المبدئ / المظهر للبدء: https://github.com/alexislepresle/gatsby-shopify-theme

أنا في الغالب وأنا بصدد عملية تغيير أشياء css مثل الانتقال من bulma إلى chakra-ui.

هذا هو الريبو الخاص بي: https://github.com/Chizzah/genesis-style
حاولت إزالة جميع عناصر الحساب وأشياء gatsby-plugin-appollo-shopify لكن هذا لا يغير الأشياء.

ها هو الرابط المباشر: https://genesis-style.netlify.app

لا شيء يبدو أنني أفعله يغير الأشياء. أفضل ألا أضطر إلى البدء من الصفر. إذا كان بإمكان أي شخص أن يعطيني تلميحًا أو شيئًا ما سأقدره.

أعتقد أنني اعتدت على إعطاء غاتسبي 90-100 ثانية مجانًا

شكرًا على هذا الموضوع حيث يلزم إجراء مناقشة حول تحقيق درجات جيدة في المنارة. أصبحت الدرجات الرائعة أكثر صعوبة مع الإصدار السادس ، ويرجع ذلك في الغالب إلى مقياس LCP الجديد. انخفض موقعي (https://www.jamify.org) من ~ 100 إلى ~ 70 باستخدام Lighthouse v6.

من أجل إعادته إلى 100 على سطح المكتب ، كان علي أن أفعل ذلك

• إزالة صورة الخلفية التي لم تكن مطلوبة (حيث تم اختيارها بشكل خاطئ على أنها LCP)
• تحسين حجم الصور
• عيّن gatsby-image إلى loading="eager" و fadeIn=false
  (هذا حقًا مصدر إزعاج لأنني أحب تأثير التمويه)

على الهاتف المحمول ، ما زلت عالقًا في 80 ، مرة أخرى بسبب LCP لمدة 5 ثوانٍ. يمكن تحسين ذلك عن طريق تغيير حجم الصور بشكل صحيح خصيصًا للجوال:

بشكل عام ، هذه التحسينات ممكنة إلى حد كبير ، ومع ذلك ، فأنا غير سعيد تمامًا لأنني مضطر الآن إلى الاختيار بين الصور البطيئة ذات التحميل الضبابي أو درجة Lighhouse الجيدة: roll_eyes:

هل أجرى أي شخص أي اختبارات حتى الآن على Lighthouse v6.1؟ لقد لاحظت تحسنًا في درجة أدائي.

تم سؤال Addy من Google عن مشكلة blur-up LCP وهو شيء يعملون على إصلاحه https://twitter.com/addyosmani/status/1277293541878673411

الدرس المستفاد هنا هو عدم التعامل مع نتائج الأداء الجديدة على أنها مطلقة حتى الآن - فهي تعمل على تحسين الحالات المتقدمة.

أعتقد أن المشكلة تزداد سوءًا مع Lighthouse 6.1. هناك بعض الاقتراحات الجيدة هنا حول LCP ولكننا لا ننظر كثيرًا إلى TBT والتي أعتقد أنها السبب الأكبر للنتائج السيئة على الهاتف المحمول والأكثر صعوبة في حلها.

يمكنك اختبار Lighthouse 6.1 في Chrome Canary. لقد قارنت موقعي بين 6.0 و 6.1 ، بالإضافة إلى العديد من المواقع الأخرى المذكورة هنا وزادت TBT بشكل كبير. على سبيل المثال في اختبارات 6.1 الخاصة بي:

• gatsbyjs.org TBT: 2550 مللي ثانية
• موقعي TBT: 2200ms
• موقع styxlab TBT: 1250 مللي ثانية

أي شيء يزيد عن 600 بالنسبة إلى TBT يكون باللون الأحمر والوزن وفقًا للآلة الحاسبة هو 25٪ لذلك يعد عاملًا رئيسيًا. ينتج TBT عن وظائف تستغرق أكثر من 50 مللي ثانية لتنفيذها بين FCP و Time to Interactive.

لقطة الشاشة أعلاه هي ملف تعريف من موقعي. إذا كنت تستخدم Lighthouse في Chrome ، فيمكنك النقر فوق الزر View Trace لتحميل النتائج في علامة تبويب ملف التعريف لترى نفس الشيء. أي مهمة بعد FCP بعلم أحمر في الزاوية تحسب نحو TBT. ما زلت بحاجة إلى البحث عن المهام ، لذا ربما يمكن لشخص لديه معرفة أكبر بـ Gatsby المساعدة في هذا المجال وربما يستطيع

IanLunn هذا أثر مثير للاهتمام ، هل تمكنت من تكوين فكرة عما كانت تحته تلك المهام؟

من المحتمل أن يكون هناك ارتباط بين مقدار JS لكل موقع من مواقع Gatsby ومدى تكلفته في الخيط الرئيسي للمتصفح. ومع ذلك ، أعتقد أن المجال المفتوح للمناقشة يمكن أن يكون ، هل هناك طريقة يمكن أن يساعد بها Gatsby في "تخفيف" التأثير من خلال كيفية تحميل الاستعلامات والنصوص تمامًا؟

هناك ثلاثة مجالات أحاول فهمها بشكل أفضل في الوقت الحالي:

• يضيف Gatsby افتراضيًا <link rel=preload/> لكل نص برمجي مطلوب (وفقًا لنمط PRPL ) بغض النظر عن عدد البرامج الموجودة. لقد لاحظت بعض الاختلافات في FCP المقاسة (التي فوجئت بها كثيرًا) ولكن في الغالب في الفجوة بين FCP / LCP عند إزالة هذه (والتي ربما لا تكون فكرة جيدة الاستغناء عن تغييرات أخرى). يناقش هذا الموضوع على المنارة الأخير.
• تنتهي الاستعلامات بإنشاء JSONs (page-data.json والأخرى المجزأة للاستعلامات الثابتة) والتي يتم تقييمها في سلسلة المحادثات الرئيسية. راجع https://github.com/gatsbyjs/gatsby/issues/18787 ولكن لا يبدو أننا وجدنا (أو إذا كان هناك) بديلًا لا يحظر الموضوع الرئيسي. كلما كانت البيانات أكبر ، زادت نسبة الأداء (لذا ستكون ميزانيات الأداء الخاصة بأحجام الاستعلام موضع ترحيب كبير بالتأكيد) - لكن البيانات ليست ضرورية حقًا حتى عملية معالجة الجفاف ، أم أنها كذلك؟
• تتم إضافة الأجزاء الفعلية كـ <script src=foo.js async /> في نهاية </body> . هذا يعني أنه بمجرد أن ينتهي المتصفح من تحليل HTML (والذي يجب أن يكون قريبًا جدًا في التتبع) ، سيبدأ في تحليل وتنفيذ هذه البرامج النصية (حيث تم تحميلها مسبقًا). ستنشأ المهام الطويلة حتمًا حيث يُطلب من الخيط الرئيسي تحليل كل جافا سكريبت وتنفيذها. هل هناك طريقة أفضل للتعامل مع هذا (على الأقل _ عند بدء تحليل هذه البرامج النصية) لتجنب حظر سلسلة المحادثات الرئيسية؟ هل هناك أي طريقة للقيام بذلك (إما التحليل أو التنفيذ) في المهام الصغيرة الإضافية التي لا تؤخر تغذية مرتدة المدخلات (وبالتالي تضر TTI) ، ولا تمنع الخيط الرئيسي في أجزاء من الوقت (وبالتالي تضر TBT)؟

في حين أنه في الوقت الحالي ، يتم معاقبة مواقع Gatsby بشكل صحيح نظرًا لأن LCP لم يتعرف بعد على نمط LQIP من gatsby-image - عندما يتعلق الأمر بأي شيء متعلق بـ TBT / TTI (وربما عقوبة كبيرة على تكلفة Javascript مقارنة بـ Lighthouse v5) لا أعتقد أن هناك أي شيء في خارطة طريق فريق Lighthouse حيث ستتحسن الأمور من النتائج الحالية.

juanferreras يبدو أن المهمة الأكبر هي domready / ready.js (جهة خارجية). لدي شعور بأن بيانك حول Lighthouse معاقبة JavaScript صحيح ، وعلى الرغم من أن التحسينات الصغيرة قد تكون ممكنة في Gatsby ، إلا أنه ليس شيئًا قابلاً للحل.

إذا كانت هذه هي الطريقة التي ستكون عليها في Lighthouse ، فأنا أميل إلى أن أطلب منهم على الأقل تقليل وزن TBT أو إعطاء خيار إعداد بيئة الاختبار المطلوبة. لا يعد تقديم النتيجة بناءً على هاتف ذي ميزانية مناسبة دائمًا للموقع الذي يتم اختباره. يجب أن نكون قادرين على إظهار الرؤساء / العملاء أنه نعم ، الهاتف ذو الميزانية المحدودة يحصل على درجة 75 ولكن الهاتف ذو الجودة الأعلى الذي حصل 95٪ من مستخدمينا على 90 درجة على سبيل المثال.

• تنتهي الاستعلامات بإنشاء JSONs (page-data.json والأخرى المجزأة للاستعلامات الثابتة) والتي يتم تقييمها في سلسلة المحادثات الرئيسية. انظر # 18787 ولكن لا يبدو أننا وجدنا (أو إذا كان هناك) بديلاً لا يحظر الموضوع الرئيسي. كلما كانت البيانات أكبر ، زادت نسبة الأداء (لذا ستكون ميزانيات الأداء الخاصة بأحجام الاستعلام موضع ترحيب كبير بالتأكيد) - لكن البيانات ليست ضرورية حقًا حتى عملية معالجة الجفاف ، أم أنها كذلك؟

juanferreras ، بخصوص مسألة تحليل بيانات json على الخيط الرئيسي ، ما يتبادر إلى الذهن هو عامل الويب. يمكن لـ Gatsby تسجيل عامل الويب إذا كان متاحًا على العميل ، وتخزين هذه الأنواع من الأشياء مؤقتًا له ، فإن عملية معالجة الجفاف ليست ضرورية حقًا على الفور ، لذلك أعتقد أن هذا ممكن

عامل الويب مدعوم في المتصفحات الرئيسية بما في ذلك ie10.

... نحن لا ننظر كثيرًا إلى TBT والتي أعتقد أنها أكبر سبب للنتائج السيئة على الهاتف المحمول والأكثر صعوبة في حلها.

أرغب في إضافة شيء أعتقد أنه ذو صلة بوقت الحظر الإجمالي. بعد مراجعة الحزم الخاصة بي باستخدام محلل حزم Webpack ، لاحظت أن البيانات من الاستعلامات الثابتة مضمنة في حزم JavaScript. أنا متأكد من أن هناك سببًا جيدًا لذلك ، لكنه يعمل ضد انخفاض ثلاثي بوتيل القصدير.

تعتبر TBT مشكلة يصعب حلها خاصةً لأن React ليست مصممة لها. يعد الانتقال إلى ما قبل الفعل خطوة أولى جيدة. سنعمل على تحسين TBT أكثر وأكثر في الأشهر القادمة ، ونريد أن يكون لـ Gatsby بصمة صغيرة حقًا.

في إصدار gatsby> 2.24.0 ، قمنا بشحن دعم polyfill المحسّن ، لذلك نقوم فقط بتحميل polyfill على المتصفحات القديمة مثل IE11. لقد أزلنا أيضًا الاستعلامات الثابتة من حزمة الويب ، منذ بضعة أيام (MarkosKon).

Teclone للأسف لا يتمتع العاملون على الويب بالعظمة لتحليل JSON. لا تزال تدفع ثمن إجراء التسلسل وإلغاء التسلسل بين الخيوط. مع ShardArrayBuffer ستكون قصة مختلفة ، للأسف يتم تعطيلها افتراضيًا بسبب الانهيار / الشبح

كنت أحصل على 100/100 بشكل رائع على كل شيء في Lighthouse (6.0) المدمج في Chrome ثم استخدمت إصدار web.dev (6.1) وعاد بأداء في السبعينيات بسبب LCP (حوالي 5-6 ثوانٍ 6.1 ، حوالي 0.5 ثانية في 6.0). إنها صورة رأس مزخرفة (باستخدام gatsby-background-image) تشكو منها.

بالنظر إلى موقع الويب الخاص بي ، فإن وقت تشغيل Webpack يحتوي على أكبر قدر من وقت تنفيذ جافا سكريبت. شيء لا تحتاجه الصفحة حتى يبدأ المستخدم في التفاعل مع الصفحة.

يبدو أن Gatsby يقوم فقط بتحميل كل هذه الموارد (أجزاء) في وقت واحد. ملف js نفسه صغير جدًا ، إنه أداة تحميل ، يمكنك أن ترى أن الأمر يستغرق 2 مللي ثانية فقط لتمرير الملف. لكن الملف نفسه يقوم بتحميل أجزاء وملفات قالب.

في الواقع ، عندما أقوم بفحص الملفات المقتطعة ، اكتشفت أن جميعها عبارة عن واردات ديناميكية ، ونأمل أن يتم تحميلها فقط عند الحاجة إليها ، ولكن كلا ، يتم تحميلها جميعًا بشكل افتراضي. هذا السلوك ليس ما أتوقعه.

لقد أجريت قدرًا معقولًا من التحسين لصورة العنوان لدينا مثل استخدام صورة مباشرة بدلاً من Gatsby-Image وتقليل الدقة والضغط ، وصورتنا أفضل قليلاً. فقط ، لقد اكتشفت للتو الطريقة الصعبة التي لا يدعم بها Safari WebP (grr). ولا يزال الأمر كذلك أن إصدار الويب من Lighthouse أقل تسامحًا بكثير من الإصدار المدمج في Chrome ، على الأقل بالنسبة لموقع التطوير "المخفي" الخاص بنا. سيحدد الوقت ما إذا كانت بيانات المستخدم المجمعة مفيدة بمجرد نشرها - لست مقتنعًا بوجود العديد من مستخدمي Moto G5s في العالم الحقيقي!

derykmarl يجب دعمه قريبًا: https://www.macrumors.com/2020/06/22/webp-safari-14/
لا أفهم لماذا استغرقت Apple الكثير من الوقت لدعم تنسيق صورة واسع الانتشار ...

قرأت أن Pagespeedinsight يحاكي كيفية احتساب النتيجة. يبدو أنهم لا يخنقون الشبكة حتى تتمكن من الحصول على تقريرك بشكل أسرع. أنا شخصياً أستخدم https://lighthouse-metrics.com/ لكنها لا تدعم 6.1 حتى الآن.

تكمن مشكلة Lighthouse 6.x في أنها تعتمد على توقيت الإدراك ، يمكنك إجراء نفس الاختبار 10 مرات ولن تحصل على نفس النتائج اعتمادًا على ظروف الشبكة.

لقد عادت بأداء في السبعينيات بسبب LCP

كان لدي LCP والذي كان صورة الخلفية لموقع الويب الخاص بي ، تمكنت من قطع LCP بشكل كبير عن طريق تقسيم الصورة إلى 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 في ملاحظة TBT / TTI ، قد نتمكن من رؤية كيف تعمل المواقع الأخرى القائمة على التفاعل الآن على تخفيف التأثير الكلي على الموضوع الرئيسي للمتصفح.

يبدو أن موقع Reactjs.org (والذي تم إنشاؤه أيضًا باستخدام Gatsby على حد علمي) يحتوي على TTI أصغر بكثير (7-8 ~ vs 12 ~) من موقع gatsbyjs.com الجديد (تهانينا على الإطلاق بالمناسبة!). احتفظ NextJS أيضًا بأرقام جيدة جدًا على TTI / TBT على الرغم من كونه قائمًا على React (قد يكون أيضًا بسبب الحجم النسبي للنصوص - حيث يحتوي gatsby.com على حوالي 628.3 كيلوبايت من النص وفقًا لـ PSI ، reatjs.org 466.1 كيلوبايت و nextjs.org 216.8 كيلوبايت فقط)

(من الواضح أن هذا تشغيل واحد ولا ينبغي استخدامه كمقارنة فعلية ، لكن الاتجاه ثابت إلى حد كبير عبر عدة عمليات).

هل يرجع معظم فرق النتيجة إلى التكلفة الإجمالية لـ Javascript ™؟ إذا قام فريق Gatsby بتحسين موقع الويب الجديد في وقت ما ، فقد تكون هذه فرصة رائعة لمشاركة بعض الأفكار حول العملية ، بشرط ألا يكون هناك الكثير من السحر المتبقي لإضافته إلى كيفية تعامل إطار gatsby بالفعل مع جافا سكريبت داخليًا.

juanferreraswardpeet ، هناك أيضًا شيء اكتشفته في مشروعي الخاص. إذا كنت تستخدم مكونات نمطية ، فبعض الأسباب ، تتم إعادة حساب / تجديد الأنماط أثناء الترطيب وإعادة حقنها في المتصفح. هذا يأخذ الكثير من الموضوع الرئيسي.

هذا بسبب مشاكل الماء في غاتسبي. https://github.com/styled-components/styled-components/issues/2171

يعمل Gatsby أيضًا على تشغيل ssr أثناء التطوير ، https://github.com/gatsbyjs/gatsby/issues/25729 ، وهذا سيساعد في اكتشاف هذا النوع من مشاكل الأداء. جدا.

تضمين التغريدة

لا يبدو أن https://github.com/styled-components/styled-components/issues/2171 يقدم حلاً. كيف أصلحته في مشروعك؟

dfguo ، في الوقت الحالي ، لا يوجد حل لذلك ، لأنه لا أحد يعرف بالضبط لماذا يتم تجديد الأنماط أثناء معالجة الجفاف لأن gatsby في الإنتاج لا يقدم مساعدة في التطوير مع أخطاء معالجة الجفاف.

أي أنه لا يوجد سجل وحدة تحكم من اختلافات تأشير React أثناء معالجة الجفاف لأنه معطل في إنشاء إنتاج gatsby.

الغرض من هذا العمل قيد التقدم # 25729 هو تشغيل SSR حقيقي قيد التطوير ، لذلك سنتمكن من معرفة السبب. بما في ذلك فريق غاتسبي.

راجع للشغل ، يمكنك إنشاء موقع Gatsby باستخدام gatsby build --no-uglify لإنشاء موقعك مع إصدار التطوير من React لمشاهدة السجلات. https://www.gatsbyjs.com/docs/gatsby-cli/#build

سيكون Dev SSR مفيدًا للغاية في المستقبل لأشياء مثل هذه!

لذلك ، قررت ترحيل موقعي من @emotion و theme-ui إلى linaria أثناء تنفيذ الوضع dark-light باستخدام متغيرات css المخصصة

كان الهدف هو تقليل وقت الحظر / الخيط الرئيسي / أي شيء متعلق بـ js ، نظرًا لأن css لم يعد يتم تقييمه في وقت التشغيل ولكن تم تجميعه في وقت الإنشاء (في الواقع يبدو linaria أكثر توافقًا مع gatsby كشوفات أكثر من @emotion في هذا الصدد)

العملية ليست سلسة تمامًا ، فمعظم الأشياء التي قمت بها باستخدام @emotion تعمل فقط بـ linaria ، لكن البعض الآخر لا يفعل ذلك ، ويجب عليك إعادة كتابتها و / أو إعادة تنفيذها من خلال css المخصصة المتغيرات

تجربة DX مع gatsby سيئة __إعادة التحميل السريع لا تعمل (عليك التوقف والبدء من جديد عند أي تغيير حيث يبدو أن المتصفح يفقد الاتصال) ، ولكن بشكل عام كانت العملية لطيفة لأنها تجبرك على أن تكون أكثر وعياً بشأن ما هل تحتاج حقًا من قدرات وقت تشغيل emotion

__مع ذلك ، مقاييس المنارة متشابهة جدًا__

يمكنني مقارنة عمليتي نشر netlify وفي الواقع يحتوي موقع @emotion على 70s مرتفعًا وموقع linaria به 70s منخفض إلى متوسط

وغني عن القول ، لست متحمسًا جدًا

تحليل الحزمة:

• تم زيادة حجم مستند الموقع من 14 كيلو بايت إلى 28 كيلو بايت
• ظل نص الإطار متطابقًا عند 38.7 كيلوبايت
• انخفض البرنامج النصي للتطبيق من 58.2 كيلوبايت إلى 46.1 كيلوبايت
• والنص الرابع ( component--content.. . ثم 20bae078.. الآن) قد انتقل من 44.2 كيلوبايت إلى 46.8 كيلوبايت

لذلك أفترض أن الأنماط في js قد انتقلت إلى أنماط في css (و 12 كيلو بايت تقريبًا مهمة IMO) ، لكن هذا لم يكن له أي تأثير حقيقي في مقاييس المنارة (وهذا ما يهم ، أليس كذلك؟)

لذلك ، أنا لا أقول على الإطلاق أن الانتقال إلى linaria لا معنى له ، لن أتفاجأ إذا فعل شخص ما الشيء نفسه ولديه نتائج أفضل (من الناحية النظرية يجب أن يكون هذا هو الحال (؟)) ، لكن العملية في يدي لم تكن ذات قيمة

لا يزال استكشاف البرنامج النصي للتطبيق قد فتحت مشكلة جديدة في محاولة لمعرفة كيفية تقليل حزمة js https://github.com/gatsbyjs/gatsby/issues/26655

تجربة DX مع برنامج gatsby سيئة ، ولا تعمل إعادة التحميل الساخنة (عليك التوقف والبدء من جديد عند أي تغيير حيث يبدو أن المتصفح يفقد الاتصال) ، ولكن بشكل عام كانت العملية لطيفة لأنها تجبرك على أن تكون أكثر وعياً بشأن ما هل تحتاج حقًا من قدرات وقت تشغيل emotion

kuworking واجهت مشكلة مماثلة ، ولكن لاحظت أنها حدثت فقط في إصدارات gatsby الأحدث من 2.24.9 ؛ لست متأكدًا مما إذا كان السبب هو نفسه ، لكنني اعتقدت أنه قد يساعد شخصًا ما على معرفة أن الناس يتحدثون عنه في العدد رقم 26192 .

kuworking واجهت مشكلة مماثلة ، ولكن لاحظت أنها حدثت فقط في إصدارات gatsby الأحدث من 2.24.9 ؛ لست متأكدًا مما إذا كان السبب هو نفسه ، لكنني اعتقدت أنه قد يساعد شخصًا ما على معرفة أن الناس يتحدثون عنه في العدد رقم 26192 .

لقد كنت مع "gatsby": "2.24.14" لعدة أسابيع على ما أعتقد ، وحتى الآن لم أجرب هذا إلا بـ linaria
لكن بمعرفة ذلك لن أقوم بتحديث برنامج gatsby حتى يتم اكتشاف ذلك ، شكرًا 👍

kuworking ما قصدت أن تصنيفك إلى 2.24.9 ، فلن تحدث مشكلة توقف خادم التطوير حتى مع linaria ؛ لكن هذه مجرد فكرة. سأكون فضوليًا لمعرفة ما إذا كان هذا هو الحال.

تجربة DX مع برنامج gatsby سيئة ، ولا تعمل إعادة التحميل الساخنة (عليك التوقف والبدء من جديد عند أي تغيير حيث يبدو أن المتصفح يفقد الاتصال) ، ولكن بشكل عام كانت العملية لطيفة لأنها تجبرك على أن تكون أكثر وعياً بشأن ما هل تحتاج حقًا من قدرات وقت تشغيل emotion

هل حاولت التحديث السريع ؟

لقد قمت مؤخرًا بترحيل موقع gatsby للإنتاج (حوالي 120 صفحة) للعمل مسبقًا على أمل تحسين TBT & LCP. موقعنا ثقيل باستخدام svg باستخدام مكونات svg المتفاعلة التي تم إنشاؤها باستخدام svgr وتصميمها باستخدام أنماط المواد-واجهة المستخدم. كان متوسط ​​نتائج الأداء في نطاق + -5 للنتيجة الأولية (~ 45 أداء للهاتف المحمول أقل من 85 ~ قبل الإصدار 6) وعلى الرغم من أن الترحيل كان غير مؤلم نسبيًا باستخدام السمة ، إلا أنه يتطلب ترحيلًا للتحديث السريع والذي كان ليس.

بصراحة ، أشعر بخيبة أمل بعض الشيء لأنه لا توجد أي تحسينات أخرى يمكنني أن أجدها لمحاولة تنفيذ المزيد من المقاييس التفصيلية إلى جانب تحذير المنارة العام "إزالة جافا سكريبت غير المستخدمة".

السرعة هي أحد الأسباب الرئيسية لاختيارنا gatsby وعلى الرغم من أن الصفحات لا تزال سريعة التحميل ، إلا أنه من الصعب تبريرها من وجهة نظر مُحسنات محركات البحث عندما تحقق نتائج رؤيتك نجاحًا كبيرًا ...

همسات: لقد تحولت إلى NextJS وأحصل على نتائج أفضل 🤭

همسات: لقد تحولت إلى NextJS وأحصل على نتائج أفضل 🤭

ماذا عن Svelte؟

سيكون من الجيد معرفة ما إذا كان مطورو Gatsby يعطون هذا إحساسًا محددًا بالأهمية / الأولوية في خريطة الطريق (بخلاف المتوقع) ، حيث أفترض أنه لا توجد حلول فورية ولكن ربما نوعًا من الاتجاهات والتطبيقات المستقبلية التي تركز على هذه ام تلك

نظرًا لأن Gatsby يقوم ببعض التجميع باستخدام gatsby-node * ، أتساءل عما إذا كانوا يستكشفون طرقًا لزيادة هذا الجزء وتقليل جزء العميل

* من أجل تقليل pageContext الذي كنت أستخدمه (بيانات حول جميع المنشورات المنشورة) ، أقوم حاليًا بتخزين (من خلال gatsby-node ) معظم هذه البيانات في ملفات json وجلبها إذا لزم الأمر من الموقع ، مما يقلل من حجم الحزمة ولكن يبدو أيضًا أكثر منطقية

لا تعلق كثيرًا على نتائج المنارة - خاصةً عندما تكون كذلك
يُقصد به أن يكون معيارًا مقارنة بالمواقع الأخرى ، وليس هدفًا حيث يجب علينا
نسعى جاهدين لتحقيق درجة مثالية.

لم يكن غاتسبي حتى وقت قريب يسمر 100 ثانية - بالتأكيد ، هناك
هي بعض المشكلات التي يجب معالجتها ولكن لعبة تحسين محركات البحث (SEO) الآن هي السرعة بالإضافة إلى المحتوى
بالإضافة إلى الروابط ، وقد قمنا بتغطيتها.

سنتى.

في الجمعة ، 28 أغسطس 2020 ، الساعة 16:57 ، كتب kuworking ، [email protected] :

همسات: لقد تحولت إلى NextJS وأحصل على نتائج أفضل 🤭

ماذا عن Svelte؟

سيكون من الجيد معرفة ما إذا كان مطورو Gatsby يقدمون هذا الأمر بالتحديد
الشعور بالأهمية / الأولوية في خارطة الطريق (بخلاف المتوقع
واحد) ، حيث أفترض أنه لا توجد حلول فورية ولكن ربما البعض
نوع من الاتجاهات والتطبيقات المستقبلية التي تركز على هذا أو ذاك

نظرًا لأن gatsby يقوم ببعض التجميع باستخدام gatsby-node * ، فأنا أتساءل عما إذا كانوا
يستكشفون طرقًا لزيادة هذا الجزء وتقليل جزء العميل

* لتقليل pageContext الذي كنت أستخدمه (بيانات حول الكل
المنشورات المنشورة) ، أقوم حاليًا بتخزين (من خلال gatsby-node) أكثر
من تلك البيانات في ملفات json وجلبها إذا لزم الأمر من الموقع ،
مما يقلل من حجم الحزمة ولكن يبدو أيضًا أكثر منطقية

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

نأسف للرد المتأخر ، فهناك الكثير من الأمور التي تدخل في الأداء ومقاييس التحميل ليست سوى جزء صغير من اللغز. نحن متحمسون في هذا الربع والربع التالي لجعل Gatsby أصغر وتقليل TBT. أكبر المشاكل في الوقت الحالي هي حجم حزمة React و MDX والصفحات الكبيرة (المحتوى / النمط) وتتبع البرامج النصية والخطوط / الصور كمحتوى رئيسي عند التحميل الأول.

أنا أبحث حاليًا في سكربتات gatsby-image والتحليلات لمعرفة كيف يمكننا تحسين وقت التحميل وتأجيل التحليلات.

للأسف ، لا يمكنني إعطاء أي تقديرات. نتطلع أيضًا إلى موقع .com الخاص بنا وعملائنا لمعرفة المشكلات الشائعة حتى نتمكن من تحويل هذه التحسينات إلى gatsby أو في المكونات الإضافية الخاصة بنا.

تعديل:

يسعدني إلقاء نظرة على أي من أكواد المصدر الخاصة بك للحصول على مزيد من الأفكار حول ما تفعلونه جميعًا لمعرفة كيف يمكننا تحسينه

لقد قمت بعمل منشور على

تؤدي إزالة gatsby-image فقط (

في بعض الاختبارات التي كنت أقوم بها مؤخرًا ، وجدت أن استخدام tracedSVG قد أدى في الواقع إلى تحسن كبير في درجة أداء Largest Contentful Paint. أتخيل أن هذا سيتم إصلاحه في Lighthouse ، ولكن حتى الآن يحدث هذا لأن SVG تعتبر ذات أبعاد صورة كاملة الدقة ، لذلك لا يتم تبديلها أبدًا من SVG كهدف LCP إلى الصورة الكاملة.

عند استخدام base64 ، فإن الدقة الصغيرة تجعلها ليست مرشحًا لـ LCP لذا تستخدم Lighthouse الصورة ذات الدقة الكاملة كلما تم تحميلها.

لذلك إذا كنت لا تمانع في مظهر SVGs المتعقبة (أفضلها شخصيًا) ، فقد ترغب في تجربة ذلك.

لماذا v5 نتيجة أفضل من v6؟ أنا أستخدم NextJS ، فقد تغيرت النتيجة دائمًا من 60 إلى 85.

+1

لقد كنت أعمل على خليفة صورة غاتسبي. إنها ليست 100٪ حتى الآن ، ما زلت بحاجة إلى كتابة نسخة قابلة للتركيب حتى تتمكن من إنشاء نكهة gatsby-image الخاصة بك ولكنها ستصلح معظم درجات المنارة السيئة.

يمكنك استخدامه بالفعل ولكن لم يتم اختباره بعد في المعركة.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

يمكنك تثبيته بـ npm install --save @wardpeet/gatsby-image-nextgen . هناك طبقة متوافقة للمستخدمين الحاليين لبرنامج gatsby-image .

الأشياء التي لم يتم دعمها بعد:

• يجب أن يتم احتواء الكائن عن طريق css خارج المكون
• اتجاه الفن

عرض gatsby-image الحالي:
الموقع: https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights: 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/

عرض جديد لبرنامج Gatsby-image-nextgen:
الموقع: https://gatsby-image-nextgen.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/؟url=https٪3A٪2F٪2Fgatsby-image-nextgen.netlify.app٪2F
webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

wardpeet ينتقل رابط Pagespeed-insights للعرض التوضيحي الحالي إلى nextgen بحيث يعرضون نفس النتائج.
عمل رائع ، راجع للشغل. من المثير حقا أن نرى التقدم.

شكرا لك ثابتة!

أشار هذا التحديث إلي شيئًا لم أتصل به من قبل ، فأنا لا أستخدم 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. تصغير css & js في html
2. قم بتحميل البتات الضرورية فقط ، عندما يتم تمكين تحميل الصورة الأصلية ، فإننا نحمل فقط حوالي 2 كيلو بايت (غير مضغوط).
3. تأكد من استدعاء العنصر النائب فقط عند التحميل الأول ، وتحميل الصور المخزنة مؤقتًا على الفور
4. إصلاح تمويه الرسوم المتحركة عن طريق فك التشفير غير المتزامن

أتساءل كم منكم يحتاج إلى مكون صورة قابل للإنشاء حيث يمكنك إنشاء غلاف خاص بك وكم منكم يستخدم بالفعل اتجاهًا فنيًا ويريد ذلك داخل صورة gatsby افتراضيًا؟ كانت فكرتي الأولى هي تعطيل الوظيفة مع تمكينها باستخدام صورة gatsby القابلة للتكوين ، لذا سيتعين عليك إنشاء مكون الصورة الخاص بك لدعمها.

أحدث عرض: https://gatsby-image-nextgen.netlify.app/

wardpeet هذا شيء عظيم! أنا أعتمد بشدة على الاتجاه الفني للبناء في صورة غاتسبي. لكني أعتقد أن المثال / مسار الترقية السلس سيكون جيدًا أيضًا!

لقد تلقيت دائمًا 99 على الهاتف المحمول الآن 76. كل شيء رائع باستثناء LCP الخاص بي الذي يبلغ 7.0s وهو يقول إنها صورتي البطل. لا معنى له. عندما أقوم بإيقاف تشغيل موقع الويب الخاص بي على أي هاتف محمول ، يكون الجو سريعًا للغاية. الناس أتعجب يا تعرف؟ يخبرني أيضًا أن أضع صوري في webp أو غيرها ، لكنني بالفعل نحن childImageSharp_withWebp حتى لا أفهمها. لقد بدأت في التفكير في أن Gastby Image و background-image لا تعملان مع هذا الإصدار الجديد في Lighthouse و Pagespeedinsight. ذهني محير. ذهبت وقتلت الرسوم المتحركة ، وقمت بتغيير حجم كل صوري إلى النصف ولم تتزحزح عن نقطة واحدة. أنا أقرأ هذا ولا أرى أي شيء يساعدني .... أوه لقد بحثت للتو ... أعتقد أن wardpeet بلدي يكون على شيء

davidpaulsson هل تشاركنا مثالاً على كيفية القيام بذلك؟ نظرًا لأن الاتجاه الفني لا يزال ممكنًا مع صورة gatsby الجديدة ، عليك القيام ببعض الخطوات اليدوية.

davidpaulsson هل تشاركنا مثالاً على كيفية القيام بذلك؟ نظرًا لأن الاتجاه الفني لا يزال ممكنًا مع صورة gatsby الجديدة ، عليك القيام ببعض الخطوات اليدوية.

أكيد! أنا استخدمه مثل هذا حاليا

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

return <Img fluid={artDirection} />

wardpeet مرحبا وارد. هل يمكن أن يكون blurha.sh مفيدًا لصورة gatsby nextgen؟

wardpeet لقد استخدمت المكوّن الإضافي gatsby-image- ثوانٍ إلى 1.5 ثانية ). شكرا لك على هذا!

ومع ذلك ، فإننا نستخدم أيضًا اتجاهًا فنيًا ، على غرار الطريقة التي يستخدمهاdavidpaulsson ، ولا يبدو أنني

هل يمكنك توضيح الخطوات اليدوية اللازمة لجعل ذلك ممكنًا باستخدام المكون الإضافي nextgen؟ شكرا لك مرة أخرى!

Jimmydalecleveland شكرا جيمي! أدى استبدال GatsbyImageSharpFluid_withWebp بـ GatsbyImageSharpFluid_withWebp_tracedSVG إلى تحسين درجة أداء Gatsby Webiste الجديدة بشكل كبير. لم أحصل على أكثر من 54٪ والآن مع tracedSVG حصلت على أكثر من 80٪. هذا تحسن كبير 💯

في بعض الاختبارات التي أجريتها مؤخرًا ، وجدت أن استخدام tracedSVG قد أدى في الواقع إلى تحسن كبير في درجة أداء Largest Contentful Paint. أتخيل أن هذا سيتم إصلاحه في Lighthouse ، ولكن حتى الآن يحدث هذا لأن SVG تعتبر ذات أبعاد صورة كاملة الدقة ، لذلك لا يتم تبديلها أبدًا من SVG كهدف LCP إلى الصورة الكاملة.

عند استخدام base64 ، فإن الدقة الصغيرة تجعلها ليست مرشحًا لـ LCP لذا تستخدم Lighthouse الصورة ذات الدقة الكاملة كلما تم تحميلها.

لذلك إذا كنت لا تمانع في مظهر SVGs المتعقبة (أفضلها شخصيًا) ، فقد ترغب في تجربة ذلك.

abdullahe لقد قمنا ولأنها تعتمد على قماش الرسم وقماش العقدة لا يمكن الاعتماد عليها بشكل كبير. أو على الأقل لم يكن في الماضي. سأخبرك إذا نظرنا في الأمر مرة أخرى :)

guydumais تأكد من وضع loading="eager" يجب أن يغير درجتك أيضًا.

BenjaminSnoha & davidpaulsson سأشارك مثالاً بعد قليل. أكبر مشكلة تتعلق بالاتجاه الفني إذا تغيرت نسبة العرض إلى الارتفاع بين الصور ، مثل الأفقي إلى الرأسي.

wardpeet كيف يمكن للمرء استخدام @wardpeet/gatsby-image-nextgen مع gatsby-remark-images ؟ هل هي مجرد الإشارة إليه كمكوِّن إضافي في gatsby-config.js ، أم أنه من غير الممكن حتى يتم دمجه في gatsby monorepo؟

في حين أن هذا قد لا يكون له علاقة بالمنارة ، إلا أنني أتساءل لماذا لا تدعم ملفات JSON لبيانات صفحة gatsby تجزئة المحتوى ، تمامًا مثل ملفات js.

أعلم أن تجزئة المحتوى لملفات js يتم إجراؤها بواسطة Webpack ، ولكن يمكن لـ gatsby أيضًا أن يفعل الشيء نفسه لملفات JSON لبيانات الصفحة. هذا يمكن أن يوفر الكثير من طلبات شبكة cdn

لا ينبغي تنزيل ملفات teclone page-data.json مرارًا وتكرارًا إذا تم إعداد التخزين المؤقت بشكل صحيح. سيتم تحميلها مرة واحدة ثم يقوم المتصفح بإعادة التحقق منها. تكمن مشكلة تجزئة المحتوى لبيانات الصفحة (مقابل ملفات JS / CSS) في وجود الكثير منها. باستخدام تجزئة المحتوى ، قبل أن تتمكن من تحميل ملف ، تحتاج إلى تحميل بيان يترجم من x إلى x.LONG_HASH لأن التجزئة غير متوقعة. باستخدام JS / CSS ، يكون تحميل البيان أمرًا معقولاً نظرًا لوجود عدد كبير جدًا من ملفات JS حتى على المواقع الكبيرة جدًا. ولكن مع بيانات الصفحة ، يوجد واحد في كل صفحة لذلك يمكن أن ينمو البيان بشكل كبير جدًا. لقد اعتدنا على القيام بذلك ووجدنا في موقع صفحة 10 كيلو بايت ، كان البيان مضغوطًا بالفعل بحوالي 500 كيلو بايت. https://github.com/gatsbyjs/gatsby/pull/13004

إذا رأيت ملفات page-data.json التي تم تنزيلها مرارًا وتكرارًا - تحقق من أنك لم تقم بتعطيل التخزين المؤقت في أدوات التطوير الخاصة بك وتحقق من رؤوس التخزين المؤقت باستخدام https://www.npmjs.com/package/check-gatsby-caching

KyleAMathews ، شكرًا لتوضيح ذلك. هذا نهج معقول للغاية

wardpeet هل صحيح أن image-nextgen لا يدعم fadeIn="false" أو fadeIn="{false}"

إنه يعمل بشكل أفضل كثيرًا ، فقد انتقل من ~ 80 إلى ~ 95

MelleNi ليس كذلك ، لا أعتقد أنه ضروري ولكننا سعداء بالنظر فيه.

يمكنك إلقاء نظرة على https://github.com/gatsbyjs/gatsby/discussions/27950 لمعرفة ما نقوم بشحنه.

wardpeet كيف يمكن للمرء استخدام @wardpeet/gatsby-image-nextgen مع gatsby-remark-images ؟ هل هي مجرد الإشارة إليه كمكوِّن إضافي في gatsby-config.js ، أم أنه من غير الممكن حتى يتم دمجه في gatsby monorepo؟

سننقل الملاحظة إلى هذا المكون الإضافي أيضًا :)

MelleNi ليس كذلك ، لا أعتقد أنه ضروري ولكننا سعداء بالنظر فيه.

يمكنك إلقاء نظرة على # 27950 لمعرفة ما نقوم بشحنه.

wardpeet كيف يمكن للمرء استخدام @wardpeet/gatsby-image-nextgen مع gatsby-remark-images ؟ هل هي مجرد الإشارة إليه كمكوِّن إضافي في gatsby-config.js ، أم أنه من غير الممكن حتى يتم دمجه في gatsby monorepo؟

سننقل الملاحظة إلى هذا المكون الإضافي أيضًا :)

من الرائع أن تسمع عن الملاحظة ، حيث رأيت الكثير من التحسن في السرعة.

ومع ذلك ، لاحظت أنه لا يمكنني الحصول على 99-100 دون تعطيل جافا سكريبت Gatsby (وإعادة دمج وظائف معينة يدويًا). يمكنني جعل صورة Gatsby القديمة تعمل بدون جافا سكريبت ، باستخدام fadeIn={false} ، لكن ليس image-nextgen. (ربما أفتقد شيئًا ما ، وهذا ممكن تمامًا؟) الآن بدون جافا سكريبت ، لم أقم بإسقاط أقل من 99 بدون الجيل التالي.

أنا أفهم أن تعطيل جافا سكريبت نوع من هزيمة فكرة غاتسبي ، ولكن حسنًا.

ومن المثير للاهتمام ، أنني رأيت تحسنًا في درجة أداء الأجهزة المحمولة (من 70 إلى 90 تقريبًا) عندما توقفت عن استخدام الخطوط ذاتية الاستضافة (مصدر الخطوط) وتحولت إلى خطوط "النظام".

wardpeet هل هناك فرصة BenjaminSnoha & davidpaulsson ، ولا أمانع في إنشاء المكون القابل للإنشاء في مشروعي الخاص.

أكبر مشكلة أراها هي التعامل مع الاستفسارات الإعلامية و SSR. مكتبات مثل fresnel work ، لكنها تعاني في الأداء لأنها تقوم بتحميل جميع المكونات ، ثم نظف DOM بعد توفر المكون window .

على موقع الويب الخاص بي ، يبدو أن جميع الصفحات التي تم إنشاؤها باستخدام createPage تحتوي على الكود المصدري (مكونات تفاعل تخفيض السعر وتخفيض السعر داخل علامة التخفيض) في pagepeed Heavy javascript (إزالة JavaScript غير المستخدمة)

لقد أطلقت للتو Plaiceholder الذي يمكن استخدامه لإنشاء عناصر نائبة غير واضحة لـ CSS . ربما هذا سيكون من الفائدة؟ أكثر من سعيد للدردشة مع أي من الفريق الأساسي حول الخيارات إلى الأمام

لقد قمت بعمل إصدار Next.js من Jamify Blog Starter الذي يسجل نتائج جيدة مع أحدث إصدار من Lighthouse 6.4.0:

يمكنك فحص الموقع التجريبي على next.jamify.org .

أنا أنشر هذا هنا ، وليس لأقترح عليك التبديل إلى Next.js. بدلا من ذلك ، لمعرفة كيف يمكن تحقيق الشيء نفسه مع Gatsby. أعتقد أن عوامل النجاح الرئيسية هي:

• صور محسّنة للغاية (يحقق Next ذلك باستخدام مُحسِّن lambda ، ولكن يمكن القيام بذلك باستخدام gatsby-plugin-sharp أيضًا).
• عنصر نائب بسيط svg (تأثيرات لطيفة مثل التمويه ستبطئ الصفحة).
• استخدام مراقب التقاطع لعرض الصور فقط عندما تكون في العرض (انظر التالية / الصور).
• ضمان التحميل البطيء للصور.
• حجم الحزمة الصغيرة.

إذا كنت ترغب في مناقشة هذا الأمر أكثر ، يمكنك التواصل معي على تويتر .

styxlab أحصل على نتائج أقل قليلاً في web.dev/measure

ولكن أفضل في نتائج المنشورات ، وقيم جيدة جدًا بشكل قاطع في أي حال ومختلفة بشكل ملحوظ عن إصدار gatsby https://demo.jamify.org/

سأقوم أيضًا بنشر ذلك في موقع واحد لقد قمت بتغيير gatsby مقابل 11ty ، وقد تحسن الأداء ولكن ليس بشكل كبير

(غاتسبي)

(تصميم مختلف ، نفس المحتوى بشكل أساسي ، 11 عامًا)

أو في صفحة مماثلة ، هذه المرة بصورة

(غاتسبي)

(تصميم مختلف ، نفس المحتوى بشكل أساسي ، 11 عامًا)

سأقول أن تجربة المطور البالغة من العمر 11 عامًا لطيفة جدًا (يمكنك أيضًا - بشكل تجريبي استخدام jsx و styled-components ) ، لكن أي js من جانب العميل تضيع (أنت يمكنك إدخاله والقتال باستخدام حزمة الويب ، تلك اللحظة هي المكان الذي تفتقد فيه غاتسبي)

بينما كنت أستخدم 11ty ، كنت أفكر أيضًا كم سيكون لطيفًا أن أتاح غاتسبي نوعًا من إستراتيجية تصيير 11ty بحيث يمكن للمرء نشر صفحات ثابتة مختلطة وغير متفاعلة في إطار واحد ...

أي تحديثات على هذا؟ ليس لدي أي صور وأحصل على 76 في الأداء بسبب إجمالي وقت الحظر