كيف تسرّع موقعك؟ الدليل الشامل لأداء أسرع

هذا الدليل مرجعي وشامل ويصلح لأي منصّة — ووردبريس، متجر مخصّص، تطبيق Next.js، أو صفحة HTML ثابتة — لأن مبادئ الأداء واحدة وإن اختلفت أدوات التنفيذ. سنرتّب كل شيء بحسب الأثر الفعلي حتى تعرف من أين تبدأ ومتى تتوقّف.

لماذا سرعة الموقع مهمّة فعلًا؟

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

التأثير يتركّز في ثلاثة محاور:

• معدّل الارتداد: كلّما زاد زمن التحميل ارتفع احتمال مغادرة الزائر قبل أن يرى المحتوى أصلًا. التدهور يتسارع بعد الثواني القليلة الأولى.
• معدّل التحويل: المتاجر والصفحات التي تجمع بيانات أو تبيع تتأثّر تحويلاتها سلبًا مع كل تأخير، لأن الاحتكاك يكسر نيّة الشراء.
• ترتيب البحث: Google يستخدم مؤشّرات تجربة الصفحة (Core Web Vitals) ضمن عوامل الترتيب، وسرعة الموقع تؤثّر في ميزانية الزحف وعدد الصفحات التي يفهرسها المحرّك يوميًا.

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

ما هي Core Web Vitals وما أهدافها؟

Core Web Vitals مجموعة مؤشّرات وضعتها Google لقياس تجربة المستخدم الحقيقية، لا الأداء المخبري فقط. ثلاثة مؤشّرات أساسية تحكم الحُكم على الصفحة:

• LCP (Largest Contentful Paint): الزمن حتى يُرسم أكبر عنصر مرئي في إطار الشاشة (غالبًا الصورة الرئيسية أو عنوان كبير). يقيس سرعة ظهور المحتوى الأهم.
• INP (Interaction to Next Paint): الزمن من تفاعل المستخدم (نقرة، كتابة) حتى يرى استجابة مرئية. حلّ محلّ FID وصار يقيس استجابة الصفحة عبر كامل الجلسة.
• CLS (Cumulative Layout Shift): مقدار «قفز» العناصر وتزحزحها أثناء التحميل. يقيس الثبات البصري.

المهمّ أن هذه الأهداف تُقاس على بيانات الميدان (المستخدمون الحقيقيون عبر تقرير تجربة Chrome) لا على بيانات المختبر فقط. قد يعطيك Lighthouse نتيجة ممتازة في بيئة مثالية بينما يعاني مستخدموك على شبكات وأجهزة أبطأ. لذا تابع دومًا قسم البيانات الميدانية في PageSpeed Insights، وهو ما يعتمده Google فعليًا.

كيف تقيس سرعة موقعك؟ المقاييس والأدوات

لا تحسّن ما لا تقيسه. القياس قبل أي تغيير يعطيك خطّ أساس، وبعده يثبت أن التحسين نجح فعلًا. أهمّ المقاييس التي تتابعها:

• TTFB (Time To First Byte): الزمن من إرسال الطلب حتى وصول أول بايت من الخادم. يعكس صحّة الاستضافة والكاش الخلفي. هدف جيّد: عادةً أقل من 200–500 مللي ثانية.
• FCP (First Contentful Paint): متى يظهر أول محتوى مرئي (نص أو صورة) على الشاشة.
• LCP: كما سبق، أكبر عنصر مرئي.
• TTI (Time To Interactive): متى تصبح الصفحة قابلة للتفاعل بثبات دون تأخير.

أدوات القياس الأساسية

قاعدة عملية في القياس

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

ترتيب الأثر: من أين تبدأ؟

الخطأ الأكبر هو البدء بالتحسينات الصغيرة (ضغط صورة هنا، تصغير سطر CSS هناك) قبل معالجة الأساس. التالي ترتيب تقريبي للأثر مقابل الجهد، يساعدك في تحديد الأولويات:

القاعدة: عالج الطبقات السفلية أوّلًا (الاستضافة والكاش)، لأن تحسينًا فيها يرفع كل الصفحات دفعة واحدة، بينما تحسين صفحة واحدة يبقى محصورًا فيها.

الاستضافة وTTFB: أساس كل شيء

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

