سرعة الموقع وشبكات CDN: كيف تجعل موقعك أسرع

في تقرير الأرشيف الشبكيّ لسنة 2025، الذي يقيس ملايين الصفحات كلّ سنة، رقمٌ يلخّص علاقة الوزن بالسرعة. الصفحات الأخفّ على الهاتف نجحت في مقياس ظهور المحتوى الرئيسيّ بنسبة 72%. والصفحات التي تزن بين 2 و3 ميغابايت، وهذا وزن الصفحة الوسيطة، نجحت بنسبة 59%. أمّا الصفحات التي تزن 5 ميغابايت فأكثر، فنجح منها 44% فقط.^[1] فكلّ ميغابايتٍ تضيفه إلى صفحتك يقلّل احتمال أن يراها زائر الهاتف في الوقت الذي يعدّه جيّدًا.

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

ما الذي تقيسه Google فعلًا

تقيس Google تجربة الصفحة بثلاثة مقاييس تسمّيها مؤشّرات الويب الأساسيّة. الأوّل وقت ظهور أكبر عنصرٍ في الشاشة، واختصاره LCP، ويجب أن يحدث خلال ثانيتين ونصف من بدء التحميل. والثاني سرعة استجابة الصفحة حين يضغط الزائر أو يكتب، واختصاره INP، والحدّ الجيّد له 200 جزءٍ من الألف من الثانية. والثالث ثبات الصفحة أثناء التحميل، واختصاره CLS، والحدّ الجيّد له 0.1 أو أقلّ.^[2] وقد أفردت لكلّ مؤشّرٍ منها شرحًا من جهة السيو، بأسبابه وطريقة قياسه في الميدان، في مقال مؤشّرات أداء الويب الأساسيّة.

وتفصيلٌ يغيّر قراءة هذه الأرقام: المطلوب أن يبلغها 75% من تحميلات الصفحة، مقيسةً للهاتف وحده وللحاسوب وحده.^[2] فإن كانت صفحتك سريعةً على حاسوبك وبطيئةً على هاتف زائرٍ بشبكةٍ ضعيفة، فالرقم الذي يُحسب عليك هو الثاني. والمقياس الثاني بالذات جديد: صار INP مؤشّرًا أساسيًّا في 12 مارس 2024، وحلّ محلّ مقياسٍ أقدم كان يقيس أوّل تفاعلٍ وحده.^[3]

أمّا أثر هذه المقاييس في ترتيب نتائج البحث، فتقول صفحة Google عنها إنّ محرّك البحث يسعى دائمًا إلى عرض المحتوى الأكثر صلة بالبحث، حتى لو كانت تجربة الصفحة دون المستوى. وتقول إنّ التجربة الجيّدة تساعد حين تتنافس صفحاتٌ كثيرةٌ مفيدةٌ على البحث نفسه.^[4] فالسرعة لن تنقذ محتوًى ضعيفًا، لكنّها قد ترجّح كفّتك بين منافسين متقاربين. والسبب الأقوى لتحسينها يبقى زائرك نفسه.

أين يذهب الوقت

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

شكل 1

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

المرحلة الثانية أوّلًا: الخادم

أبدأ بالمرحلة الثانية لأنّها مرحلة الاستضافة، ولأنّ كلّ ما بعدها ينتظرها. يقيسها رقمٌ اسمه الزمن حتى أوّل بايت، واختصاره TTFB: المدّة بين طلب الصفحة ووصول أوّل جزءٍ منها. وتقول web.dev إنّ على معظم المواقع أن تسعى إلى زمنٍ لا يتجاوز 0.8 ثانية، وإنّ ما يزيد على 1.8 ثانيةٍ يُعدّ ضعيفًا.^[5] وهذا الرقم ليس من المؤشّرات الأساسيّة الثلاثة، لكنّه يسبقها كلّها، فلا يظهر شيءٌ قبله.

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

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

