على مرّ السنين، جمعت منتديات الويب مجموعة كبيرة من المعلومات حول تحسين أداء الويب. على الرغم من أنّ أيّ عملية تحسين واحدة قد تُحسِّن أداء العديد من المواقع الإلكترونية، إلا أنّ تطبيقها جميعًا في الوقت نفسه قد يكون أمرًا شاقًا، ومن الواقعي أنّ بعض هذه التحسينات فقط يمكن تطبيقها على أيّ موقع إلكتروني معيّن.
ما لم يكن أداء الويب هو وظيفتك اليومية، من المحتمل ألا يكون واضحًا لك التحسينات التي ستُحدث أكبر تأثير في موقعك الإلكتروني. من المرجّح ألا يكون لديك الوقت لإجراء كلّ هذه التحسينات، لذا من المهمّ أن تسأل نفسك ما هي التحسينات الأكثر تأثيرًا التي يمكنك اختيارها لتحسين الأداء للمستخدمين؟
في ما يلي الحقيقة حول تحسينات الأداء: لا يمكنك الحكم عليها استنادًا إلى مزاياها الفنية فقط. عليك أيضًا مراعاة العوامل البشرية والتنظيمية التي تؤثّر في مدى احتمالية تنفيذ أي عملية تحسين معيّنة. قد يكون لبعض تحسينات الأداء تأثير كبير من الناحية النظرية، ولكن في الواقع، لن يتوفّر لدى سوى عدد قليل من المطوّرين الوقت أو الموارد لتنفيذها. من ناحية أخرى، قد تكون هناك أفضل ممارسات ذات تأثير كبير في الأداء يتبعها الجميع تقريبًا. يحدِّد هذا الدليل تحسينات أداء الويب التي:
- أن تحقّق أكبر تأثير في العالم الواقعي
- أن تكون ذات صلة وقابلة للتطبيق على معظم المواقع الإلكترونية
- أن تكون قابلة للتنفيذ من قِبل معظم المطوّرين
وهذه هي الطرق الأكثر واقعية وتأثيرًا التي يمكنك من خلالها تحسين مقاييس مؤشرات أداء الويب الأساسية. إذا كنت مبتدئًا في مجال أداء الويب، أو إذا كنت لا تزال تختار ما الذي سيحقّق لك أكبر عائد على الاستثمار، هذا هو أفضل مكان للبدء.
مدى استجابة الصفحة لتفاعلات المستخدم (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 containment لعرض محتوى DOM خارج الشاشة بشكلٍ بطيء. قد لا يكون ذلك واضحًا دائمًا، ولكن من خلال عزل المناطق التي تحتوي على تصاميم معقدة، يمكنك تجنُّب العمل غير الضروري على التصميم والعرض.
سرعة عرض أكبر محتوى مرئي (LCP)
سرعة عرض أكبر محتوى مرئي (LCP) هي مؤشر "أداء الويب الأساسي" الذي يواجه المطوّرون صعوبة في تحسينه. ف%40 من المواقع الإلكترونية في تقرير تجربة المستخدم في Chrome لا تستوفي الحدّ الأدنى المُقترَح لسرعة عرض أكبر محتوى مرئي لتوفير تجارب مستخدمين جيدة. ينصح فريق Chrome باستخدام الأساليب التالية باعتبارها الطرق الأكثر فعالية لتحسين LCP.
1. التأكّد من أنّه يمكن العثور على مورد LCP من مصدر HTML ومنحه الأولوية
لاحظ فريق Chrome ما يلي في ما يتعلّق بمقياس LCP على الويب:
- وفقًا لتقرير Web Almanac لعام 2024 الصادر عن HTTP Archive، تتضمّن %73 من صفحات الأجهزة الجوّالة صورة كعنصر LCP.
- يُظهر تحليل بيانات المستخدمين الفعليين من Chrome أنّ معظم المواقع التي تحقّق أداءً ضعيفًا في مقياس LCP تقضي أقل من%10 من وقت p75 LCP في تنزيل صورة LCP.
- من بين الصفحات التي تحقّق أداءً ضعيفًا في مقياس "سرعة عرض أكبر محتوى مرئي" (LCP)، يتأخّر تحميل صور LCP على العميل بمقدار 1,290 ملي ثانية في الشريحة المئوية التسعون، أي أكثر من نصف الميزانية لتوفير تجربة سريعة.
- من الصفحات التي كان فيها عنصر LCP صورة، كان لنسبة% 35 من هذه الصور عناوين URL لمصادرها لا يمكن اكتشافها في الردّ الأوّلي لملف HTML (مثل
<img src="...">
أو<link rel="preload" href="...">
)، ما كان سيتيح لماسح التحميل المُسبَق للمتصفّح اكتشافها في أقرب وقت ممكن. - وفقًا لـ Web Almanac، كانت 15% من الصفحات المؤهّلة تستفيد من سمة HTML
fetchpriority
لمنح الأولوية الأعلى للموارد، بما في ذلك تلك التي يمكن أن تحسّن سرعة عرض أكبر محتوى مرئي للصفحة بقليل من الجهد.
تشير هذه الإحصاءات إلى أنّ المطوّرين لديهم فرصة كبيرة للحدّ من كلّ من مهلة تحميل الموارد ومدة تحميل الموارد لصور LCP.
إذا كانت المشكلة هي تأخّر تحميل الموارد، من المهم تذكُّر أنّه قد يكون قد تأخّر الوقت كثيرًا لتحقيق قيمة جيدة لمقياس LCP إذا كانت الصفحة بحاجة إلى الانتظار إلى أن يتم تحميل CSS أو JavaScript بالكامل قبل أن تبدأ الصور في التحميل. بالإضافة إلى ذلك، يمكن تقليل مدة تحميل الموارد لصورة LCP من خلال إعادة تحديد أولوياتها كي تحصل على المزيد من النطاق الترددي وبالتالي يتم تحميلها بشكل أسرع باستخدام سمة fetchpriority
HTML.
إذا كان عنصر LCP صورة، يجب أن يكون عنوان URL للصورة قابلاً للاستكشاف في استجابة HTML لتقليل تأخّر تحميل الموارد. في ما يلي بعض النصائح لإجراء ذلك:
- حمِّل الصورة باستخدام عنصر
<img>
مع السمةsrc
أوsrcset
. لا تستخدِم سمات غير عادية مثلdata-src
التي تتطلّب JavaScript لعرضها، لأنّ ذلك سيبطئ الأداء دائمًا. تخفي 7% من الصفحات صورة 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
.
لا يؤدي استعادة الصفحات المعروضة بالكامل إلى تحسين أداء التحميل فحسب، بل يساهم أيضًا في ثبات التنسيق. يمكنك الاطّلاع على مزيد من المعلومات عن ميزة "التخزين المؤقت للصفحات" ومدى فعاليتها في تحسين مقياس CLS في قسم التأكّد من أنّ الصفحات مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات".
Browser Support
إنّ ميزة "العرض المُسبَق" للصفحة التالية التي يزورها المستخدِم هي طريقة أخرى فعّالة لتحسين أداء LCP بشكل كبير، ويمكن تحقيق ذلك من خلال واجهة برمجة التطبيقات Speculation Rules API. لتحقيق هذه المكاسب، تأكَّد من أنّه يتمّ عرض الصفحات الصحيحة مسبقًا. تؤدي التكهّنات غير الصحيحة إلى إهدار الموارد على كلّ من الخادم والعميل، ما قد يؤثّر سلبًا في الأداء. وبالتالي، كلما قلّت ثقتك بما ستكون عليه الصفحة التالية، يجب أن تكون أكثر حذقًا في العرض المُسبَق لها. في حال الشك، يمكن أن تمنحك بيانات الإحصاءات الثقة اللازمة لعرض الصفحات مسبقًا بشكل أكثر حرصًا، وذلك للصفحات التي يُرجّح زيارتها بعد ذلك.
3- استخدام شبكة توصيل المحتوى (CDN) لتحسين وقت استجابة خادم الويب
ركّز الاقتراح السابق على عمليات التنقّل الفورية التي توفّر أفضل تجربة ممكنة للمستخدمين، ولكن قد تكون هناك حالات لا تنطبق فيها تقنيات bfcache وتحميل التخمين. لنفترض أنّ أحد المستخدِمين يتبع رابطًا من مصدر مختلف إلى موقعك الإلكتروني، حيث تحظر استجابة مستند HTML الأوّلية بفعالية مقياس LCP. لا يمكن للمتصفّح بدء تحميل أيّ موارد فرعية إلى أن يتلقّى أول بايت من الاستجابة. وكلما تم ذلك في وقت أقرب، كان بإمكانك البدء في تنفيذ كل المهام الأخرى.
ويُعرف هذا الوقت باسم مدة تحميل أول بايت (TTFB). إليك أفضل الطرق لتقليل وقت استجابة الخادم:
- اعرض المحتوى الخاص بك في أقرب مكان جغرافي ممكن من المستخدمين.
- تخزين هذا المحتوى في ذاكرة التخزين المؤقت حتى يمكن عرضه بسرعة إذا تم طلبه مرة أخرى في المستقبل القريب
وأفضل طريقة لإجراء هذين الأمرين هي استخدام شبكة توصيل المحتوى (CDN). توزّع شبكات CDN مواردك على الخوادم الطرفية في جميع أنحاء العالم، ما يحدّ من المسافة التي يجب أن تقطعها هذه الموارد عبر الإنترنت للوصول إلى المستخدمين. تتضمّن شبكات CDN عادةً أيضًا عناصر تحكّم دقيقة في التخزين المؤقت يمكن تعديلها لتلبية احتياجات موقعك الإلكتروني.
يمكن لشبكات توصيل المحتوى (CDN) أيضًا عرض ملفات HTML وتخزينها مؤقتًا، ولكن وفقًا لـ Web Almanac، تم عرض % 33 فقط من طلبات ملفات HTML من شبكة توصيل محتوى. وهذا يعني أنّ هناك فرصة كبيرة أمام المواقع الإلكترونية لتحقيق وفورات إضافية.
في ما يلي بعض النصائح لضبط خدمات CDN:
- تخزين ملفات HTML الثابتة مؤقتًا على سبيل المثال، هل من المهم أن يكون المحتوى جديدًا دائمًا؟ أم يمكن أن يكون قد مرّ عليه بضع دقائق؟
- استكشِف ما إذا كان بإمكانك نقل المنطق الديناميكي الذي يتم تشغيله على خادم المصدر إلى الشبكة الطرفية، وهي ميزة في معظم شبكات CDN الحديثة.
في أي وقت يمكنك فيه عرض المحتوى مباشرةً من حافة الشبكة وتجنُّب الانتقال إلى خادم المصدر، يعني ذلك تحسُّنًا في الأداء. حتى في الحالات التي تتطلّب منك الانتقال إلى المصدر، يتم تحسين شبكات CDN بشكل عام لإجراء ذلك بشكل أسرع، لذا ستستفيد من هذه الميزة في كلتا الحالتَين.
متغيّرات التصميم التراكمية (CLS)
متغيّرات التصميم التراكمية (CLS) هي مقياس للثبات البصري لصفحة الويب. على الرغم من أنّه يتمثّل في المقياس الذي تحقّق معظم المواقع الإلكترونية أداءً جيدًا فيه، لا يزال ربعها تقريبًا لا يستوفي الحدّ الأدنى المقترَح، لذا لا تزال هناك فرصة كبيرة أمام العديد من المواقع الإلكترونية لتحسين تجربة المستخدمين.
1. ضبط أحجام محدّدة لأي محتوى يتم تحميله من الصفحة
تحدث عمليات تغيير التنسيق عادةً عند نقل المحتوى الحالي بعد انتهاء تحميل محتوى آخر. إنّ الطريقة الأساسية لتحسين متغيّرات التصميم التراكمية هي حجز المساحة المطلوبة مسبقًا قدر الإمكان.
إنّ أفضل طريقة لحلّ مشكلة تغييرات التنسيق الناتجة عن الصور غير المحددة الحجم هي ضبط السمتَين width
وheight
بشكل صريح أو خصائص CSS المماثلة. تحتوي 66% من الصفحات على صورة واحدة على الأقل غير مُحدَّدة الحجم. في حال عدم تحديد حجم واضح، يكون ارتفاع هذه الصور 0px
في البداية، ما قد يؤدي إلى تغييرات في التنسيق عند تحميل هذه الصور واكتشاف المتصفّح لأبعادها. يمثّل ذلك فرصة كبيرة للويب المجمّع، وتتطلّب هذه الفرصة جهدًا أقل من بعض الاقتراحات الأخرى الواردة في هذا الدليل.
إنّ الصور ليست المساهم الوحيد في CLS. قد تحدث تغييرات التنسيق بسبب محتوى آخر يتم تحميله عادةً بعد عرض الصفحة في البداية، بما في ذلك الإعلانات التابعة لجهات خارجية أو الفيديوهات المضمّنة. يمكن أن تساعدك السمة aspect-ratio
في ذلك. وهي ميزة أساسية متاحة على نطاق واسع في CSS تسمح للمطوّرين بضبط نسبة العرض إلى الارتفاع للصور والعناصر غير الصور بشكل صريح. يتيح لك ذلك ضبط width
ديناميكي (على سبيل المثال، استنادًا إلى حجم الشاشة)، وجعل المتصفّح يحسب الارتفاع المناسب تلقائيًا، بالطريقة نفسها التي يحسب بها الارتفاع المناسب للصور التي تتضمّن سمات.
ومع ذلك، لا يمكن دائمًا معرفة الحجم الدقيق للمحتوى الديناميكي. حتى إذا لم تكن تعرف الحجم الدقيق، لا يزال بإمكانك تقليل شدة تغييرات التنسيق. إنّ ضبط قيمة معقولة لسمة min-height
يكون أفضل دائمًا تقريبًا من السماح للمتصفّح باستخدام الارتفاع التلقائي الذي يبلغ 0px
لعنصر فارغ. عادةً ما يكون استخدام min-height
هو الحلّ الأسهل، لأنّه يسمح للحاوية بالنمو إلى ارتفاع المحتوى النهائي إذا لزم الأمر، ما يؤدي إلى تقليل مقدار النمو إلى مستوى يُحتمل أن يكون أكثر قبولاً.
2. التأكّد من أنّ الصفحات مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات"
كما ذكرنا سابقًا في هذا الدليل، تحمِّل ذاكرة التخزين المؤقت للصفحات (bfcache) صفحة من وقت سابق أو لاحق في سجلّ المتصفّح على الفور من لقطة ذاكرة. على الرغم من أنّ ذاكرة التخزين المؤقت للصفحات Bfcache هي أداة تحسين أداء مهمة على مستوى المتصفّح تعمل على تحسين مقياس سرعة عرض أكبر محتوى مرئي (LCP)، إلا أنّها تزيل أيضًا عمليات تغيير التنسيق بالكامل. في الواقع، كان طرح ذاكرة التخزين المؤقت bfcache في عام 2022 مسؤولاً عن أكبر تحسين في مقياس CLS الذي شهدناه في ذلك العام.
ومع ذلك، عدد كبير من المواقع الإلكترونية غير مؤهَّلة لاستخدام ذاكرة التخزين المؤقت bfcache، وبالتالي لا تستفيد من هذه الميزة المجانية لتحسين أداء الويب. تأكَّد من أنّ صفحاتك مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات"، ما لم تكن الصفحة تحمّل معلومات حسّاسة لا تريد استعادتها من الذاكرة.
على مالكي المواقع الإلكترونية التحقّق مما إذا كانت الصفحات مؤهّلة لاستخدام ذاكرة التخزين المؤقت bfcache وإصلاح أي أسباب تمنع ذلك. يحتوي Chrome على أداة اختبار bfcache في أدوات المطوّرين، ويمكنك أيضًا استخدام Not Restored Reasons API لرصد أسباب عدم الأهلية في الحقل.
3- تجنَّب استخدام الصور المتحركة وتأثيرات الانتقال التي تستخدِم خصائص CSS التي تؤدي إلى إنشاء تنسيق.
ومن الأسباب الشائعة الأخرى لتغيُّر التنسيقات هي إضافة مؤثرات متحركة إلى العناصر. على سبيل المثال، غالبًا ما تساهم إعلانات البانر لملفات تعريف الارتباط أو إعلانات البانر الأخرى للإشعارات التي تنزل من الأعلى أو الأسفل في زيادة مقياس CLS. ويشكّل ذلك مشكلة كبيرة، خاصةً عندما تدفع هذه البانر الإعلانية المحتوى الآخر إلى جانب الصفحة، ولكن حتى في حال عدم حدوث ذلك، يمكن أن يؤثّر استخدام الصور المتحركة فيها في مقياس CLS.
على الرغم من أنّ بيانات HTTP Archive لا يمكنها ربط الصور المتحركة بوضوح بتغييرات التنسيق، إلا أنّ البيانات تُظهر أنّ الصفحات التي تُنشئ صورًا متحركة لأيّ سمة CSS يمكنها التأثير في التنسيق يقلّ احتمال أن تحقّق قيمة "جيدة" لمقياس CLS بنسبة% 15 مقارنةً بالصفحات بشكل عام. ترتبط بعض المواقع الإلكترونية بقيمة CLS أسوأ من غيرها. على سبيل المثال، الصفحات التي تعرض صورًا متحركة بعرض margin
أو border
تحقّق قيمة "منخفضة" لمقياس CLS بمعدّل يقارب ضعف معدّل التقييم "منخفض" للصفحات بشكل عام.
قد لا يكون هذا الأمر مفاجئًا، لأنّه في أي وقت تنقل فيه أي خاصية CSS تؤدي إلى تغيير التنسيق أو تضيف لها حركة، سيؤدي ذلك إلى تغييرات في التنسيق. إذا لم تحدث تغييرات التصميم هذه خلال 500 ملي ثانية من تفاعل المستخدم، ستؤثّر في مقياس CLS.
قد يفاجئ بعض المطوّرين أنّ ذلك صحيح حتى في الحالات التي يتم فيها نقل العنصر خارج مسار المستند العادي. على سبيل المثال، تؤدي العناصر التي تم وضعها بشكل مطلق وتستخدم top
أو left
في الصور المتحركة إلى تغييرات في التنسيق، حتى إذا لم تكن تدفع المحتوى الآخر. ومع ذلك، إذا أضفت تأثيرًا متحركًا على transform:translateX()
أو transform:translateY()
بدلاً من top
أو left
، لن يؤدي ذلك إلى تعديل المتصفّح لتنسيق الصفحة، وبالتالي تجنُّب تغييرات التنسيق.
لطالما كان تفضيل استخدام الصور المتحركة لخصائص CSS التي يمكن تعديلها في سلسلة المكوّنات في المتصفّح من أفضل الممارسات لتحسين الأداء لأنّه ينقل هذه المهمة من سلسلة المهام الرئيسية إلى وحدة معالجة الرسومات. بالإضافة إلى أنّها من أفضل الممارسات العامة لتحسين الأداء، يمكن أن تساعد أيضًا في تحسين مقياس CLS.
كقاعدة عامة، لا تُضِف أبدًا تأثيرات متحركة أو انتقالات إلى خصائص CSS التي تتطلّب من المتصفّح تعديل تنسيق الصفحة، ما لم تكن تفعل ذلك استجابةً لنقرة المستخدم أو الضغط على مفتاح (وليس hover
). وفضِّل استخدام الانتقالات والصور المتحركة باستخدام خاصية transform
في CSS كلما أمكن ذلك.
تحذّر عملية تدقيق Lighthouse في تجنُّب الصور المتحركة غير المركّبة عندما تُنشئ صفحة صورًا متحركة لخصائص CSS قد تكون بطيئة.
الخاتمة
قد يبدو تحسين أداء الصفحة أمرًا شاقًا، خاصةً أنّ هناك الكثير من الإرشادات على الإنترنت التي يجب أخذها في الاعتبار. ومع ذلك، من خلال التركيز على هذه القائمة المختصرة التي تتضمّن أفضل الممارسات الأكثر فعالية، يمكنك معالجة المشكلة بتركيز متجدّد، ونأمل أن يؤدي ذلك إلى تحسين مؤشرات أداء الويب الأساسية لموقعك الإلكتروني.
إذا أردت إجراء تحسينات إضافية غير المُدرَجة هنا، يمكنك الاطّلاع على الأدلة التالية للحصول على مزيد من المعلومات:
الملحق: سجلّ التغييرات
سيتم تتبُّع التغييرات الرئيسية في هذا المستند هنا للمساعدة في توضيح وقت تغيُّر أهم الاقتراحات وسببه.
أكتوبر 2024
تعديل 2024:
- مدى استجابة الصفحة لتفاعلات المستخدم (INP)
- لقد بدّلنا هذا المقياس من "مهلة الاستجابة الأولى" إلى "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) بالتزامن مع إطلاق مقياس INP كمقياس من مؤشرات Core Web Vitals، وجعلناه أهم مقياس في القائمة.
- تراجعنا عن اقتراحنا باستخدام واجهة برمجة التطبيقات
isInputPending
كجزء من تقسيم المهام الطويلة. يمكنك الاطّلاع على مزيد من المعلومات حول أسبابنا في مقالة تحسين المهام الطويلة.
- سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)
- لقد جمعنا اقتراحات تسهيل العثور على المحتوى واقتراحات تحديد الأولويات في اقتراح واحد.
- أضفنا اقتراحًا جديدًا يهدف إلى تسهيل التنقّل الفوري.
كانون الثاني (يناير) 2023
في ما يلي القائمة الأولية للاقتراحات:
- سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)
- التأكّد من أنّ مورد LCP قابل للاكتشاف من مصدر HTML
- التأكّد من منح الأولوية لمورد LCP
- استخدام شبكة توصيل المحتوى (CDN) لتحسين وقت استجابة المستندات والموارد
- متغيّرات التصميم التراكمية (CLS)
- ضبط أحجام محدّدة لأي محتوى يتم تحميله من الصفحة
- التأكّد من أنّ الصفحات مؤهّلة لاستخدام ميزة "التخزين المؤقت للصفحات"
- تجنَّب استخدام الصور المتحركة وتأثيرات الانتقال التي تستخدِم خصائص CSS التي تؤدي إلى إنشاء تنسيق.
- مقياس FID
- تجنُّب المهام الطويلة أو تقسيمها
- تجنُّب استخدام JavaScript غير الضروري
- تجنُّب تعديلات العرض الكبيرة
يمكنك أيضًا مشاهدة العرض التقديمي لعام 2023 في مؤتمر Google I/O للحصول على ملخّص في فيديو.