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