ولاحظ أنّ التخزين المؤقّت للصفحات يعمل على الصفحات التي يراها الجميع متشابهة: مقالٌ أو صفحةٌ تعريفيّة أو صفحة منتج. أمّا سلّة الشراء، وصفحة حسابك، ولوحة التحكّم، فتُبنى لكلّ زائرٍ وحده ولا تُخزَّن. ولهذا قد تجد متجرك سريعًا في صفحات المنتجات وبطيئًا في صفحة الدفع التي تهمّك أكثر من غيرها، والعلاج هناك في الخادم وقاعدة البيانات، لا في التخزين المؤقّت.

المرحلة الأولى: المسافة

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

وصار هذا الخيار متاحًا لجمهور الخليج أكثر ممّا كان. تعرض Kinsta، إحدى شركات الاستضافة المُدارة لووردبريس، على صفحة مراكز بياناتها ثلاثين موقعًا يختار منها صاحب الموقع عند إنشائه، منها دبيّ والرياض، وتوصي باختيار الأقرب إلى الزوّار.^[6] فاسأل أيّ مزوّدٍ قبل أن تشترك: أين مراكز بياناتكم، وهل أستطيع أن أختار منها؟ فإن كان أغلب زوّارك في الرياض وخادمك في فرانكفورت، فكلّ ما سيأتي بعده في هذا المقال يعمل ضدّ مسافةٍ كان يمكن تجنّبها.

وشبكة توزيع المحتوى تختصر هذه المسافة بطريقةٍ أخرى: تحفظ نسخًا من ملفّات موقعك في مدنٍ كثيرة، فيُخدَم الزائر من أقربها إليه. وتعرض Cloudflare على صفحة شبكتها 19 مدينةً في الشرق الأوسط، منها الرياض وجدّة والدمّام ودبيّ والدوحة والكويت والمنامة ومسقط وعمّان وبيروت وبغداد.^[7] وليس في قائمتها مدينةٌ سوريّة، فزائرك في دمشق أو حلب يُخدَم من مدينةٍ مجاورة. وزائرك في أوروبا أو أمريكا الشماليّة يجد نقاطًا أكثر بكثير، ففي أمريكا الشماليّة وحدها 55 مدينةً بحسب الصفحة نفسها.

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

المرحلة الثالثة: الوزن، والصور أوّلًا

الصور غالبًا أثقل ما في الصفحة، وتحسينها أعلى الخطوات مردودًا بعد الخادم. ابدأ بالصيغة. يدعم ووردبريس منذ الإصدار 6.5 في 2024 صيغة AVIF، ويقول إعلان الإصدار إنّ صورها قد تكون أصغر من JPEG بنسبةٍ تصل إلى 50% بالجودة نفسها.^[8] وصيغة WebP خيارٌ ثانٍ أوسع دعمًا بين الأدوات. وأيًّا كانت الصيغة، حجّم الصورة إلى أكبر مقاسٍ ستُعرض به فعلًا قبل أن ترفعها، فصورةٌ بعرض أربعة آلاف نقطةٍ تُعرض في عمودٍ عرضه سبعمئة لا تفيد زائرك بشيء.

ثمّ التحميل المؤجّل. منذ الإصدار 5.5 يضيف ووردبريس إلى الصور خاصّيّةً تؤجّل تحميلها حتى يقترب منها الزائر، بشرط أن تحمل الصورة عرضها وارتفاعها.^[9] وهذا يوفّر تنزيل صورٍ في أسفل الصفحة قد لا يصل إليها الزائر أبدًا. لكنّ للتأجيل حدًّا: وجدت تجربةٌ نشرتها web.dev أنّ تأجيل الصور الظاهرة في أعلى الشاشة يؤخّر ظهور المحتوى الرئيسيّ، وأنّ ترك الصورة الأولى دون تأجيلٍ أسرع من تعطيل التأجيل كلّه.^[10] فأجّل ما تحت الشاشة، ولا تؤجّل الصورة الكبيرة التي يراها الزائر أوّلًا.

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

المرحلة الرابعة: العرض والاستجابة

بعد أن تصل الملفّات يبقى أن تظهر الصفحة ثابتةً وتستجيب. وأشهر سببٍ لاهتزاز الصفحة أثناء التحميل، بحسب web.dev، صورٌ بلا أبعاد: يرسم المتصفّح النصّ، ثمّ تصل الصورة فتدفعه إلى الأسفل. والعلاج أن تحمل كلّ صورةٍ عرضها وارتفاعها في شيفرتها، فيحجز المتصفّح مكانها قبل أن تصل.^[11] وتضيف الصفحة نفسها الإعلانات والإطارات المضمّنة بلا أبعاد، والخطوط التي تتبدّل بعد ظهور النصّ.

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

