الطرق الأكثر فعالية لتحسين "مؤشرات أداء الويب الأساسية"

على مرّ السنين، ساهم منتدى الويب في بناء مجموعة وافرة من المعلومات المتعلقة بتحسين أداء الويب. على الرغم من أنّ أي تحسين واحد قد يُحسِّن الأداء في العديد من المواقع الإلكترونية، إلا أنّ تطبيق جميع التحسينات في الوقت نفسه قد يكون أمرًا شاقًا، وبعض التحسينات فقط هي التي يمكن تطبيقها على أي موقع إلكتروني معيّن.

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

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

• يمكنك تحقيق أكبر تأثير حقيقي
• تكون ملائمة وقابلة للتطبيق على معظم المواقع الإلكترونية
• أن تكون قابلة للتنفيذ من قِبل معظم المطوّرين

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

مدى استجابة الصفحة لتفاعلات المستخدم (INP)

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

1. استخدِم Yield بشكل متكرّر لتقسيم المهام الطويلة.

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

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

تتيح لك Scheduler API إضافة المهام إلى "قائمة الانتظار" باستخدام نظام الأولويات. وعلى وجه التحديد، تُقسّم واجهة برمجة التطبيقات scheduler.yield()‎ المهام الطويلة مع ضمان إمكانية معالجة التفاعلات بدون التخلي عن مكانها في قائمة المهام.

من خلال تقسيم المهام الطويلة، تمنح المتصفّح المزيد من الفرص لتنفيذ المهام المُهمّة التي تمنع المستخدمين من التصفّح.

2. تجنُّب استخدام JavaScript غير الضروري

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

ومع ذلك، هذه المشكلة قابلة للحل، وتتوفّر لك خيارات:

• استخدِم ميزات Baseline المتاحة على نطاق واسع لمنصّة الويب بدلاً من عمليات التنفيذ المتكرّرة المستندة إلى JavaScript.
• استخدِم أداة تغطية الرمز في Chrome DevTools للعثور على الرموز غير المستخدَمة في نصوصك البرمجية. من خلال تقليل حجم الموارد المطلوبة أثناء بدء التشغيل، يمكنك ضمان أن تقضي الصفحات وقتًا أقل في تحليل الرمز البرمجي وتجميعه، ما يقدّم تجربة أولية أكثر سلاسة للمستخدم.
• استخدِم ميزة تقسيم الرموز البرمجية لإنشاء حِزمة منفصلة للرموز البرمجية غير الضرورية للعرض الأوّلي، ولكن سيتم استخدامها لاحقًا.
• إذا كنت تستخدم أحد برامج إدارة العلامات، يجب تحسين علاماتك بشكل دوري. ويمكن إزالة العلامات القديمة التي تحتوي على رمز غير مستخدَم لتقليل تأثير JavaScript في أداة "إدارة العلامات من Google".

3- تجنُّب تعديلات العرض الكبيرة

إنّ تنفيذ JavaScript ليس سوى تأثير واحد يؤثّر في استجابة موقعك الإلكتروني. إنّ العرض هو نوع من الأعمال المُكلفة بحد ذاتها، وخلال عمليات تعديل العرض الكبيرة، قد يستغرق موقعك الإلكتروني وقتًا أطول في الاستجابة لتفاعلات المستخدمين.

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

• أعِد تنظيم عمليات القراءة والكتابة في DOM في رمز JavaScript لتجنُّب التنسيق القسري والتغيير المفاجئ في التنسيق.
• احرص على أن تكون أحجام DOM صغيرة. هناك ارتباط بين حجم DOM وكثافة عمل التنسيق. عندما يحتاج المشغّل إلى تعديل تنسيق نموذج DOM كبير جدًا، يمكن أن يزداد العمل المطلوب لإعادة احتساب تنسيقه بشكل كبير.
• استخدِم احتواء CSS لعرض محتوى DOM خارج الشاشة بشكل كسول. ولا يسير الأمر دائمًا بشكل مباشر، ولكن من خلال عزل المناطق التي تحتوي على تخطيطات معقدة، يمكنك تجنب أعمال التخطيط والعرض غير الضرورية.

