لماذا Elementor بطيء إلى هذا الحد؟ الإصلاحات التي تحسّن PageSpeed فعلًا

نادرًا ما يكون Elementor بطيئًا بذاته. فمعظم مواقع Elementor البطيئة بطيئة بسبب طريقة بنائها: أقسام متداخلة بعمق، وحزم إضافات (addons)، وملفات خطوط كثيرة، وشريط تمرير (slider) في الواجهة، وكومة من سكربتات الأطراف الثالثة، واستضافة بلا تخزين مؤقت للصفحات. أصلح هذه بالترتيب الصحيح، ويمكن لموقع Elementor أن يحقق درجة جيدة في PageSpeed Insights.

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

أولًا: هل الموقع بطيء، أم المحرر؟

عبارة “Elementor بطيء” تعني مشكلتين مختلفتين، لكل منهما أسباب مختلفة.

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

لبطء المحرر، ابدأ بـ متطلبات النظام الخاصة بـ Elementor. فحتى أكتوبر 2026 تشترط PHP 7.4 أو أعلى (مع التوصية بـ PHP 8.x)، وحد ذاكرة WordPress لا يقل عن 256 ميجابايت، مع التوصية بـ 512 ميجابايت و 768 ميجابايت لأفضل أداء. وكثير من باقات الاستضافة الرخيصة ما زالت تأتي بأقل من ذلك. ورفع حد الذاكرة والانتقال إلى PHP 8.x يحل عددًا مدهشًا من شكاوى “Elementor لا يُحمَّل”. وإن لم يحلها، فعطّل الإضافات الأخرى واحدة تلو الأخرى للعثور على التعارض.

بقية هذا المقال عن الموقع الحي.

قِس قبل أن تغيّر أي شيء

مرّر أهم صفحة لديك (عادة الصفحة الرئيسية أو صفحة الهبوط الرئيسية) عبر PageSpeed Insights على تبويب الجوال، ودوّن ثلاثة أشياء:

1. تقييم Core Web Vitals في الأعلى (بيانات المستخدمين الحقيقيين) والمقياس الفاشل.
2. عنصر Largest Contentful Paint. يذكره PageSpeed في التشخيصات. وفي مواقع Elementor يكون عادة صورة الواجهة، أو صورة خلفية، أو العنوان الرئيسي.
3. التشخيصات المتكررة: “Avoid an excessive DOM size”، و “Reduce unused JavaScript”، و “Eliminate render-blocking resources”، و “Reduce initial server response time”.

الدرجة في الأعلى محاكاة معملية، أما التقييم فمبني على زوار حقيقيين، وكثيرًا ما يختلفان. وإذا لم تكن متأكدًا بأيهما تثق، فاقرأ أولًا ما الذي يخبرك به تقرير Core Web Vitals فعلًا، فهو يحدد الإصلاحات المهمة.

وإذا فضّلت ألا تبحث في التقرير بنفسك، فسأرسل لك تقرير PageSpeed و Core Web Vitals مجانيًا ضمن تدقيق MarTech الذي أقدمه.

الأسباب المعتادة لبطء موقع Elementor

1. أقسام متداخلة بدلًا من الحاويات

تتراكم تخطيطات Elementor القديمة هكذا: قسم ← عمود ← قسم داخلي ← عمود ← عنصر. وكل طبقة تضيف عناصر div مغلِّفة، و DOM الكبير يجعل المتصفح يبذل جهدًا أكبر لتنسيق الصفحة وتخطيطها. أما الحاويات فتستخدم Flexbox، فيحتاج التخطيط نفسه إلى مغلِّفات أقل. وفي مقارنة الحاويات من Elementor نفسها، أنتج قسم من خمسة عناصر مبني بالطريقة القديمة 37 عنصر div، مقابل 23 في نسخة الحاوية.

لا تحتاج إلى إعادة بناء كل شيء. أعد بناء الترويسة والتذييل وأعلى قوالبك زيارات بالحاويات أولًا؛ فهذه تُحمَّل في كل صفحة.