وكثيرٌ من هذه السكربتات ليس من موقعك أصلًا. يقول تقرير الأرشيف الشبكيّ لسنة 2025 إنّ ما بين 90% و92% من الصفحات تحمّل موارد من جهاتٍ خارجيّة: أدوات تحليل، وخطوطٌ من خوادم أخرى، ومقاطع فيديو مضمّنة، وأزرار دردشة، وإعلانات.^[12] وكلّ جهةٍ منها تعني اتّصالًا جديدًا بخادمٍ لا تتحكّم في سرعته. فراجع ما تحمّله صفحتك من الخارج، واسأل عن كلٍّ منه: هل أحتاجه في كلّ صفحة، أم في صفحةٍ واحدة؟

وأدوات «التصغير» و«الدمج» التي تقدّمها إضافات التسريع تفيد، لكنّها أرضٌ حسّاسة. قد يكسر دمج السكربتات أو تأجيلها وظيفةً مهمّةً في موقعك دون أن تلاحظ ذلك، كنموذج تواصلٍ لا يُرسل أو قائمةٍ لا تنفتح على الهاتف. ففعّل خياراتها واحدًا واحدًا، وجرّب بعد كلّ خيارٍ صفحاتك المهمّة، وأعد القياس. وإن احتجت أن تختار، فحذف سكربتٍ لا تحتاجه أنفع من ضغط عشرة تحتاجها.

الملفّات الثابتة: الضغط وذاكرة المتصفّح

الصور والخطوط وملفّات التنسيق والسكربتات لا تتغيّر بين زائرٍ وآخر، ولهذا تُعامل معاملةً خاصّة. أوّلها الضغط أثناء النقل: يضغط الخادم الملفّات النصّيّة قبل إرسالها بطريقةٍ مثل Brotli أو Gzip، ويفكّها المتصفّح عند وصولها. ويقول فصل شبكات التوزيع في تقرير الأرشيف الشبكيّ لسنة 2025 إنّ هذه الشبكات تطبّق الضغط وإصدارات البروتوكول الحديثة HTTP/2 وHTTP/3 قبل أن تصل إلى خوادم المواقع بسنوات.^[13] فموقعك يكسبها بمجرّد أن يمرّ عبر شبكة توزيع، ولو كان خادمه قديمًا.

وثانيها ذاكرة المتصفّح: أن يحتفظ متصفّح الزائر بالملفّات الثابتة بعد أوّل زيارة، فلا ينزّلها ثانيةً في الصفحة التالية. ويخبره الخادم بالمدّة في ترويسةٍ مع كلّ ملفّ، مثل هذه التي تسمح بحفظ الملفّ سنةً كاملة:

Cache-Control: public, max-age=31536000, immutable

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

كيف تقيس قبل أن تغيّر

أداة PageSpeed Insights من Google تعطيك نوعين من الأرقام، وخلطهما أشهر خطأٍ في قراءة تقاريرها. الأوّل بياناتٌ ميدانيّةٌ من زوّارٍ حقيقيّين يستعملون Chrome، تجمعها في تقريرٍ اسمه CrUX وتعرض فيها تجاربهم خلال الأيّام الثمانية والعشرين الماضية. والثاني بياناتٌ مخبريّة من محاكاةٍ واحدةٍ تجريها أداة Lighthouse. وتقول الوثائق إنّ البيانات المخبريّة مفيدةٌ للتشخيص، لكنّها قد لا تلتقط اختناقات العالم الحقيقيّ، وإنّ الميدانيّة هي التي تلتقط تجربة المستخدم الفعليّة.^[14]

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