سرعة عرض أكبر محتوى مرئي (LCP)

سرعة عرض أكبر محتوى مرئي (LCP) هي مؤشر "أداء الويب الأساسي" الذي يواجه المطوّرون صعوبة في تحسينه. و%40 من المواقع الإلكترونية في تقرير تجربة المستخدم في Chrome لا تستوفي الحدّ الأدنى المُقترَح لسرعة عرض أكبر محتوى مرئي لتوفير تجارب مستخدمين جيدة. ينصح فريق Chrome باستخدام الأساليب التالية باعتبارها الطرق الأكثر فعالية لتحسين LCP.

1. تأكَّد من أنّه يمكن العثور على مورد LCP من مصدر HTML ومن أنّه تم منحه الأولوية.

لاحظ فريق Chrome ما يلي في ما يتعلّق بمقياس LCP على الويب:

• وفقًا لتقرير Web Almanac لعام 2022 الصادر عن HTTP Archive، تتضمّن %72 من صفحات الأجهزة الجوّالة صورة كعنصر LCP.
• يُظهر تحليل بيانات المستخدمين الفعليين من Chrome أنّ معظم المواقع التي تحقّق أداءً ضعيفًا في مقياس LCP تقضي أقل من %10 من وقت p75 LCP في تنزيل صورة LCP.
• من بين الصفحات التي تحقّق أداءً ضعيفًا في مقياس "سرعة عرض أكبر محتوى مرئي" (LCP)، يتأخّر تحميل صور LCP على العميل بمقدار 1,290 ملي ثانية في الشريحة المئوية التسعون، أي أكثر من نصف الميزانية لتوفير تجربة سريعة.
• من الصفحات التي كان فيها عنصر LCP صورة، كان لنسبة %39 من هذه الصور عناوين URL لمصادرها لا يمكن اكتشافها في ردّ HTML الأوّلي (مثل <img src="..."> أو <link rel="preload" href="...">)، ما كان سيسمح لماسح التحميل المُسبَق للمتصفّح باكتشافها في أقرب وقت ممكن.
• وفقًا لإحصاءات الويب، %0.03 فقط من الصفحات المؤهّلة كانت تستفيد من سمة HTML fetchpriority لمنح الأولوية للموارد، بما فيها الموارد التي يمكن أن تحسّن سرعة عرض أكبر محتوى مرئي على الصفحة بدون بذل مجهود ضئيل نسبيًا.

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

عند حدوث تأخير في تحميل الموارد، من الضروري تذكُّر أنه قد فات الأوان لتحقيق سرعة عرض أكبر محتوى مرئي (LCP) إذا كانت الصفحة تحتاج إلى الانتظار حتى يتم تحميل CSS أو JavaScript بالكامل قبل أن تتمكن من بدء تحميل الصور. بالإضافة إلى ذلك، يمكن تقليل مدة تحميل مورد صورة LCP من خلال إعادة ترتيب أولوياتها لكي تتلقّى معدل نقل بيانات أكبر، وبالتالي يتم تحميلها بسرعة أكبر باستخدام سمة HTML fetchpriority.

إذا كان عنصر LCP صورة، يجب أن يكون عنوان URL للصورة قابلاً للاستكشاف في استجابة HTML لتقليل تأخّر تحميل الموارد. في ما يلي بعض النصائح لإجراء ذلك:

