برمجه وتصميم

أساسيات الويب الأساسية: دليل لمقاييس أداء الويب من Google

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

للأسف، “أداء” هو مصطلح شامل لعشرات المقاييس …

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

تعرض الأدوات المختلفة مجموعات مختلفة من النتائج وقد يكون من الصعب معرفة من أين تبدأ.

تهدف مبادرة “أساسيات الويب” من Google إلى تبسيط تقييم الأداء ومساعدتك على التركيز على التحسينات الأكثر أهمية. تعد “أساسيات الويب الأساسية” مقاييس أداء مهمة تعكس تجارب المستخدم في العالم الحقيقي. تم الإبلاغ عن بعضها بواسطة لوحة Lighthouse في Chrome DevTools ، PageSpeed ​​Insights، و ال جوجل Search Console.

ال مكتبة جافا سكريبت لمؤشرات الويب الحيوية يمكن أن تساعد في قياس مقاييس أكثر واقعية من المستخدمين الحقيقيين الذين يدخلون إلى موقعك. يمكن نشر النتائج في Google Analytics أو نقاط نهاية أخرى لمزيد من التحليل.

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

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

أكبر طلاء محتوى (LCP)

يقيس LCP أداء التحميل – مدى سرعة ظهور المحتوى.

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

يوضح Largest Contentful Paint (LCP) وقت عرض أكبر صورة أو كتلة نصية مرئية داخل منفذ العرض. يعتبر الوقت الأقل من 2.5 ثانية جيدًا وأي شيء يزيد عن 4.0 ثوانٍ يعتبر ضعيفًا.

أنواع العناصر المعتبرة في LCP هي:

  • <img> عناصر
  • <image> العناصر داخل ملف <svg>
  • صورة ملصق أ <video> جزء
  • عنصر مع صورة خلفية تم تحميله باستخدام CSS url() خاصية
  • عناصر على مستوى الكتلة تحتوي على عقد نصية.

يتم تحديد أكبر عنصر عند تحميل المحتوى ويتم حساب الحجم ليكون أبعاده المرئية في إطار عرض المتصفح.

يمكن أن يتأثر LCP بما يلي:

  • أوقات استجابة الخادم
  • أوقات تحميل الموارد
  • CSS أو JavaScript لحظر العرض
  • أوقات معالجة حجم العميل

قد تكون تحسينات LCP ممكنة عن طريق:

  1. باستخدام شبكة توصيل المحتوى (CDN) لتوجيه الطلبات إلى خوادم أقرب
  2. تحسين استجابة الخادم عن طريق تقليل عدد عمليات وقت العرض الباهظة
  3. تقليل حجم ملف الأصول
  4. تخزين الأصول مؤقتًا محليًا ، وربما استخدام عامل خدمة لإرجاع الإصدار المحلي أولاً.

أول تأخير في الإدخال (FID)

يقيس FID الاستجابة – مدى سرعة استجابة الصفحة لإجراء المستخدم.

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

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

لذلك تستخدم Google والأدوات المختلفة إجمالي وقت الحظر (TBT) كمقياس بديل يمكن حسابه دون إدخال المستخدم الحقيقي. يقيس TBT الوقت الإجمالي بين:

  1. الرسم الأول للمحتوى (FCP) – الوقت الذي تم فيه عرض أي جزء من محتوى الصفحة ، و
  2. وقت التفاعل (TTI) – الوقت الذي تكون فيه الصفحة قادرة على الاستجابة بشكل موثوق لإدخال المستخدم (لا توجد مهام طويلة قيد التشغيل ولم يتم حل أكثر من طلبي GET بعد).

قد تكون تحسينات FID / TBT ممكنة من خلال:

  1. تقليل وقت تنفيذ JavaScript ، عادةً عن طريق إرجاء التعليمات البرمجية غير الهامة
  2. تفكيك المهام الطويلة الأمد
  3. باستخدام عمال الويب لتشغيل المهام في سلسلة رسائل خلفية
  4. تحميل جافا سكريبت طرف ثالث عند الطلب.

التحول في التخطيط التراكمي (CLS)

يقيس CLS الاستقرار البصري – الحركة غير المتوقعة للمحتوى عند عرض الصفحة.

