يوضّح فريق Chrome DevRel مجموعة من أفضل الممارسات التي يعتبرها الفريق الأكثر فعالية لتحسين أداء "مؤشرات أداء الويب الأساسية" في 2023.
على مرّ السنين، قدّمنا في Google الكثير من الاقتراحات لمطوّري برامج الويب حول كيفية تحسين الأداء.
على الرغم من أنّ كلّ اقتراح من هذه الاقتراحات بشكل فردي قد يساعد في تحسين أداء العديد من المواقع الإلكترونية، لا شكّ في أنّ المجموعة الكاملة من الاقتراحات تبدو مُربكة ولا يمكن لأيّ شخص أو موقع إلكتروني اتّباعها كلها.
ما لم يكن أداء الويب هو وظيفتك اليومية، لن يكون من الواضح على الأرجح الاقتراحات التي سيكون لها أكبر تأثير إيجابي في موقعك الإلكتروني. على سبيل المثال، لعلك رأيت أنّ استخدام CSS مهم يمكن أن يحسّن أداء التحميل، وربما سمعت أيضًا أنّه من المهم تحسين صورك. ولكن، إذا لم يكن لديك الوقت الكافي للعمل على كلا الأمرين، كيف ستقرر أيهما تختار؟
في فريق Chrome، أمضينا العام الماضي في محاولة الإجابة عن هذا السؤال: ما هي أهم الاقتراحات التي يمكننا تقديمها للمطوّرين لمساعدتهم في تحسين الأداء للمستخدمين؟
للإجابة بشكل كافٍ عن هذا السؤال، علينا أن نأخذ في الاعتبار ليس فقط المزايا الفنية لأي اقتراح معيّن، بل أيضًا العوامل البشرية والتنظيمية التي تؤثر في احتمالية أن يتمكن المطوّرون من تطبيق هذه الاقتراحات. بعبارة أخرى، قد تكون بعض الاقتراحات ذات تأثير كبير من الناحية النظرية، ولكن في الواقع، سيتوفّر لعدد قليل جدًا من المواقع الإلكترونية الوقت أو الموارد اللازمة لتنفيذها. وبالمثل، تكون بعض التوصيات بالغة الأهمية، ولكن معظم المواقع الإلكترونية تتبع هذه الممارسات بالفعل.
باختصار، أردنا التركيز على ما يلي في قائمة أهم الاقتراحات المتعلقة بأداء الموقع الإلكتروني:
- سيكون للاقتراحات التي نعتقد أنّها التأثير الأكبر على أرض الواقع
- الاقتراحات التي تكون ذات صلة وتنطبق على معظم المواقع الإلكترونية
- اقتراحات واقعية بالنسبة إلى معظم المطوّرين
على مدار العام الماضي، أمضينا الكثير من الوقت في مراجعة المجموعة الكاملة من الاقتراحات المتعلّقة بالأداء التي نقدّمها وتقييم كلّ منها (نوعيًا وكميًا) وفقًا للمعايير الثلاثة المذكورة أعلاه.
توضّح هذه المشاركة أهم الاقتراحات التي نقدّمها لتحسين الأداء وفقًا لكل مقياس من مقاييس مؤشرات أداء الويب الأساسية. إذا كنت مبتدئًا في مجال أداء الويب أو كنت تسعى إلى تحديد الخيار الذي سيكسبك أكبر عائد لأرباحك، نعتقد أن هذه الاقتراحات هي أفضل طريقة للبدء.
سرعة عرض أكبر محتوى مرئي (LCP)
كانت مجموعتنا الأولى من الاقتراحات تتعلّق بسرعة عرض أكبر محتوى مرئي (LCP)، وهو مقياس لأداء التحميل. ومن بين المقاييس الثلاثة في "مؤشرات أداء الويب الأساسية"، يكون مقياس LCP هو المقياس الذي يواجه أكبر عدد من المواقع الإلكترونية مشكلة، حيث يستوفي حوالي جميع المواقع الإلكترونية على الويب حاليًا الحد الأدنى المقترَح، لذا لنبدأ.
التأكّد من أنّ مورد LCP قابل للاكتشاف من مصدر HTML
وفقًا لـ تقويم الويب لعام 2022 من أرشيف 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 من مصدر HTML هو خطوة أولى مهمة لضمان بدء التحميل مبكرًا لمورد LCP، ولكن هناك خطوة مهمة أخرى تتمثّل في ضمان منح تحميل هذا المورد أولوية وعدم وضعه في قائمة الانتظار خلف مجموعة من الموارد الأخرى الأقل أهمية.
على سبيل المثال، حتى إذا كانت صورة LCP متوفّرة في مصدر HTML باستخدام علامة <img> عادية، إذا كانت صفحتك تتضمّن عشرات علامات <script> في <head> من المستند قبل علامة <img> هذه، قد يستغرق بدء تحميل مورد الصور بعض الوقت.
إنّ أسهل طريقة لحلّ هذه المشكلة هي تقديم تلميح للمتصفح حول الموارد ذات الأولوية القصوى من خلال ضبط السمة fetchpriority="high" الجديدة على العلامة <img> أو <link> التي تحمِّل صورة سرعة عرض أكبر جزء من المحتوى على الصفحة. حيث يوجّه هذا المتصفح المتصفح لتحميله في مرحلة مبكرة، بدلاً من انتظار اكتمال هذه النصوص البرمجية.
وفقًا لـ 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)، جرِّب استخدام إشارات استدلالية لاختيار صورة مرشحة معقولة.
إنّ تأجيل الموارد غير المهمة هو طريقة أخرى لتعزيز الأولوية النسبية لمورد سرعة عرض أكبر جزء من المحتوى على الصفحة بشكل فعّال. على سبيل المثال، يمكن تأجيل النصوص البرمجية التي لا تعمل على واجهة المستخدم (مثل النصوص البرمجية للإحصاءات أو التطبيقات المصغّرة للشبكات الاجتماعية) بشكل آمن إلى أن يتم تنشيط حدث load، ما يضمن عدم تنافس هذه النصوص مع الموارد المهمة الأخرى (مثل مورد LCP) في ما يتعلّق بمعدل نقل البيانات للشبكة.
باختصار، يجب اتّباع أفضل الممارسات التالية لضمان تحميل مورد LCP مبكرًا وبأولوية عالية:
- أضِف
fetchpriority="high"إلى العلامة<img>لصورة سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP). في حال تحميل مورد LCP من خلال علامة<link rel="preload">، لا داعي للقلق لأنّه يمكنك أيضًا ضبطfetchpriority="high"على ذلك. - لا يتم مطلقًا ضبط
loading="lazy"على علامة<img>لصورة سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP). سيؤدي هذا الإجراء إلى تقليل أولوية الصورة وتأخير التحميل عند بدء التحميل. - تأجيل الموارد غير المُهمة قدر الإمكان: ويمكنك إمّا نقلها إلى نهاية المستند، أو استخدام التحميل الكسول المحلي للصور أو إطارات iframe، أو تحميلها بشكلٍ غير متزامن عبر JavaScript.
استخدام شبكة توصيل للمحتوى (CDN) لتحسين TTFB في المستندات والموارد
ركّزت الاقتراحان السابقان على التأكّد من اكتشاف مورد LCP مبكرًا وإعطاء الأولوية له كي يبدأ التحميل على الفور. الجزء الأخير من هذا اللغز هو التأكد من وصول الرد الأوّلي للمستند في أسرع وقت ممكن أيضًا.
لا يمكن للمتصفّح بدء تحميل أي موارد فرعية حتى يتلقّى البايت الأول من استجابة مستند HTML الأول، وكلما أسرعت في حدوث ذلك، بدأ كل شيء آخر في الحدوث أيضًا.
وتُعرف هذه المدة باسم الوقت المطلوب حتى أول بايت (TTFB)، وأفضل طريقة لتقليل مدة البايت (TTFB) هي:
- عرض المحتوى في أقرب وقت ممكن من الموقع الجغرافي للمستخدمين
- تخزين هذا المحتوى في ذاكرة التخزين المؤقت حتى يمكن عرض المحتوى المطلوب مؤخرًا مرة أخرى بسرعة.
تتمثل أفضل طريقة لتنفيذ هذَين الإجراءين في استخدام شبكة توصيل محتوى (CDN). توزّع شبكات توصيل المحتوى (CDN) مواردك على خوادم الحافة المنتشرة في جميع أنحاء العالم، وبالتالي الحدّ من المسافة التي يجب أن تقطعها هذه الموارد عبر السلك بين المستخدمين. عادةً ما تتضمّن شبكات توصيل المحتوى (CDN) أيضًا عناصر تحكّم دقيقة في التخزين المؤقت يمكن تخصيصها وتحسينها لتلبية احتياجات موقعك الإلكتروني.
يعرف العديد من المطوّرين كيفية استخدام شبكة توصيل المحتوى (CDN) لاستضافة مواد العرض الثابتة، ولكن يمكن لشبكات توصيل المحتوى (CDN) عرض مستندات HTML وتخزينها مؤقتًا أيضًا، حتى تلك التي يتم إنشاؤها ديناميكيًا.
وفقًا لـ Web Almanac، تم عرض 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) الذي شهدناه في 2022.
وعلى الرغم من ذلك، فإنّ عددًا كبيرًا من المواقع الإلكترونية غير مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات" وبالتالي تفوتك فرصة الاستفادة من هذا الأداء المجاني على الويب عند إجراء عدد كبير من عمليات التنقّل. ما لم يتم تحميل معلومات حساسة في صفحتك ولا تريد استعادتها من الذاكرة، فستحتاج إلى التأكد من أن صفحاتك مؤهلة.
على مالكي المواقع الإلكترونية التأكّد من أنّ صفحاتهم مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات" والعمل على تحديد أي أسباب لعدم أهلية الصفحات. يتوفّر حاليًا في Chrome أداة اختبار ذاكرة التخزين المؤقت لميزة "التخزين المؤقت للصفحات" في "أدوات مطوري البرامج"، ونخطط هذا العام لتحسين الأدوات هنا من خلال عملية تدقيق جديدة في Lighthouse تُجري اختبارًا مشابهًا وواجهة برمجة تطبيقات لقياس ذلك في المجال.
وعلى الرغم من أننا أدرجنا ميزة "التخزين المؤقت للصفحات" في قسم "متغيّرات التصميم التراكمية" (CLS)، ولأنّنا شهدنا أكبر قدر من الأرباح حتى الآن، ستعمل ميزة "التخزين المؤقت للصفحات" بشكل عام أيضًا على تحسين "مؤشرات أداء الويب الأساسية" الأخرى أيضًا. وهو أحد عدد من عمليات التنقل الفورية المتاحة لتحسين عمليات التنقل في الصفحات بشكلٍ كبير.
تجنُّب الصور المتحركة أو الانتقالات التي تستخدم خصائص CSS التي تؤثر في التنسيق
مصدر آخر شائع لمتغيّرات التصميم هو عندما تكون العناصر متحركة. على سبيل المثال، غالبًا ما تكون إعلانات بانر الخاصة بملفات تعريف الارتباط أو غيرها من إعلانات البانر التي يتم سحبها من أعلى الشاشة أو أسفلها تساهم في متغيّرات التصميم التراكمية (CLS). ويشكّل ذلك مشكلة كبيرة، خاصةً عندما تدفع إعلانات البانر هذه محتوًى آخر إلى إبعاد المحتوى، ولكن حتى في حال عدم حدوث ذلك، يمكن أن تؤثّر الصور المتحركة في متغيّرات التصميم التراكمية (CLS).
على الرغم من أنّه لا يمكن لبيانات أرشيف HTTP ربط الصور المتحركة بشكل نهائي بمتغيّرات التصميم، تُظهر البيانات أنّ الصفحات التي تحرّك أي خاصية من خصائص CSS يمكن أن تؤثر في التنسيق تكون أقل عرضة بنسبة% 15 أن تحتوي على متغيّرات التصميم التراكمية (CLS) "جيدة" مقارنةً بالصفحات ككل. ترتبط بعض المواقع بمتغيّرات التصميم التراكمية أسوأ من غيرها. على سبيل المثال، إنّ الصفحات التي تتضمّن مؤثرات عرض margin أو border تكون ذات قيمة "سيئة" متغيّرات التصميم التراكمية (CLS) تُظهر ضعف معدّل تقييم الصفحات بشكل عام بأنّها ضعيفة.
قد لا يكون هذا الأمر مفاجئًا، لأنّه في أي وقت يتم فيه نقل أو تحريك أي خاصية CSS تساعد في التنسيق، سيؤدي ذلك إلى متغيّرات في التنسيق، وإذا كانت مدة متغيّرات التصميم هذه لا تتجاوز 500 مللي ثانية من تفاعل المستخدم، سيؤثر ذلك في متغيّرات التصميم التراكمية (CLS).
ما قد يثير دهشة بعض المطورين هو أن هذا صحيح حتى في الحالات التي يتم فيها أخذ العنصر خارج التدفق العادي للمستند. على سبيل المثال، إذا تم تحديد موضع إعلان معيّن وتحريك top أو left، سيؤدي ذلك إلى حدوث متغيّرات في التنسيق، حتى إذا لم تكن هذه العناصر تعرض محتوًى آخر. ومع ذلك، إذا تم تحريك transform:translateX() أو transform:translateY() بدلاً من إنشاء صورة متحركة لـ top أو left، لن يؤدي ذلك إلى تعديل المتصفِّح لتنسيق الصفحة، وبالتالي لن ينتج عنه أي متغيّرات في التنسيق.
لطالما كان تفضيل الصور المتحركة لخصائص 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 في مدير العلامات وزيادة فعاليته.
تجنُّب التعديلات على عمليات العرض الكبيرة
وتجدر الإشارة إلى أن JavaScript ليس العنصر الوحيد الذي يمكن أن يؤثر في مدى استجابة موقعك الإلكتروني. يمكن أن يكون العرض نوعًا من العمل المكلف بحدّ ذاته، وعندما يتم إجراء تعديلات كبيرة على العرض، يمكن أن يؤثّر ذلك في قدرة موقعك الإلكتروني على الاستجابة لإدخالات المستخدمين.
إنّ تحسين عمل العرض ليس عملية مباشرة، وغالبًا ما يعتمد على ما تحاول تحقيقه. مع ذلك، هناك بعض الإجراءات التي يمكنك اتّخاذها للتأكّد من أنّ تحديثات العرض معقولة وعدم توسّعها إلى مهام طويلة:
- تجنَّب استخدام
requestAnimationFrame()لتنفيذ أي عمل غير مرئي. تتم معالجة طلباتrequestAnimationFrame()أثناء مرحلة العرض ضمن حلقة الأحداث، وعند إنجاز الكثير من العمل أثناء هذه الخطوة، قد يتأخر عرض تحديثات العرض. من الضروري أن يكون أي عمل تقوم به باستخدامrequestAnimationFrame()محصورًا تمامًا بالمهام التي تتضمّن عرض التحديثات. - حافِظ على صغر حجم DOM. يرتبط حجم DOM وكثافة عمل التخطيط. عندما يضطر العارض إلى تحديث التنسيق لـ DOM الكبير جدًا، فقد يزيد العمل المطلوب لإعادة حساب تصميمه بشكل كبير.
- استخدِم احتواء CSS. يعتمد احتواء CSS على السمة
containفي CSS التي تقدّم تعليمات إلى المتصفّح حول كيفية تنفيذ عمل التنسيق للحاوية التي تم ضبط السمةcontainعليها، بما في ذلك عزل نطاق التنسيق والعرض على جذر معيّن في DOM. إنها ليست دائمًا عملية سهلة، ولكن من خلال عزل المناطق التي تحتوي على تخطيطات معقدة، يمكنك تجنب القيام بعمل التخطيط وعرض العمل لها وهو ليس ضروريًا.
الخلاصة
قد يبدو تحسين أداء الصفحات مهمة شاقة، لا سيما أنّ هناك مجموعة كبيرة من الإرشادات على الويب يجب أخذها في الاعتبار. مع ذلك، يمكنك من خلال التركيز على هذه الاقتراحات التعامل مع المشكلة بالتركيز والهدف، ونأمل أن تساعدك في تحسين مؤشرات أداء الويب الأساسية لموقعك الإلكتروني.
على الرغم من أنّ الاقتراحات الواردة هنا ليست شاملة بأي حال من الأحوال، نعتقد أنّه استنادًا إلى التحليل الدقيق لحالة الويب على الويب أنّ هذه الاقتراحات هي الطُرق الأكثر فعالية التي يمكن للمواقع الإلكترونية من خلالها تحسين أدائها في "مؤشرات أداء الويب الأساسية" في 2023.
وإذا كنت تريد تجاوز الاقتراحات الواردة هنا، يمكنك مراجعة أدلة التحسين هذه للحصول على مزيد من المعلومات:
نتمنى لك سنة جديدة والويب أسرع للجميع. يمكنك توفير سرعة موقعك الإلكتروني للمستخدمين بجميع الطرق الأكثر أهمية.
تصوير ديفين أفيري