• حمِّل الصورة باستخدام عنصر <img> مع السمة src أو srcset. لا تستخدِم سمات غير عادية، مثل data-src، تتطلّب JavaScript من أجل عرضها، لأنّ هذه السمات ستكون دائمًا أبطأ. تحجب %9 من الصفحات صورة LCP خلف data-src.
• افضِّل العرض من جهة الخادم (SSR) على العرض من جهة العميل (CSR)، لأنّ العرض من جهة الخادم يشير إلى أنّ ترميز الصفحة الكامل (بما في ذلك الصورة) متوفّر في مصدر HTML. تتطلّب حلول CSR تشغيل JavaScript قبل أن يتم اكتشاف الصورة.
• إذا كان يجب الإشارة إلى صورتك من ملف CSS أو JS خارجي، سيظل بإمكانك تضمينها في مصدر HTML باستخدام علامة <link rel="preload">. يُرجى العلم أنّ أداة فحص التحميل المُسبَق في المتصفّح لا يمكنها اكتشاف الصور التي تتم الإشارة إليها من خلال الأنماط المضمّنة، لذا قد يستمر حظر اكتشافها حتى إذا تم العثور عليها في مصدر HTML، وذلك أثناء تحميل موارد أخرى، لذا يمكن أن يساعد التحميل المُسبَق في هذه الحالات.

بالإضافة إلى ذلك، يمكنك تقليل مدة تحميل أحد الموارد من خلال التأكّد من تحميل مورد LCP مبكرًا وبأولوية عالية:

• أضِف سمة fetchpriority="high" إلى علامة <img> أو <link rel="preload"> لصورة LCP. يؤدي ذلك إلى زيادة أولوية مورد الصورة حتى يبدأ تحميله في وقت أقرب.
• أزِل سمة loading="lazy" من علامة <img> لصورة LCP. ويؤدي ذلك إلى تجنُّب تأخُّر التحميل الناتج عن التأكّد من ظهور الصورة في مساحة العرض أو بالقرب منها.
• أرجِئ تحميل الموارد غير المهمة متى أمكن. سيساعد نقل هذه الموارد إلى نهاية المستند أو تحميل الصور بشكل بطيء أو إطارات iframe أو تحميلها بشكل غير متزامن باستخدام JavaScript في إزالة العوائق أمام الموارد الأكثر أهمية، مثل صورة LCP، لتحميلها بشكل أسرع.

2. استهدِف عمليات التنقّل الفورية.

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

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

تتيح ميزة التخزين المؤقت للصفحات (bfcache) استعادة الصفحات التي سبق لك زيارتها. لاستخدام هذه الميزة، يجب التأكّد من أنّ صفحاتك تستوفي معايير الأهلية لاستخدام ذاكرة التخزين المؤقت في علامة التبويب الإضافية (bfcache). إنّ الأسباب الشائعة لعدم أهلية الصفحات لاستخدام ذاكرة التخزين المؤقت bfcache هي أنّها يتم عرضها باستخدام توجيهات التخزين المؤقت no-store أو أنّها تحتوي على أدوات معالجة أحداث unload.

لا تؤدي استعادة الصفحات المعروضة بالكامل إلى تحسين أداء التحميل فحسب، بل يحسِّن أيضًا ثبات التنسيق. يمكنك معرفة المزيد من المعلومات عن ميزة bfcache ومدى فعاليتها في تحسين متغيّرات التصميم التراكمية (CLS) في قسم تأكد من أن الصفحات مؤهلة لاستخدام ميزة bfcache.

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

3- استخدام شبكة توصيل المحتوى (CDN) لتحسين وقت استجابة خادم الويب

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

ويُعرف هذا الوقت باسم مدة تحميل أول بايت (TTFB). إليك أفضل الطرق لتقليل وقت استجابة الخادم:

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

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

يمكن لشبكات توصيل المحتوى (CDN) أيضًا عرض ملفات HTML وتخزينها مؤقتًا، ولكن وفقًا لـ Web Almanac، تم عرض %29 فقط من طلبات ملفات HTML من شبكة توصيل محتوى. وهذا يعني أنّ هناك فرصة كبيرة أمام المواقع الإلكترونية لتحقيق وفورات إضافية.

تتضمن بعض النصائح حول ضبط شبكات توصيل المحتوى (CDN) ما يلي:

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

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

متغيّرات التصميم التراكمية (CLS)

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

1. تعيين أحجام واضحة لأي محتوى يتم تحميله من الصفحة

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

