تحديث Google في مايو 2021: نظرة فاحصة على Core Web Vitals

تحديث: عالم التسويق الرقمي يتغير باستمرار ، ولكن لا تقلق ، فنحن على رأسه. لقد غيرت Google رأيها بشأن الخوارزمية القادمة.

اقرأ التغييرات الأخيرة هنا في تحديثنا ، ولكن لا تتردد في قراءة هذه المدونة أيضًا.

في مايو 2021 ، ستقدم Google مقاييس Core Web Vitals (CWV) لتشكل جزءًا من خوارزمية تصنيف البحث. إليك ما تحتاج إلى معرفته ، والقيام به قبل ذلك ...

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

لكن جوجل لا تتوقف عند هذا الحد. مرة أخرى في مايو 2020 ، أخبرونا عن Core Web Vitals وفي 10 نوفمبر 2020 ، أعلنوا أنه في مايو 2021 ، سيتم دمج Core Web Vitals كإشارة بحث في خوارزمية التصنيف الشاملة.

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

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

لكن أولاً ، خلاصة ...

خلاصة: ما هي "حيوية الويب الأساسية"؟

تعد "أساسيات الويب الأساسية" مجموعة من 3 مقاييس جديدة لتجربة الصفحة تدخل في النتائج الإجمالية لسرعة الموقع. تلعب هذه المقاييس بالفعل دورًا بارزًا في أداة PageSpeed ​​Insights من Google PSI ومراقبة أداء Lighthouse في مكان آخر.

تتكون مقاييس CWV الجديدة مما يلي:

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

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

تساهم العديد من العوامل في LCP عالي بما في ذلك استجابة الخادم ونصوص وأنماط حظر العرض وتعقيد CSS والخطوط والصور

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

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

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

ترتبط مقاييس PSI الحالية لوقت التفاعل وإجمالي وقت الحظر بـ FID ، وتمثل مجتمعة 35٪ من درجات السرعة الإجمالية.

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

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

انهيار درجة السرعة

يوضح الرسم البياني أدناه تفصيلًا لدرجة السرعة الإجمالية ومدى حجم الدور الذي تلعبه مقاييس CWV الجديدة هذه في نتائج GPSI.

بيانات المصدر من تحديث نقاط Lighthouse

في حين أن المقاييس غير CWV تشكل أيضًا النتيجة الإجمالية بما في ذلك First Content Paint (FCP) و Time to Interactive (TTI) و Total Blocking Time (TBT) ، فإن التركيز على مقاييس CWV الثلاثة سيكون له تأثير مباشر على الآخرين. LCP سريع غير ممكن على سبيل المثال بدون FCP سريع ودرجات FID العالية تتأثر بشكل مباشر بواسطة TBT و TTI.

نصائح لأكبر تحسين محتوى مضمون

يتكون مقياس LCP من العديد من العوامل الفردية ويتأثر بشكل مباشر بـ FCP المرتفع. إذا تم وضع علامة FCP على أنها فقيرة ، فقد ترغب في البدء هنا. سيؤثر أي شيء بدءًا من اتصال الشبكة واستجابة الخادم و Time To First Byte TTFB وملفات حظر العرض على قيمة FCP. للحصول على مزيد من التعمق في بعض توصيات سرعة الصفحة الأكثر عمومية هذه ، تحقق من الكتاب الإلكتروني لسرعة الصفحة الخاص بنا حول هذا الموضوع بالإضافة إلى نصائح LCP المحددة أدناه.

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

حدد أكبر عنصر

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

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

على موقع Hallam في المثال أعلاه ، يعرض مراقب الأداء LCP كعنوان رئيسي "Thrive Online". من الناحية المثالية ، يجب أن يتبع LCP فورًا FCP كما في هذا المثال ، وإذا كانت هناك فجوة بين الاثنين ، فنحن بحاجة إلى محاولة فهم السبب.

هل تم تحسين الخطوط؟

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

