رسم توضيحي لـ Core Web Vitals يظهر شخصًا جالسًا أمام جهاز الكمبيوتر الخاص به ، مع ساعة توقيت كبيرة فوق لوحة المفاتيح.
تقوم Google بمهمة تحسين أداء الويب باستخدام Core Web Vitals. لماذا ا؟ نظرًا لأن أعمال Google تعتمد في الغالب على الويب – تدفع المواقع وتطبيقات الويب البطيئة المستخدمين إلى التطبيقات الأصلية.
يتم تحديد موضعك في نتائج بحث Google إلى حد كبير من خلال الكلمات الرئيسية لمصطلح البحث ، واستخدام هذه الكلمات الرئيسية في صفحتك ، وشعبية صفحتك وفقًا لعدد (وجودة) الروابط من أي مكان آخر. بدءًا من أغسطس 2021 ، تبذل Google جهودًا أيضًا لتقييم الصفحات بناءً على الأداء.
ستوضح لك هذه المقالة كيف يمكنك تحسين موقعك لمقاييس “أساسيات الويب” من Google.
المحتوى لا يزال حاسما. ولكن إذا قارنت موقعين بنص وشعبية متشابهين ، فسيتم إعطاء الموقع الذي يقدم أفضل تجربة ويب أولوية أعلى في نتائج بحث Google.
بالإضافة إلى ترتيب الصفحة المحسّن ، فإن المواقع عالية الأداء مؤهلة للتضمين في مكتبة بحث الجوال. كان هذا محجوزًا سابقًا لـ Accelerated Mobile Pages (AMP) ، الأمر الذي يتطلب منك نقل المحتوى إلى موقع منفصل تستضيفه Google. لقد اجتذبت AMP انتقادات ، خاصة وأن الصفحات ليست دائمًا أسرع من المحسن جيدًا أو الموقع الثابت. ومع ذلك ، لم يعد هذا مطلبًا بعد الآن.
بغض النظر عما اخترته ، كلما كان موقعك أسرع وأكثر استجابة ، كانت فرصة أفضل له في الترتيب الأعلى في نتائج بحث Google.
عندما تفكر في أن متوسط الصفحة يبلغ حوالي 2 ميغابايت ، وتقدم أكثر من 60 طلبًا من طلبات HTTP ، وتستغرق 16 ثانية للعرض على جهاز محمول بالكامل ، فسترى أن هناك مجالًا لتحسين موقعك. سنعرض لك أفضل الطرق لتحقيق تلك التحسينات.
هناك أربعة عوامل تصنيف رئيسية يجب فحصها قبل البدء في تقييم الأداء:
HTTPS: HTTPS ضروري. هل ينشئ موقعك اتصالاً آمنًا بين متصفح المستخدم وخادم الويب؟
التوافق مع الجوّال: يجب أن يعمل موقعك جيدًا على جهاز محمول. هل موقعك قابل للاستخدام على الأجهزة ذات الشاشات الصغيرة؟ هل يتم عرضه بدون فائض المحتوى؟ هل النص كبير بما يكفي؟ هل دورة المناطق القابلة للنقر كافية للتحكم باللمس؟
بلا إعلانات بينية: تجنب الإعلانات البينية المتطفلة التي تتطلب قدرًا غير معقول من مساحة الشاشة. هل المحتوى الخاص بك قابل للقراءة دائمًا؟ هل تحجبه الإعلانات البينية المنبثقة أو اللافتات جزئيًا؟ هل الإعلانات الترويجية أو الترويجية تجعل استخدام الموقع صعبًا؟
التصفح الآمن: يجب أن يكون موقعك خاليًا من البرامج الضارة والفيروسات والتصيد الاحتيالي وعمليات الاحتيال الأخرى.
بمجرد استيفاء هذه المتطلبات ، سيتم تقييم أداء موقعك.
يُعد جعل تحميل موقعك سريعًا وعرضه سريعًا والاستجابة سريعًا أمرًا حيويًا. لكن هل يشعر المستخدمون بالسرعة؟
تقدم تطبيقات قياس الأداء مثل المتصفح DevTools تقريرًا عن القياسات الفنية مثل:
وقت الحظر: الوقت المستغرق في انتظار بدء التنزيل ، عادةً لأن الأصول الأخرى مثل أوراق الأنماط والبرامج النصية لها أولوية أعلى.
تحليل DNS: الوقت اللازم لتحليل اسم مضيف إلى عنوان IP لاسترداد أحد الأصول.
وقت الاتصال: الوقت اللازم لبدء اتصال TCP.
الوقت حتى البايت الأول (TTFB): الوقت الإجمالي بين الطلب وأول بايت من الاستجابة.
وقت الاستلام: الوقت اللازم لاسترداد الأصل بالكامل.
وقت تحميل DOM: وقت تنزيل نموذج كائن مستند HTML وعرضه. عادةً ما تكون هذه هي النقطة الأولى التي يمكن عندها تشغيل البرامج النصية التي تحلل أو تعدل DOM بشكل موثوق.
وقت تحميل الصفحة: وقت تنزيل الصفحة وجميع الأصول مثل الصور وأوراق الأنماط والنصوص وما إلى ذلك.
إجمالي وزن الصفحة: الحجم الإجمالي لجميع الأصول. غالبًا ما يتم الإبلاغ عنه بحجم مضغوط (تنزيل) وحجم غير مضغوط.
عدد عناصر DOM: العدد الإجمالي لعناصر HTML على الصفحة. كلما زاد عدد العناصر ، زادت مدة معالجة الصفحة.
First Contentful Paint (FCP): الوقت المستغرق قبل أن يعرض المستعرض بكسل المحتوى الأول.
الرسم الأول المعنى (FMP): الوقت المستغرق قبل أن يصبح محتوى الصفحة الأساسي مرئيًا للمستخدم.
وقت التفاعل (TTI): الوقت المستغرق قبل أن تصبح الصفحة تفاعلية بالكامل ويمكن أن تستجيب بشكل موثوق لإدخال المستخدم.
أول وحدة المعالجة المركزية في وضع الخمول: الوقت الذي تستغرقه وحدة المعالجة المركزية لعرض الصفحة وتشغيل جميع البرامج النصية للتهيئة ، في انتظار المزيد من المدخلات.
استخدام وحدة المعالجة المركزية: نشاط المعالجة المطلوب أثناء عرض الصفحة والاستجابة لإدخال المستخدم.
التخطيطات في الثانية: المعدل الذي يجب على المستعرض إعادة حساب الأنماط وتخطيطات الصفحة به.
يمكن استخدامها لتحديد الاختناقات المحددة مثل تحميل الخادم والتخزين المؤقت لنظام إدارة المحتوى والتخزين المؤقت للمتصفح وسرعات التنزيل وكفاءة JavaScript . لكن لا يمكنهم تحديد ما إذا كانت الصفحة توفر انطباعًا جيدًا أو سيئًا للمستخدم. على سبيل المثال:
يمكن تنزيل التطبيق والظهور بسرعة ولكنه يصبح غير مستجيب بعد التفاعل الأول لأنه ينفذ كمية كبيرة من كود JavaScript غير المحسن.
يمكن لتطبيق الدردشة تنزيل البيانات باستمرار أثناء قيام المستخدمين بنشر الرسائل. قد تفترض أداة التقييم أنه لم يكتمل تحميلها مطلقًا ، على الرغم من استجابة الصفحة.
Core Web Vitals هي محاولة Google لحل هذه المعضلات.
أساسيات الويب الأساسية من Google (CWV) هي ثلاثة مقاييس للأداء تقيم تجربة المستخدم في العالم الحقيقي:
أكبر طلاء محتوى (LCP): أداء التحميل
أول تأخير في الإدخال (FID): أداء التفاعل
التحول في التخطيط التراكمي (CLS): أداء الاستقرار المرئي
بدأ تحديث خوارزمية Google الجديد هذا في الظهور عالميًا بحلول نهاية أغسطس 2021. تؤثر مقاييس “أساسيات الويب الأساسية” بشكل أساسي على نتائج بحث الجوّال ، ولكن معادلات سطح المكتب ستتبع إذا نجحت التجربة.
تستند درجات LCP و FID و CLS للصفحة إلى آخر 28 يومًا من مقاييس المستخدم الحقيقي التي تم جمعها بشكل مجهول من خلال متصفح Chrome. يمكن أن تختلف هذه القياسات بسبب جهاز المستخدم والاتصال والأنشطة المتزامنة الأخرى ، لذلك يتم حساب النسبة المئوية الخامسة والسبعين بدلاً من المتوسط.
بعبارة أخرى ، يتم فرز المقاييس من جميع المستخدمين من الأفضل إلى الأسوأ ، ويتم أخذ الرقم عند نقطة الثلاثة أرباع. لذلك سيختبر ثلاثة من كل أربعة زوار للموقع هذا المستوى من الأداء أو أفضل.
ستحصل أي صفحة تحقق درجة جيدة (خضراء) لجميع مقاييس Core Web Vitals الثلاثة على ترتيب أعلى في نتائج البحث وسيتم تضمينها في مكتبة “Top Stories” في تطبيق أخبار Google.
في الأقسام التالية ، سنصف الخوارزمية المستخدمة لحساب أحد المقاييس ، والأدوات التي يمكنك استخدامها لتحديد درجة الصفحة ، والأسباب النموذجية للدرجات المنخفضة ، والخطوات التي يمكنك اتخاذها لحل مشكلات الأداء.
أكبر طلاء محتوى يقيس أداء التحميل . من حيث الجوهر ، ما مدى سرعة عرض المحتوى القابل للاستخدام على الصفحة؟
يحلل LCP الوقت الذي يستغرقه ظهور أكبر صورة أو كتلة نصية داخل إطار عرض المتصفح (في الجزء المرئي من الصفحة). في معظم الحالات ، سيكون العنصر الأبرز صورة رئيسية أو شعار أو عنوان أو كتلة نصية كبيرة.
أي من العناصر التالية مؤهل لتحليل Largest Contentful Paint:
صور ( <img>عنصر)
الصور داخل الرسومات المتجهة ( <image>مضمنة في أ <svg>)
الصور المصغرة للفيديو (يتم تعيين سمة الملصق على عنوان URL للصورة داخل <video>عنصر)
عناصر بها صور خلفية (عادةً ما يتم تحميلها background-image url()بخاصية CSS )
عناصر على مستوى الكتلة تحتوي على نص
الصفحات التي يتم فيها إكمال أكبر لوحة محتوى خلال أول 2.5 ثانية من تحميل الصفحة تعتبر جيدة (خضراء). الصفحات التي تتجاوز 4.0 ثوانٍ تعتبر رديئة (حمراء):
LCP هو أسهل مقياس أساسي لـ Web Vital يمكن فهمه ، ولكن قد لا يكون واضحًا العنصر الذي سيتم اختياره للتحليل.
يتم توفير لوحة DevTools Lighthouse في المتصفحات القائمة على Chromium مثل Chrome و Edge و Brave و Opera و Vivaldi. افتح DevTools من قائمة المتصفح – عادةً في المزيد من الأدوات > أدوات المطور أو اختصارات لوحة المفاتيح Ctrl | كمد + شيفت + ط أو F12 – ثم انتقل إلى منارة التبويب (الطبعات القديمة قد سمها ما التدقيق ).
أنشئ تقرير أداء للجوال ، ثم افحص قسم الأداء الناتج . يتم عرض أكبر وقت لطلاء المحتوى مع قسم قابل للتوسيع ، والذي يحدد العنصر المختار:
يمكنك إنشاء معلومات متطابقة في أدوات قياس PageSpeed Insights و web.dev عبر الإنترنت إذا لم يكن لديك وصول إلى متصفح يستند إلى Chromium:
تعرض لوحة DevTools Performance أيضًا مؤشر LCP. للبدء ، انقر فوق رمز السجل الدائري ، وأعد تحميل صفحتك ، ثم انقر فوق الزر ” إيقاف” لعرض التقرير. انقر فوق رمز LCP في قسم التوقيتات لتحديد العنصر وعرض ملخص للإحصائيات.
على تمديد الويب الأعضاء الحيوية متاح لجوجل كروم ولكن يمكن تركيبها على معظم المتصفحات أساس الكروم. يقوم بحساب مقاييس Core Web Vitals لكل موقع تزوره ، ويتحول الرمز الخاص به إلى اللون الأخضر أو البرتقالي أو الأحمر حسب النتيجة. يمكنك أيضًا النقر فوق رمز الامتداد لعرض المزيد من تفاصيل LCP:
تقدم Google Search Console الآن قسم “أساسيات الويب الحيوية” إذا تمت إضافة موقعك كموقع . يوضح التقرير كيف تغيرت مقاييس CWV بمرور الوقت. لاحظ أنه لا يحدد مقاييس LCP معينة ، ولا تتوفر سوى المواقع ذات عدد الزيارات المرتفع بشكل معقول:
في تجربة التبليغ كروم يسمح لك الاستعلام إحصائيات الاستخدام الحقيقية، بما في ذلك نظام الإجراءات الجزائية في مختلف البلدان، وصلات، والأجهزة، لURL محددة. إنه مشروع عام على Google BigQuery ، لذا يجب عليك التسجيل للحصول على حساب Google Cloud Platform وتقديم تفاصيل الفواتير. مرة أخرى ، سيكون التقرير مفيدًا فقط عندما يكون لعنوان URL مستوى مرتفع بشكل معقول من حركة المرور.
أخيرًا ، مكتبة JavaScript الخاصة بأساسيات الويب عبارة عن برنامج نصي صغير بسعة 1 كيلوبايت يمكنه حساب LCP ومقاييس Core Web Vital الأخرى للمستخدمين الحقيقيين على موقعك المباشر. نظرًا لأنه يمكن تنزيله من CDN ، يمكنك إضافة البرنامج النصي التالي إلى HTML الخاص بك <head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->getLCP()هي وظيفة غير متزامنة يتم تمريرها إلى رد اتصال يتم تشغيله عند حساب قيمة LCP (على الرغم من أنه قد لا يتم تشغيله أبدًا إذا تم تحميل الصفحة في علامة تبويب الخلفية). يتم تمرير وظيفة رد الاتصال كائنًا يحتوي على:
name: اسم المقياس (“LCP” في هذه الحالة)
value: القيمة المحسوبة
id: معرّف فريد يمثل هذا المقياس للصفحة الحالية
delta: دلتا بين القيمة الحالية وآخر قيمة تم الإبلاغ عنها
entries: مصفوفة من الإدخالات المستخدمة في حساب القيمة
يقوم البرنامج النصي أعلاه بإخراج الكائن إلى وحدة التحكم ، على الرغم من أنه من العملي إرسال البيانات إلى خادم أو Google Analytics لمزيد من التحليل.
عادةً ما تكون نتائج LCP الضعيفة ناتجة عن بطء تحميل الصفحات التي تمنع أكبر كتلة من الظهور بسرعة:
قد تكون استجابة الخادم بطيئة بسبب زيادة التحميل عليها أو القيام بعمل كثير لعرض الصفحة. قد لا يكون هذا خطأ موقعك بالضرورة – فقد يكون ذلك بسبب قيود الخادم إذا كنت تستخدم خدمة استضافة مشتركة .
يمكن أن يؤدي CSS و JavaScript لحظر العرض إلى تأخير تحميل الصفحة إذا تمت الإشارة إليهما في HTML أعلى المحتوى الأساسي.
يمكن أن تقلل الموارد الأخرى مثل الصور ومقاطع الفيديو الكبيرة النطاق الترددي المتاح وتستغرق وقتًا أطول للعرض.
يستغرق محتوى الصفحة الذي يتم إنشاؤه على العميل بدلاً من الخادم وقتًا أطول للظهور.
يمكن أن تحدد المراجعة الشاملة مشكلات التحميل ، ولكنها بشكل عام مسألة تقليل كمية البيانات المرسلة إلى المتصفح . ستساعد النصائح التالية في الحصول على درجة LCP أكثر صحة:
قم بترقية الخادم الخاص بك و / أو خدمة الاستضافة . تأكد من أن سرعات التنزيل تظل سريعة حتى في أوقات الاستخدام العالي.
تنشيط ضغط الخادم و HTTP / 2 +. لا يوجد سبب لعدم!
تقليل جهد الخادم . قم بإزالة التعليمات البرمجية غير المستخدمة ومكونات CMS الإضافية ، ثم قم بتمكين التخزين المؤقت الفعال .
تأكد من أن المتصفح يمكنه تخزين الملفات مؤقتًا بشكل فعال. قم بتعيين تجزئات Expires و Last-Modified و / أو ETag المناسبة في رأس HTTP ، بحيث لا يتم طلب الملفات مرة أخرى.
استخدم شبكة توصيل المحتوى (CDN) لتقسيم التحميل وأصول المضيف على خوادم أقرب جغرافيًا إلى المستخدمين.
تحسين الصور الخاصة بك . اختصرها إلى أصغر أبعادها واستخدم تنسيقًا مناسبًا لتقليل أحجام الملفات. تأكد من طلب أي صورة في أكبر كتلة محتوى في أقرب وقت ممكن ؛ و التحميل المسبق يمكن أن تساعد.
تحميل الصور الكسولة عن طريق إضافة loading=”lazy”سمة. أضف سمات العرض والارتفاع لضمان حجز المساحة المناسبة على الصفحة قبل اكتمال تحميل الصورة.
قلل طلبات الجهات الخارجية إلى الحد الأدنى ، وفكر في نقل الأصول إلى نطاقك الأساسي لتجنب عمليات البحث الدخيلة في نظام أسماء النطاقات.
قلل عدد وحجم الملفات المطلوبة ، خاصة في الجزء العلوي من HTML.
تأكد من تحميل خطوط الويب المطلوبة فقط. قم بالتبديل إلى الخطوط الآمنة للويب لتحقيق أقصى أداء.
قم بإزالة ملفات JavaScript و CSS غير المستخدمة.
اربط ملفات JavaScript و CSS وتصغيرها.
تجنب عبارات CSSimport – فهي تحظر التجسيد وتحميل الأنماط في سلسلة.
تجنب ترميز Base64 – فهو يزيد من أحجام الملفات ويتطلب معالجة إضافية.
ضع في اعتبارك CSS المضمنة الهامة. قم بتضمين CSS أساسي “الجزء المرئي من الصفحة” في <link>قالب بأعلى الصفحة ، ثم قم بتحميل المزيد من أوراق الأنماط بشكل غير متزامن.
استخدم JavaScript غير متزامن أو مؤجل أو وحدة ES لتشغيل البرامج النصية لاحقًا. نفِّذ عمليات جافا سكريبت طويلة المدى في عامل خدمة.
يقيس تأخير الإدخال الأول مدى استجابة صفحتك. في الأساس ، ما مدى سرعة استجابته لإجراءات المستخدم مثل النقر والنقر والتمرير؟
يتم حساب مقياس FID على أنه الوقت بين تفاعل المستخدم ومعالجة المتصفح لطلبه. لا يقيس الوقت اللازم لتشغيل وظيفة المعالج ، والتي عادةً ما تقوم بمعالجة الإدخال وتحديث DOM.
تعتبر الصفحات التي لها وقت FID 100 مللي ثانية أو أقل جيدة (خضراء). الصفحات التي يتجاوز حجمها 300 مللي ثانية تعتبر رديئة (أحمر):
من المستحيل محاكاة “تأخير الإدخال الأول” لأنه لا يمكن قياسه إلا عند تقديم الصفحة إلى مستخدم فعلي يتفاعل مع الصفحة. وبالتالي ، فإن النتيجة تعتمد على سرعة المعالج وقدراته.
لم يتم حساب FID في لوحة DevTools Lighthouse أو PageSpeed Insights . ومع ذلك ، يمكنهم تحديد إجمالي وقت الحظر (TBT). هذا تقدير تقريبي معقول لتأخير الإدخال الأول. يقيس الفرق في الوقت بين:
First Contentful Paint (FCP) ، أو الوقت الذي يبدأ فيه عرض محتوى الصفحة ، و
وقت التفاعل (TTI) ، أو الوقت الذي يمكن للصفحة فيه الاستجابة لإدخال المستخدم. يتم افتراض TTI عندما لا تكون هناك مهام نشطة لفترة طويلة ولا يزال أقل من ثلاثة طلبات HTTP لم تكتمل.
على تمديد الأعضاء الحيوية الويب لجوجل كروم يمكن أيضا أن تبدي ااا متري بعد التفاعل مع الصفحة عن طريق التمرير أو النقر. انقر فوق رمز الامتداد للكشف عن مزيد من المعلومات:
مثل LCP ، يتيح لك تقرير تجربة مستخدم Chrome الاستعلام عن إحصائيات FID الحقيقية المسجلة عبر بلدان واتصالات وأجهزة مختلفة لعنوان URL محدد.
و الحيويه الويب جافا سكريبت مكتبة يمكن أيضا حساب مقاييس ااا لمستخدمي حقيقي على موقعك المباشر. يمكنك إضافة البرنامج النصي التالي إلى HTML <head>لإخراج مقاييس FID إلى وظيفة رد الاتصال:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->عادةً ما تكون درجات FID و TBT الضعيفة ناتجة عن رمز من جانب العميل يعيق المعالج ، مثل:
هل سئمت من دعم استضافة وورد بريس من المستوى 1 دون الإجابات؟ جرب فريق الدعم العالمي! تحقق من خططنا
كميات كبيرة من CSS و JavaScript لحظر العرض ، مما يوقف تحميل الصفحة أثناء تنزيل الشفرة وتحليلها
نصوص برمجية كبيرة كثيفة المعالجة يتم تشغيلها فور تحميل الصفحة
مهام JavaScript طويلة المدى أو ضعيفة الأداء
بشكل افتراضي ، تعمل المتصفحات على سلسلة محادثات واحدة ، والتي يمكنها فقط معالجة مهمة واحدة في كل مرة. إذا استغرق تنفيذ وظيفة JavaScript ثانية واحدة ، فسيتم حظر جميع عمليات العرض الأخرى خلال تلك الثانية. لا يمكن للصفحة أن تتفاعل مع إدخال المستخدم أو تحديث DOM أو إظهار الرسوم المتحركة أو ما إلى ذلك. حتى الرسوم المتحركة بتنسيق GIF يمكن حظرها في المتصفحات القديمة.
يمكن لمراجعة JavaScript من جانب العميل تحديد المشكلات ، ولكنها تتعلق بشكل عام بإزالة التعليمات البرمجية الزائدة والتأكد من تنفيذ المهام بسرعة.
ستساعد النصائح التالية في الحصول على درجة FID أكثر صحة:
قم بإنشاء وتخزين أكبر قدر ممكن من محتوى HTML الثابت على الخادم. حاول ألا تعتمد على أطر عمل JavaScript من جانب العميل لعرض نفس HTML للجميع.
تأكد من أن المتصفح يمكنه تخزين الملفات مؤقتًا بشكل فعال. قم بتعيين تجزئات Expires و Last-Modified و / أو ETag المناسبة في رأس HTTP ، بحيث لا يتم طلب الملفات مرة أخرى.
اعتماد تقنيات التحسين التدريجي ، بحيث تكون الواجهة قابلة للاستخدام في HTML و CSS قبل تشغيل JavaScript.
قم بإزالة ملفات JavaScript و CSS غير المستخدمة.
اربط ملفات JavaScript و CSS وتصغيرها.
تجنب الاستخدام المفرط لخصائص CSS باهظة الثمن مثل box-shadow و filter.
استخدم JavaScript غير متزامن أو مؤجل أو وحدة ES لتشغيل البرامج النصية لاحقًا.
قلل طلبات JavaScript من الجهات الخارجية للتحليلات وأدوات الوسائط الاجتماعية ومنتديات المناقشة وما إلى ذلك.
مكونات JavaScript ذات التحميل الكسول عند الطلب ، مثل أدوات الدردشة ومشغلات الفيديو وما إلى ذلك.
تأخير تحميل النصوص الأقل أهمية مثل التحليلات والإعلانات وأدوات الوسائط الاجتماعية.
تفريق منذ فترة طويلة المهام جافا سكريبت في سلسلة من أصغر وظيفة التي تنفذ بعد فترة قصيرة requestIdleCallback ، setTimeout ، أو requestAnimationFrame تأخير.
ضع في اعتبارك تنفيذ عمليات جافا سكريبت طويلة المدى في عامل الويب ، والذي يستخدم مؤشر ترابط في الخلفية.
يقيس CLS الاستقرار المرئي للصفحة. في الأساس ، هل يتحرك محتوى الصفحة أو يقفز بشكل غير متوقع ، خاصة أثناء التحميل الأولي؟
يحسب CLS النتيجة عندما تتحرك العناصر دون تحذير أو تفاعل المستخدم. من المحتمل أنك واجهت هذا عند قراءة مقال على جهاز محمول – يقفز النص فجأة خارج الشاشة ، وتفقد مكانك. قد تتسبب أسوأ الأمثلة في النقر فوق ارتباط غير صحيح.
تكون مشكلات CLS أكثر وضوحًا عندما يتم تحميل صورة كبيرة أو إعلان فوق موضع التمرير الحالي وتزداد مساحة الارتفاع الصفري على الفور بعدة مئات من البكسل.
يتم حساب درجات التحول في التخطيط التراكمي بضرب المقاييس التالية معًا:
جزء التأثير: هذا هو إجمالي المساحة لجميع العناصر غير المستقرة في منفذ العرض ، أي العناصر التي “ستقفز”. إذا تم إزاحة العناصر التي تغطي 60٪ من إطار العرض أثناء تحميل الصفحة ، فسيكون جزء التأثير 0.6. لاحظ أن العناصر التي تسببت في هذا التحول ، مثل صورة أو إعلان ، تعتبر مستقرة لأنها لا تتحرك بالضرورة بعد عرضها.
جزء المسافة: هو أكبر مسافة يتحركها أي عنصر واحد غير مستقر في منفذ العرض. إذا حدثت أكبر إزاحة لعنصر يتحرك من 0.100 إلى 0.800 ، فهذا يعني أنه قد تم إزاحته بمقدار 700 بكسل رأسيًا. إذا كان ارتفاع إطار عرض الجهاز 1000 بكسل ، فإن جزء المسافة هو 700 بكسل / 1000 بكسل = 0.7. وبالتالي ، فإن درجة تحول التخطيط التراكمي المحسوبة هي 0.6 × 0.7 = 0.42.
أجرت Google تغييرات على مقياس CLS لاستيعاب المواقف التالية:
يتم تجميع تحولات التخطيط في “جلسات” تستمر لمدة خمس ثوان ولكنها تغلق بعد ثانية واحدة إذا لم تحدث تغييرات أخرى في التخطيط. في حالة حدوث نوبتين أو أكثر في غضون ثانية واحدة ، تتم إضافة درجاتهم.
لا يتم تسجيل تغييرات التخطيط لمدة 500 مللي ثانية بعد تفاعل المستخدم ، مثل النقرة. في بعض الحالات ، يؤدي هذا إلى تشغيل تحديثات DOM (على سبيل المثال ، فتح قائمة ، أو إظهار رسالة خطأ ، أو عرض مربع حوار مشروط ، وما إلى ذلك).
لا تتأثر التطبيقات أحادية الصفحة التي تظل مفتوحة لفترات أطول وتقوم بإجراء العديد من تحديثات DOM.
تعتبر الصفحات التي تحمل نتيجة CLS 0.1 أو أقل جيدة (خضراء). الصفحات التي تتجاوز 0.25 تعتبر رديئة (أحمر):
التحول في التخطيط التراكمي.
التحول في التخطيط التراكمي.
وتحسب CLS المقاييس في DevTools منارة لوحة، إحصاءات PageSpeed ، و web.dev قياس الأدوات:
PageSpeed Insights CLS.
PageSpeed Insights CLS.
يعرض ملحق Web Vitals لـ Google Chrome أيضًا مقياس CLS:
ملحق Web Vitals CLS.
ملحق Web Vitals CLS.
مثل LCP و FID ، يتيح لك تقرير تجربة مستخدم Chrome الاستعلام عن إحصائيات CLS الحقيقية المسجلة عبر بلدان واتصالات وأجهزة مختلفة لعنوان URL محدد.
و الحيويه الويب جافا سكريبت مكتبة يمكن أيضا أن تحسب CLS مقاييس المستخدمين الحقيقية على الموقع عبر الإنترنت، تماما كما هو الحال مع نظام الإجراءات الجزائية وااا. يمكن إضافة البرنامج النصي التالي إلى HTML <head>لإخراج مقاييس CLS إلى وظيفة رد الاتصال:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->عادةً ما تكون نتائج CLS الضعيفة ناتجة عن بطء تحميل أصول الصفحة وعناصر DOM الديناميكية أو غير الحجم:
المساحة الموجودة على الصفحة غير محجوزة للصور وإطارات iframe والإعلانات وما إلى ذلك.
يتم حقن المحتوى ديناميكيًا في DOM ، عادةً بعد طلب الشبكة للإعلانات وأدوات الوسائط الاجتماعية وما إلى ذلك.
يؤدي تحميل خط الويب إلى ظهور وميض ملحوظ للنص غير المرئي (FOIT) أو فلاش للنص غير المصمم (FOUT).
كيفية تحسين درجات التحول في التخطيط التراكمي
يمكن للتدقيق من جانب العميل تحديد المشكلات ، ولكن الأمر يتعلق عمومًا بضمان تخصيص مساحة للمحتوى قبل تنزيله. سيكون لنصائح تحسين الخادم المقترحة لـ Largest Contentful Paint بعض الفوائد ، ولكن من الممكن إجراء المزيد من التحسينات:
إضافة إلى عرض والصفات الارتفاع إلى HTML <img>و <iframe>العلامات أو استخدام جديدة CSS الممتلكات التي تبلغ نسبة أبعادها لضمان حجز مساحة مناسبة على الصفحة قبل التنزيلات الأصول.
قم بتعيين الأبعاد المناسبة لعناصر الحاوية التي تتضمن محتوى الطرف الثالث بطيء التحميل مثل الإعلانات والأدوات.
تأكد من طلب الصور والأصول الأخرى التي تظهر أعلى الصفحة في أقرب وقت ممكن – قد يكون التحميل المسبق مفيدًا.
قلل من استخدام خط الويب ، وفكر في استخدام خطوط نظام التشغيل المتاحة بشكل شائع عندما يكون ذلك ممكنًا.
قم بتحميل خطوط الويب واضبط عرض خطوط CSS على اختياري أو قم بالتبديل. تأكد من استخدام خط احتياطي بحجم مماثل لتقليل إزاحة التخطيط.
تجنب إدراج عناصر في الجزء العلوي من الصفحة ما لم تستجيب لإجراء مستخدم مثل نقرة.
تأكد من اكتمال تفاعلات المستخدم في غضون 500 مللي ثانية من مشغل الإدخال.
استخدم تحويل CSS والتعتيم للحصول على رسوم متحركة أكثر فاعلية لا تتطلب إعادة تخطيط.
ضع في اعتبارك CSS المضمنة الهامة. قم بتضمين CSS أساسي “الجزء المرئي من الصفحة” في <link>قالب بأعلى الصفحة ، ثم قم بتحميل أوراق أنماط إضافية بشكل غير متزامن.
عند الضرورة ، ضع في اعتبارك الاحتواء ، وهي ميزة CSS جديدة تسمح لك بتحديد الأشجار الفرعية المعزولة للصفحة. يمكن للمتصفح تحسين المعالجة عن طريق عرض – أو عدم عرض – كتل محتوى معينة من DOM.
لا يحرص المطورون دائمًا على الرقص على أنغام Google. تتمتع الشركة بقوة كبيرة ، ويمكن أن تؤثر التحديثات الطفيفة على محرك البحث سلبًا على إنتاجية المؤسسات القائمة على الويب وربحيتها.
ومع ذلك ، تتخذ Core Web Vitals نهج “الجزرة” بدلاً من “العصا”. تتمتع المواقع المُحسَّنة جيدًا والقابلة للاستخدام والتي تتخلى عن الأنماط المظلمة بفرصة نجاح أفضل من المواقع المتضخمة ذات النوافذ المنبثقة المكثفة التي تقدم واجهة مستخدم ضعيفة للجوّال.
توفر “أساسيات الويب الأساسية” طريقة قابلة للقياس لتقييم تجربة المستخدم لمساعدتك على التركيز على التحسينات الأكثر أهمية. قد لا تؤدي التغييرات التي تطرأ على العناصر الحيوية الخاصة بك إلى زيادة الإيرادات ، ولكن سيكون المستخدمون أكثر سعادة وأكثر ولاءً.