تقوم CLS بتقييم تلك المواقف المزعجة عندما يتحرك المحتوى دون سابق إنذار – عادةً عندما يتغير DOM بعد إعلان أو صورة أعلى موضع التمرير الحالي الخاص بك اكتمال التحميل. تظهر المشكلة بشكل خاص على الأجهزة المحمولة ويمكن أن تتسبب في فقد مكانك أو النقر فوق الارتباط الخطأ.

يتم حساب CLS بضرب:

  1. جزء التأثير: المساحة الإجمالية للعناصر غير المستقرة في منفذ العرض (تلك التي ستتحرك). يشير جزء التأثير البالغ 0.5 إلى أنه سيتم إزاحة العناصر التي يبلغ مجموعها نصف إطار العرض.
  2. جزء المسافة: أكبر مسافة يتحركها أي عنصر فردي داخل منفذ العرض. يشير جزء المسافة البالغ 0.25 إلى أنه تم تحريك عنصر واحد على الأقل بمقدار ربع إطار العرض (أفقيًا أو رأسيًا).

ضع في اعتبارك المثال التالي الذي يحمل إعلانًا بعد وقت قصير من عرض الشعار والقائمة وصورة البطل:

مثال CLS

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

  1. البطل 360 × 510 بكسل في إطار عرض 360 × 720. لذلك فإن كسر التأثير هو (360 × 510) / (360 × 720) = 0.71
  2. يتحرك بمقدار 90 بكسل رأسيًا في ارتفاع منفذ العرض 720 بكسل ، لذا فإن كسر المسافة هو 90/720 = 0.125

وبالتالي فإن CLS هو 0.71 × 0.125 = 0.089

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

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

ال استدعاء لوحة في Chrome DevTools (القائمة> المزيد من الأدوات> العرض) توفر ملف مناطق التحول التخطيطي اختيار. حدد المربع وقم بتحديث الصفحة – يتم تمييز تغييرات التخطيط باللون الأزرق. يمكنك أيضًا تعديل سرعة الشبكة بتنسيق شبكة الاتصال لوحة لإبطاء التحميل.

قد تكون تحسينات FID / TBT ممكنة من خلال:

  1. حجز مساحة للصور ومقاطع الفيديو وعناصر iframe بإضافة أبعاد بها width و height الصفات CSS aspect-ratio خاصية، أو خدعة الحشو القديمة حسب الاقتضاء
  2. تجنب FOUT (Flash of Unstyled Text) و FOIT (Flash of Invisible Text) عند تحميل خطوط الويب. سيساعدك التحميل المسبق أو استخدام الخطوط الاحتياطية ذات الحجم المماثل
  3. عدم إدراج عناصر DOM فوق المحتوى الموجود أثناء تحميل الصفحة الأولي ، مثل الاشتراك في النشرة الإخبارية ومربعات الإشعارات المماثلة
  4. باستخدام CSS transform و opacity للحصول على رسوم متحركة أقل تكلفة.

أولويات الأداء

ستتطور “حيوية الويب الأساسية” بمرور الوقت ولكن تقييم مقاييس LCP و FID و CLS يمكن أن يساعد في تحديد المشكلات الأكثر أهمية. قم بمعالجة المشكلات السريعة والسهلة أولاً – غالبًا ما تحقق أكبر عائد على الاستثمار:

  • تفعيل ضغط الخادم و HTTP / 2 أو HTTP / 3
  • تأكد من استخدام التخزين المؤقت للمتصفح من خلال تعيين رؤوس انتهاء صلاحية HTTP
  • التحميل المسبق الأصول في وقت مبكر
  • قم بتسلسل CSS و JavaScript وتصغيرهما
  • إزالة الأصول غير المستخدمة
  • فكر في استخدام CDN أو استضافة أفضل
  • استخدام أحجام وتنسيقات الصور المناسبة
  • تحسين أحجام ملفات الصور والفيديو (يمكن أن يساعد CDN متخصص)

يوفر كتاب Jump Start Web Performance كتاب SitePoint عشرات النصائح لتحسين سرعة الموقع وتقليل التكاليف وإرضاء المستخدمين.

المصدر

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

زر الذهاب إلى الأعلى