1. استخدم عرض خط CSS: swap؛ لضمان عرض الخط الفوري أثناء تحميل ملف الخط. تتمتع كل من Google Fonts و Typekit من Adobe بالقدرة على تعيين معلمة "عرض" الخط.
2. حاول استضافة ملفات الخطوط .woff و. woff2 محليًا على الخادم بدلاً من إجراء طلبات عبر المجال لخطوط الجهات الخارجية. تعد Google Fonts سريعة جدًا ، وخطوط Typekit أبطأ وبعض أدوات إنشاء الخطوط التابعة لجهات خارجية يمكن أن تكون أقل موثوقية.
3. يمكن أن يساعد تحميل ملفات الخطوط مسبقًا. غالبًا ما يتم تضمين الخطوط المستضافة محليًا في ورقة الأنماط الرئيسية لمواقع الويب ، ولكن يجب تنزيل ورقة الأنماط هذه وتحليلها قبل تقديم طلب إضافي للخط الموجود بداخلها. يُخبر التحميل المسبق المتصفح ببدء تنزيل الخط في وقت أقرب ، دون انتظار تحليل CSS.
4. استخدم الاتصال المسبق والجلب المسبق لنظام أسماء النطاقات لمنشئي خطوط الجهات الخارجية. ستساعد هذه التوجيهات في إنشاء اتصالات DNS و TLS و TCP بين نطاقات الطرف الثالث قبل تقديم الطلب للخطوط.
5. قم فقط بتضمين ملفات الخطوط للطباعة المطلوبة للشاشة العلوية القابلة للطي. من المعروف أن أصول الخطوط الخاصة بمكتبات الأيقونات مثل Font Awesome ثقيلة بشكل ملحوظ ولكن الطلبات لهذه (ومكتبة الأيقونات CSS المقابلة) يمكن عادةً تأجيلها وتحميلها بعد عنصر <head>.
6. لا تقدم طلبات عبر المجال لملفات الخطوط داخل ورقة أنماط الموقع الرئيسي لأن هذا يعتمد على الاتصال والبحث الإضافي لمجال طرف ثالث.
7. ضع في اعتبارك الخطوط الآمنة للويب. هذه لا تتطلب أي طلبات لملفات الخطوط ، على الرغم من أنها يمكن أن تكون محدودة للغاية من حيث الجماليات.

هل الصور محسّنة؟

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

1. استخدم نوع ملف الصورة الصحيح. يجب استخدام صور JPG للصور الفوتوغرافية أو SVG للرسومات المتجهة والأيقونات أو ملفات PNG للصور الأكثر تعقيدًا وغير الفوتوغرافية وإذا كانت الشفافية مطلوبة.
2. تأكد من حفظ صور JPG أو إخراجها بجودة تتراوح بين 50 و 60٪. في هذا المستوى ، يجب ألا يكون هناك خسارة ملحوظة في الجودة. تأكد أيضًا من إزالة البيانات الوصفية من الصور.
3. يمكن لمكونات الضغط أو الخدمات مثل tinypng.com تحسين الصور تلقائيًا وبشكل مجمّع وإزالة البيانات الوصفية غير الضرورية.
4. يجب أن تكون الصور بحجم مناسب للمنطقة التي يتم عرضها فيها. لا تقم بإخراج صورة سطح المكتب عالية الجودة على الهاتف المحمول.
5. يجب إخراج الصور باستخدام علامة <img> القياسية مع السمة "srcset" للصور سريعة الاستجابة.
6. يجب أن تستخدم الصور الموجودة أسفل الجزء المرئي من الشاشة أو التي تظهر خارج الشاشة سمة التحميل = "كسول".
7. استخدم تنسيق ملف صورة الويب من الجيل التالي للحصول على معدلات ضغط أفضل. هذا يمكن أن يوفر بسهولة 30٪ وفي كثير من الحالات أعلى من ذلك بكثير.
8. ضع في اعتبارك التحميل المسبق لأكبر صورة فوق الجزء المرئي من الصفحة لبدء التنزيل بشكل أسرع قبل المحتوى الآخر الذي قد يكون أقل أهمية.

تقليل حظر الملفات

يعتبر أي ملف JavaScript أو CSS يتم تحميله في عنصر <head> </head> بمثابة حظر للعرض حيث يلزم تنزيل هذه الملفات قبل أن تبدأ الصفحة في العرض. يمكن أن يكون لهذا تأثير كبير على كل من مقياس FCP و LCP. يجب استخدام ملفات حظر العرض في الرأس فقط إذا كانت ضرورية للعرض الأولي فوق الجزء المرئي على الصفحة.

ستؤدي إزالة أي ملفات غير مستخدمة في <head> ، أو تحميل ملفات غير مهمة في التذييل ، أو دمج ملفات متعددة في ملفات أقل إلى تقليل مقدار أصول حظر العرض.

لا تستخدم JavaScript لعرض LCP

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

