الأداء 27 فبراير 2026 2 دقائق للقراءة

لماذا يبدو موقعك بطيئاً؟ (وكيف تحل المشكلة فعلاً)

بطء تحميل موقعك عادةً ما ينبع من مجموعة مشاكل قابلة للإصلاح. إليك كيفية إيجادها وقياسها وإصلاحها بالترتيب الصحيح.

صفحتك الرئيسية تُحمَّل في 4.2 ثوانٍ. سمعت أن هذا سيء، لكنك لا تعرف من أين تبدأ. تُجري اختبار سرعة، تحصل على نتيجة 58، وتجد أمامك قائمة توصيات تبدو كأنها بلغة أجنبية.

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

ابدأ بالقياس، لا بالتخمين

قبل أن تلمس أي ملف، قِس أولاً. أنت تحتاج إلى بيانات حقيقية، ليس إلى حدس.

استخدم هذه الأدوات للحصول على صورة واضحة:

  • Google PageSpeed Insights — يمنحك نتائج Core Web Vitals من مستخدمي Chrome الحقيقيين إضافةً إلى بيانات المختبر
  • GTmetrix — يعرض شلالاً لكل مورد تُحمِّله صفحتك ومدة كل منه
  • WebPageTest — يتيح لك الاختبار من مواقع جغرافية وأنواع اتصال محددة
  • Lighthouse — مدمج في Chrome DevTools، ممتاز للتكرار المحلي

أجرِ الاختبارات من مواقع متعددة. موقع يُحمَّل في 1.2 ثانية في تل أبيب قد يستغرق 3.8 ثوانٍ في لوس أنجلوس إذا كان خادمك في أوروبا بدون شبكة CDN أمامه.

فهم Core Web Vitals

تستخدم Google ثلاثة مقاييس Core Web Vitals كإشارات ترتيب. هذه ليست مقاييس شكلية — بل تعكس مباشرةً تجربة زوارك على موقعك.

أكبر رسم محتوى (LCP)

يقيس LCP المدة التي يستغرقها تحميل أكبر عنصر مرئي. عادةً ما يكون صورة رئيسية، أو عنواناً كبيراً، أو صورة مصغرة لفيديو. هدفك هو أقل من 2.5 ثانية.

أكبر مُعيقات LCP:

  • الصور الرئيسية غير المحسَّنة (صورة JPEG بحجم 2 ميغابايت هي كارثة حقيقية)
  • CSS أو JavaScript يعيق التصيير فوق الطيّة
  • أوقات استجابة بطيئة من الخادم (TTFB أعلى من 600ms)
  • لا توجد CDN لخدمة الأصول قريباً من المستخدم

التفاعل حتى الرسم التالي (INP)

حلّ INP محل First Input Delay ويقيس كامل زمن الاستجابة لتفاعلات المستخدم — النقرات، واللمس، وإدخال لوحة المفاتيح. الهدف: أقل من 200ms. مهام JavaScript الطويلة على الخيط الرئيسي هي السبب الأول هنا.

التحوّل التراكمي للتخطيط (CLS)

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

أصلح CLS بتحديد سمتي width وheight دائماً على الصور، واستخدام font-display: optional أو font-display: swap بعناية.

تحسين الصور: أكبر مكسب ربما تفوّتك

الصور تمثّل عادةً 50–70% من الحجم الإجمالي للصفحة. هنا تملك معظم المواقع أكبر مجال للتحسين.

استخدم الصيغ الحديثة

يوفر WebP حجم ملف أصغر بنحو 25–35% من JPEG بجودة مكافئة. أما AVIF فيذهب أبعد من ذلك — أصغر بنسبة 50% من JPEG في كثير من الحالات. قدّمها مع بديل احتياطي:

<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="Hero image" width="1200" height="600"> </picture>

حمّل الصور خارج نطاق الرؤية بشكل كسول

لا تحمّل الصور التي لا يراها المستخدم بعد. سمة loading="lazy" الأصلية تعمل في جميع المتصفحات الحديثة ولا تحتاج إلى أي JavaScript:

<img src="product.webp" alt="Product photo" loading="lazy" width="800" height="600">

لا تُطبّق التحميل الكسول على صورة LCP. هذا سيضر بنتيجتك لا يساعدها.

اضغط دون إتلاف الجودة

أدوات مثل Squoosh وSharp (لخطوط أنابيب Node.js) وImagick (لـ PHP) تتيح لك الضغط بقوة مع الحفاظ على جودة بصرية عالية. استهدف جودة 80–85% على JPEG/WebP. معظم المستخدمين لا يلاحظون الفرق، لكن الفرق في حجم الملف يكون كبيراً.

التخزين المؤقت: الاستراتيجية التي تضاعف كل تحسين آخر

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

التخزين المؤقت على جانب الخادم

بالنسبة لمواقع WordPress والمواقع القائمة على PHP، يحفظ التخزين المؤقت للصفحة الكاملة HTML المُصيَّرة حتى لا يعمل PHP وMySQL في كل طلب. أدوات مثل Redis Object Cache تخزن نتائج استعلامات قاعدة البيانات في الذاكرة، لتستغرق عمليات البحث المتكررة ميكروثوانٍ بدلاً من ميلي ثوانٍ.