• أقراص NVMe: أسرع بكثير من SSD التقليدي وأضعاف القرص الميكانيكي في قراءة الملفات وعمليات قاعدة البيانات.
• موارد كافية (CPU/RAM): الاستضافة المشتركة المزدحمة تتشارك الموارد مع مئات المواقع، فتتذبذب الاستجابة تحت الحمل. كلما زادت مواردك المخصّصة استقرّ TTFB.
• خادم ويب حديث: LiteSpeed أو Nginx يتفوّقان على Apache التقليدي في خدمة الطلبات المتزامنة وفي دمج الكاش. LiteSpeed تحديدًا يأتي مع كاش مدمج فعّال.
• موقع الخادم الجغرافي: كلما قرب الخادم من جمهورك قلّ زمن الرحلة. إن كان جمهورك في الخليج، فخادم في المنطقة أو قريب منها يقلّ زمن الاستجابة مقارنةً بخادم في قارة أخرى.
• HTTP/2 وHTTP/3: يسمحان بتعدّد الطلبات على اتصال واحد ويقلّلان زمن إنشاء الاتصال. HTTP/3 فوق QUIC يحسّن الأداء على الشبكات غير المستقرّة كالجوّال. تفعيلهما غالبًا مرتبط بـ HTTPS، فراجع دليل تركيب SSL وتفعيل HTTPS.

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

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

الكاش بطبقاته: لماذا هو أرخص تسريع؟

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

طبقات الكاش الرئيسية:

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

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

هذه الترويسة تخبر المتصفّح بأن يحتفظ بالملف سنة كاملة دون إعادة طلبه، وتُستخدم بأمان مع أسماء ملفات تحمل بصمة محتوى (versioned filenames). للتفاصيل الكاملة عن كل طبقة ومتى تستخدمها وكيف تبطل الكاش بأمان، راجع دليل الكاش بالتفصيل.

شبكة CDN: متى تحتاجها؟

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

تحتاج CDN خصوصًا عندما:

• جمهورك موزّع في دول أو قارّات متعدّدة.
• موقعك يحوي أصولًا ثقيلة (صور، فيديو، ملفات تنزيل).
• تريد حماية إضافية وتخفيف هجمات الحِمل وحجب الزحف الضارّ.

كثير من شبكات CDN تقدّم ميزات إضافية: ضغط تلقائي، تحويل الصور إلى تنسيقات حديثة، تصغير الأصول، وHTTP/3 على الحافة. لشرح آلية العمل والإعداد والمزايا بالتفصيل راجع دليل شبكة CDN. ملاحظة مهمّة: CDN يكمّل الاستضافة الجيّدة ولا يعوّض عن خادم أصل بطيء — لأن الطلبات الأولى وغير المخزّنة تعود للأصل.

كيف تحسّن الصور؟ أثقل عنصر في الصفحة

الصور غالبًا أكبر مساهم في وزن الصفحة، وهي عادةً عنصر LCP. تحسينها يعطي أحد أعلى العوائد. المحاور الأساسية:

• التنسيق الحديث: AVIF ثم WebP يقلّان الحجم بشكل كبير مقارنةً بـ JPEG/PNG عند جودة بصرية مماثلة.
• الأبعاد الصحيحة: لا تخدم صورة بعرض 4000 بكسل في حاوية عرضها 800 بكسل. صغّر الأبعاد للمقاس المعروض فعلًا.
• الضغط: خفض الجودة قليلًا (مثلًا 80–85%) يقلّل الحجم كثيرًا دون فرق مرئي يُذكر.
• التحميل الكسول (lazy loading): أجّل تحميل الصور خارج إطار الشاشة حتى يقترب منها الزائر بالتمرير.
• srcset والأحجام المتجاوبة: قدّم نسخًا بأحجام مختلفة ليختار المتصفّح الأنسب لكل شاشة.
• استثناء صورة LCP: لا تجعل الصورة الرئيسية (LCP) كسولة التحميل، بل حمّلها فورًا واستخدم preload لها لتسريع ظهورها.

مثال على تحميل مسبق لصورة LCP:

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />

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

كيف تحسّن الخطوط؟

الخطوط المخصّصة جميلة لكنها قد تؤخّر ظهور النص أو تسبّب قفزًا بصريًا. التحسينات الأساسية:

• Subset (تجزئة): أزل المحارف غير المستخدمة. خطّ عربي كامل ثقيل، فحمّل النطاق المطلوب فقط.
• preload للخطّ الحرج: حمّل خطّ النص الأساسي مسبقًا ليكون جاهزًا عند الرسم.
• font-display: swap: أظهر نصًا بخطّ بديل فورًا ثم بدّله بالخطّ المخصّص عند جاهزيته، بدل ترك النص غير مرئي.
• قلّل عدد الأوزان: كل وزن (regular، bold، إلخ) ملف إضافي. اكتفِ بالأوزان التي تستخدمها فعلًا.
• استضف الخطوط محليًا: خدمتها من نطاقك تتجنّب اتصال نطاق خارجي إضافي.

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont-subset.woff2") format("woff2");
  font-display: swap;
  font-weight: 400;
}