إذا كان عرض أكبر عنصر يعتمد على JavaScript ، فقد يتسبب ذلك غالبًا في تأخير طويل حيث يجب تنزيل JavaScript وتحليله وتنفيذه قبل ظهور العنصر. عادةً ما يتم تحميل ملفات JavaScript (وبشكل صحيح تمامًا) بعد عنصر <head> لذا فهي ليست "تمنع العرض" ، ولكن هذا يعني أنه لا يزال بإمكانها منع عرض LCP بشكل فعال.

ألق نظرة على المثال أدناه (تم تعتيم الشعار وتغيير العنوان) هذا من موقع يحرز درجات عالية في PSI. يقع LCP (نص العنوان الرئيسي) على بعد عدة ثوانٍ من FCP والذي ينتج عن متطلبات JavaScript (ممثلة بالأشرطة الصفراء) للتنزيل والتحليل والتنفيذ قبل أن يتلاشى النص.

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

يمكن لتقنيات جافا سكريبت مثل هذه أن تقلل على الفور من نتائج السرعة الإجمالية بنسبة 25٪ ويجب عدم استخدامها لإعاقة أو منع تحميل العنصر الأكبر بأي شكل من الأشكال.

تنفيذ البرامج النصية عند تحميل النافذة

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

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

قم بتبديل LCP

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

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

تلميحات لتحسين تأخير الإدخال الأول

كما ذكرنا من قبل ، يقيس FID مدى استجابة الصفحة لإدخال المستخدم. فهو يجمع بين TTI التفاعلية ووقت الحظر الإجمالي TBT والتي يمكن أن تمثل ما يصل إلى 35٪ من درجات السرعة الإجمالية.

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

من المهم ملاحظة أن "بيانات المختبر" الموضحة في PSI لا تقيس FID بشكل مباشر. ويرجع ذلك إلى الطبيعة التفاعلية للقياس من الصنابير أو النقرات من قبل المستخدم والتي يصعب محاكاتها. بدلاً من ذلك ، يتم جمعها بواسطة "بيانات الحقل" ؛ تم جمع القياسات من المستخدمين الفعليين على مدار 28 يومًا استنادًا إلى تقرير تجربة مستخدم Chrome CrUX.

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

إذن كيف نبدأ في تحسين هذه المقاييس؟

تدقيق جافا سكريبت الخاص بك

يمكن أن تأتي JavaScript بجميع الأشكال والأحجام وليس من غير المألوف أن يكون تضمين فيديو واحد أو أداة دردشة أو نص ReCaptcha أو تكامل HubSpot هو السبب الوحيد وراء ارتفاع مقاييس FID و TTI و TBT.

تُعد لوحات التشخيص في Page Speed ​​Insights مكانًا جيدًا للبدء. سيخبرك قسم "تقليل عمل الخيط الرئيسي إلى الحد الأدنى" بمقدار وقت التنفيذ الذي تستغرقه JavaScript ، وسيشير قسم "تقليل وقت تنفيذ JavaScript" إلى الملفات ذات أوقات التحليل والتنفيذ العالية و "تقليل تأثير الجهات الخارجية كود 'سوف يبرز ويجمع نصوص الطرف الثالث عالية التأثير.

تُظهر لقطة الشاشة أدناه موقعًا يعاني من العديد من البرامج النصية الثقيلة ، مع قياس وقت التفاعل لمدة 15 ثانية. العديد من البرامج النصية من جهات خارجية بما في ذلك HubSpot و Vimeo.

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

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

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

تحميل البرامج النصية بشكل غير متزامن

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

تحميل JavaScript بشروط

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

تبسيط حزم JavaScript

غالبًا ما تُستخدم مكتبات JavaScript مثل jQuery UI أو Bootstrap لتوفير ميزات ووظائف JavaScript إضافية. إذا كنت تستخدم حزمة ، فتأكد من تضمين الميزات ذات الصلة فقط داخل الحزمة لحفظ JavaScript غير الضرورية من التنزيل والتحليل.

نصوص تحميل كسول عند الحاجة

حتى إذا تم تحميل JavaScript فقط على الصفحات المطلوبة عليها ، فإن النص البرمجي نفسه لا يحتاج بالضرورة إلى التحليل والتنفيذ أثناء تحميل الصفحة أو حدث تحميل النافذة. يمكن أن يؤدي تحميل JavaScript فقط عند الحاجة إليه بالفعل إلى إحداث فرق كبير في مقاييس TTI و TBT و FID. وهنا بعض الأمثلة:

