التخلص من عمليات التنزيل غير الضرورية

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

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

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

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

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

التأثيرات على "مؤشرات أداء الويب الأساسية"

قدّم محرّك بحث Google مبادرة "مؤشرات أداء الويب الأساسية" بهدف توفير مجموعة من المقاييس التي تعكس ما يواجهه المستخدمون أثناء استخدام الويب. هناك العديد من استراتيجيات التحسين المتعلّقة بمؤشرات Core Web Vitals، إلا أنّ السؤال عن تحميل مرجع معيّن على صفحة قد يسلّط الضوء على مسار لتحسين هذه المقاييس على موقعك الإلكتروني. فيما يلي بعض الأمثلة — المجمَّعة حسب كل واحد من مؤشرات أداء الويب الأساسية — التي تستحق اهتمامك. على الرغم من أنّ هذه ليست قائمة شاملة بالأمثلة (وهناك الكثير منها)، ولكن قد تمنحكم قراءتها بعض الأفكار.

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

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

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

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

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

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

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

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

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

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

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

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

الخلاصة

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

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

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