استخدم تنسيق woff2 فهو الأكثر كفاءة وضغطًا ومدعوم على نطاق واسع.

تقليل JavaScript وCSS

JavaScript أثقل مورد على المعالج، وهو السبب الأشيع لضعف INP وتأخّر التفاعل. الصفحة قد تظهر بسرعة لكنها لا تستجيب لأن المتصفّح مشغول بتنفيذ سكربتات. المحاور:

• التصغير (minify): أزل المسافات والتعليقات من JS وCSS لتقليل الحجم.
• defer وasync: أجّل تنفيذ السكربتات غير الحرجة حتى لا تحجب رسم الصفحة. استخدم defer لما يحتاج ترتيبًا، وasync للمستقلّ.
• إزالة غير المستخدم: احذف المكتبات والإضافات التي لا تستعملها. كل سكربت إضافي تكلفة.
• تقسيم الكود (code splitting): حمّل كود كل صفحة عند الحاجة بدل حزمة عملاقة واحدة لكل الموقع.
• Critical CSS: استخرج CSS اللازم للجزء الظاهر أوّلًا وضعّه مضمّنًا، وأجّل بقيّة CSS.

<!-- سكربت غير حرج يُؤجَّل حتى لا يحجب الرسم -->
<script src="/analytics.js" defer></script>

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

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

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

تقليل عدد الطلبات وأحجامها

كل ملف على صفحتك طلب منفصل وله تكلفة. تقليل عدد الطلبات وحجمها يحسّن السرعة، خصوصًا على الشبكات البطيئة.

• ضغط النقل (Brotli/Gzip): فعّل ضغط الاستجابات النصّية. Brotli أكفأ من Gzip غالبًا، وكلاهما يقلّ حجم HTML/CSS/JS بقدر كبير عبر الشبكة.
• الدمج عند اللزوم: مع HTTP/1.1 كان دمج الملفات مفيدًا لتقليل الطلبات. مع HTTP/2 وHTTP/3 يقلّ هذا الإلحاح لأن الطلبات تتعدّد على اتصال واحد، فلا تبالغ في الدمج.
• أزل الموارد غير الضرورية: كل أيقونة أو خطّ أو سكربت لا يُستعمل يُحذف.

تحقّق أن الضغط مفعّل عبر ترويسة الاستجابة:

Content-Encoding: br

إن لم تجد br أو gzip، فالضغط غير مفعّل — وهو من أسهل المكاسب وأسرعها.

قاعدة البيانات والاستعلامات

المواقع الديناميكية (ووردبريس، المتاجر، التطبيقات) تبني صفحاتها من قاعدة بيانات. استعلام بطيء أو جدول منتفخ يرفع TTFB حتى مع استضافة جيّدة. المحاور:

• كاش الكائنات: خزّن نتائج الاستعلامات المتكرّرة في Redis أو Memcached لتجنّب ضرب قاعدة البيانات في كل طلب.
• الفهارس (Indexes): أضف فهارس على الأعمدة المستعلَمة كثيرًا لتسريع البحث.
• تنظيف البيانات المنتفخة: احذف المراجعات القديمة والبيانات المؤقّتة والسجلّات المهملة التي تثقل الجداول.
• حدّد الاستعلامات الثقيلة: استخدم أدوات تحديد الاستعلامات البطيئة لمعرفة أين يضيع الوقت.

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

الموبايل أولًا

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

ركائز أداء الجوال:

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

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

سيناريو واقعي: جدول قبل/بعد

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

الملاحظة الجوهرية: لم يأتِ التحسّن من إجراء واحد سحري، بل من معالجة الطبقات بالترتيب — الاستضافة والكاش أوّلًا (أثر شامل)، ثم الأصول الأمامية. هذا هو المنهج الصحيح.

أخطاء شائعة

تجنّب هذه الأخطاء المتكرّرة التي تُفشل جهود التسريع أو تُضيّع الوقت:

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

تشخيص ومعالجة المشكلات

عندما يفشل مؤشّر معيّن، ابدأ من العَرَض وارجع للسبب. التالي دليل تشخيص مرتّب حسب المؤشّر:

LCP بطيء

