تُحدَّد سرعة الموقع بمجموعة محددة وقابلة للترتيب من العوامل التقنية — لا صفة غامضة يملكها موقع أو يفتقدها. فهم الترتيب الذي تميل فيه للتأثير يجعل ترتيب أولويات تحسين السرعة أكفأ بكثير من تطبيق كل تقنية تحسين ممكنة دفعة واحدة، وعدة منها لن تحرّك المؤشر لعنق الزجاجة الفعلي لموقع معيّن.
زمن استجابة الخادم: الأساس الذي يُبنى عليه كل شيء آخر
قبل أن يستطيع متصفح عرض أي شيء، يجب أن يستقبل أول بايت من الاستجابة — وكل تحسين آخر في هذه القائمة يؤثر فقط فيما يحدث بعد تلك النقطة. زمن استجابة خادم بطيء ("وقت حتى أول بايت" مرتفع) يضع أرضية تحت مدى سرعة شعور الصفحة الممكنة، بغض النظر عن مدى تحسين كل ما بعدها. يتأثر هذا بأداء التطبيق على جانب الخادم، وكفاءة استعلامات قاعدة البيانات، وبنية الاستضافة الأساسية نفسها — معالج وذاكرة كافيان وتخزين سريع، مشروح بتفصيل أكبر أدناه. يمكن لموقع أن يملك صورًا محسَّنة تمامًا ولا نصوصًا برمجية معطّلة للعرض وما زال يشعر ببطء إن استغرق الخادم نفسه ثانية أو أكثر فقط ليبدأ بالاستجابة.
التخزين المؤقت: عدم تكرار عمل أُنجِز بالفعل
يخزّن التخزين المؤقت نتيجة عمل مكلف — صفحة مُعروضة، نتيجة استعلام قاعدة بيانات، قيمة محسوبة — بحيث تستطيع الطلبات اللاحقة إعادة استخدامها بدلاً من إعادة إنجازها. غالبًا ما يكون هذا أعلى تحسين سرعة تأثيرًا متاح لموقع تجاري نموذجي قائم على نظام إدارة محتوى، لأن معظم الصفحات لا تحتاج إعادة توليد من الصفر عند كل زيارة؛ المحتوى نفسه لمعظم الزوار معظم الوقت. يعالج التخزين المؤقت على مستوى الصفحة، والتخزين المؤقت للكائنات لاستعلامات قاعدة البيانات، وتخزين المتصفح المؤقت للأصول الثابتة (بحيث لا يعيد زائر عائد تحميل ملفات لم تتغيّر) كل منها طبقة مختلفة، وموقع يفتقد أيًا منها يترك تحسينًا كبيرًا نسبيًا دون استغلال. إن كان الموقع المعني يعمل على ووردبريس تحديدًا، راجع كيف تسرِّع موقع ووردبريس دون أن تكسره لخطوات تخزين مؤقت خاصة بهذا النظام والأخطاء الواجب تجنبها عند تفعيلها.
الصور ووزن الأصول
عادة ما تكون الصور أكبر مساهم منفرد في وزن الصفحة الإجمالي، وصورة رئيسية كبيرة الحجم أو غير مضغوطة أو بصيغة خاطئة من أكثر أسباب شعور تحميل الصفحة بالبطء شيوعًا. تقديم الصور بصيغة حديثة، مضغوطة بشكل مناسب لحجم العرض المطلوب فعليًا (لا دقة الرفع الأصلية)، وتحميل الصور تحت الطية فقط حين يقترب الزائر منها بالتمرير (التحميل الكسول)، يقلل كل منها كمية البيانات الواجب نقلها وفك ترميزها قبل أن تشعر الصفحة بالاكتمال. هذا أيضًا العامل الأكثر ارتباطًا مباشرة بـLargest Contentful Paint — راجع مؤشرات الويب الأساسية لمواقع الشركات لمعرفة كيف يُقاس ويُشخَّص ذلك المقياس تحديدًا.
الموارد المعطّلة للعرض
لا يستطيع متصفح بدء رسم صفحة حتى يعالج CSS، وفي إعدادات كثيرة، بعض JavaScript في رأس الصفحة — الموارد المعطّلة للعرض تؤخر النقطة التي يصبح فيها أي شيء مرئيًا أصلاً، حتى لو كان المحتوى الأساسي نفسه جاهزًا بسرعة خلاف ذلك. تأجيل CSS وJavaScript غير الحرجين، وتضمين فقط القدر الصغير من CSS المطلوب فعليًا لعرض الجزء المرئي من الصفحة فورًا، يقلل هذا التأخير مباشرة. هذه حالة يتعلق فيها الإصلاح تحديدًا بـمتى تُحمَّل الموارد، لا بحجمها — يمكن لنص برمجي صغير معطّل للعرض أن يسبب تأخيرًا أكثر وضوحًا من نص أكبر مؤجَّل بشكل صحيح.
النصوص البرمجية الخارجية
علامات التحليلات، وأدوات المحادثة، والنصوص الإعلانية، والتضمينات الاجتماعية مصدر تباطؤ شائع ومُغفَل بشكل جماعي، لأن كل واحدة بمفردها صغيرة بما يكفي لتبدو غير ضارة بينما الأثر التراكمي لعدة منها محمّلة في كل صفحة ليس كذلك. يضيف كل نص برمجي خارجي طلب شبكة خاصًا به، ووقت تنفيذ خاصًا به على الخيط الرئيسي للمتصفح، ولبعضها، طلبات تابعة إضافية خاصة به يُطلقها بعد التحميل. تدقيق أي النصوص البرمجية الخارجية ضرورية فعليًا، وتأجيل أو تحميل التي لا تتطلبها تجربة الصفحة الأولية بشكل كسول، غالبًا مكسب أكبر مما يبدو أولاً، تحديدًا لأنها الفئة الأكثر احتمالاً للوجود في كل صفحة من صفحات موقع دون أن يقرر أحد تحديدًا إضافة كل ذلك الوزن التراكمي.
مثال على ترتيب الأولويات
يقيس موقع تجاري بشكل ضعيف على LCP وبشكل معقول على INP وCLS. بدلاً من العمل عبر قائمة التحسين العامة الكاملة، يبدأ النهج المستهدف بالأسباب المرتبطة تحديدًا بـLCP: يتضح أن الوقت حتى أول بايت سريع، ما يستبعد زمن استجابة الخادم كسبب، لكن الصورة الرئيسية على الصفحة الرئيسية ملف JPEG غير مُحسَّن بحجم 3 ميجابايت يُحمَّل قبل أي محتوى مرئي آخر — ضغط تلك الصورة الواحدة وتحديد حجمها بشكل صحيح، وضبطها لتُحمَّل بأولوية، يحل معظم مشكلة LCP بمفرده. فحص ثانٍ وأصغر يعالج نصًا برمجيًا للتحليلات معطِّلاً للعرض في رأس الصفحة بتأجيله، ليغلق معظم الفجوة المتبقية. تغييران مستهدفان، مدفوعان بما حدده القياس فعليًا، ينجزان أكثر من فحص عام يطبّق كل تقنية في القائمة الكاملة — بما فيها عدة تقنيات، كتدقيق نصوص برمجية خارجية أخرى غير نص التحليلات ذاك، لم تكن تساهم فعليًا بشكل ملموس في مشكلة هذا الموقع المحددة.
قياس ما يهم فعليًا
الطريقة العملية لترتيب أولويات هذه العوامل لموقع محدد هي القياس أولاً بدلاً من تخمين أيها ينطبق. تشير مؤشرات الويب الأساسية — LCP وINP وCLS — كل منها إلى فئة مختلفة من القائمة أعلاه: يعود LCP البطيء عادة إلى زمن استجابة الخادم أو صور غير مُحسَّنة؛ ويعود INP الضعيف عادة إلى JavaScript ثقيل، غالبًا من نصوص برمجية خارجية؛ ويعود CLS الضعيف عادة إلى صور أو محتوى مضمّن دون مساحة محجوزة. قياس أي مقياس محدد فاشل فعليًا، بدلاً من تطبيق كل تحسين في هذه القائمة بشكل موحّد، يحدد العامل الذي هو عنق الزجاجة الفعلي لموقع معيّن ويجعل الإصلاح مستهدفًا لا جهدًا عامًا وغير مركّز.
لماذا تضع الاستضافة سقفًا لكل تحسين آخر
يستحق الأمر الختام بالنقطة التي افتتحت بها القائمة، لأنها الأكثر إغفالاً: كل تحسين أعلاه — التخزين المؤقت، ضغط الصور، النصوص البرمجية المؤجَّلة — يحسّن مدى كفاءة استخدام صفحة للموارد المتاحة لها، لكن لا شيء منها يرفع السقف الأساسي الذي تفرضه تلك الموارد. خادم ناقص المعالج سيطبّق منطق التخزين المؤقت أبطأ من خادم جيد الموارد؛ خادم بتخزين بطيء سيكتب إدخالات التخزين المؤقت ونتائج الاستعلامات أبطأ بغض النظر عن مدى جودة تصميم استراتيجية التخزين المؤقت نفسها. هذا سبب استحقاق موقع طبّق كل تحسين واجهة أمامية في هذه القائمة وما زال يشعر ببطء التحقق على مستوى طبقة الاستضافة تحديدًا — معالج وذاكرة كافيان لحمل التطبيق الفعلي، وتخزين سريع بمستوى NVMe لأي شيء يلامس القرص، مشروح بتفصيل أكبر في كيف تؤثر المعالج والذاكرة والتخزين على أداء الخادم. تحسين الواجهة الأمامية والاستضافة الكافية ليسا بديلين لبعضهما؛ يعالجان طبقتين مختلفتين من المشكلة نفسها، وتخطي أي منهما يترك سرعة حقيقية ومتاحة دون استغلال. موقع مبني جيدًا على استضافة ناقصة، وموقع مبني بشكل سيئ على استضافة ممتازة، يميلان للوصول إلى موضع مخيّب للأمل مشابه تقريبًا لزائر ليس لديه رؤية عن أي طبقة هي المذنبة فعليًا — وهذا بالضبط سبب حاجة كلتا الطبقتين للانتباه بدلاً من معاملة إحداهما كبديل عن الأخرى.