وأداة مشرفي المواقع من Google تعرض الأرقام نفسها من زاويةٍ أوسع. تقرير مؤشّرات الويب الأساسيّة فيها يجمع صفحات موقعك في مجموعاتٍ متشابهة، ويصنّفها إلى جيّدةٍ وتحتاج تحسينًا وضعيفة، لكلّ مقياسٍ من الثلاثة، معتمدًا على بيانات الزوّار الحقيقيّين. وإن ظهرت لك رسالة غياب البيانات، فالسبب بحسب صفحة المساعدة أنّ الموقع جديدٌ في الأداة، أو أنّ تقرير CrUX لا يملك ما يكفي من بياناتٍ لذلك النوع من الأجهزة.^[15] وفائدة هذا التقرير أنّه يريك أيّ نوعٍ من صفحاتك بطيء، كصفحات المنتجات كلّها، فتعالج القالب الذي يجمعها مرّةً واحدة.

فقس الصفحات التي يزورها الناس فعلًا، لا الرئيسيّة وحدها: مقالك الأكثر قراءة، وصفحة المنتج الأكثر مبيعًا. وقس على الهاتف قبل الحاسوب، لأنّه الرقم الأصعب والأكثر تمثيلًا. ثمّ غيّر شيئًا واحدًا، وانتظر، وأعد القياس. البيانات الميدانيّة تتحرّك ببطء لأنّها تغطّي ثمانيةً وعشرين يومًا، فلا تحكم على تغييرٍ في يومه.

مثالٌ واحد، بالترتيب

لنأخذ مثالًا افتراضيًّا لمقالٍ على مدوّنة ووردبريس، يقول تقرير الزوّار الحقيقيّين فيه على الهاتف: الزمن حتى أوّل بايت 1.9 ثانية، وظهور المحتوى الرئيسيّ 4.2 ثانية، والاهتزاز 0.24. أوّل رقمٍ يستحقّ النظر هو الأوّل، لأنّه فوق حدّ الضعف الذي تضعه web.dev. فقبل أن يبدأ المتصفّح بتنزيل أيّ صورة، انقضت قرابة ثانيتين من الثانيتين والنصف المتاحتين كلّها.

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

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

أخطاء شائعة

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

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

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

جرّبه بنفسك

افتح PageSpeed Insights واكتب عنوان أكثر صفحةٍ يزورها الناس في موقعك، واختر الهاتف. انظر أوّلًا إلى قسم تجارب الزوّار الحقيقيّين إن ظهر، وسجّل الأرقام الثلاثة ومعها الزمن حتى أوّل بايت. ثمّ انزل إلى قائمة التشخيصات، وابحث فيها عن أكبر صورةٍ وعن الصور التي تنقصها الأبعاد.

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

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

خلاصة عمليّة

تقيس Google ثلاثة أشياء: ظهور المحتوى الرئيسيّ خلال ثانيتين ونصف، واستجابةً خلال 200 جزءٍ من الألف من الثانية، وثباتًا لا يتجاوز 0.1، عند ثلاثة أرباع زوّارك على الهاتف. وتأتي الصلة بالبحث قبل السرعة في ترتيبها. والوقت يضيع في أربع مراحل: المسافة، وتجهيز الخادم، والوزن، والعرض. فابدأ بالخادم والتخزين المؤقّت، ثمّ قرّب الموقع من جمهورك بشبكة توزيع، ثمّ خفّف الصور ولا تؤجّل الصورة الأولى، وأعطِ كلّ صورةٍ أبعادها، واحذف السكربتات التي لا تحتاجها. وقس دائمًا بالبيانات الميدانيّة، واترك الدرجة المخبريّة للتشخيص.

بهذا يكتمل ما تحتاج أن تعرفه عن الاستضافة من داخلها: أنواعها، وإدارتها، وتأمينها، وتسريعها. بقي أن تجمع هذا كلّه في قرارٍ واحد: أيّ استضافةٍ تختار لموقعك أنت، وما الأسئلة التي تكشف العرض الجيّد من الإعلان الجيّد. هذا موضوع المقال التالي: كيف تختار الاستضافة المناسبة.

المصادر