2. حزم الإضافات وعناصر الأطراف الثالثة

من هنا يأتي معظم الانتفاخ الذي أراه. يثبّت الموقع حزمتين أو ثلاثًا من حزم “ultimate addons” من أجل عنصر واحد من كل منها، وكل حزمة تجلب سكربتاتها وأنماطها الخاصة.

وهناك خرافة تستحق التخلي عنها: لا تحتاج إلى تعطيل عناصر Elementor الأصلية غير المستخدمة. فـ Elementor تقول إن العناصر والخطوط والأيقونات الأصلية غير المستخدمة في صفحة ما لا تحمّل ملفاتها، باستثناء قاعدة مشتركة صغيرة. لكن الأمر ليس مضمونًا مع إضافات الأطراف الثالثة؛ فبعضها يحمّل ملفاته في كل مكان. افحص قائمة “Reduce unused JavaScript” في PageSpeed: إذا ظهرت ملفات إضافة ما في صفحات لا تستخدمها، فتلك الإضافة تكلّفك.

3. الخطوط ومكتبات الأيقونات

كل وزن خط ملف منفصل. ثلاث عائلات بأربعة أوزان لكل منها تعني دزينة من التنزيلات قبل أن يستقر نصك. اختر عائلة أو اثنتين والأوزان التي يستخدمها التصميم فعلًا فقط.

ثم تحقق من طريقة تقديمها. يستطيع Elementor تحميل خطوط Google محليًا من خادمك بدلًا من خوادم Google. انتبه: بدءًا من Elementor 3.32.1 أصبح هذا الخيار معطّلًا افتراضيًا، وإذا كان مفعّلًا لديك من قبل، فعليك تفعيله مجددًا بعد التحديث. ويتيح لك Elementor أيضًا اختيار طريقة تحميل خطوط Google (Swap و Fallback و Optional وغيرها). يعرض “Swap” النص فورًا بخط احتياطي، ما يحسّن السرعة المُدركة، لكنه قد يسبب انزياحًا صغيرًا في التخطيط عند وصول الخط الحقيقي.

وللأيقونات، تعرض ميزة Inline Font Icons في Elementor الأيقونات كـ SVG مضمّن بدلًا من تحميل مكتبتي Font Awesome و eicons كاملتين.

4. الواجهة: أشرطة التمرير والفيديوهات والصور الضخمة

أول ما يراه الزائر هو عادة عنصر Largest Contentful Paint، لذا فهو يحدد LCP لديك. شريط تمرير بخمس صور بعرض كامل، أو فيديو خلفية، أو صورة PNG بعرض 3,000 بكسل، كلها تؤخره. استبدل شريط التمرير في الواجهة بصورة واحدة مضغوطة جيدًا (WebP أو AVIF، بحجم يناسب الحاوية)، ولا تؤجل تحميل صورة الواجهة أبدًا. ويشرح دليل Google عن LCP لماذا يجب أن يبدأ تنزيل صورة LCP في أبكر وقت ممكن.

5. سكربتات الأطراف الثالثة

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

6. الاستضافة وغياب التخزين المؤقت للصفحات

تُبنى صفحات Elementor عبر PHP مع كل طلب ما لم يخزنها شيء مؤقتًا. وعلى خادم مشترك بطيء دون تخزين مؤقت للصفحات، قد يستغرق الخادم وقتًا طويلًا لمجرد إرسال أول بايت، ولا شيء في الواجهة الأمامية يعوّض ذلك. وإذا أشار PageSpeed إلى “Reduce initial server response time”، فأصلح هذا قبل أي شيء آخر: فعّل التخزين المؤقت للصفحات (من الاستضافة أو عبر إضافة تخزين مؤقت)، واستخدم CDN، وإذا ظل الخادم بطيئًا، فانتقل إلى استضافة أخرى.

إعدادات الأداء في Elementor التي تستحق التفعيل

