لماذا تعتبر Lighthouse 90 عائقًا لشحن وحداتنا

كل وحدة في هذه السوق تمر بميزانية أداء Lighthouse قبل أن تصبح متاحة. الرقم هو 90 على الهواتف المحمولة، يتم قياسه مقابل متجر مرجعي Magento 2.4.6 بالإضافة إلى Hyvä 1.3 مع الوحدة المثبتة والنشطة.

إذا انخفضت النتيجة عن 90، فلن يتم شحن الوحدة. نعيدها إلى المطور مع أثر الفشل.

لماذا توجد هذه القاعدة

في عام 2019، قضت الفريق الذي يدير هذه السوق ستة أشهر في مطاردة تراجع LCP لمدة 1.4 ثانية على متجر عميل. قاد المسار عبر ثلاث وحدات طرف ثالث. لم يكسر أي منها Lighthouse بشكل فردي، ولكن معًا شحنت 240 كيلوبايت من JavaScript غير المستخدمة وأربع طلبات شبكة تعيق الرسم الأول.

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

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

ما الذي يلتقطه ميزانية 90 في الواقع

تجري المراجعة تسع فحوصات محددة:

1. إجمالي وقت الحظر أقل من 200 مللي ثانية. المهام الطويلة أثناء العرض الأول تفشل بسرعة.
2. أكبر رسم محتوى أقل من 2.5 ثانية. الصور البطل المدخلة من الوحدة أو الأدوات فوق الطية التي لا تقوم بالتحميل الكسول تفشل هنا.
3. التحول التراكمي للتخطيط أقل من 0.1. أي أداة تظهر بعد الرسم الأول دون مساحة محفوظة تفشل.
4. لا JavaScript قديم. يتم الإشارة إلى الوحدات المشحونة مع polyfills ES5 المستهدفة من Babel للمتصفحات التي لا يستخدمها أحد.
5. لا CSS غير مستخدم يزيد عن 20 كيلوبايت. يتم القبض على بقايا Bootstrap أو Materialize.
6. الموارد التي تعيق العرض أقل من 600 مللي ثانية. الخطوط الخارجية، البرامج النصية المتزامنة، أوراق الأنماط المعيقة كلها تفشل في ذلك.
7. تنسيقات الصور الحالية. صور PNG البطل عندما يمكن استخدام WebP، صور JPEG البطل عندما يمكن استخدام AVIF.
8. لا iframes طرف ثالث تعيق العرض. أدوات الدردشة الحية التي تعيق الرسم بدلاً من التحميل بعد الرسم تفشل.
9. استجابة الخادم تبقى أقل من 600 مللي ثانية TTFB مع كود الخلفية للوحدة نشطًا.

يمكن أن تمر الوحدات بذكاء، تقسيم الكود، تحميل مؤجل، عرض من جانب الخادم. تكافئ الميزانية السلوكيات الصحيحة، وليس التنفيذات المحددة.

الحجة التي لدينا في كثير من الأحيان

يسأل المطورون أحيانًا لماذا لا نجري المراجعة على متجر العميل الحقيقي بدلاً من متجر مرجعي. سؤال معقول.

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

نقوم أيضًا بإجراء مراجعة ثانوية على بعض تكوينات المتاجر الواقعية قبل الموافقة النهائية، ولكن مراجعة المتجر المرجعي هي البوابة.

ماذا يعني ذلك للمشترين

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

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

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