أسباب شائعة: TTFB مرتفع، صورة رئيسية ثقيلة أو غير محسّنة، مورد حاجب للرسم (CSS/خطّ)، أو غياب التحميل المسبق.

CLS مرتفع

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

INP ضعيف

أسباب شائعة: تنفيذ JavaScript طويل يحجب الخيط الرئيسي، معالِجات أحداث ثقيلة، سكربتات طرف ثالث مرهِقة.

TTFB مرتفع رغم الكاش

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

الخلاصة

تسريع الموقع منهج مرتّب لا مجموعة حِيَل متفرّقة. ابدأ من الأساس: استضافة بزمن استجابة منخفض، ثم طبّق الكاش بكل طبقاته لأنه أرخص تسريع وأعلاه أثرًا، ثم وزّع المحتوى بـ CDN إن كان جمهورك متفرّقًا. بعدها عالج أثقل ما على الصفحة — الصور أوّلًا، ثم الخطوط وJavaScript وCSS — وأنهِ بتحسين قاعدة البيانات للأجزاء الديناميكية. قِس قبل وبعد بأدوات موضوعية، واحكُم بالنهاية على بيانات المستخدمين الحقيقيين عبر Core Web Vitals لا على نتيجة مختبرية معزولة. خصّص جهدًا أكبر لظروف الجوال لأنها الأقسى وهي ما يعيشه أغلب زوّارك. وتذكّر القاعدة الذهبية: تحسين واحد في الطبقة الصحيحة يفوق عشرات التحسينات في الطبقة الخطأ.

أهمّ خطوة عملية الآن: قِس موقعك في PageSpeed Insights، حدّد المؤشّر الأضعف، وعالجه من جذره وفق ترتيب الأثر في هذا الدليل.

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

الأسئلة الشائعة

كم تحتاج سرعة الصفحة فعليًا؟

استهدف تمرير Core Web Vitals: LCP تحت 2.5 ثانية، INP تحت 200 مللي ثانية، وCLS تحت 0.1، مقاسة على بيانات المستخدمين الحقيقيين. هذه ليست أرقامًا تعسفية بل عتبات يعتمدها Google لتقييم تجربة الصفحة. ما دون ذلك يكفي، والمبالغة فوق المطلوب عائدها يتناقص.

ما الفرق بين بيانات المختبر وبيانات الميدان؟

بيانات المختبر تُقاس في بيئة مضبوطة واحدة (مثل Lighthouse)، بينما بيانات الميدان تأتي من زيارات مستخدمين حقيقيين بأجهزة وشبكات متنوّعة عبر تقرير تجربة Chrome. Google يعتمد بيانات الميدان في تقييم الترتيب، لذا قد تكون نتيجتك المختبرية ممتازة بينما يعاني مستخدموك فعلًا. تابع الاثنين، لكن احكم بالميدان.

هل CDN يكفي لتسريع موقع بطيء؟

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

أيّ تنسيق صور أستخدم في 2026؟

استخدم AVIF كخيار أوّل لأفضل ضغط، مع WebP كبديل، وأبقِ JPEG/PNG كحلّ احتياطي للتوافق القديم. معظم أدوات وإضافات تحسين الصور تولّد هذه التنسيقات تلقائيًا وتقدّم الأنسب لكل متصفّح. المهمّ أيضًا الأبعاد الصحيحة والضغط، لا التنسيق وحده.

هل أحتاج VPS لأجعل موقعي سريعًا؟

ليس دائمًا. كثير من المواقع تكفيها استضافة مشتركة جيّدة (NVMe + LiteSpeed + كاش). لكن مع حركة عالية أو معالجة ثقيلة أو متجر نشط، تصبح موارد VPS المخصّصة فارقًا حقيقيًا لاستقرار TTFB. القاعدة: رقِّ عندما تصطدم بحدود الموارد لا قبلها.

لماذا موقعي بطيء رغم تثبيت إضافة تسريع؟

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

ما أثر سكربتات الطرف الثالث على السرعة؟

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

هل أحسّن للجوال أم لسطح المكتب أولًا؟

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

كم مرّة أقيس أداء موقعي؟

قِس عند كل تغيير جوهري (تحديث قالب، إضافة جديدة، تغيير استضافة) وبشكل دوري شهريًا على الأقل، لأن الأداء يتدهور بصمت مع تراكم المحتوى والإضافات. راقب بيانات الميدان في Search Console باستمرار، فهي تنبّهك مبكرًا قبل أن يتأثّر ترتيبك.