مجموعة من أفضل الممارسات التي يعتقد فريق مطوّري برامج Chrome أنّها الطُرق الأكثر فعالية لتحسين أداء "مؤشرات أداء الويب الأساسية" في عام 2023
على مرّ السنين، قدّمنا في Google الكثير من الاقتراحات للمطوّرين على الويب حول كيفية تحسين الأداء.
وعلى الرغم من أن كل اقتراح من هذه الاقتراحات، على حدة، قد يحسّن أداء العديد من المواقع الإلكترونية، فإنّ مجموعة الاقتراحات الكاملة مربكة للغاية، ومن الناحية الواقعية، لا يمكن لأي شخص أو موقع إلكتروني واحد متابعتها جميعًا.
ما لم يكن أداء الويب هو وظيفتك اليومية، قد لا يكون واضحًا لك الاقتراحات التي سيكون لها أكبر تأثير إيجابي على موقعك الإلكتروني. على سبيل المثال، ربما تكون قد قرأت أنّ تنفيذ لغة CSS مهمة يمكن أن يحسّن أداء التحميل، وربما تكون أيضًا قد سمعت بأهمية تحسين صورك. ولكن إذا لم يكن لديك الوقت للعمل على كلا الأمرين، فكيف ستقرر أيهما تختار؟
في فريق Chrome، حاولنا خلال العام الماضي الإجابة عن هذا السؤال: ما هي أهم الاقتراحات التي يمكننا تقديمها للمطوّرين لمساعدتهم في تحسين أداء مستخدمي تطبيقاتهم؟
للإجابة بشكل كافٍ عن هذا السؤال، علينا مراعاة ليس فقط المزايا الفنية لأي اقتراح معيّن، ولكن أيضًا العوامل البشرية والتنظيمية التي تؤثر في احتمالية تبنّي هذه الاقتراحات للمطوّرين. بمعنى آخر، قد تكون بعض الاقتراحات ذات تأثير كبير من الناحية النظرية، ولكن في الواقع، عدد قليل جدًا من المواقع الإلكترونية سيكون لديها الوقت والموارد اللازمة لتنفيذها. وعلى الرغم من أنّ بعض الاقتراحات بالغة الأهمية، فإنّ معظم المواقع الإلكترونية تتّبع هذه الممارسات حاليًا.
باختصار، أردنا أن تركّز قائمة أفضل اقتراحات أداء الويب على ما يلي:
- الاقتراحات التي نعتقد أنّها سيكون لها أكبر تأثير على أرض الواقع
- الاقتراحات ذات الصلة التي تنطبق على معظم المواقع الإلكترونية
- يشير هذا المصطلح إلى اقتراحات واقعية يجب أن يتّبعها معظم المطوّرين.
لقد أمضينا على مدار العام الماضي الكثير من الوقت في التدقيق في المجموعة الكاملة لاقتراحات الأداء التي نقدّمها، وتقييم كل منها (نوعيًا وكميًا) بالاستناد إلى المعايير الثلاثة المذكورة أعلاه.
توضّح هذه المشاركة أهم الاقتراحات لتحسين الأداء لكل مقياس من مقاييس مؤشرات أداء الويب الأساسية. إذا كنت مبتدئًا في مجال أداء الويب أو إذا كنت تحاول تحديد الخيار الذي سيحقق لك أفضل النتائج، نعتقد أنّ هذه الاقتراحات هي أفضل نقطة للبدء.
سرعة عرض أكبر محتوى مرئي (LCP)
أول مجموعة من الاقتراحات لدينا هي سرعة عرض أكبر محتوى مرئي (LCP)، وهو مقياس لأداء التحميل. من بين مقاييس "مؤشرات أداء الويب الأساسية" الثلاثة، يُعدّ مقياس LCP هو المقياس الذي يواجه أكبر صعوبات في التعامل مع المواقع الإلكترونية، إذ إنّ نصف فقط جميع المواقع الإلكترونية على الويب اليوم تستوفي الحدّ الأدنى المقترَح، لذا لِنبدأ عندها.
تأكَّد من إمكانية اكتشاف مورد LCP من مصدر HTML.
وفقًا لإحصاءات 2022 Web Almanac التي أنشأها أرشيف HTTP، تتضمّن 72% من الصفحات المتوافقة مع الأجهزة الجوّالة صورة كعنصر LCP، ما يعني أنّه لكي تحسِّن معظم المواقع الإلكترونية سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، عليها ضمان إمكانية تحميل هذه الصور بسرعة.
ما قد لا يكون واضحًا للعديد من المطوّرين أنّ الوقت المستغرق لتحميل الصورة هو مجرد جزء واحد من التحدي. هناك جزء مهم آخر وهو الوقت قبل بدء تحميل الصورة، وتشير بيانات "أرشيف HTTP" إلى أنّ العديد من المواقع الإلكترونية يتعطّل فعليًا.
في الواقع، من الصفحات التي كان فيها عنصر سرعة عرض أكبر محتوى مرئي (LCP) صورة، تتضمّن 39% من هذه الصور عناوين URL لمصدر قابلة للاكتشاف من مصدر مستند HTML. بعبارة أخرى، لم يتم العثور على عناوين URL هذه في سمات HTML العادية (مثل <img src="..."> أو <link rel="preload" href="...">)، ما يسمح للمتصفح باكتشافها بسرعة وبدء تحميلها على الفور.
إذا كانت الصفحة تحتاج إلى الانتظار حتى يتم تنزيل ملفات CSS أو JavaScript بالكامل وتحليلها ومعالجتها قبل أن تتمكن من بدء تحميل الصورة، قد يكون الوقت متأخرًا بالفعل.
بشكل عام، إذا كان عنصر LCP صورة، يجب أن يكون عنوان URL الخاص بالصورة قابلاً للاكتشاف دائمًا من مصدر HTML. إليك بعض النصائح لتحقيق ذلك:
حمِّل الصورة باستخدام عنصر
<img>مع السمةsrcأوsrcset. لا تستخدِم سمات غير عادية، مثلdata-src، والتي تتطلّب JavaScript لعرضها، لأنها ستكون أبطأ دائمًا. تحجب %9 من الصفحات صورتها من خلال مقياس LCP خلفdata-src.يُفضَّل العرض من جهة الخادم (SSR) على العرض من جهة العميل (CSR)، حيث تشير SSR إلى أنّ ترميز الصفحة الكاملة (بما في ذلك الصورة) موجود في مصدر HTML. تتطلب حلول CSR تشغيل JavaScript قبل التمكن من اكتشاف الصورة.
إذا كنت بحاجة إلى الإشارة إلى صورتك من ملف CSS أو JS خارجي، لا يزال بإمكانك تضمينها في مصدر HTML من خلال علامة
<link rel="preload">. يُرجى العِلم أنّه لا يمكن لـ أداة فحص التحميل المُسبق في المتصفّح اكتشاف الصور المُشار إليها باستخدام الأنماط المضمَّنة، لذا قد يُحظَر العثور عليها في مصدر HTML عند تحميل موارد أخرى، وبالتالي يمكن أن يساعد التحميل المُسبق في هذه الحالات.
لمساعدتك في معرفة ما إذا كانت هناك مشاكل في قابلية العثور على صورة LCP، ستصدر أداة Lighthouse تدقيقًا جديدًا في الإصدار 10.0 (المتوقَّع في كانون الثاني/يناير 2023).
كما أن ضمان قابلية اكتشاف مورد LCP من مصدر HTML يمكن أن يؤدي إلى تحسينات قابلة للقياس، كما يتيح فرصًا إضافية لتحديد أولوية المورد، وهذا هو اقتراحنا التالي.
التأكّد من منح الأولوية لمورد LCP
إنّ التأكد من إمكانية اكتشاف مورد LCP من مصدر HTML هو خطوة أولى مهمة لضمان إمكانية بدء تحميل مورد LCP مبكرًا، ولكن هناك خطوة مهمة أخرى تتمثّل في ضمان إعطاء الأولوية لتحميل هذا المورد وعدم إدراجه في قائمة انتظار قبل مجموعة من الموارد الأخرى الأقل أهمية.
على سبيل المثال، حتى إذا كانت صورة LCP متوفّرة في مصدر HTML باستخدام علامة <img> عادية، إذا كانت صفحتك تتضمن عشرات علامات <script> في <head> من مستندك قبل علامة <img> هذه، قد يستغرق تحميل مورد الصور بعض الوقت.
أسهل طريقة لحلّ هذه المشكلة هي تقديم تلميح للمتصفِّح بشأن الموارد ذات الأولوية القصوى من خلال ضبط السمة الجديدة fetchpriority="high" على العلامة <img> أو <link> التي تحمِّل صورة LCP. يؤدي هذا إلى توجيه المتصفح لتحميله مبكرًا بدلاً من انتظار اكتمال هذه النصوص البرمجية.
وفقًا لـ Web Almanac، إنّ 0.03% فقط من الصفحات المؤهّلة تستفيد من واجهة برمجة التطبيقات الجديدة هذه، ما يعني أنّ هناك الكثير من الفرص المتاحة لمعظم المواقع الإلكترونية لتحسين سرعة عرض أكبر محتوى مرئي (LCP) بجهد ضئيل جدًا. على الرغم من أنّ السمة fetchpriority متاحة حاليًا في المتصفّحات المستنِدة إلى Chromium فقط، فإنّ واجهة برمجة التطبيقات هذه هي تحسين تدريجي تتجاهله المتصفحات الأخرى، لذا ننصح بشدة المطوّرين باستخدامها الآن.
بالنسبة إلى المتصفّحات التي لا تستخدم Chromium، إنّ الطريقة الوحيدة لضمان إعطاء الأولوية لمورد LCP أعلى من الموارد الأخرى هي الإشارة إليه مسبقًا في المستند. باستخدام المثال مجددًا في موقع إلكتروني يتضمّن الكثير من علامات <script> في <head> من المستند، إذا أردت التأكّد من منح الأولوية لمورد LCP قبل موارد النص البرمجي هذه، يمكنك إضافة علامة <link rel="preload"> قبل أي من هذه النصوص البرمجية، أو يمكنك نقل هذه النصوص البرمجية إلى أسفل <img> لاحقًا في <body>. على الرغم من أنّ هذا الإجراء يعمل، فإنّه أقل راحة من استخدام fetchpriority، لذا نأمل أن تضيف المتصفحات الأخرى الدعم قريبًا.
هناك جانب آخر مهم لمنح الأولوية لمورد LCP، وهو التأكّد من عدم اتخاذ أي إجراء قد يؤدي إلى عدم منح الأولوية له، مثل إضافة سمة loading="lazy". في الوقت الحالي، ضبط 10% من الصفحات loading="lazy" على صورة مقياس LCP. يجب الانتباه إلى حلول تحسين الصور التي تطبّق بشكل عشوائي سلوك التحميل الكسول على جميع الصور. وإذا كانت هذه الإعدادات توفّر طريقة لإلغاء هذا السلوك، احرص على استخدامه مع صورة مقياس LCP. وإذا لم تكن متأكدًا من الصورة التي ستمثل LCP، جرِّب الاستعانة بالاستدلالات لاختيار صورة مرشحة معقولة.
إنّ تأجيل الموارد غير المهمة هو طريقة أخرى لتعزيز الأولوية النسبية لمورد سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بشكل فعّال. على سبيل المثال، يمكن تأجيل النصوص البرمجية التي لا تعمل على واجهة المستخدم (مثل النصوص البرمجية للإحصاءات أو التطبيقات المصغّرة الاجتماعية) إلى أن يتم تنشيط حدث load، ما يضمن عدم تنافسها مع الموارد المُهمّة الأخرى (مثل مورد LCP) في معدّل نقل البيانات للشبكة.
باختصار، يجب اتّباع أفضل الممارسات التالية لضمان تحميل مورد LCP في وقت مبكر وبأولوية عالية:
- أضِف
fetchpriority="high"إلى العلامة<img>في صورة مقياس LCP. في حال تحميل مورد LCP من خلال علامة<link rel="preload">، لا داعي للقلق لأنه يمكنك أيضًا ضبطfetchpriority="high"على ذلك. - لا يتم ضبط
loading="lazy"مطلقًا على العلامة<img>لصورة مقياس LCP. سيؤدي ذلك إلى تقليل أولوية صورتك وإلى تأخير بدء التحميل. - أجِّل الموارد غير المهمة إن أمكن. يمكنك إما نقلها إلى نهاية المستند أو استخدام التحميل الكسول المحلي للصور أو إطارات iframe أو تحميلها بشكل غير متزامن عبر JavaScript.
استخدام شبكة توصيل المحتوى (CDN) لتحسين ميزة "تحويل النص إلى كلام" (TTFB) للمستندات والموارد
ركّزنا الاقتراحان السابقان على التأكّد من اكتشاف موارد سرعة عرض أكبر محتوى مرئي (LCP) في وقت مبكر ومنحها الأولوية حتى يبدأ التحميل على الفور. الجزء الأخير من هذا اللغز هو التأكد من وصول الرد الأولي على المستند في أسرع وقت ممكن أيضًا.
لا يمكن للمتصفّح بدء تحميل أي موارد فرعية حتى يتلقّى البايت الأول من الاستجابة الأولية لمستند HTML، وكلما أسرع هذا الأمر، بدأت الأمور الأخرى في الحدوث أيضًا.
يُعرف هذا الوقت باسم وقت وصول أول بايت (TTFB)، وتتمثل الطريقة المثلى لخفض مقدار تحويل النص إلى كلام في إجراء ما يلي:
- عرض المحتوى بالقرب من المستخدمين جغرافيًا قدر الإمكان
- خزِّن ذلك المحتوى مؤقتًا لكي يتم عرض المحتوى المطلوب مؤخرًا لإعادة العرض بسرعة.
وأفضل طريقة لتنفيذ هذين الإجراءين هي استخدام شبكة توصيل محتوى (CDN). توزِّع شبكات توصيل المحتوى (CDN) مواردك على الخوادم الهامشية، التي تنتشر في جميع أنحاء العالم، وبالتالي تحد من المسافة التي يجب أن تنتقل بها هذه الموارد عبر الأسلاك إلى المستخدمين. عادةً ما تحتوي شبكات توصيل المحتوى (CDN) على عناصر تحكّم دقيقة في التخزين المؤقت يمكن تخصيصها وتحسينها لتناسب احتياجات موقعك الإلكتروني.
العديد من المطوّرين على دراية باستخدام شبكة توصيل المحتوى (CDN) لاستضافة مواد عرض ثابتة، ولكن بإمكان شبكات توصيل المحتوى (CDN) عرض مستندات HTML وتخزينها مؤقتًا أيضًا، حتى تلك التي يتم إنشاؤها ديناميكيًا.
وفقًا لـ Web Almanac، لم تقدّم شبكة توصيل المحتوى (CDN) سوى 29% من طلبات مستندات HTML، ما يعني أنّ هناك فرصة كبيرة تتيح للمواقع الإلكترونية طلب توفير المزيد من المستندات.
وفي ما يلي بعض النصائح لضبط شبكات توصيل المحتوى (CDN):
- ننصحك بزيادة مدّة التخزين المؤقت للمحتوى (على سبيل المثال، هل يجب أن يكون المحتوى جديدًا دائمًا؟ أم يمكن أن يكون قديمًا بضع دقائق؟).
- ويمكنك أيضًا تخزين المحتوى مؤقتًا إلى أجل غير مسمى، وإزالة ذاكرة التخزين المؤقت نهائيًا عند إجراء أي تحديث.
- تعرَّف على ما إذا كان بإمكانك نقل المنطق الديناميكي المُشغَّل حاليًا على خادم المصدر إلى الحافة (ميزة في أحدث شبكات توصيل المحتوى (CDN).
بوجه عام، فإنّ أي وقت يتيح لك عرض المحتوى من الحافة مباشرةً (تجنب الانتقال إلى خادم المصدر)، يحقّق لك النجاح في تحقيق الأداء. وحتى في الحالات التي اضطررت فيها إلى الانتقال إلى خادم المصدر، تكون شبكات توصيل المحتوى (CDN) محسّنة بشكل عام لإنجاز ذلك بسرعة أكبر، لذلك تكون هناك مكسب في كلتا الحالتين.
متغيّرات التصميم التراكمية (CLS)
المجموعة التالية من الاقتراحات هي متغيّرات التصميم التراكمية (CLS) التي تقيس الثبات البصري على صفحات الويب. على الرغم من تحسُّن كبير في متغيّرات التصميم التراكمية (CLS) على الويب منذ عام 2020، ما زالت حوالى ربع المواقع الإلكترونية لا تستوفي الحدّ الأدنى المقترَح، لذلك لا تزال هناك فرصة كبيرة أمام العديد من المواقع الإلكترونية لتحسين تجربة المستخدمين.
تعيين أحجام واضحة لأي محتوى يتم تحميله من الصفحة
تحدث تغييرات التصميم عادةً عند نقل محتوى حالي بعد انتهاء تحميل محتوى آخر. لذلك، فإن الطريقة الأساسية للتخفيف من ذلك هي حجز أي مساحة مطلوبة مقدمًا قدر الإمكان.
الطريقة الأبسط لحلّ متغيّرات التصميم الناتجة عن الصور غير الحجم هي ضبط السمتَين width وheight بشكل صريح (أو سمات CSS المكافئة). ومع ذلك، وفقًا لأرشيف HTTP، تتضمّن 72% من الصفحات صورة واحدة على الأقل بلا حجم. في حال عدم استخدام حجم واضح، ستضبط المتصفّحات في البداية ارتفاعًا تلقائيًا على 0px، ما قد يؤدي إلى حدوث تغيُّر ملحوظ في التصميم عند تحميل الصورة في النهاية واكتشاف الأبعاد. وهذا يمثل فرصة كبيرة لشبكة الويب الجماعية، وتتطلب هذه الفرصة جهدًا أقل بكثير من بعض الاقتراحات الأخرى المقترحة في هذه المقالة.
يُرجى العلم أيضًا أنّ الصور ليست العامل الوحيد في متغيّرات التصميم التراكمية (CLS). قد تحدث تغييرات في التصميم بسبب محتوى آخر يتم تحميله عادةً بعد عرض الصفحة في البداية، بما في ذلك الإعلانات التابعة لجهات خارجية أو الفيديوهات المضمّنة. يمكن أن تساعد السمة aspect-ratio في التصدّي لهذه المشكلة. وهي ميزة جديدة نسبيًا في CSS تتيح للمطوّرين توفير نسبة عرض إلى ارتفاع للصور بالإضافة إلى العناصر غير الخاصة بالصور. سيتيح لك ذلك ضبط سمة width ديناميكية (استنادًا إلى حجم الشاشة مثلاً)، وضبط المتصفّح تلقائيًا على قيمة الارتفاع المناسب، بالطريقة نفسها المتّبعة مع الصور ذات الأبعاد.
في بعض الأحيان، لا يمكن معرفة الحجم الدقيق للمحتوى الديناميكي لأنه ذو طبيعة ديناميكية. ومع ذلك، حتى إذا كنت لا تعرف الحجم الدقيق، لا يزال بإمكانك اتّخاذ خطوات لتقليل شدّة متغيّرات التصميم. غالبًا ما يكون ضبط min-height معقولة أفضل من السماح للمتصفح باستخدام الارتفاع التلقائي 0px لعنصر فارغ. إنّ استخدام min-height هو أيضًا حلّ سهل لأنّه يسمح للحاويات بالنمو إلى ارتفاع المحتوى النهائي إذا لزم الأمر، ما أدّى إلى تقليل مقدار النمو من الحجم الكامل إلى مستوى أفضل على نحو متحمّس.
التأكّد من أنّ الصفحات مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات"
تستخدم المتصفّحات آلية تنقُّل تُسمّى التخزين المؤقت للصفحات أو استخدام ميزة "التخزين المؤقت للصفحات" لتحميل صفحة فورًا من سجلّ سابق أو لاحقًا في سجلّ المتصفّح مباشرةً من لقطة ذاكرة.
إنّ ميزة "التخزين المؤقت للصفحات" هي تحسين مهم للأداء على مستوى المتصفّح، وتقضي تمامًا على متغيّرات التصميم أثناء تحميل الصفحة، وهي المكان الذي تظهر فيه معظم متغيّرات التصميم التراكمية (CLS) في العديد من المواقع الإلكترونية. أدّى استخدام ميزة "التخزين المؤقت للصفحات" إلى أكبر تحسُّن في متغيّرات التصميم التراكمية (CLS) لاحظناه في عام 2022.
وعلى الرغم من ذلك، فإنّ عددًا كبيرًا من المواقع الإلكترونية غير مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات" وبالتالي ستفقد فرصة تحقيق هذا الأداء المجاني على الويب عند إجراء عدد كبير من عمليات الانتقال. إذا لم تحمِّل صفحتك معلومات حساسة لا تريد استعادتها من الذاكرة، عليك التأكّد من أنّ صفحاتك مؤهَّلة لذلك.
على مالكي المواقع الإلكترونية التأكّد من أنّ صفحاتهم مؤهلة لاستخدام ميزة "التخزين المؤقت للصفحات" والعمل على أي أسباب وراء ذلك. يتضمّن Chrome حاليًا أداة اختبار bfcache في "أدوات مطوري البرامج"، ونخطط هذا العام لتحسين الأدوات هنا من خلال إجراء تدقيق جديد من Lighthouse يؤدي اختبارًا مشابهًا وواجهة برمجة تطبيقات لقياس هذا الأمر في المجال.
لقد أدرجنا هذه الميزة في قسم متغيّرات التصميم التراكمية (CLS)، لأنّنا حققنا أكبر قدر من الأرباح حتى الآن، لكنّها ستعمل أيضًا بشكل عام على تحسين مؤشرات Core Web Vitals الأخرى. إنّها واحدة من عدد من عمليات التنقّل الفورية المتاحة لتحسين عمليات التنقّل في الصفحة بشكل كبير.
تجنُّب الصور المتحركة أو الانتقالات التي تستخدم خصائص CSS التي تستخدم التنسيق
هناك مصدر شائع آخر لمتغيّرات التصميم هو عندما تكون العناصر متحركة. على سبيل المثال، غالبًا ما تكون إعلانات بانر ملفات تعريف الارتباط أو بانر الإشعارات الأخرى التي تظهر من الأعلى أو الأسفل من العوامل المساهمة في متغيّرات التصميم التراكمية (CLS). ويشكّل ذلك مشكلة بشكل خاص عندما تُبعد إعلانات البانر المحتوى الآخر عن المحتوى، ولكن حتى لو لم تفعل ذلك، فإنّ الصور المتحركة يمكن أن تؤثر في متغيّرات التصميم التراكمية (CLS).
على الرغم من أنّ بيانات "أرشيف HTTP" لا يمكنها ربط الصور المتحركة بمتغيّرات التصميم بشكل نهائي، فإنّ البيانات تُظهِر أنّ الصفحات التي تحرّك أي خاصية في CSS قد تؤثر في التنسيق يقلّل من احتمال حصولها على متغيّرات التصميم التراكمية (CLS) "جيدة" بنسبة% 15 مقارنةً بالصفحات بشكل عام. ترتبط بعض المواقع بمتغيّرات CLS أسوأ من غيرها. على سبيل المثال، إنّ الصفحات التي تحرّك العرض margin أو border تسجّل متغيّرات التصميم التراكمية (CLS) "ضعيفة" بمعدّل يقارب ضعف معدّل تقييم الصفحات على أنّها سيئة.
وقد لا يكون ذلك مفاجئًا، لأنّه في كل مرة تنتقل فيها أو تحرّك أي موقع إلكتروني على CSS يتضمّن تنسيقًا، سيؤدّي ذلك إلى تغييرات في التنسيق. وإذا لم تكن متغيّرات التصميم هذه ضمن فترة 500 ملّي ثانية من تفاعل المستخدِم، ستؤثّر في متغيّرات التصميم التراكمية (CLS).
ما قد يفاجئ بعض المطورين هو أن هذا صحيح حتى في الحالات التي يتم فيها أخذ العنصر خارج تدفق المستند العادي. على سبيل المثال، ستؤدي العناصر ذات الموضع الصحيح بشكل كامل والتي تحرّك top أو left إلى حدوث متغيّرات في التصميم، حتى إذا لم تكن تعرض المحتوى الآخر. ومع ذلك، إذا أردت إنشاء تأثير متحرك لـ top أو left بدلاً من إضافة صور متحركة transform:translateX() أو transform:translateY()، لن يؤدي ذلك إلى تعديل المتصفّح لتنسيق الصفحة، وبالتالي لن ينتج عن ذلك أي متغيّرات تصميم.
لطالما كان تفضيل الصور المتحركة لخصائص CSS التي يمكن تحديثها على سلسلة أداة التركيب في المتصفّح أحد أفضل الممارسات المتعلقة بالأداء، وذلك بسبب نقل هذه السمات التي تعمل إلى وحدة معالجة الرسومات وخارج سلسلة التعليمات الرئيسية. وبالإضافة إلى كونها من أفضل الممارسات العامة المتعلقة بالأداء، يمكن أن تساعد أيضًا في تحسين متغيّرات التصميم التراكمية (CLS).
كقاعدة عامة، يجب عدم تحريك أو نقل أي خاصية CSS تتطلب من المتصفّح تعديل تنسيق الصفحة، إلا إذا كنت تفعل ذلك استجابةً للنقر أو الضغط على مفتاح المستخدم (ولكن ليس hover). وكلما كان ذلك ممكنًا، ننصحك بتفضيل عمليات الانتقال والرسوم المتحركة باستخدام سمة CSS transform.
عند مراجعة Lighthouse، سيتم إصدار تحذير بحق تجنُّب الصور المتحركة غير المُركّبة عندما تتضمّن الصفحة صورًا متحركة لسمات CSS التي يُحتمل أن تكون بطيئة.
مهلة الاستجابة لأوّل إدخال (FID)
مجموعة الاقتراحات الأخيرة التي نقدّمها هي مهلة الاستجابة الأولى (FID)، وهي مقياس لمدى استجابة الصفحة لتفاعلات المستخدم. على الرغم من أنّ معظم المواقع الإلكترونية على الويب تحقّق حاليًا أداءً جيدًا في مقياس FID، سجّلنا أوجه القصور في مقياس FID في الماضي، ونعتقد أنّ هناك الكثير من الفرص المتاحة للمواقع الإلكترونية لتحسين مدى استجابة المواقع الإلكترونية بشكل عام لتفاعلات المستخدمين.
قد يشكّل مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP) الجديد أحد الحلول المحتملة لمهلة الاستجابة الأولى (FID)، وتنطبق أيضًا جميع الاقتراحات الواردة أدناه على كلٍّ من FID وINP. بما أنّ المواقع الإلكترونية تُحقّق أداءً أسوأ على مقياس INP مقارنةً بمقياس FID، لا سيّما على الأجهزة الجوّالة، ننصح مطوّري البرامج بمراعاة هذه الاقتراحات بشأن مدى الاستجابة السريعة بجديّة، على الرغم من توفُّر مقياس FID "جيد".
تجنُّب المهام الطويلة أو قطعها
تُعد المهام أي جزء من العمل المنفصل الذي يقوم به المتصفح. تتضمن المهام عرض النصوص البرمجية والتخطيط والتحليل وتجميع النصوص البرمجية وتنفيذها. عندما تصبح المهام مهام طويلة، أي 50 ملي ثانية أو أكثر، تمنع سلسلة المحادثات الرئيسية من الاستجابة بسرعة لإدخالات المستخدمين.
وفقًا لـ "تقويم الويب"، هناك الكثير من الأدلة التي تشير إلى أنّ المطوّرين قد يبذلون جهدًا أكبر لتجنُّب المهام الطويلة أو التوقف عن استخدامها. على الرغم من أن تقسيم المهام الطويلة قد لا يتطلب مجهودًا كبيرًا مثل التوصيات الأخرى في هذه المقالة، إلا أنه أقل جهدًا من الأساليب الأخرى غير الواردة في هذه المقالة.
على الرغم من أنّه يجب عليك دائمًا بذل مجهود ضئيل قدر الإمكان في JavaScript، يمكنك مساعدة سلسلة التعليمات الرئيسية قليلاً من خلال تقسيم المهام الطويلة إلى مهام أصغر. يمكنك تنفيذ ذلك من خلال الانتقال إلى سلسلة المحادثات الرئيسية في كثير من الأحيان ليتم عرض التعديلات وتفاعلات المستخدمين الأخرى بسرعة أكبر.
ويمكنك أيضًا استخدام واجهات برمجة التطبيقات، مثل isInputPending وscheduler API. isInputPending هي دالة تعرض قيمة منطقية تشير إلى ما إذا كان إدخال المستخدم في انتظار المراجعة. أما إذا عرضَت القيمة true، فيمكنك الخضوع لسلسلة المحادثات الرئيسية لكي تتمكّن من معالجة البيانات التي أدخلها المستخدم والتي كانت في انتظار المراجعة.
تُعد واجهة برمجة التطبيقات Scheduler API أسلوبًا أكثر تقدمًا، تسمح لك بجدولة العمل استنادًا إلى نظام الأولويات الذي يأخذ في الاعتبار ما إذا كان العمل الذي يتم إنجازه مرئيًا للمستخدم أو في الخلفية.
وهذا بدوره يؤدي إلى منح المتصفّح المزيد من الفرص لملاءمة الأعمال المهمة والمرئية للمستخدم، مثل التعامل مع التفاعلات وأي تحديثات ناتجة عن العرض.
تجنُّب لغة JavaScript غير الضرورية
لا شك في ذلك: تشحن المواقع الإلكترونية بشكل أكبر من أي وقت مضى باستخدام JavaScript، ولن يتغيّر هذا المؤشر قريبًا. عندما تضع الكثير من ملفات JavaScript، فأنت بذلك تنشئ بيئة تتنافس فيها المهام لجذب انتباه سلسلة التعليمات الرئيسية. يمكن أن يؤثر ذلك بالتأكيد في استجابة موقعك الإلكتروني، خاصةً خلال فترة بدء التشغيل المهمة.
ومع ذلك، هذه ليست مشكلة لا يمكن حلها. وتتوفّر لك بعض الخيارات:
- يمكنك استخدام أداة التغطية في "أدوات مطوري البرامج في Chrome" للعثور على الرمز غير المستخدَم في موارد موقعك الإلكتروني. من خلال تقليل حجم الموارد التي تحتاج إليها أثناء بدء التشغيل، يمكنك التأكّد من أنّ موقعك الإلكتروني يقضي وقتًا أقل في تحليل الرموز وتجميعها، ما يؤدي إلى تجربة مستخدِم أوّلية أكثر سلاسة.
- في بعض الأحيان، يتم وضع علامة "غير مستخدم" على الرمز غير المستخدَم الذي تعثر عليه باستخدام أداة التغطية لأنّه لم يتم تنفيذه أثناء بدء التشغيل، ولكنه لا يزال ضروريًا لبعض الوظائف في المستقبل. هذا رمز يمكنك نقله إلى حزمة منفصلة من خلال تقسيم الرمز.
- إذا كنت تستخدم أحد برامج إدارة العلامات، احرص على فحص علاماتك بشكل دوري للتأكّد من تحسينها أو حتى إذا كانت لا تزال قيد الاستخدام. يمكن محو العلامات القديمة التي تحتوي على رمز غير مستخدَم لجعل رمز JavaScript في أداة "إدارة العلامات من Google" أصغر حجمًا وأكثر كفاءة.
تجنُّب تحديثات العرض الكبير
إنّ لغة JavaScript ليست هي الشيء الوحيد الذي قد يؤثر في استجابة موقعك الإلكتروني. يمكن أن يكون العرض نوعًا من العمل المكلف بذاته، وعند إجراء تعديلات على العرض الكبير، قد يتداخل مع قدرة موقعك الإلكتروني على الاستجابة لإدخالات المستخدمين.
إنّ تحسين عرض المحتوى ليس عملية مباشرة، وغالبًا ما يعتمد على ما تحاول تحقيقه. ومع ذلك، هناك بعض الإجراءات التي يمكنك اتّخاذها لضمان أن تكون التعديلات المتعلّقة بالعرض معقولة ولا تؤدي إلى مهام طويلة:
- تجنَّب استخدام
requestAnimationFrame()للقيام بأي عمل غير مرئي. تتم معالجة استدعاءاتrequestAnimationFrame()أثناء مرحلة العرض من تكرار الأحداث، وعندما يتم تنفيذ الكثير من العمل أثناء هذه الخطوة، قد يتأخر عرض التعديلات. من الضروري أن يكون أي عمل يتم تنفيذه باستخدام "requestAnimationFrame()" محجوزًا فقط للمهام التي تتضمّن عرض تحديثات. - احرص على أن يكون حجم DOM صغيرًا. يرتبط حجم نموذج العناصر في المستند وكثافة العمل التخطيطي. عندما يحتاج العارض إلى تعديل تنسيق عنصر DOM كبير جدًا، يمكن أن يزيد العمل المطلوب لإعادة حساب تنسيقه بشكلٍ كبير.
- استخدِم احتواء CSS. يعتمد احتواء CSS على سمة
containفي CSS التي تقدّم تعليمات للمتصفّح حول كيفية تنفيذ التنسيق للحاوية التي تم ضبط السمةcontainعليها، بما في ذلك عزل نطاق التنسيق والعرض إلى جذر معيّن في DOM. إنها ليست دائمًا عملية سهلة، ولكن من خلال عزل المناطق التي تحتوي على تخطيطات معقدة، يمكنك تجنب تنفيذ عمل تخطيط وعرض غير ضروري لها.
الخلاصة
قد تبدو عملية تحسين أداء الصفحة مهمة شاقة، خاصةً مع توفّر مجموعة كبيرة من الإرشادات على الويب. مع ذلك، من خلال التركيز على هذه الاقتراحات، يمكنك التعامل مع المشكلة بتركيز وهدف، ونأمل أن تساعدك في تحسين مؤشرات Core Web Vitals الخاصة بموقعك الإلكتروني.
مع أنّ الاقتراحات المدرَجة هنا ليست شاملة بأي شكل من الأشكال، فإنّنا نعتقد استنادًا إلى التحليل الدقيق لحالة الويب أنّ هذه الاقتراحات هي أكثر الطرق فعالية التي يمكن للمواقع الإلكترونية من خلالها تحسين أداء "مؤشرات أداء الويب الأساسية" في عام 2023.
إذا كنت تريد تجاوز الاقتراحات المذكورة هنا، يمكنك الاطّلاع على أدلة التحسين هذه لمزيد من المعلومات:
أطيب الأمنيات بمناسبة العام الجديد، ونأمل أن تكون شبكة الويب أسرع للجميع. اجعل مواقعك الإلكترونية سريعة للمستخدمين بكل الطرق الأكثر أهمية.
الصورة من إعداد ديفين أفيري