فيه خيار واحد في إضافات التسريع بيرفع نتيجة Lighthouse من 46 لـ 86 في دقيقة. اسمه «Delay JavaScript Execution»، وهو موجود في أشهر ووردبريس لتضيف له ميزة جديدة، مثل متجر أو نموذج تواصل أو تحسين للسيو، دون كتابة كود. اختر الإضافات الموثوقة المحدّثة، ولا…">الإضافات اللي بتستخدمها.
ودي بالظبط المشكلة: النتيجة بتطلع، والموقع نفسه مبقاش أسرع ولا حاجة.
هذا المقال مبني على تحليل Martin Michálek من فريق PageSpeed.ONE، وهو رأي صريح لصاحب المقال بعد تحسين مئات المواقع دون أن يوصي بهذه التقنية مرة واحدة. الآليات التقنية التي يشرحها قابلة للتحقق بنفسك على موقعك، وهذا ما يهمنا هنا.
كيف يرفع الخيار النتيجة بهذه الدقة
أداة Lighthouse تفتح الصفحة وتقيسها. هي لا تمرّر الصفحة، ولا تضغط، ولا تلمس الشاشة إطلاقًا.
الأكواد المؤجلة حتى التفاعل لا تعمل أثناء الاختبار إذن. ومعنى ذلك أن مقياس Total Blocking Time يختفي من القياس تمامًا — وهو أثقل مقياس في نتيجة Lighthouse، يمثل 30% منها وحده. ومقياس LCP يتحسن أيضًا، لأن المتصفح لا يجد شيئًا ينفّذه.
النتيجة ترتفع، والـ JavaScript لم تختفِ. هي فقط انتقلت إلى وقت لاحق — وغالبًا إلى أسوأ لحظة ممكنة.
هذا الرأي ليس رأي كاتب المقال وحده. يقول Barry Pollard، المتخصص في أداء الويب لدى Google:
«نمط شائع أراه: تأجيل كل الـ JavaScript حتى يتفاعل المستخدم مع الصفحة. رائع لنتائج Lighthouse! وسيئ جدًا للمستخدمين في الغالب.»
أربعة مخاطر لتأجيل كل شيء
1. يضر بتجربة التفاعل (INP). الزائر يفتح الصفحة، يقرأ العنوان، ثم يضغط. تلك هي اللحظة التي تنطلق فيها كل الأكواد المتراكمة في وقت واحد. الخيط الرئيسي (Main Thread) ينشغل، وأول ضغطة للمستخدم تنتظر.
2. يضر باستقرار التصميم (CLS). الأكواد التي تبني محتوى متأخرًا — السلايدرات، التخصيص حسب الزائر — تعمل الآن متأخرة. واختبار Lighthouse لا يرى أي إزاحة، لأن ذلك الكود لم يعمل أثناءه، فتفقد القدرة على رؤية قيمة CLS الحقيقية عندك.
3. قياساتك تتوقف عن العمل. التحليلات، ونافذة الموافقة على الكوكيز، والشات، واختبارات A/B، وتتبع التحويلات — كلها تتأجل مع الباقي. بياناتك تتوقف عن المطابقة ولا أحد يعرف السبب.
4. يفقد مؤشر Lighthouse قيمته التشخيصية. النتيجة ليست مقياسًا للسرعة الواقعية، لكنها مفيدة لمقارنة تأثير تغييراتك. إذا جرّدتها من كل الـ JavaScript فأنت تقيس شيئًا آخر غير موقعك.
ولنكن دقيقين في النقطة الأولى: لا توجد دراسة ميدانية منشورة تقيس تدهور INP بعد تفعيل هذا الخيار. ما لدينا هو آلية تقنية يشرحها مهندسون في Google، مع إقرار من WP Rocket نفسها بأن قيمة INP لم تتحسن في اختبارها الخاص. هذا مؤشر قوي، وليس أثرًا مقيسًا.
أي الإضافات تشحن هذا الخيار؟
مراجعة أشهر إضافات التحسين في ووردبريس، بحثًا عن ثلاثة أشياء في كل واحدة: اسم الخيار، وهل هو مفعّل افتراضيًا، وهل توضح الوثائق المخاطر:
| الإضافة | اسم الخيار | افتراضيًا | تحذّر من المخاطر؟ |
|---|---|---|---|
| WP Rocket | Delay JavaScript Execution | مغلق | لا |
| — | — | — | — |
| LiteSpeed Cache | Load JS Deferred → Delayed | مغلق | نعم |
| WP-Optimize | Delay JS | مغلق | جزئيًا |
| Perfmatters | Delay all scripts | مغلق | لا |
| NitroPack | Delay non-critical resources | مفعّل في وضع Ludicrous | جزئيًا |
| WP Meteor | Infinite Delay | مغلق | نعم |
| Autoptimize Pro | Delay JavaScript (timeout 0) | مغلق | نعم |
| SpeedyCache | Delay All | مغلق | نعم |
«جزئيًا» في العمود الأخير تعني أن الوثائق تحذّر فقط من احتمال تعطّل الموقع، دون ذكر أي شيء عن تأثير الخيار على نتيجة Lighthouse أو على المستخدمين. وإضافة واحدة فقط، هي SpeedyCache، تحذّرك أيضًا من أن التحليلات ستتعطل.
صفّان يستحقان تعليقًا:
LiteSpeed Cache لها طريقان إلى نفس النتيجة. الطريق المباشر هو Load JS Deferred مضبوطًا على Delayed، وهو مغلق افتراضيًا والوثائق تحذّر منه. والطريق الثاني هو Guest Optimization (حزمة تحسينات أقصى للزيارة الأولى والبوتات)، وهي لا تعمل إلا مع تفعيل Guest Mode. التثبيت الجديد لا يشحن هذه التقنية من تلقاء نفسه، لكن بعد تفعيل Guest Mode — أو بعد أن يفعّله لك إعداد جاهز من الاستضافة — يمكن أن تفرض Guest Optimization وضع Delayed بصمت، حتى لو كان Load JS Deferred مغلقًا.
WP Rocket غيّرت القواعد في الإصدار 3.9. قبله كان عليك إدراج الأكواد التي تريد تأجيلها. من 3.9 فصاعدًا كل شيء مؤجَّل وأنت تُدرج الاستثناءات. وقائمة الاستثناءات للمستخدم الجديد تبدأ فارغة، أي أن تفعيل الخيار يؤجل كل شيء فورًا. وللإنصاف: الإضافة تذكر خطر INP، لكن في صفحة مساعدة أخرى أقل زيارة بكثير، أما صفحة الخيار نفسه فلا تتضمن كلمة واحدة عنه.
مؤشر أمانة عملي: مهلة التوقيت (Timeout). الإضافات التي تفرض حدًا زمنيًا ستشغّل الكود في النهاية حتى بدون تفاعل، فيراه Lighthouse. أما التي لا تضع مهلة، أو تسمح لك بضبطها على صفر، فهي تنتظر التفاعل إلى الأبد. وهذا أقرب إلى التحسين من أجل الاختبار وحده.
الشركات تعرف ذلك، وبعضها كتبه
لا حاجة للتخمين حول معرفة المطورين بما يفعله الخيار في اختبارات السرعة. بعضهم كتبه في وثائقه بالحرف.
من مدونة WP Rocket عند إصدار 3.9:
«هذا يعني أن ملفات JavaScript لن يكتشفها Lighthouse… هل هذا غش؟ ليس تمامًا إذا أخذت في اعتبارك ما يلي…»
ووثائق LiteSpeed Cache تذهب أبعد وتعترف بأن الخيار يخفي مشاكل الموقع الحقيقية:
«هذا الإعداد يمكن أن يحسّن نتائج سرعة الصفحة كثيرًا… وإضافةً إلى ذلك، يمكن لـ Guest Optimization أن “تخفي” أي مشاكل حقيقية قد تكون في موقعك.»
ويقول Frank Goossens، مؤلف Autoptimize، عن خيار ضبط المهلة على صفر:
«ضبط التأجيل على 0 فيه شيء من الالتباس، لأنك عند هذه النقطة تخفي تلك الملفات عن اختبارات الأداء.»
والأرقام التي نشرتها WP Rocket مع إصدار 3.7 تستحق الذكر: على موقعها نفسه، نقل هذا الخيار نتيجة الموبايل من 46 إلى 86 نقطة. وفي الوقت نفسه، تقريرها عن INP يقول إن قيمة INP لم تتغير.
احترس: ليس كل ما اسمه «Delay» من هذا النوع
كلمة delay تُستخدم بتوسّع في عالم الإضافات، ومن السهل أن تظلم إضافة بريئة. هذه الخصائص لا تؤجل حتى التفاعل، رغم أن أسماءها تشير إلى ذلك:
- Breeze من Cloudways فيها خيار «Delay All JavaScript»، لكنها في الواقع تضيف خاصية
deferوتحمّل الأكواد كوحدات (Modules). - Jetpack Boost وخيار «Defer Non-Essential JavaScript» ينقل وسوم
<script>إلى نهاية المستند. - Speed Optimizer من SiteGround يضيف
deferعاديًا تحت «Defer Render-blocking JavaScript». - Rocket Loader من Cloudflare يستخدم نفس حيلة خاصية
type، لكنه يعيد الأكواد إلى العمل بعد رسم الصفحة، لا بعد التفاعل. أي أن Lighthouse يشغّلها ويقيسها.
الأربعة قد تسبب مشاكل أخرى، في ترتيب تنفيذ الأكواد مثلًا، لكنها لا تنفخ نتيجة Lighthouse نفخًا مصطنعًا.
متى يكون التأجيل هو الصواب؟
للإنصاف: تأجيل كود حتى يتفاعل المستخدم هو الحل الصحيح تمامًا في حالات معروفة. الفرق أن تؤجل مكوّنًا واحدًا محددًا، لا كل شيء.
المثال النموذجي هو نمط الواجهة البديلة (Facade Pattern): بدلًا من تضمين فيديو YouTube، تعرض صورة معاينة وزر تشغيل، وتحمّل سير العمل في أداة الأتمتة، مثل استقبال Webhook أو نشر مقالة جديدة أو حلول موعد مجدول، وبدونه لا تعرف الأداة متى يجب أن…">المشغّل الحقيقي عند الضغط. ونفس الأسلوب يصلح لودجت الشات والخرائط والتعليقات.
وهنا تظهر أوضح علامة: Lighthouse لديه اختبار مخصص يوصي بنمط الواجهة البديلة. أما تأجيل كل الـ JavaScript فليس له عنده شيء على الإطلاق.
في القالب كاملًا والنماذج والنوافذ المنبثقة.">Elementor: إذا كنت على Elementor Pro وتشغّل سلايدرات أو نوافذ منبثقة (Popups) أو نماذج، فهي تعتمد على JavaScript لتعمل. تأجيلها حتى أول تفاعل يعني أن أول ضغطة من الزائر على زر النموذج قد لا تفعل شيئًا — وهذا من أكثر الأعراض تكرارًا: «الفورم مش بيرسل من أول مرة». وإذا اضطررت لتفعيل الخيار، فاستثنِ ملفات Elementor من قائمة التأجيل واختبر النماذج والسلايدرات بنفسك قبل أن تعتبره آمنًا.
كيف تكتشف النوع السيئ على موقعك
هذه الإضافات تترك آثارًا واضحة في كود HTML. الشائع أنها تعيد كتابة خاصية type في وسم <script> إلى قيمة لا يفهمها المتصفح، وتخفي رابط الكود الأصلي في خاصية مخصصة.
ابحث في مصدر الصفحة عن:
type="text/rocketlazyloadscript"وdata-rocket-src— WP Rockettype="litespeed/javascript"— LiteSpeed Cachetype="pmdelayedscript"— Perfmatterstype="javascript/blocked"— WP Meteortype="text/plain"مع خاصيةdata-src— WP-Optimize
وإن كنت تفضّل ألّا تقرأ كودًا: افتح الصفحة ولوحة Network مفتوحة، ولا تحرّك الماوس. ثم حرّكه. إذا انطلقت دفعة من طلبات JavaScript في تلك اللحظة بالضبط، فقد وجدت جوابك.
ملاحظة تهم المنطقة: كثير من خطط الاستضافة المشتركة (Shared Hosting) المعتمدة على LiteSpeed تُسلَّم بإعدادات جاهزة تفعّل Guest Mode من أجل رفع أرقام السرعة في لوحة العميل. افتح إعدادات LiteSpeed Cache على موقعك وتأكد بنفسك بدلًا من افتراض أن التثبيت نظيف. والأثر هنا أكبر عندنا مما هو في السوق الأمريكي: معظم الزيارات في مصر والخليج من الموبايل على شبكات محمولة، وهي الحالة التي يكون فيها انفجار كل الأكواد عند أول لمسة أشد إيلامًا.
وفي كل الأحوال، اختم دائمًا بالنظر إلى بيانات المستخدمين الحقيقيين. نتيجة مخبرية أكثر اخضرارًا بدون أي تحسن في بيانات المستخدم ليست انتصارًا.
الخلاصة
قرار إيه اللي يتحمّل، وإمتى، وبأي ترتيب — ده شغل هندسي محتاج تعرف الموقع اللي بين إيديك. مربع اختيار واحد مش هيعمل الشغل ده.
افتح إعدادات إضافة التسريع عندك دلوقتي، شوف الخيار ده مفعّل ولا لأ، وبعدين افتح مصدر الصفحة ودوّر على القيم اللي فوق. لو لقيتها، قِس INP من بيانات المستخدمين الحقيقيين قبل وبعد ما تقفله — ده الرقم اللي يهم، مش نتيجة الاختبار.
مرجع المقال (بالإنجليزية): Delaying all JavaScript doesn’t make your site faster
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
اقرأ أيضًا
الأسئلة الشائعة
هل تفعيل Delay JavaScript يسرّع موقعي فعلًا؟
لا يسرّع تجربة الزائر الحقيقي. هو ينقل تنفيذ الأكواد إلى لحظة أول تفاعل من المستخدم، فتختفي من قياس Lighthouse لكنها تعمل كلها مرة واحدة عند أول لمسة أو تمرير. النتيجة في الاختبار تتحسن، والإحساس الفعلي بالسرعة لا يتحسن وقد يسوء.
لماذا ترتفع نتيجة Lighthouse بهذا الشكل إذن؟
لأن Lighthouse يفتح الصفحة ويقيسها دون أن يمرّر أو يضغط أو يلمس الشاشة. الأكواد المؤجلة لا تعمل أثناء الاختبار أصلًا، فيسقط مقياس Total Blocking Time من الحساب — وهو أثقل عنصر في النتيجة بنسبة 30% منها.
ما الفرق بين defer وتأجيل الأكواد حتى التفاعل؟
خاصية defer تؤجل التنفيذ حتى انتهاء تحليل صفحة HTML، لكن الكود يعمل في نفس تحميل الصفحة ويقيسه Lighthouse. أما التأجيل حتى التفاعل فينتظر حركة من المستخدم، وقد لا يعمل الكود أبدًا إذا لم يتفاعل. الأول تقنية مشروعة، والثاني هو موضوع هذا المقال.
هل التأجيل خطأ في كل الحالات؟
لا. تأجيل مكوّن واحد محدد أسلوب صحيح ومُوصى به، مثل استبدال فيديو YouTube بصورة معاينة وزر تشغيل يحمّل المشغّل عند الضغط. المشكلة في تأجيل كل شيء بضغطة واحدة دون معرفة ما في الصفحة.
كيف أعرف أن الخيار مفعّل على موقعي؟
افتح مصدر الصفحة وابحث عن قيم غريبة في خاصية type داخل وسوم <script> مثل text/rocketlazyloadscript أو litespeed/javascript. أو افتح لوحة Network في أدوات المتصفح، واترك الماوس ساكنًا ثم حرّكه: إذا انطلقت دفعة من طلبات JavaScript في تلك اللحظة، فالخيار مفعّل.