إنّ أفضل طريقة لحلّ مشكلة تغييرات التنسيق الناتجة عن الصور غير المحددة الحجم هي ضبط السمتَين width وheight بشكل صريح أو السمتَين المكافئتَين في CSS. تحتوي %72 من الصفحات على صورة واحدة على الأقل غير مُعدّة للعرض. في حال عدم تحديد حجم واضح، يكون ارتفاع هذه الصور 0px في البداية، ما قد يؤدي إلى تغييرات في التنسيق عند تحميل هذه الصور واكتشاف المتصفّح لأبعادها. يمثّل ذلك فرصة كبيرة للويب المجمّع، وتتطلّب هذه الفرصة جهدًا أقل من بعض الاقتراحات الأخرى الواردة في هذا الدليل.

إنّ الصور ليست المساهم الوحيد في CLS. قد تحدث تغييرات في التصميم بسبب محتوى آخر يتم تحميله عادةً بعد عرض الصفحة لأول مرة، بما في ذلك إعلانات الجهات الخارجية أو الفيديوهات المضمّنة. يمكن أن تساعدك السمة aspect-ratio هنا. وهي ميزة CSS متوفّرة على نطاق واسع تسمح للمطوّرين بضبط نسبة عرض إلى ارتفاع للصور وكذلك على العناصر غير المتعلّقة بالصور. يتيح لك ذلك ضبط width ديناميكي (على سبيل المثال، استنادًا إلى حجم الشاشة)، وجعل المتصفّح يحسب الارتفاع المناسب تلقائيًا، بالطريقة نفسها التي يحسب بها الارتفاع المناسب للصور التي تتضمّن سمات.

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

2. التأكّد من أنّ الصفحات مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات"

كما هو موضّح سابقًا في هذا الدليل، تعمل ميزة التخزين المؤقت للصفحات (bfcache) على تحميل صفحة سابقة أو لاحقًا في سجلّ المتصفّح من لقطة ذاكرة. على الرغم من أنّ ميزة "التخزين المؤقت للصفحات" تُعدّ تحسينًا مهمًا للأداء على مستوى المتصفّح تعمل على تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، فإنها تزيل تمامًا متغيّرات التصميم. في الواقع، كان طرح ذاكرة التخزين المؤقت bfcache في عام 2022 مسؤولاً عن أكبر تحسين في مقياس CLS الذي شهدناه في ذلك العام.

ومع ذلك، عدد كبير من المواقع الإلكترونية غير مؤهَّلة لاستخدام ذاكرة التخزين المؤقت bfcache، وبالتالي لا تستفيد من هذه الميزة المجانية لتحسين أداء الويب. تأكَّد من أنّ صفحاتك مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات"، ما لم تكن الصفحة تحمّل معلومات حسّاسة لا تريد استعادتها من الذاكرة.

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

3- تجنَّب استخدام الصور المتحركة وتأثيرات الانتقال التي تستخدِم خصائص CSS التي تؤدي إلى تغيير التنسيق.

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

على الرغم من أنّ بيانات HTTP Archive لا يمكنها ربط الصور المتحركة بوضوح بتغييرات التنسيق، إلا أنّ البيانات تُظهر أنّ الصفحات التي تُنشئ صورًا متحركة لأيّ سمة CSS يمكنها التأثير في التنسيق يقلّ احتمال أن تحقّق قيمة "جيدة" لمقياس CLS بنسبة %15 مقارنةً بالصفحات بشكل عام. ترتبط بعض المواقع الإلكترونية بقيمة CLS أسوأ من غيرها. على سبيل المثال، إنّ الصفحات التي تحرّك العرض margin أو border تسجّل متغيّرات التصميم التراكمية (CLS) "ضعيفة" بمعدّل يقارب ضعف معدّل تقييم الصفحات على أنّها سيئة.

وهذا ليس بالأمر المستغرب، لأنّه في كل مرة تنتقل فيها أو تحرّك أي خاصية بتنسيق CSS، سيؤدي ذلك إلى حدوث تغييرات في التنسيق. إذا لم تحدث تغييرات التصميم هذه خلال 500 ملي ثانية من تفاعل المستخدم، ستؤثّر في مقياس CLS.