1. ‏HTTP Archive، «Web Almanac 2025: Page Weight» (بيانات يوليو 2025): نسبة النجاح في LCP على الهاتف 72% للصفحات الأخفّ، و59% للصفحات بين 2 و3 ميغابايت، و44% للصفحات من 5 ميغابايت فأكثر.
2. ‏web.dev، «Web Vitals» (قُرئت في 24 سبتمبر 2026): LCP خلال 2.5 ثانية، وINP بـ200 جزءٍ من الألف من الثانية أو أقلّ، وCLS بـ0.1 أو أقلّ، مقيسةً عند المئين 75 من تحميلات الصفحة للهاتف والحاسوب كلٌّ على حدة.
3. ‏web.dev، «Interaction to Next Paint is officially a Core Web Vital» (12 مارس 2024): INP مؤشّرٌ أساسيٌّ مستقرّ يحلّ محلّ First Input Delay.
4. ‏Google Search Central، «Understanding page experience in Google Search results» (قُرئت في 24 سبتمبر 2026): البحث يعرض المحتوى الأكثر صلةً حتى لو كانت تجربة الصفحة دون المستوى، والتجربة الجيّدة تساعد حين يكثر المحتوى المفيد.
5. ‏web.dev، «Time to First Byte (TTFB)» (قُرئت في 24 سبتمبر 2026): الجيّد 0.8 ثانية أو أقلّ، والضعيف أكثر من 1.8 ثانية، وليس من المؤشّرات الأساسيّة.
6. ‏Kinsta، «Data Center Locations» (حُدّثت في 2 فبراير 2026): 30 مركز بياناتٍ يُختار منها عند إنشاء الموقع، منها دبيّ والرياض، والتوصية باختيار الأقرب إلى الزوّار.
7. ‏Cloudflare، «Cloudflare Global Network» (قُرئت في 24 سبتمبر 2026): 19 مدينةً في الشرق الأوسط منها الرياض وجدّة والدمّام ودبيّ والدوحة والكويت والمنامة ومسقط وعمّان وبيروت وبغداد، و55 مدينةً في أمريكا الشماليّة.
8. ‏WordPress Core، «WordPress 6.5 adds AVIF support» (23 فبراير 2024): دعم AVIF، وصوره قد تصغر حتى 50% عن JPEG بالجودة نفسها.
9. ‏WordPress Core، «Lazy-loading images in 5.5» (14 يوليو 2020): التحميل المؤجّل افتراضيًّا بالخاصّيّة loading للصور التي تحمل width وheight.
10. ‏web.dev، «The performance effects of too much lazy loading» (قُرئت في 24 سبتمبر 2026): تأجيل الصور داخل الشاشة يؤخّر LCP، وترك الصورة الأولى دون تأجيلٍ أسرع حتى من تعطيل التأجيل كلّه.
11. ‏web.dev، «Optimize Cumulative Layout Shift» (قُرئت في 24 سبتمبر 2026): أشهر الأسباب صورٌ بلا أبعاد، وإعلاناتٌ وإطاراتٌ بلا أبعاد، ومحتوًى يُحقن لاحقًا، والخطوط؛ والعلاج width وheight أو aspect-ratio.
12. ‏HTTP Archive، «Web Almanac 2025: Third Parties» (بيانات 2025): ما بين 90% و92% من الصفحات تستعمل جهةً خارجيّةً واحدةً على الأقلّ.
13. ‏HTTP Archive، «Web Almanac 2025: CDN» (بيانات 2025): شبكات التوزيع تطبّق HTTP/2 وHTTP/3 وضغط Brotli وGzip قبل أن تعتمدها الخوادم الأصليّة بسنوات.
14. ‏Google، «About PageSpeed Insights» (قُرئت في 24 سبتمبر 2026): بياناتٌ ميدانيّة من CrUX خلال فترة الجمع السابقة البالغة 28 يومًا، وبياناتٌ مخبريّة من Lighthouse مفيدةٌ للتشخيص وقد لا تلتقط اختناقات الواقع.
15. ‏Google Search Console Help، «Core Web Vitals report» (قُرئت في 24 سبتمبر 2026): تجميع الصفحات بحسب الحالة والمقياس ومجموعات الصفحات المتشابهة من بيانات الاستعمال الحقيقيّ، و«لا بيانات متاحة» حين يكون الموقع جديدًا أو لا تكفي بيانات CrUX.