تخطَّ إلى المحتوى

الهندسة

في مواقع الشركات، الأداء قرار تصميمي

اجتياز مؤشرات Core Web Vitals ليس جولة تحسين في النهاية، بل نتيجة قرارات البنية والتصميم المتّخذة في اليوم الأول.

تاريخ النشر: آخر تحديث: 6 دقيقة قراءةNeuros Web Team · هندسة الويب

باختصار

ما السرعة المطلوبة للموقع وكيف تُقاس؟

تُقاس مؤشرات الويب الأساسية بثلاث عتبات: أكبر رسم للمحتوى دون 2.5 ثانية، والتفاعل حتى الرسم التالي دون 200 ميلي ثانية، وإزاحة التخطيط التراكمية دون 0.1. ولا يجتازها الموقع المؤسسي إلا إذا كُتب الأداء كميزانية وفرضها خط النشر؛ فبدون ميزانية يجعل كل مكوّن جديد الصفحة أثقل قليلًا.

السرعة ليست ميزة تُضاف لاحقًا. فمن دون ميزانية موارد منذ البداية، يتحوّل كل قرار في مرحلة التصميم بهدوء إلى دَين في الأداء.

كيف تُحدَّد ميزانية الأداء؟

حدّد سقفًا لكل صفحة لإجمالي جافاسكربت ووزن الصور وسكربتات الأطراف الثالثة. وافرض هذا السقف في خط التكامل المستمر بحيث لا يمكن دمج أي تغيير يتجاوزه.

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

كم تكلّف الحركة من الأداء؟

الحركة المرتبطة بالتمرير رخيصة ما دامت تقتصر على التحويل والشفافية. أما كل ما يستدعي إعادة التخطيط فيعود إليك على شكل إطارات ساقطة على هاتف متوسط الفئة.

كيف تُقاس مؤشرات الويب الأساسية قياسًا صحيحًا؟

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

عتبات مؤشرات الويب الأساسية (Google، web.dev)
المؤشرجيديحتاج تحسينًاضعيف
LCP — أكبر رسم للمحتوى≤ 2.5 ثانية2.5 – 4.0 ثانية> 4.0 ثانية
INP — التفاعل حتى الرسم التالي≤ 200 ميلي ثانية200 – 500 ميلي ثانية> 500 ميلي ثانية
CLS — إزاحة التخطيط التراكمية≤ 0.10.1 – 0.25> 0.25

المصادر

  1. 01Core Web Vitals — LCP, INP, CLS eşikleriGoogle · web.dev · 2024
  2. 02Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2023
  3. 03DORA — DevOps Research and Assessment metrikleriGoogle Cloud · 2024

الأسئلة الشائعة

أسئلة تتكرّر علينا

أثرها في الترتيب ليس حاسمًا بذاته؛ فجودة المحتوى ما زالت أثقل وزنًا. لكن الصفحة التي تخفق في العتبات تخسر المستخدم أيضًا: إذ يغادر الزائر الصفحةَ البطيئة قبل رؤية المحتوى. ولذلك فاعتبار الأداء شرطًا لقراءة المحتوى — لا تكتيكًا للترتيب — إطارٌ أدقّ.

جافاسكربت التي تشغل الخيط الرئيسي مددًا طويلة. فحين يضغط المستخدم زرًّا يجب أن يُنهي المتصفّح المهمة التي أمامه قبل أن يستجيب، وإن طالت تأخّر التفاعل. والأسباب المعتادة حزمٌ كبيرة، وحسابات ثقيلة عند تحميل الصفحة، ومستمعات تُطلَق مع كل تمرير. والحلّ تقسيم الشيفرة وتأجيل العمل إلى ما بعد التفاعل.

لا يكفي. فاختبار المختبر يفترض جهازًا ثابتًا واتصالًا ثابتًا، بينما قد يكون المستخدم الحقيقي على هاتف أقدم وشبكة متقلّبة. والاثنان لا يحلّ أحدهما محلّ الآخر: يلتقط اختبار المختبر الانحدارات، ويُظهر قياس المستخدم الحقيقي أي فئة تعاني. وينبغي أن تقرأ القرارات الاثنين معًا.

لنناقش هذا مع فريقك

يمكننا عقد جلسة تقنية تترجم أيًا من هذا إلى سياقك الخاص.