قد يفاجئ بعض المطوّرين أنّ ذلك صحيح حتى في الحالات التي يتم فيها نقل العنصر خارج مسار المستند العادي. على سبيل المثال، تؤدي العناصر التي تم وضعها بشكل مطلق وتستخدم top أو left في الصور المتحركة إلى تغييرات في التنسيق، حتى إذا لم تكن تدفع المحتوى الآخر. ومع ذلك، إذا أضفت صورًا متحركة لـ top أو left بدلاً من إضافة صور متحركة transform:translateX() أو transform:translateY()، لن يعدِّل المتصفّح تنسيق الصفحة، وبالتالي يتم تجنُّب متغيّرات التصميم.

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

كقاعدة عامة، لا تُضِف أبدًا تأثيرات متحركة أو انتقالات إلى خصائص CSS التي تتطلّب من المتصفّح تعديل تنسيق الصفحة، ما لم تكن تفعل ذلك استجابةً لنقرة المستخدم أو ضغطه على مفتاح (وليس hover). واختَر الانتقالات والصور المتحركة كلما أمكن باستخدام خاصية transform في CSS.

يُصدر تقرير تدقيق Lighthouse الخاص بـ تجنُّب الصور المتحركة غير المركّبة تحذيرًا عندما تعرض الصفحة صورًا متحركة لخصائص CSS قد تكون بطيئة.

الخاتمة

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

إذا أردت إجراء المزيد من التحسينات غير المُدرَجة هنا، يمكنك الاطّلاع على الأدلة التالية للحصول على مزيد من المعلومات:

• تحسين INP
• تحسين LCP
• تحسين متغيّرات التصميم التراكمية

الملحق: سجلّ التغييرات

سيتم تتبُّع التغييرات الرئيسية في هذا المستند هنا للمساعدة في توضيح وقت تغيُّر أهم الاقتراحات وسببه.

أكتوبر 2024

تعديل 2024:

• مدى استجابة الصفحة لتفاعلات المستخدم (INP)
  • لقد حوّلنا هذا المقياس من مقياس FID إلى INP وفقًا لإطلاقه كمقياس "مؤشرات أداء الويب الأساسية"، وجعلناه هو المقياس الأفضل في القائمة.
  • تراجعنا عن اقتراحنا باستخدام واجهة برمجة التطبيقات isInputPending كجزء من تقسيم المهام الطويلة. يمكنك الاطّلاع على مزيد من المعلومات حول أسبابنا في مقالة تحسين المهام الطويلة.
• سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)
  • لقد جمعنا اقتراحات بشأن قابلية الاكتشاف وتحديد الأولوية في اقتراح واحد.
  • أضفنا اقتراحًا جديدًا يهدف إلى تسهيل التنقّل الفوري.

كانون الثاني (يناير) 2023

في ما يلي القائمة الأولية للاقتراحات:

• سرعة عرض أكبر محتوى مرئي (LCP)
  • تأكَّد من إمكانية اكتشاف مورد LCP من مصدر HTML.
  • التأكّد من منح الأولوية لمورد LCP
  • استخدام شبكة توصيل المحتوى (CDN) لتحسين تقنية "تحويل النص إلى كلام" (TTFB) للمستندات والموارد
• متغيّرات التصميم التراكمية (CLS)
  • ضبط أحجام محدّدة لأي محتوى يتم تحميله من الصفحة
  • التأكّد من أنّ الصفحات مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات"
  • تجنَّب استخدام الصور المتحركة وتأثيرات الانتقال التي تستخدِم خصائص CSS التي تؤدي إلى تغيير التنسيق.
• مقياس FID
  • تجنُّب المهام الطويلة أو تقسيمها
  • تجنُّب استخدام JavaScript غير الضروري
  • تجنُّب تحديثات العرض الكبير

يمكنك أيضًا مشاهدة هذا العرض التقديمي لمؤتمر Google I/O لعام 2023 للحصول على ملخّص فيديو.