تسريع مواقع ووردبريس: الدليل العملي الشامل
افتح موقعك على موبايلك دلوقتي وعِدّ معايا: واحد، اتنين، تلاتة. لو الصفحة لسه بتحمّل بعد 3 ثواني، فأنت بتخسر زوار قبل ما يقرأوا أول سطر في مقالك. الدليل ده مش نظريات — ده خطة مرتبة بالأولوية: تقيس، تفهم الأرقام، تطبّق، وتقيس تاني.
خليني أكون صريح معاك من أول سطر: أغلب مقالات “تسريع ووردبريس” عبارة عن قائمة إضافات مرصوصة ورا بعض من غير ترتيب ولا منطق. النتيجة؟ حد يركّب 4 إضافات كاش مع بعض وموقعه يبقى أبطأ من الأول. المشكلة إن السرعة مش إضافة سحرية — السرعة نظام: قياس، ثم أهم سبب، ثم اللي بعده. وهنا بقى الفرق بين اللي بيحسّن بجد واللي بيجرّب حظه.
الدليل ده مبني على ترتيب واحد بسيط: الأكبر تأثيرًا والأسهل تنفيذًا أولًا. كل خطوة فيها: إيه اللي هتعمله، ليه، وإزاي تتأكد إنه اشتغل. وفي الآخر هتلاقي مصادر موثقة فعليًا — روابط مباشرة اتفتحت واتأكدت، مش أسماء مرصوصة من الذاكرة.
ليه سرعة موقعك قرار تجاري مش تقني
ناس كتير بتتعامل مع السرعة كـ “تحسين تقني لطيف لو فضينا”. الحقيقة إنها فلوس مباشرة. الزائر اللي بيفتح مقالك من إعلان أو من بحث جوجل عنده صبر محدود جدًا — وكل ثانية تأخير بتقلل احتمال إنه يكمل قراءة، أو يضغط على إعلان، أو يشتري.
الرقم اللي يستاهل تقف عنده: 57% من المستهلكين بيسيبوا موقع بياخد أكتر من 3 ثواني عشان يفتح — وده حسب صفحة WP Rocket الرسمية. يعني لو موقعك بيفتح في 5 ثواني، فأكتر من نص زوارك المحتملين مشيوا قبل ما يشوفوا المحتوى أصلًا. مش “تجربة مستخدم سيئة” — ده نزيف زوار.
وجوجل نفسها دخلت على الخط: مقاييس Core Web Vitals بقت جزء من إشارات تجربة الصفحة اللي بتظهر في كل أدوات جوجل، وليها تقرير مخصص في Search Console. يعني السرعة مش بس بتأثر على الزائر اللي وصل — بتأثر على عدد الزوار اللي هيوصلوا أصلًا من البحث.
الموبايل أولًا — مش شعار
أغلب جمهورك بيفتح من الموبايل، والموبايل معناه معالج أضعف وشبكة أبطأ وباقة محدودة. الصفحة اللي “بتفتح بسرعة” على لابتوبك المتصل بالواي فاي ممكن تاخد 3 أضعاف الوقت على موبايل متوسط بباقة عادية. عشان كده كل قياس في الدليل ده يبدأ من نسخة الموبايل — لو الموبايل أخضر، الديسكتوب هيبقى أخضر لوحده في الغالب. والعكس مش صحيح.
المعادلة ببساطة
- زائر أسرع وصولًا = وقت أطول في الصفحة = مشاهدات إعلانات أكتر = أرباح أعلى.
- موقع أسرع = تقييم أفضل في أدوات جوجل = فرصة ظهور أحسن في البحث.
- صفحة خفيفة = استهلاك أقل لموارد الاستضافة = موقع يتحمّل زوار أكتر على نفس الباقة.
طيب، نبدأ منين؟ من القياس. مش من الإضافات.
قِس الأول: القياس قبل أي تحسين
أهم جملة في الدليل كله: من غير رقم قبل ورقم بعد، أنت بتخمن مش بتحسّن. ناس كتير بتركّب إضافات وتقول “حاسس الموقع بقى أسرع” — الإحساس مش مقياس. اللي بيفرق المحترف عن الهاوي إنه بيسجّل أرقامًا ويقارن.
الأدوات الثلاثة اللي هتحتاجها
1. PageSpeed Insights: أداة جوجل الرسمية والمجانية. ميزتها إنها بتديك نوعين من البيانات: بيانات المعمل (اختبار لحظي لصفحتك) وبيانات الميدان (أرقام حقيقية من زوار فعليين عبر تقرير تجربة مستخدمي كروم، لو موقعك عليه زيارات كافية). اختبر نسختي الموبايل والديسكتوب منفصلين — الموبايل هو اللي يهم جمهورك.
2. GTmetrix: قوته في الـ Waterfall — شريط زمني بيوريك كل ملف اتحمّل إمتى واخد وقت قد إيه. ده اللي بيجاوب على سؤال “إيه اللي مبطّأ موقعي بالظبط؟” — صورة معينة؟ سكريبت؟ السيرفر نفسه بطيء في الرد؟ من غير الـ Waterfall أنت بتضرب في الضلمة.
3. WebPageTest: الأعمق والأدق للتشخيص. بيديك تفاصيل زي زمن أول بايت من السيرفر (TTFB) وإمكانية الاختبار من أماكن مختلفة. لما تكون محتاج تفهم مش تحس، ده مكانك.
سجّل الأرقام دي في ملف بسيط — حتى لو في نوت على موبايلك. بعد كل خطوة من خطوات الخطة الجاية، ارجع قِس نفس الصفحات وقارن. التحسين اللي مش باين في الأرقام = تحسين وهمي.
Core Web Vitals بالعربي المبسّط
جوجل اختصرت “تجربة المستخدم” في 3 مقاييس أساسية. مش لازم تبقى خبير — لازم تفهم كل واحد بيقيس إيه عشان تعرف تصلّحه:
LCP — أكبر عنصر مرئي (الهدف: 2.5 ثانية أو أقل)
بيقيس إمتى أكبر حاجة شايفها الزائر بتظهر — غالبًا صورة الهيرو أو عنوان المقالة الرئيسي. لو صورة الهيرو بتاعتك 2 ميجا وبتتحمّل متأخر، الـ LCP بتاعك هيبقى وحش مهما عملت. إصلاحه = صورة أخف + تحميل مبكر للعنصر المهم.
INP — سرعة الاستجابة للتفاعل (الهدف: 200 مللي ثانية أو أقل)
بيقيس الزمن بين ما الزائر يدوس على حاجة والصفحة تستجيب — ضغطة زر، فتح قائمة. الجافاسكريبت التقيل هو القاتل الأول هنا: سكريبتات كتير شغالة في الخلفية بتخلي المتصفح مشغول ومش قادر يرد على الزائر بسرعة. إصلاحه = تقليل وتأجيل الجافاسكريبت غير الضروري.
CLS — ثبات التخطيط (الهدف: 0.1 أو أقل)
بيقيس حركة العناصر المفاجئة أثناء التحميل — الصورة اللي بتظهر فجأة وتزق النص لتحت، أو الإعلان اللي بيظهر ويحرّك المحتوى. أكتر حاجة بتغيظ الزائر: ييجي يدوس على زر فيتحرك مكانه ويدوس على حاجة تانية. إصلاحه = أبعاد صريحة للصور + مساحة محجوزة للإعلانات.
مقياسان تشخيصيان لازم تعرفهم
TTFB (زمن أول بايت): المدة بين طلب الصفحة وأول رد من السيرفر. لو عالي، المشكلة في الاستضافة نفسها — ولا إضافة في الدنيا هتصلح سيرفر بطيء. FCP (أول رسم للمحتوى): إمتى أول حاجة ظهرت على الشاشة. لو متأخر، يبقى فيه ملفات CSS أو JS بتحجب العرض.
إزاي تقرأ تقرير PageSpeed زي المحترفين
أغلب الناس بتفتح PageSpeed Insights، تبص على الرقم الكبير الملوّن (الأداء من 100)، وتقفل الصفحة محبطة أو مبسوطة. الرقم ده آخر حاجة تبص عليها. التقرير فيه 3 مناطق أهم منه بكتير:
المنطقة الأولى: بيانات الميدان (Field Data)
دي أرقام زوار حقيقيين لموقعك من تقرير تجربة مستخدمي كروم — مش اختبار معملي. لو متاحة لموقعك، فهي الحكم الحقيقي: جوجل بتقيّم موقعك على أساسها مش على أساس الاختبار اللحظي. لو بيانات الميدان خضراء والمعمل أحمر، موقعك في الحقيقة كويس — المشكلة في ظروف الاختبار مش في موقعك.
المنطقة الثانية: الفرص (Opportunities)
قائمة مرتبة حسب حجم التوفير المتوقع — كل عنصر جنبه “وفّر X ثانية”. ابدأ من فوق لتحت: أول 3 فرص هم 80% من التحسين. تجاهل أي فرصة توفيرها أقل من 0.2 ثانية في الأول — دي تفاصيل لمرحلة التلميع مش البداية.
المنطقة الثالثة: التشخيصات (Diagnostics)
معلومات إضافية عن صحة الصفحة: عدد الطلبات، حجم الملفات، سلاسل الطلبات الحرجة. دي اللي بتجاوب على “ليه” — ليه الـ LCP عالي؟ التشخيص هيقولك: عشان فيه 4 ملفات CSS بتحجب العرض قبل الصورة.
وطبّق نفس المنطق على GTmetrix: الـ Grade الإجمالي أقل أهمية من الـ Waterfall. شوف أطول شريط في الـ Waterfall — ده الملف اللي سارق وقتك. لو الشريط الأول (الـ HTML نفسه) هو الأطول، المشكلة في السيرفر (TTFB). لو صورة معينة واخدة ثانيتين، المشكلة في الصور. التشخيص الصح = نصف العلاج.
خطة التسريع المرتبة: 10 خطوات بالترتيب الصح
دي الخطة. بالترتيب. متبدأش من الخطوة 5 قبل ما تخلّص 1 و2 و3 — كل خطوة بتبني على اللي قبلها، والترتيب ده متعمّد: الأكبر تأثيرًا والأسهل تنفيذًا أولًا.
1 الاستضافة ونسخة PHP: الأساس قبل كل حاجة
لو الـ TTFB بتاعك فوق ثانية كاملة، فالمشكلة في الاستضافة قبل أي إضافة. ولا كاش ولا ضغط صور هيعوّض سيرفر بطيء — الكاش بيخزّن صفحة جاهزة، لكن أول زيارة (وتحديث الكاش) لسه بتمر على السيرفر.
خطوتان عمليتان: أولًا، تأكد إن موقعك شغال على نسخة PHP حديثة (8.x) — الفرق في السرعة بين النسخ القديمة والحديثة ضخم، والتحديث غالبًا بضغطة واحدة من لوحة الاستضافة. ثانيًا، لو موقعك كبر والاستضافة المشتركة بقت خانقاه، الترقية لخطة أعلى أو استضافة متخصصة في ووردبريس استثمار مش مصروف. لو لسه بتبني موقعك من الصفر وعاوز تختار صح من الأول، راجع دليل تطوير مواقع ووردبريس الكامل — فيه معايير اختيار الاستضافة بالتفصيل.
2 قالب خفيف: اختار سلاحك صح
القالب هو أكبر ملف ثابت بيتحمّل مع كل صفحة. القوالب متعددة الأغراض اللي فيها 40 ديمو و200 عنصر بتحمّل أطنانًا من CSS وJS أنت مش مستخدم 90% منهم. القاعدة: قالب خفيف + اللي ناقصك ضيفه بإضافة واحدة، مش قالب تقيل وتحاول تخففه.
أسماء مجرّبة وخفيفة: Astra وGeneratePress وKadence وBlocksy — كلها مجانية بأساس قوي ودعم مستمر. جرّب القالب على PageSpeed قبل ما تستقر عليه: لو النسخة التجريبية نفسها بطيئة، متتوقعش معجزات بعد التركيب.
3 إضافة كاش واحدة — واحدة بس
الكاش هو أكبر قفزة سرعة هتشوفها في حياتك: بدل ما ووردبريس ينفّذ PHP ويستعلم من قاعدة البيانات مع كل زيارة، بيقدّم نسخة HTML جاهزة. الفرق بيكون من ثواني لأجزاء من الثانية.
القاعدة المقدسة: إضافة كاش واحدة فقط. إضافتين كاش مع بعض مش “احتياط” — ده تعارض مضمون وكسر للموقع. اختار واحدة من المقارنة في القسم الجاي والتزم بيها. ولو استضافتك شغالة على LiteSpeed، فـ LiteSpeed Cache المجانية بتديك كاش على مستوى السيرفر نفسه — أسرع من أي كاش على مستوى PHP.
4 الصور: الملف الأثقل اللي محدش واخد باله منه
في أغلب مواقع ووردبريس، الصور هي أكبر مكوّن في حجم الصفحة. صورة واحدة مرفوعة بمقاس الكاميرا الأصلي (4000 بكسل) عشان تتعرض بعرض 800 بكسل = ميجابايتات بتتحمّل على الفاضي، وكل زائر موبايل بيدفع تمنها من باقته ووقته.
العلاج في 4 حركات: ارفع بالمقاس الصح من الأول، حوّل لـ WebP أو AVIF (أصغر بكتير من JPG بنفس الجودة)، فعّل الضغط التلقائي، وخلّي التحميل الكسول (lazy load) شغال لكل الصور اللي تحت الطية. التفاصيل الكاملة في قسم الصور تحت.
5 CSS وJS: نظّف ما يُعرض أولًا
المتصفح مش بيرسم الصفحة لحد ما يخلّص ملفات CSS وJS اللي بتحجب العرض (render-blocking). الحل مش حذفها — الحل ترتيبها: أجّل الجافاسكريبت غير الضروري لما بعد التحميل، وصغّر وادمج ملفات CSS وJS، واستخرج الـ Critical CSS (الأنماط اللازمة لأول شاشة بس) وحمّلها أولًا والباقي بعدين.
إضافة Autoptimize المجانية بتعمل ده كله من واجهة واحدة — بس فعّل الخيارات واحدة واحدة واختبر موقعك بعد كل واحدة، لأن دمج الجافاسكريبت أحيانًا بيكسر عناصر تفاعلية لو فيه سكريبت حساس للترتيب.
6 الخطوط: الضيف التقيل اللي محدش عزمه
خطوط جوجل من الـ CDN معناها طلبات خارجية إضافية لكل زائر — ولو حمّلت 6 أوزان من الخط “احتياطًا” فأنت بتحمّل 6 ملفات عشان تستخدم اتنين. القواعد: حمّل الخطوط محليًا على سيرفرك بدل الـ CDN، استخدم وزنين بس (عادي وعريض)، واعمل preload لملف الخط الأساسي عشان المتصفح يجيبه أولًا. ولو خطك بيدعم font-display: swap فعّله — النص يظهر بخط بديل فورًا ويتبدّل لما الخط الأصلي يوصل، بدل شاشة فاضية.
7 قاعدة البيانات: المخزن اللي اتملى كراكيب
كل مسودة محفوظة، وكل مراجعة مقالة (revisions)، وكل تعليق سبام، وكل transient منتهي — كل ده صفوف في قاعدة البيانات بتتفحص مع الاستعلامات. المواقع القديمة بتوصل لآلاف الصفوف الزائدة اللي بتبطّئ كل تحميل.
الحل: تنظيف مجدول أسبوعي بإضافة زي WP-Optimize — بتمسح المراجعات الزائدة والمسودات التلقائية والسبام والـ transients المنتهية. وقبل أول تنظيف: نسخة احتياطية كاملة. التنظيف آمن عمومًا، لكن النسخة الاحتياطية عادة المحترفين اللي مش بتتفاوض.
8 Heartbeat وWP-Cron: النشاط الخفي
ووردبريس فيه Heartbeat API بيبعت نبضات AJAX دورية للسيرفر — مفيد في صفحة كتابة المقالات (الحفظ التلقائي)، لكنه شغال برضه في لوحة التحكم كلها وبيستهلك موارد. قلّل تكراره أو عطّله في الأماكن اللي مش محتاجاه.
وكمان WP-Cron: نظام المهام المجدولة بتاع ووردبريس بيشتغل مع كل زيارة — يعني زائر واحد ممكن يشغّل فحص مهام كامل. لو عندك إمكانية تعمل cron حقيقي من السيرفر، عطّل الـ WP-Cron الافتراضي وخلّي السيرفر هو اللي يشغّل المهام في مواعيدها. إضافة Perfmatters المدفوعة بتخليك تتحكم في الاتنين بضغطات بسيطة.
9 CDN: قرّب موقعك من الزائر
لو سيرفرك في أوروبا وزائرك في مصر، كل ملف بياخد رحلة ذهاب وعودة. شبكة توصيل المحتوى (CDN) بتنسخ ملفاتك الثابتة (صور، CSS، JS) على سيرفرات حول العالم، فالزائر بيحمّل من أقرب نقطة له. Cloudflare بتقدم خطة مجانية كافية لمعظم المواقع — وتفعيلها أسهل مما تتخيل: تغيير الـ nameservers وخلاص.
ملاحظة: الـ CDN مش بديل للكاش — ده مكمّل له. الكاش بيسرّع توليد الصفحة، والـ CDN بيسرّع توصيل ملفاتها.
10 قِس تاني وقارن: إثبات مش إحساس
ارجع لنفس الصفحات اللي قستها في الأول، بنفس الأدوات، وسجّل الأرقام الجديدة جنب القديمة. التحسين الحقيقي هو اللي باين في الأرقام: LCP نزل، عدد الطلبات قلّ، حجم الصفحة صغر. ولو خطوة معينة ما غيّرتش حاجة، اعرف كده بصراحة بدل ما تكمّل على عماها.
إزاي تعرف إن كل خطوة نجحت: علامات قابلة للقياس
كل خطوة في الخطة ليها “علامة نجاح” تقيسها — من غيرها هتفضل تخمّن. الجدول ده مرجعك السريع:
| الخطوة | علامة النجاح | تقيسها بإيه |
|---|---|---|
| الاستضافة وPHP | TTFB ثابت ومنخفض — الصفحة بتبدأ ترد بسرعة من أول طلب | WebPageTest أو GTmetrix Waterfall (أول شريط) |
| القالب الخفيف | عدد طلبات CSS وJS أقل، وحجم الصفحة الكلي نزل بوضوح | GTmetrix: عدد الطلبات وحجم الصفحة |
| إضافة الكاش | زمن تحميل الصفحة للزائر المتكرر نزل لأجزاء من الثانية | PageSpeed: قارن قبل التفعيل وبعده |
| الصور | حجم الصفحة الكلي نزل، والـ LCP اتحسّن | PageSpeed: LCP + حجم الملفات في التشخيصات |
| CSS وJS | تحذير “احجب العرض” اختفى أو قلّ، والـ FCP اتحسّن | PageSpeed: الفرص والتشخيصات |
| الخطوط | لا شاشة فاضية مكان النص، ولا قفزة في الخط بعد التحميل | ملاحظة بصرية + CLS مستقر |
| قاعدة البيانات | حجم القاعدة نزل، وزمن توليد الصفحة (غير المكاشة) اتحسّن | لوحة الإضافة + TTFB للصفحات الديناميكية |
| Heartbeat وCron | استهلاك موارد السيرفر في لوحة الاستضافة نزل | إحصائيات الاستضافة (CPU/العمليات) |
| CDN | زمن تحميل الملفات الثابتة نزل للزوار البعيدة عن السيرفر | WebPageTest من موقع جغرافي مختلف |
| القياس والمقارنة | عندك جدول قبل/بعد مكتمل بالأرقام الخمسة | ملف المتابعة بتاعك |
إضافات الكاش: مقارنة صريحة
السوق مليان إضافات، والإعلانات بتقول كل واحدة “الأسرع”. خلينا نبص على الحقائق من صفحاتهم الرسمية — كل رابط تحت اتفتح واتأكد فعليًا:
| الإضافة | السعر | نقاط القوة | الأنسب لمين |
|---|---|---|---|
| LiteSpeed Cache | مجاني | كاش على مستوى السيرفر (أسرع من كاش PHP)، ضغط صور، توليد Critical CSS تلقائي، تحكم في Heartbeat — كل ده مجانًا ومفتوح المصدر | أي موقع على استضافة LiteSpeed — ده الاختيار الأول بلا منازع |
| WP Rocket | مدفوع | بيطبّق 80% من أفضل ممارسات السرعة لحظة التفعيل من غير تعقيد — حسب كلامهم الرسمي. أسهل إعداد في السوق | اللي عاوز نتيجة سريعة من غير ما يتعمق في الإعدادات |
| WP-Optimize | Freemium | كاش + ضغط صور + تصغير ملفات + تنظيف قاعدة بيانات في إضافة واحدة — 4 وظائف بسعر (مجاني) إضافة واحدة | اللي عاوز يقلل عدد الإضافات لأقصى حد |
| Autoptimize | مجاني | متخصص في تجميع وتصغير CSS وJS، وتأجيل الجافاسكريبت، وتحسين خطوط جوجل — خفيف ومركّز | مكمّل ممتاز جنب إضافة الكاش (مش بديل عنها) |
| Perfmatters | مدفوع | بيشيل الزوائد: تعطيل سكريبتات وأنومات لكل صفحة على حدة، تحكم في Heartbeat، تنظيف قاعدة البيانات — كود خفيف بلا جافاسكريبت في الواجهة | المواقع اللي عدّت مرحلة الأساسيات وعاوزة تحسينًا دقيقًا |
الصور: الملف الأثقل في موقعك
هنا بقى التفصيل اللي بيفرق. الصور غالبًا أكبر مكوّن في الصفحة، ومعالجتها الغلط هي السبب الأول في LCP عالي وCLS وحش. الخبر الحلو: إصلاحها سهل ومضمون النتيجة.
1. ارفع بالمقاس الصح من الأول
أكبر خطأ: رفع صورة 4000×3000 بكسل عشان تتعرض بعرض 800 بكسل. المتصفح بيحمّل الملف الكامل وبعدين يصغّره — يعني الزائر حمّل 5 أضعاف اللي محتاجه. القاعدة: جهّز الصورة بالمقاس اللي هتتعرض بيه (أو أكبر شوية للشاشات عالية الكثافة)، مش بمقاس الكاميرا.
2. WebP وAVIF بدل JPG وPNG
صيغ الجيل الجديد أصغر بكتير بنفس الجودة المرئية. صفحة WP-Optimize الرسمية بتقول إن WebP أصغر لحد 34% من JPEG و26% من PNG. إضافات زي Smush وShortPixel بتحوّل مكتبتك كلها تلقائيًا وبتقدّم الصيغة المناسبة لكل متصفح — والمتصفحات القديمة بتاخد النسخة الأصلية عادي، فمفيش مخاطرة.
3. الضغط التلقائي: lossy للصور الفوتوغرافية
الضغط الفاقد (lossy) بيقلل الحجم بشكل كبير بفرق جودة شبه غير مرئي للعين في صور الموقع العادية. فعّل الضغط التلقائي عند الرفع — صورة واحدة منسية بحجم 3 ميجا كفيلة تخرب LCP صفحة كاملة. والقاعدة الذهبية في الموقع ده: WebP بجودة 80 — توازن ممتاز بين الحجم والجودة.
4. التحميل الكسول لكل ما تحت الطية
الـ lazy load بيخلّي الصور تتحمّل لما الزائر يقرب منها مش كلها مرة واحدة أول ما الصفحة تفتح. ده بيقلل التحميل الأولي بشكل ضخم في المقالات الطويلة. لكن: صورة الهيرو والصورة البارزة فوق الطية مستثناة — دي لازم تتحمّل فورًا (بل ويفضّل تعملها preload) لأنها غالبًا عنصر الـ LCP نفسه. تأجيل صورة الـ LCP = تدمير متعمّد لأهم مقياس عندك.
5. أبعاد صريحة لكل صورة: علاج CLS
كل img لازم يكون لها width وheight صريحين. من غيرهم المتصفح بيحجز مساحة صفر للصورة، ولما تتحمّل فجأة بتزق كل المحتوى لتحت — وهو ده الـ CLS بعينه. إضافات الصور الحديثة (زي Smush) بتضيف الأبعاد تلقائيًا، لكن راجع قالبك: الصور اللي بيضيفها القالب يدويًا أحيانًا بتكون بلا أبعاد.
قاعدة البيانات: التنظيف اللي بيفرق
قاعدة البيانات زي مخزن البيت: كل حاجة بتتحط فيه، وقليل اللي بيترمي. مع الوقت بتتراكم:
- مراجعات المقالات (Revisions): كل مرة تدوس “حفظ مسودة”، ووردبريس بيحتفظ بنسخة. مقالة اتعدلت 30 مرة = 30 نسخة مرمية في القاعدة.
- المسودات التلقائية والمهملات: مسودات لم تكتمل ومحتوى محذوف لسه قاعد.
- تعليقات السبام: آلاف التعليقات المرفوضة اللي محدش مسحها.
- الـ Transients المنتهية: بيانات مؤقتة كان المفروض تتمسح لوحدها وفضلت.
- جداول الأيتام: إضافات اتحذفت وسابت جداولها وراها.
الحل العملي: WP-Optimize بجدولة أسبوعية — بيكنس كل ده بضغطة واحدة وبيحتفظ بنسخة احتياطية قبل التنظيف (وبينصح بـ UpdraftPlus للنسخ الاحتياطي). القاعدة: تنظيف مجدول + نسخة احتياطية قبل أي تنظيف يدوي كبير. ولو هتدخل phpMyAdmin بنفسك، اعرف بالظبط بتمسح إيه — الغلطة هنا مش “الموقع بقى بطيء”، الغلطة هنا “الموقع اختفى”.
إمتى التنظيف اليدوي وإمتى التلقائي؟
القاعدة: التلقائي المجدول للروتين، واليدوي للطوارئ. التنظيف الأسبوعي أو الشهري التلقائي بيمنع التراكم أصلًا — وده اللي يعمله أغلب المواقع. التدخل اليدوي (حذف جداول أيتام لإضافات محذوفة، أو تنظيف بيانات مؤقتة عنيدة) بييجي لما تلاحظ بطئًا رغم إن كل حاجة تانية سليمة، وساعتها: نسخة احتياطية أولًا، ثم الحذف بحذر، ثم اختبار الموقع صفحة صفحة. ولو مش متأكد من جدول معين — سيبه. جدول زائد أهون بكتير من جدول ناقص.
أخطاء شائعة بتقتل السرعة
دول الأخطاء اللي بشوفها بتتكرر في مواقع كتير — وكل واحد فيهم كفيل يضيّع مجهود كل الخطوات اللي فوق:
1. إضافتان لنفس الوظيفة
إضافتي كاش، إضافتي سيو، إضافتي ضغط صور “عشان واحدة بتعمل كذا والتانية بتعمل كذا”. النتيجة: تعارض، ملفات مكررة، وموقع أبطأ. وظيفة واحدة = إضافة واحدة. دي مش نصيحة — دي قاعدة.
2. مكتبة إضافات “يمكن أحتاجها”
30 إضافة منهم 12 معطّلة “احتياطًا”. الإضافة المعطّلة لسه ملفات على السيرفر، وبعضها بيسيب جداول ومهام مجدولة شغالة. اللي مش مستخدم يتحذف حذفًا كاملًا مش تعطيلًا.
3. سلايدر تقيل في الهيرو
سلايدر بـ 5 صور عالية الدقة في أول الصفحة = 5 أضعاف وزن الهيرو + جافاسكريبت تقيل + LCP مدمّر. لو لازم سلايدر، صورة واحدة محسّنة أحسن من 5 صور خام. والأحسن: صورة ثابتة واحدة قوية.
4. فيديو خلفية بيشتغل تلقائيًا
فيديو 20 ميجا بيتحمّل قبل ما الزائر يشوف أي حاجة. لو الفيديو أساسي للتصميم، استخدم صورة بوستر (poster) تظهر أولًا وحمّل الفيديو بعد تفاعل الزائر — أو استبدله بصورة متحركة خفيفة.
5. 6 أوزان من نفس الخط
كل وزن ملف مستقل. حمّل اللي بتستخدمه فعلًا (غالبًا وزنان)، والباقي شيله من إعدادات الخط.
6. الإعلانات بتزق المحتوى
وحدة إعلانية بتظهر متأخرة من غير مساحة محجوزة = قفزة في التخطيط = CLS عالي. الحل: احجز مكان كل وحدة إعلانية بـ CSS (min-height ثابت) عشان لما الإعلان يتحمّل يدخل في مكانه من غير ما يحرّك حاجة. دي نقطة مهمة لمواقع أدسنس بالذات — الإعلان مصدر الدخل، لكن ظهوره الغلط بيضرب مقياس CLS.
7. نسيان تحديث PHP والقالب والإضافات
كل تحديث رئيسي بيجيب تحسينات أداء. التأجيل المستمر معناه إنك شغال بنسخ أبطأ من اللي متاح لك مجانًا. (وطبعًا: نسخة احتياطية قبل التحديثات الكبيرة، والتجربة على نسخة staging لو الموقع مهم.)
3 سيناريوهات تشخيص عملية
عشان تربط النظري بالعملي، دي 3 سيناريوهات توضيحية (أمثلة افتراضية للشرح) — كل واحد بعرضه وتشخيصه وعلاجه. لو موقعك فيه عرض من دول، فأنت عارف هتبدأ منين:
السيناريو الأول: كل حاجة بطيئة من أول طلب
العرض: الـ TTFB فوق ثانية ونص، وأول شريط في الـ Waterfall (ملف الـ HTML نفسه) هو أطول شريط. الصور والسكريبتات بريئة — المشكلة إن السيرفر نفسه بياخد وقت عشان يرد.
التشخيص: دي مشكلة استضافة أو نسخة PHP قديمة، مش مشكلة إضافات. الكاش هيحسّن الزيارات المتكررة، لكن أول زيارة (وأي صفحة ديناميكية) هتفضل بطيئة.
العلاج بالترتيب: حدّث PHP لنسخة حديثة من لوحة الاستضافة ← فعّل الكاش ← لو الـ TTFB لسه عالي، راجع خطة الاستضافة نفسها أو انقل لمزود أفضل. دي الحالة الوحيدة اللي “اشتري حاجة أحسن” فيها هو الحل الصح.
السيناريو الثاني: الصفحة بتفتح بس الصورة الرئيسية بتتأخر
العرض: الـ FCP كويس (حاجة ظهرت بسرعة)، لكن الـ LCP عالي — 4 أو 5 ثواني. في الـ Waterfall: صورة الهيرو ملف ضخم بيتحمّل متأخر.
التشخيص: مشكلة صور كلاسيكية: صورة كبيرة الحجم، بصيغة قديمة، وبتتحمّل متأخرة (وأحيانًا الأسوأ: محطوطة على lazy load وهي عنصر الـ LCP).
العلاج بالترتيب: صغّر الصورة للمقاس الفعلي ← حوّلها لـ WebP ← استثنها من الـ lazy load ← اعمل لها preload. الأربعة دول مع بعض بينزلوا الـ LCP بشكل درامي في أغلب الحالات.
السيناريو الثالث: الصفحة بتفتح بس “مكتّفة” — الدوسات بتتأخر
العرض: الأرقام البصرية كويسة (LCP وCLS تمام)، لكن الـ INP عالي — الزائر يدوس على القائمة أو الزر ويحس بتأخير واضح قبل الاستجابة.
التشخيص: مشكلة جافاسكريبت: سكريبتات كتير بتتنافس على انتباه المتصفح. المتهمين المعتادين: إضافات بتحمّل سكريبتاتها في كل صفحة (حتى اللي مش محتاجاها)، وسكريبتات تتبع وإعلانات متزامنة.
العلاج بالترتيب: راجع الإضافات بـ Query Monitor وشوف مين بيحمّل إيه فين ← عطّل سكريبتات الإضافات من الصفحات اللي مش محتاجاها ← أجّل الجافاسكريبت غير الحرج ← قلّل سكريبتات التتبع الخارجية. الـ INP من أكتر المقاييس اللي بتتحسن بسرعة لما تنظّف الجافاسكريبت.
قائمة الفحص السريع: 15 سؤالًا قبل ما تركّب أي إضافة
قبل ما تلمس أي إعداد، امشِ على الأسئلة دي وجاوب بصراحة. كل “لا” أو “مش عارف” هي خطوة في خطتك:
- موقعك شغال على نسخة PHP كام؟ لو مش عارف، ادخل لوحة الاستضافة وشوف. النسخ القديمة أبطأ بفرق واضح — التحديث لنسخة حديثة مدعومة غالبًا بضغطة واحدة وبيفرق من أول صفحة.
- الـ TTFB بتاع صفحتك الرئيسية كام؟ قيسه من WebPageTest. لو فوق ثانية كاملة باستمرار، فأنت بتحارب في المكان الغلط — المشكلة في الاستضافة قبل أي تحسين تاني.
- مركّب كام إضافة كاش؟ الإجابة الصح: واحدة. لو اتنين أو أكتر، عطّل الزيادة فورًا — التعارض بينهم بيكسر الموقع مش بيسرّعه.
- إجمالي عدد الإضافات كام؟ مش عشان العدد نفسه، عشان كل واحدة محتاجة مراجعة: بتعمل إيه؟ ولو اتشالت هيحصل إيه؟ اللي إجابته “مش عارف” يتحذف.
- أكبر صورة في الصفحة الرئيسية حجمها كام؟ لو لقيت صورة فوق 500 كيلوبايت في صفحة عادية، فدي أول حاجة تتصلح: تصغير + WebP + ضغط.
- صورة الهيرو محطوطة على lazy load؟ لو أيوه، فأنت بتأخّر أهم عنصر في الصفحة بنفسك. صورة الـ LCP لازم تتحمّل فورًا — بل ويفضّل preload.
- صور موقعك ليها أبعاد width وheight صريحة؟ افتح مصدر أي صفحة ودور على وسوم img. من غير أبعاد، كل صورة بتزق المحتوى لما تظهر — وهو ده الـ CLS.
- كام ملف CSS وJS بيتحمّل في الصفحة الرئيسية؟ شوفهم في الـ Waterfall بتاع GTmetrix. لو العدد فوق 40-50 ملف، فعندك مجال كبير للدمج والتأجيل.
- خطوط موقعك من CDN ولا محلية؟ الخطوط من خوادم جوجل معناها طلبات خارجية إضافية لكل زائر. التحميل المحلي أسرع وأضمن — ومع وزنين بس مش ستة.
- إمتى آخر مرة نظّفت قاعدة البيانات؟ لو الإجابة “عمري ما عملت كده” وموقعك شغال من شهور، فعندك آلاف الصفوف الزائدة (مراجعات، مسودات، سبام، transients منتهية) مستنية الكنسة.
- الـ Heartbeat API شغال بكامل طاقته؟ النبضات الدورية دي مفيدة في صفحة الكتابة بس، وشغالة في لوحة التحكم كلها بتستهلك موارد على الفاضي — قلّلها أو قيّدها.
- عندك CDN؟ لو جمهورك في دول مختلفة عن مكان السيرفر، فالإجابة لازم تبقى أيوه. Cloudflare المجانية بتتفعّل في دقايق وبتفرق خصوصًا في الصور والملفات الثابتة.
- وحداتك الإعلانية ليها مساحة محجوزة؟ لو الإعلان بيظهر ويزق المحتوى، فالـ CLS بتاعك بيتضرب من مصدر دخلك نفسه. احجز مكان كل وحدة بـ min-height ثابت.
- القالب بتاعك آخر تحديث ليه إمتى؟ القالب المهجور مش بس خطر أمني — ده كود قديم بلا تحسينات الأداء اللي نزلت في النسخ الأحدث. التحديث المستمر معيار اختيار قبل ما يكون رفاهية.
- عندك أرقام “قبل” مسجلة؟ لو هتبدأ التحسين من غير baseline، فأنت مش هتعرف إيه اللي اشتغل وإيه اللي لأ. سجّل 5 أرقام دلوقتي: LCP وINP وCLS وحجم الصفحة وعدد الطلبات.
ملاحظات خاصة للمتاجر (ووكومرس)
المتاجر ليها طبيعة مختلفة: صفحات ديناميكية، سلة بتتحدث، ودفع لازم يفضل لحظيًا. قواعد إضافية:
- استثنِ صفحات السلة والدفع والحساب من الكاش — دي صفحات شخصية لكل زائر، وتخزينها مؤقتًا معناه زائر يشوف سلة زائر تاني. إضافات الكاش المحترمة بتعمل ده تلقائيًا لووكومرس، لكن تأكد بنفسك.
- صور المنتجات أولوية قصوى: صفحة منتج فيها 8 صور خام = كارثة. ضغط + WebP + lazy load للصور غير الرئيسية إلزامي هنا.
- قلّل طلبات AJAX السلة: بعض القوالب بتحدّث السلة مع كل حركة. راجع إعدادات القالب وقلّل التحديثات غير الضرورية.
- الاستضافة أهم للمتاجر: المتجر الديناميكي بيستهلك موارد أكتر من المدونة. الباقة الرخيصة اللي كانت كافية لمدونة ممكن تخنق متجرًا عليه طلبات.
روتين الحفاظ على السرعة
التسريع مش مشروع مرة واحدة — ده روتين. المواقع بتتخن مع الوقت: إضافات جديدة، صور منسية، تحديثات متراكمة. الروتين الشهري البسيط ده بيحافظ على مكاسبك:
- قياس شهري: نفس الصفحات، نفس الأدوات، 5 دقايق. أي تراجع هيبان فورًا وتعرف سببه (غالبًا: إضافة جديدة أو صورة تقيلة).
- بعد أي تغيير كبير: قالب جديد، إضافة جديدة، حملة إعلانية — قِس قبل وبعد.
- مراجعة الإضافات كل 3 شهور: افتح قائمة الإضافات واسأل على كل واحدة: “دي بتعمل إيه؟ ولو شلتها هيحصل إيه؟” — اللي إجابته “مش عارف” يتحذف.
- تنظيف قاعدة البيانات مجدول: أسبوعي أو شهري حسب نشاط الموقع — تلقائي ومن غير تدخل.
- التحديثات أولًا بأول: نواة ووردبريس والقالب والإضافات — التحديث = أداء + أمان.
5 إشارات خطر: موقعك بيبطّأ وانت مش واخد بالك
- تقرير PageSpeed الشهري نزل فجأة — غالبًا إضافة جديدة أو صورة تقيلة اترفعت من غير ضغط.
- لوحة تحكم ووردبريس نفسها بقت بطيئة — علامة على قاعدة بيانات متخمة أو Heartbeat خارج عن السيطرة.
- معدل الارتداد ارتفع في الإحصائيات من غير سبب واضح في المحتوى — الزوار بيمشوا قبل ما الصفحة تكمل.
- استهلاك موارد الاستضافة بيزيد شهريًا من غير زيادة مقابلة في الزيارات — فيه حاجة بتاكل موارد في الخلفية.
- شكاوى “الموقع بيعلّق” من زوار بعينهم (دولة معينة أو شبكة معينة) — ممكن تكون مشكلة CDN أو سيرفر بعيد عنهم.
أي إشارة من دول = ارجع لقائمة الفحص السريع فوق وابدأ من أول سؤال.
والأمان جزء من المعادلة: الموقع المخترق أو المصاب ببرمجيات خبيثة بيبقى بطيئًا مهما عملت — السكريبتات الخبيثة بتستهلك موارد السيرفر في الخفاء. حافظ على موقعك مؤمّنًا ومحدّثًا، والسرعة هتفضل في مكانها.
تسريع المواقع كخدمة: للفريلانسر
لو أنت شغال فريلانسر أو ناوي، اسمع دي: تسريع مواقع ووردبريس خدمة مطلوبة ومدفوعة كويس. أصحاب المواقع والمتاجر عارفين إن مواقعهم بطيئة ومش عارفين يعملوا إيه — وانت بعد الدليل ده عندك منهجية كاملة.
الخدمة دي سهلة البيع لسبب بسيط: نتيجتها قابلة للإثبات بالأرقام. اعرض على العميل تقريرًا من PageSpeed قبل وبعد — “موقعك كان بيفتح في 6 ثواني وبقى يفتح في ثانيتين” أقوى من أي كلام تسويقي. ابدأ بمواقع معارفك أو عملاء سابقين، وثّق كل حالة قبل/بعد، وابنِ عليها بورتفوليو.
ولو عاوز تحوّل المهارة دي لمسار دخل كامل — من أول اختيار المهارة لحد أول عميل — راجع دليل أهم 6 مهارات تحقق دخلًا بالدولار، وتطوير ووردبريس نفسه واحدة من أقوى المهارات اللي تقدر تبني عليها.
باقات الخدمة الثلاث
متعرضش “تسريع موقع” كخدمة واحدة مبهمة — قسّمها لباقات واضحة يفهمها العميل:
- تقرير التدقيق: فحص شامل بالأدوات اللي في الدليل + تقرير مكتوب بالأرقام والتوصيات مرتبة بالأولوية. العميل يدفع مقابل التشخيص حتى لو نفّذ بنفسه.
- الإصلاح لمرة واحدة: تنفيذ كل التوصيات — الكاش، الصور، التنظيف، الإعدادات — مع تقرير قبل/بعد بالأرقام. دي الباقة الأعلى سعرًا لأنها شغل مركز.
- الصيانة الشهرية: مراقبة دورية + تحديثات + تنظيف مجدول + تقرير شهري بسيط. دخل متكرر من نفس العميل، وهو أحلى أنواع الدخل لأنه متوقع ومستقر.
ابدأ بالتدقيق كخدمة دخول بسعر رمزي — التقرير الاحترافي بالأرقام هو اللي بيبيع الباقتين التانيين لوحده.
المصادر الموثقة
كل رابط تحت اتفتح واتأكد فعليًا قبل ما يتحط هنا — روابط مباشرة للمورد نفسه، مش لصفحات عامة. والشارة بتوضح حالته بصراحة:
أدوات القياس
أداة جوجل الرسمية لقياس السرعة — بتجمع بين اختبار المعمل اللحظي وبيانات الميدان الحقيقية من زوار موقعك، وبتفصل نتائج الموبايل عن الديسكتوب.
المرجع الرسمي لمقاييس Core Web Vitals: تعريف LCP وINP وCLS والأهداف الرقمية (2.5 ثانية / 200 مللي ثانية / 0.1) وطريقة القياس على الشريحة 75.
تحليل سرعة مفصّل مع الـ Waterfall اللي بيوريك كل ملف بياخد وقت قد إيه — أقوى أداة لتشخيص “إيه اللي مبطّأ موقعي بالظبط”. الخطة المجانية كافية للاستخدام الأساسي.
الاختبار الأعمق: تفاصيل TTFB وزمن الاستجابة وإمكانية الاختبار من مواقع جغرافية مختلفة — للتشخيص المتقدم لما تحتاج تفهم مش تحس.
إضافات التسريع
إضافة الكاش الأشمل مجانًا: كاش على مستوى السيرفر (أسرع من كاش PHP)، ضغط صور، توليد Critical CSS، تحكم في Heartbeat. أقوى نتيجة على استضافات LiteSpeed.
إضافة الكاش الأشهر — بتطبّق أغلب أفضل ممارسات السرعة لحظة التفعيل من غير تعقيد في الإعدادات. خيار ممتاز للي عاوز نتيجة سريعة ومش فارق معاه الاشتراك.
4 في 1: كاش + ضغط صور + تصغير ملفات + تنظيف قاعدة البيانات — النسخة المجانية قوية، والمدفوعة بتضيف جدولة متقدمة ومزايا للمتاجر.
متخصص تحسين CSS وJS: تجميع وتصغير الملفات، تأجيل الجافاسكريبت، وتحسين خطوط جوجل. مكمّل مثالي جنب إضافة الكاش — مش بديل عنها.
ضغط الصور الأشهر: تحويل تلقائي لـ WebP وAVIF، تحميل كسول، وإضافة الأبعاد تلقائيًا لعلاج CLS. النسخة المجانية بتغطي الاحتياجات الأساسية.
خدمة ضغط صور متقدمة بخوارزميات خاصة — ضغط فاقد وغير فاقد مع حفاظ ممتاز على الجودة، وتحويل لـ WebP وAVIF. حصة مجانية شهرية كافية للمواقع الصغيرة والمتوسطة.
لوحة أدوات المطوّر: بتوريك استعلامات قاعدة البيانات البطيئة والمكررة، والسكريبتات المحمّلة، والأخطاء — عشان تعرف بالظبط إيه اللي بيستهلك موارد موقعك.
إزالة الزوائد بدقة جراحية: تعطيل سكريبتات وإضافات لكل صفحة على حدة، تحكم في Heartbeat وWP-Cron — خفيف جدًا ومن غير جافاسكريبت في الواجهة.
البنية التحتية
شبكة توصيل المحتوى الأشهر — الخطة المجانية بتقدّم CDN وحماية أساسية كافية لمعظم المواقع، والتفعيل بتغيير الـ nameservers فقط.
الأسئلة الشائعة
إيه أسرع طريقة لتسريع موقع ووردبريس؟
أكبر قفزتين بأقل مجهود: تفعيل إضافة كاش واحدة (زي LiteSpeed Cache المجانية) وضغط الصور وتحويلها لـ WebP. الاتنين مع بعض بيحوّلوا موقعًا بيفتح في 5-6 ثواني لموقع بيفتح في ثانيتين أو أقل في أغلب الحالات — وبعدها كمّل باقي خطوات الخطة بالترتيب.
هل إضافة الكاش لوحدها كفاية؟
لا. الكاش بيحل مشكلة توليد الصفحة من السيرفر، لكنه مش بيصغّر صورة 3 ميجا ولا بيأجّل جافاسكريبت تقيل ولا بينضّف قاعدة بيانات مليانة كراكيب. الكاش خطوة أساسية من منظومة — قوية لوحدها، لكن الكمال بييجي مع باقي الخطوات.
أختار WP Rocket ولا LiteSpeed Cache؟
لو استضافتك شغالة على LiteSpeed، فـ LiteSpeed Cache المجانية هي الاختيار الأول — الكاش على مستوى السيرفر أسرع من أي كاش PHP. لو عاوز أسهل إعداد ممكن ومش فارق معاك الاشتراك المدفوع، WP Rocket ممتازة. القاعدة الوحيدة اللي مش بتتفاوض: واحدة بس منهم على الموقع.
إزاي أعرف إيه اللي مبطّأ موقعي بالظبط؟
افتح GTmetrix وشوف الـ Waterfall: هيوريك كل ملف اتحمّل إمتى واخد وقت قد إيه — هتعرف فورًا هل المشكلة صورة معينة، ولا سكريبت، ولا السيرفر نفسه بطيء في الرد (TTFB عالي). وكمّل بـ PageSpeed Insights عشان تشوف مقاييس LCP وINP وCLS وتوصيات جوجل المباشرة.
الـ LCP عندي عالي — أعمل إيه؟
حدّد أكبر عنصر ظاهر في أول الشاشة (غالبًا صورة الهيرو): صغّر حجمها وحوّلها لـ WebP، واعمل لها preload عشان المتصفح يجيبها أولًا، وتأكد إنها مستثناة من الـ lazy load. لو العنصر نصي، راجع ملفات CSS اللي بتحجب العرض واستخرج الـ Critical CSS.
الـ CLS عندي عالي — أعمل إيه؟
السبب في أغلب الحالات واحد من اتنين: صور بلا أبعاد صريحة، أو عناصر بتظهر متأخرة (إعلانات، بانرات، تضمينات). الحل: أبعاد width وheight لكل صورة، ومساحة محجوزة بـ CSS لكل وحدة إعلانية وعنصر ديناميكي — عشان لما يتحمّل يدخل مكانه من غير ما يزق المحتوى.
الـ INP عندي عالي — أعمل إيه؟
المشكلة جافاسكريبت في الغالب: سكريبتات كتير شغالة ومشغولة المتصفح عن الاستجابة للزائر. أجّل كل الجافاسكريبت غير الضروري لما بعد التحميل، وشيل الإضافات اللي بتحمّل سكريبتات في صفحات مش محتاجاها (إضافات زي Perfmatters بتخليك تعطل السكريبتات لكل صفحة على حدة).
هل عدد الإضافات بيأثر على السرعة؟
الجودة أهم من العدد. عشرون إضافة خفيفة ومحترمة أحسن من خمس إضافات ثقيلة ومبرمجة بسوء. لكن القاعدة العملية: كل إضافة زيادة معناها ملفات إضافية واحتمال تعارض أكبر — فراجع قائمتك كل فترة، واللي مش مستخدم يتحذف حذفًا كاملًا مش تعطيلًا.
WebP ولا AVIF — أختار إيه؟
الاتنين صيغ جيل جديد أصغر بكتير من JPG وPNG بنفس الجودة. WebP مدعوم على نطاق أوسع، وAVIF أصغر شوية في الحجم. عمليًا: إضافات الصور الحديثة (Smush وShortPixel) بتقدّم الصيغة الأنسب لكل متصفح تلقائيًا — فعّل التحويل التلقائي ومتشغلش بالك بالاختيار.
هل السرعة بتأثر فعلًا على ترتيبي في جوجل؟
أيوه. مقاييس Core Web Vitals جزء من إشارات تجربة الصفحة اللي بتظهر في كل أدوات جوجل، وليها تقرير مخصص في Search Console — يعني جوجل بتقيسها وبتاخدها في الاعتبار ضمن عوامل الترتيب. مش العامل الوحيد طبعًا، لكنها عامل حقيقي ومؤثر.
موقعي على استضافة مشتركة رخيصة — أعمل إيه؟
طبّق كل الخطوات المجانية الأول: كاش، ضغط صور، تنظيف قاعدة بيانات، تقليل الإضافات. لو الـ TTFB لسه عالي (فوق ثانية كاملة باستمرار)، فالمشكلة في الاستضافة نفسها مش في موقعك — ولا إضافة هتعوّض سيرفر بطيء، والترقية لاستضافة أفضل بقت ضرورة مش رفاهية.
كل قد إيه أراجع سرعة موقعي؟
قياس سريع شهريًا لنفس الصفحات بنفس الأدوات (5 دقايق)، وقياس فوري بعد أي تغيير كبير — قالب جديد، إضافة جديدة، أو حملة إعلانية. ومراجعة شاملة لقائمة الإضافات كل 3 شهور. المواقع بتتخن مع الوقت، والروتين ده هو اللي بيحافظ على مكاسبك.
خطوتك الأولى النهاردة
متقفلش الصفحة وتقول “هبقى أعمل كده بعدين”. افتح PageSpeed Insights دلوقتي، اختبر صفحتك الرئيسية، وسجّل 3 أرقام: LCP وCLS وحجم الصفحة. الأرقام دي هي نقطة البداية — وبعد ما تطبّق أول 3 خطوات من الخطة، ارجع قارن. الفرق اللي هتشوفه هو اللي هيخليك تكمّل.
وتذكّر القاعدة اللي مش بتتغير: السرعة مش إضافة — السرعة عادة. اللي بيقيس شهريًا وينضّف أول بأول، موقعه بيفضل سريع سنين. واللي بيعملها مرة وينسى، بيرجع لنفس النقطة بعد 6 شهور. اختار تبقى من النوع الأول.