حتى أكتوبر 2026، يضع Elementor هذه الإعدادات في Elementor → Editor → Settings، في تبويبي Performance و Features، وفقًا لـ دليل ميزات الأداء. فعّلها واحدة تلو الأخرى واختبر بعد كل منها، خاصة في موقع فيه CSS مخصص أو إضافات.

ميزة Element Caching تستحق ملاحظة. يقول دليل Element Caching من Elementor إن الحاويات والأقسام تُخزَّن مؤقتًا تلقائيًا، وأنت تحدد عدد مرات مسح الذاكرة المؤقتة عبر Element Cache Expiration في تبويب Performance. إنها تساعد في زمن استجابة الخادم، لكنها ليست بديلًا عن التخزين المؤقت للصفحات.

ترتيب الإصلاحات الذي يحسّن الدرجة

الترتيب مهم لأن كل إصلاح يجعل قياس الذي يليه أسهل. وهذا التسلسل الذي أستخدمه:

1. استجابة الخادم. تخزين مؤقت للصفحات مفعّل، و PHP 8.x، وذاكرة كافية، و CDN. إذا كان أول بايت بطيئًا، فلن يظهر أثر أي شيء آخر.
2. الواجهة. صورة واحدة محسّنة، غير مؤجلة التحميل، مع تفعيل Optimized Image Loading.
3. الخطوط. قلّل العائلات والأوزان، وقدّمها محليًا، واختر طريقة تحميل.
4. الإضافات وحزم الإضافات. احذف حزم الإضافات التي بالكاد تستخدمها، والإضافات التي تكرر بعضها.
5. سكربتات الأطراف الثالثة. احذفها أو أخّرها، ثم أعد اختبار التتبع.
6. البنية. حوّل الترويسة والتذييل وأهم القوالب إلى حاويات.
7. ميزات Elementor. Inline Font Icons، وتأجيل صور الخلفية، ثم Element Caching على العناصر الثابتة.

أعد تشغيل PageSpeed بعد كل خطوة. تتحرك الدرجات المعملية فورًا، أما تقييم المستخدمين الحقيقيين فيستغرق أسابيع ليلحق بها، لأنه مبني على زيارات آخر 28 يومًا.

التحسين أم إعادة البناء؟ Elementor مقابل Gutenberg في السرعة

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

حسّن موقع Elementor إذا:

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

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

أبني بـ Elementor و Gutenberg، إضافة إلى البرمجة المخصصة، وأستهدف لكل موقع وصفحة هبوط درجة PageSpeed بين 95 و 100. ومن النتائج التي حققتها خفض زمن التحميل بنسبة 25% ودرجة PageSpeed بلغت 98، لذا لا مصلحة لي في منشئ بعينه. الإجابة الصحيحة تعتمد على من يحرر الموقع وما الذي يُبطئه فعلًا.

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

هل يُبطئ Elementor موقع WordPress؟

يضيف بعض الترميز و CSS و JavaScript مقارنة بقالب مكونات بسيط، لذا سيكون الموقع المبني بإهمال أثقل. لكن موقع Elementor مبنيًا جيدًا بالحاويات وإضافات قليلة وخطوط محلية واستضافة جيدة يمكنه اجتياز Core Web Vitals. ومعظم البطء يأتي من طريقة بناء الموقع واستضافته.

لماذا محرر Elementor بطيء إلى هذا الحد؟

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

هل يجب أن أعطّل عناصر Elementor غير المستخدمة؟

ليس عناصر Elementor الأصلية. تقول Elementor إن العناصر الأصلية غير المستخدمة لا تحمّل ملفاتها. أما عناصر إضافات الأطراف الثالثة فمختلفة؛ تحقق هل تُحمَّل ملفاتها في صفحات لا تستخدمها.

هل ما زال Elementor يستحق في 2026؟

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

السرعة جزء واحد فقط من رحلة العميل المحتمل، لذا إذا أردت رؤية البقية، فمن المفيد إجراء تدقيق كامل للسرعة والتتبع وتدفق العملاء المحتملين.