1. عادةً ما يكون لتضمينات الفيديو مثل YouTube و Vimeo تأثير كبير. ضع في اعتبارك تحميل هذه البرامج النصية فقط عند النقر فوق الصورة المصغرة للفيديو بدلاً من ذلك.
2. يمكن أن تكون عمليات تكامل نماذج الجهات الخارجية مثل HubSpot مكثفة. إذا ظهر النموذج في شكل مشروط ، أو في أسفل الصفحة ، ففكر في تحميل أو إدخال البرنامج النصي المطلوب في التمرير أو التنشيط الشرطي بدلاً من تحميل الصفحة.
3. يمكن أن تؤثر أدوات الدردشة المباشرة على نتائج السرعة الإجمالية بنسبة تصل إلى 35٪. ضع في اعتبارك نقل أداة الدردشة المباشرة إلى صفحة اتصال مخصصة مع دعم CTA العالمي للدردشة المباشرة ، أو حقن نص الدردشة الحية فقط عند النقر على زر "الدردشة معنا".
4. يمكن أن تساعد إضافة السمة "loading =" lazy "على المحتوى المضمّن المستند إلى iFrame ، ولكنها ميزة جديدة في المستعرض وستحتاج إلى اختبار اعتمادًا على تضمين iFrame المستخدم.

تقييم أدوات ذكاء الأعمال

يعد تحليل سلوك المستخدم باستخدام أدوات مثل Hotjar أو برنامج اختبار A / B مثل VWO أمرًا مهمًا حقًا لذكاء الأعمال وفي كثير من الحالات ، ستفوق فوائدها التأثير على سرعة الموقع.

بعد قولي هذا ، لا يزال من المفيد تقييم أهمية تشغيل هذه الأدوات على مدار الساعة طوال أيام الأسبوع اعتمادًا على مدى تكرار تحليل البيانات. يجب إيقاف تشغيل اختبار A / B في حالة عدم تشغيل اختبارات نشطة على سبيل المثال ، وقد يتم إلغاء تنشيط أدوات تحليل السلوك مثل Hotjar بعد جمع بيانات كافية ومعالجتها.

تلميحات للتحسين التراكمي لمخطط التحول

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

تحديد عنصر CLS

في بعض الأحيان قد يبدو واضحًا ما هو العنصر أو العناصر التي تسبب تحولًا في المحتوى ، ولكن الأمر يستحق دائمًا التحقق من ذلك من خلال لوحة Layout Shift في PSI كما هو موضح أدناه.

يجب أن يكون مقياس CLS أقل من 0.1 ، ولكن في المثال أعلاه ، يتم تجاوز ذلك بأكثر من 400٪ وسيتكلف انخفاضًا بنسبة 5٪ في الدرجات. إذا كانت هذه مشكلة عالمية ، فإن هذا يمثل 5٪ في كل صفحة.

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

احترس من الرسوم المتحركة

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

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

حدد أبعاد الصورة

إذا لم يكن للعلامة <img> مجموعة سمات العرض والارتفاع ، أو لم يتم استخدام CSS لتعيين أبعاد أو نسبة الصورة ، فستحتاج المتصفحات إلى تنزيل الصورة أولاً قبل التمكن من تحديد منطقة البكسل التي تحتاجها عرض في. يمكن أن يتسبب هذا في تغيير أي محتوى يتم عرضه أسفل الصورة ، حيث يتم تحميل الصورة.

سيضمن تحديد عرض الصورة وارتفاعها ، أو تعيين أبعاد أو نسبة الصورة (أو الحاوية الأصلية) داخل CSS قبل تنزيل الصورة ، أن تعرف المتصفحات المنطقة التي يجب أن تظهر فيها الصورة وتتجنب التخطيط المحتمل تحول.

لافتات

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

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

هناك عدد من القرارات لهذا:

1. عيّن حدًا أدنى للارتفاع لحاوية البانر أو الشعار في CSS حتى يتمكن المستعرض من عرض عنصر نائب بشكل فعال. على الرغم من أن هذا قد يكون مشكلة إذا كان مقدار المحتوى ديناميكيًا وغير معروف.
2. تمامًا أو قم بإصلاح موضع اللافتة أعلى الشاشة أو أسفلها. بالنسبة إلى اللافتات التي يمكن إغلاقها أو رفضها ، يعد هذا اعتبارًا جيدًا لأن العناصر الثابتة لن تؤثر على موضع أي عناصر أخرى.
3. انظر إلى عرض جانب الخادم لمحتوى الشعارات إن أمكن ، مما يعني أنه يمكن تحميل أبعاد المحتوى والشعار مقدمًا قبل أن تصل إلى المستخدم.

ملخص

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

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