في Proginter، التخزين المؤقت على جانب الخادم مدمج في اللوحة. يمكنك تفعيله بنقرة واحدة ومشاهدة Time to First Byte ينخفض من 800ms إلى أقل من 100ms على الصفحات المخزنة مؤقتاً.

التخزين المؤقت في المتصفح

أخبر المتصفحات بالاحتفاظ بالأصول الثابتة — الصور وCSS والخطوط وJavaScript — حتى لا يضطر الزوار العائدون إلى تنزيلها مجدداً. اضبط ذلك عبر HTTP headers:

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

استخدم هذا للأصول ذات الإصدارات (أي شيء يحتوي على hash في اسم الملف). بالنسبة لـ HTML، استخدم أوقات تخزين مؤقت أقصر أو no-cache حتى تظهر التغييرات فوراً.

التخزين المؤقت عبر CDN

تخزّن شبكة توصيل المحتوى (CDN) نسخاً من أصولك الثابتة في عقد حافة حول العالم. مستخدم في ساو باولو يحصل على صورك من خادم في البرازيل، لا من خادمك الأصلي في فرانكفورت. ينخفض زمن الاستجابة من 180ms إلى 12ms لذلك الأصل.

شبكات CDN ضرورة لا تنازل عنها إذا كان لديك زيارات دولية. معظم مزودي الاستضافة المُدارة، بما في ذلك Proginter، يتضمنون تكاملاً مع CDN في خططهم.

أداء PHP وقاعدة البيانات

بطء وقت استجابة الخادم غالباً ما يكون مشكلة PHP أو قاعدة بيانات، ليس مشكلة شبكة.

أداء PHP

بعض المكاسب السريعة التي لها تأثير حقيقي:

  • فعّل OPcache — يُترجم PHP النصوص البرمجية إلى bytecode ويخزنها في الذاكرة. هذا وحده يمكنه تقليل وقت تنفيذ PHP بنسبة 40–60%.
  • استخدم PHP 8.2 أو أحدث — كل إصدار رئيسي يجلب تحسينات سرعة ملموسة. PHP 8.x أسرع بكثير من 7.x.
  • تجنب الإضافات غير الضرورية — في WordPress، كل إضافة نشطة تضيف عبئاً على تنفيذ PHP. راجع إضافاتك بانتظام.

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

استعلام واحد غير مُفهرَس على جدول كبير يمكنه إضافة مئات الميلي ثوانٍ إلى تحميل الصفحة. استخدم سجل الاستعلامات البطيئة لتحديد أسوأ المشكلات:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;

ثم أضف فهارس على الأعمدة التي تُصفّي أو تُرتّب بها بشكل متكرر. في WordPress، جدول wp_postmeta يُعدّ عنق زجاجة شائعاً — تأكد من فهرسة meta_key، وهو مُفهرَس افتراضياً، لكن الاستعلامات المخصصة ضده غالباً لا تكون كذلك.

طبقة البنية التحتية: تخزين NVMe وموارد الخادم

تحسينات البرمجيات تهم أقل عندما يكون الحديد الذي تعمل عليه بطيئاً. أقراص NVMe SSD تقرأ وتكتب البيانات بسرعة أعلى بـ5–7 أضعاف مقارنةً بأقراص SATA SSD التقليدية. بالنسبة للمواقع المعتمدة على قواعد البيانات، يُترجم هذا مباشرةً إلى تنفيذ أسرع للاستعلامات وانخفاض في TTFB.

راقب استخدام موارد خادمك بأدوات مثل htop وNetdata أو مقاييس لوحة الاستضافة المدمجة. انتبه إلى:

  • استخدام CPU يتجاوز 70% باستمرار — قد تحتاج إلى التحسين أو التوسيع
  • استخدام الذاكرة يقترب من الحدود — سيبدأ عمال PHP-FPM في وضع الطلبات في قائمة انتظار
  • أوقات انتظار Disk I/O فوق 5% — علامة على أن الاستعلامات أو عمليات الملفات تُشكّل عنق زجاجة

اختبار الحمل قبل أن تحتاجه

لا تنتظر حتى تحدث طفرة في الزيارات لتكتشف أن خادمك ينهار تحت الضغط. اختبره مسبقاً.

k6 وLocust أدوات مفتوحة المصدر ممتازة لمحاكاة المستخدمين المتزامنين. اختبار k6 أساسي يرتفع إلى 200 مستخدم افتراضي خلال 30 ثانية لا يحتاج سوى 10 أسطر من JavaScript وسيخبرك بالضبط أين يتعطل موقعك.

أجرِ اختبارات الحمل على بيئة التطوير، ليس على الإنتاج. في Proginter، كل خطة تتضمن بيئة تطوير مرحلية لهذا السبب بالذات.

تجميع الأمور معاً

أداء الويب ليس شيئاً واحداً تُصلحه — بل هو مجموعة قرارات متراكمة. الترتيب مهم:

  1. قِس أولاً. اعرف نقطة انطلاقك.
  2. أصلح TTFB — التخزين المؤقت للخادم، وتحسين PHP، وتخزين NVMe.
  3. حسّن الصور — الصيغة، والضغط، والأبعاد، والتحميل الكسول.
  4. أعدّ CDN والتخزين المؤقت في المتصفح.
  5. عالج مشاكل Core Web Vitals تحديداً — LCP وINP وCLS لكل منها إصلاحات مختلفة.
  6. اختبر الحمل قبل أحداث الزيارات الكبرى.

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

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