إنّ المورد الأسرع والأكثر تحسينًا هو المورد الذي لم يتم إرساله. يجب إزالة الموارد غير الضرورية من تطبيقك. من الممارسات الجيدة أن تسأل فريقك عن الافتراضات الضمنية والصريحة وتعيد النظر فيها بشكل دوري. وفي ما يلي بعض الأمثلة على ذلك:
- لقد كنت دائمًا تُدرِج المورد "س" في صفحاتك، ولكن هل تُلغي تكلفة تنزيله وعرضه القيمة التي يقدّمها للمستخدم؟ هل يمكنك قياس قيمتها وإثباتها؟
- هل يقدّم المرجع (خاصةً إذا كان مرجعًا تابعًا لجهة خارجية) أداءً متسقًا؟ هل هذا المورد في المسار الحرج، أو يجب أن يكون كذلك؟ إذا كان المورد في المسار الحرج، هل يمكن أن يكون نقطة فشل واحدة للموقع الإلكتروني؟ بمعنى آخر، إذا لم يكن المرجع متاحًا، هل يؤثر ذلك في الأداء وتجربة المستخدم لصفحاتك؟
- هل يحتاج هذا المورد إلى اتّفاقية مستوى خدمة أو لديه اتّفاقية؟ هل يتّبع هذا المرجع أفضل الممارسات المتعلقة بالأداء، مثل الضغط والتخزين المؤقت وما إلى ذلك؟
غالبًا ما تحتوي الصفحات على موارد غير ضرورية، أو أسوأ من ذلك، تؤدي إلى عرقلة أداء الصفحة بدون تقديم قيمة كبيرة للزائر أو للموقع الإلكتروني الذي يتم استضافتها عليه. وينطبق ذلك على الموارد والتطبيقات المصغّرة التابعة للطرف الأول والجهات الخارجية على حدّ سواء:
- قرّر الموقع الإلكتروني "أ" عرض لوحة عرض دوّارة للصور على صفحته الرئيسية للسماح للزائر بمعاينة صور متعدّدة بنقرة سريعة. يتم تحميل كل الصور عند تحميل الصفحة، وينتقل المستخدم بين الصور.
- السؤال: هل قيّمت عدد المستخدمين الذين يطّلعون على صور متعدّدة في لوحة العرض الدوّارة؟ قد تتحمل تكاليف عالية من خلال تنزيل موارد لا يطّلع عليها معظم الزوّار.
- قرّر الموقع الإلكتروني "ب" تثبيت تطبيق مصغّر تابع لجهة خارجية لعرض محتوى ذي صلة أو تحسين التفاعل الاجتماعي أو تقديم خدمة أخرى.
- السؤال: هل يمكنك تتبُّع عدد الزوّار الذين يستخدمون الأداة أو نسبة النقر إلى الظهور على المحتوى الذي تقدّمه الأداة؟ هل التفاعل الذي تحقّقه هذه الأداة كافٍ لتبرير النفقات المرتبطة بها؟ بالإضافة إلى ذلك، هل من الممكن استخدام استراتيجية تحميل لضمان عدم تحميل النص البرمجي إلى أن تكون هناك حاجة إليه؟
غالبًا ما يتطلّب تحديد ما إذا كان يجب إيقاف عمليات التنزيل غير الضرورية الكثير من التفكير والقياس الدقيق. للحصول على أفضل النتائج، يجب مراجعة هذه الأسئلة بشكل دوري لكلّ مادة عرض على صفحاتك.
التأثيرات على "مؤشرات أداء الويب الأساسية"
أطلقت Google مبادرة "مؤشرات أداء الويب الأساسية" لتقديم مجموعة من المقاييس التي تعكس تجربة المستخدمين أثناء تصفّح الويب. على الرغم من توفّر العديد من استراتيجيات التحسين لـ "مؤشرات أداء الويب الأساسية"، فإنّ التساؤل عمّا إذا كان يجب تحميل مورد معيّن على الصفحة قد يفتح لك مسارًا لتحسين هذه المقاييس على موقعك الإلكتروني. في ما يلي بعض الأمثلة التي تستحقّ الانتباه، وهي مجمّعة حسب كلّ مقياس من "مؤشرات أداء الويب الأساسية". على الرغم من أنّ هذه القائمة ليست شاملة (وهناك العديد من الأمثلة)، إلا أنّ قراءتها قد تمنحك بعض الأفكار المفيدة.
سرعة عرض أكبر محتوى مرئي (LCP)
يقيس مقياس سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) وقت تحميل أكبر محتوى (مثل صورة رئيسية أو عنوان). ويُعدّ مقياسًا مهمًا يعتمد على الإدراك يعطي المستخدم انطباعًا بأنّ الموقع الإلكتروني يتم تحميله بسرعة.
بشكل عام، يعني تنزيل عدد أقل من الموارد أنّ النطاق الترددي المتاح للمستخدم سيتم توزيعه على عدد أقل من الموارد، وقد يؤدي ذلك إلى تحسين مقياس LCP. ومن الأمثلة الكلاسيكية على ذلك ميزة "التحميل الكسول"، حيث لا يتم تنزيل الصور خارج إطار العرض أثناء تحميل الصفحة إلى أن يحدّد المتصفّح أنّه من المرجّح أن يراها المستخدم. إذا كان لديك معرض صور مصغّرة كبير يتضمّن 50 صورة مثلاً، فإنّ ميزة "التحميل البطيء" لجميع الصور باستثناء العشرة الأولى منها تعني أنّ المتصفّح يمكنه الاستفادة بشكل أكثر فعالية من معدل نقل البيانات المتاح له، وسيتم تحميل الصور الأولى التي سيراها المستخدم بشكل أسرع.
ومع ذلك، لا يقتصر الأمر على تحميل عدد أقل من الصور. يحتوي المتصفّح على مخطّط أولوية داخلي يحدّد مقدار النطاق الترددي الذي يجب أن يحصل عليه كلّ مورد. ومع ذلك، حتى مع هذا كل الموارد، خاصةً تلك التي يتم تنزيلها بأولوية عالية، يمكن أن تحرم العنصر المحتمل لـ LCP من المورد المرتبط به. وينطبق ذلك بشكل خاص على عمليات الاتصال بالشبكة البطيئة. قد يكون هذا المورد التابع ملف صورة يمثّل عنصر LCP للصفحة، ولكن قد يكون أيضًا موردًا لخط ويب يحتاج إليه المتصفّح لعرض عقدة نصية يمكن تحديدها كعنصر LCP للصفحة.
إذا كان موقعك الإلكتروني يتضمّن الكثير من النصوص، قد يكون عنصر LCP للصفحة هو عقدة نصية. على الرغم من توفّر العديد من استراتيجيات تحسين الخطوط وتحميلها الجيدة، قد يكون من المفيد التفكير في ما إذا كان خط النظام كافيًا لتلبية احتياجات موقعك الإلكتروني، حتى تتمكّن عناصر LCP التي تشكّل عقد نصية من التحميل بدون الاعتماد على مورد خط ويب وعرضها على الفور تقريبًا عند وصول ملفّي CSS وHTML من الخادم.
متغيّرات التصميم التراكمية (CLS)
يمكن أن يساهم كلّ مورد تحمّله في متغيّرات التصميم التراكمية (CLS) للصفحة، لا سيما إذا لم ينتهِ تنزيله بحلول وقت سرعة عرض الصفحة الأولية. بالنسبة إلى الصور، يشمل تجنُّب مقياس متغيّرات التصميم التراكمية (CLS) ممارسات مثل ضبط أبعاد صريحة. بالنسبة إلى الخطوط، يمكن أن تقلّل إدارة تحميل الخطوط ومطابقة الخطوط الاحتياطية من التغييرات أثناء فترة تبديل خط الويب. بالنسبة إلى JavaScript، يمكن أن يكون ذلك من خلال إدارة كيفية معالجة النص البرمجي لنموذج DOM بحيث يتم تقليل التحولات في التنسيق إلى حدّ مقبول.
يتطلّب كلّ مورد يساهم في مقياس CLS للصفحة قدرًا من العمل لضمان ثبات تخطيط الصفحة بشكلٍ كافٍ. من خلال التساؤل عمّا إذا كنت بحاجة إلى مرجع معيّن أم لا، لا تسرِّع فقط من تحميل الصفحات، بل تقلّل أيضًا من الجهد المعرفي اللازم للحفاظ على ثبات التنسيق. ويؤدي ذلك إلى توفير تجربة أفضل للمستخدمين والمطوّرين، لأنّه سيتوفّر لك المزيد من الوقت لتحقيق أهداف أخرى في مشاريعك.
مدى استجابة الصفحة لتفاعلات المستخدم (INP)
يقيس مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP) مستوى الاستجابة لبيانات المستخدم طوال مدة عرض الصفحة. يمكن أن يتأثّر مقياس INP للصفحة بشكل كبير برمز JavaScript الذي تحمّله، لأنّ JavaScript هو ما يحقّق معظم التفاعل الذي يشهده المستخدمون على الويب. وعلى وجه الخصوص، يمكن أن يؤدي عدد موارد النصوص البرمجية التي يتم تنزيلها أثناء تحميل الصفحة إلى بدء عمل باهظ التكلفة قد يكون مرتبطًا بتقييم النصوص البرمجية وتجميعها. كلما قلّت كمية JavaScript التي تحمّلها أثناء بدء التشغيل، قلّ العمل الذي يجب أن يبذله المتصفّح في تلك المرحلة المهمة من تجربة الصفحة، حيث قد يحاول المستخدمون التفاعل معها.
على الرغم من توفّر استراتيجيات لتقليل حجم موارد JavaScript التي يتم تنزيلها أثناء بدء التشغيل، مثل تقسيم الرموز وإزالة العناصر غير الضرورية من الشجرة، من المفيد تدقيق الحِزم التي تستخدمها في مشاريعك لمعرفة ما إذا كانت ضرورية على الإطلاق. على سبيل المثال، تتضمّن lodash العديد من الطرق التي لا تزال مفيدة حتى اليوم، ولكنها تأتي مع طرق يوفّرها المتصفّح تلقائيًا، مثل الدوالّ الخاصة بـ Array للتعيين والتقليل والفلترة والعديد من الدوالّ الأخرى.
يُعدّ التحسين التدريجي أيضًا نهجًا مفيدًا لتطبيق JavaScript، إذ يتيح لك تقديم تجربة أساسية (ولكنها لا تزال وظيفية) للمستخدمين يمكنك إضافتها للمستخدمين الذين لديهم أجهزة أكثر فعالية واتصالات أسرع بالشبكة. سواء كنت تلتزم بمبدأ التحسين التدريجي أم لا، تبقى النقطة الأساسية هي أنّ كلّ مرجع JavaScript يمكنك تجنُّب تنزيله يمكن أن يؤدي إلى تجربة تستجيب بشكل أسرع لتفاعلات المستخدمين، ما يشكّل جانبًا حيويًا من أداء الويب.
الخاتمة
قد تكون التدقيق في موقعك الإلكتروني بحثًا عن عمليات تنزيل غير ضرورية مجرد جانب واحد من جوانب تقديم تجارب سريعة للمستخدمين، ولكنّه جانب يُحتمَل أن يكون له تأثير كبير. باختصار:
- يمكنك حصر مواد العرض الخاصة بك ومواد العرض التابعة لجهات خارجية على صفحاتك.
- يمكنك قياس أداء كلّ مادة عرض: قيمتها وأدائها الفني.
- تحديد ما إذا كانت الموارد توفّر قيمة كافية
- فهم تأثير عمليات التنزيل غير الضرورية على مؤشرات أداء الويب الأساسية والمقاييس الداعمة
من خلال تحسين كفاءة المحتوى بهذه الطريقة، لا تُحسِّن الأداء بشكل عام فحسب، بل تحرص أيضًا على عدم إهدار معدل نقل البيانات للمستخدمين، بالإضافة إلى إمكانية تحسين المقاييس التي تركّز على المستخدمين وتقديم تجربة أفضل لهم.