حين بدأت العمل على تسريع موقع ووردبريس على الجوال، لم أكن أريد تحويل الأمر إلى مشروع تقني مفتوح. أردت أن أفهم سبب التأخير، وأزيل ما لا يحتاجه الموقع، ثم أتوقف عند تحسن واضح لا يأتي على حساب وظائفه.
موقعي هو midad.blog، ويعمل بووردبريس وقالب الكتل مِداد، على استضافة Hostinger، مع إضافة LiteSpeed Cache. وخلال ساعة واحدة، انتقلت نتيجة الأداء على الجوال من 75 إلى 87.
تركزت التغييرات في خطوط تُحمّل بلا استخدام، وطريقة تشغيل بعض الملفات، وإضافات لم أكن أحتاج إليها. هذه تفاصيل التجربة، بما تحسن وما قررت تركه كما هو.
1. نقطة البداية: نتيجة PageSpeed الأولى
بدأت من PageSpeed Insights، أداة Google التي تفحص الصفحة وتعرض مؤشرات لأدائها. على الحاسوب كانت النتيجة 98، بينما حصل اختبار الجوال على 75؛ لذلك ركزت على مشكلة الجوال.
كان First Contentful Paint — FCP، أي الوقت حتى ظهور أول نص أو صورة، يساوي 2.8 ثانية. أما Largest Contentful Paint — LCP، وهو وقت ظهور أكبر عنصر محتوى مرئي في مساحة العرض، فبلغ 4.7 ثانية.
وصل Speed Index، المؤشر الذي يصف سرعة اكتمال ظهور محتوى الصفحة بصريًا، إلى 5.1 ثانية. وبلغ Total Blocking Time — TBT، أي مجموع فترات انشغال المتصفح بما يعيق استجابته أثناء التحميل، 10 ملي ثانية فقط.
أما Cumulative Layout Shift — CLS، الذي يقيس تحرك العناصر بصورة غير متوقعة أثناء العرض، فكان 0. كانت هذه نقطة جيدة: لم يكن لديّ تحرك في التخطيط بحسب الاختبار، لكن ظهور المحتوى احتاج إلى وقت أقل.
لم أتعامل مع 75 بوصفها تشخيصًا كاملًا. الرقم يلخص النتيجة، بينما تفاصيل الملفات هي التي تساعد على اختيار التعديل المناسب.
2. اكتشاف المشكلة: خطوط لا يستعملها أحد تُبطئ الموقع
المفاجأة كانت في MailPoet، إضافة البريد التي أستخدمها. كانت تحمّل ثلاثة ملفات من Google Fonts، خدمة تحميل الخطوط من Google، تضم عشرات الخطوط التي لا يستعملها الموقع أبدًا.
من بينها Pacifico وRoboto وMontserrat. لم تكن هذه الخطوط جزءًا من تصميم الصفحة، ومع ذلك كانت ملفاتها تُحمّل قبل ظهورها. هنا بدا السؤال أبسط من البحث عن إعداد متقدم: لماذا أحمّل شيئًا لا أستخدمه؟
وجدت أيضًا أن Hostinger Reach تحمّل سكربتًا خارجيًا دون أن أستخدمها. والسكربت ملف يحتوي تعليمات برمجية ينفذها المتصفح، وقد يضيف طلبًا إلى جهة خارج الموقع.
وكانت مكتبة jQuery تُحمّل في رأس الصفحة. وهي مجموعة أدوات مبنية على JavaScript، اللغة المستخدمة لإضافة السلوك التفاعلي إلى الصفحات. لكن وجودها مبكرًا لم يكن سببًا كافيًا لحذفها؛ كان عليّ أن أعرف ما يعتمد عليها أولًا.
خرجت من هذه المراجعة بأولويات محددة: إيقاف الخطوط غير المستخدمة، وضبط تأجيل الملفات، ثم تعطيل الإضافات التي لا أستعملها.
3. الخطوة الأولى: إطفاء خطوط Google في إضافة البريد
بدأت بالخطوط، لأنني لم أكن أحتاج إليها أصلًا. أوقفت تحميلها من الإضافة التي تستدعيها، بدل محاولة تحسين تحميل ملفات لا يستعملها الموقع.
كانت الخطوات التي اتبعتها:
- فتحت MailPoet ثم Settings.
- انتقلت إلى Advanced.
- أطفأت خيار تحميل Google Fonts، ثم حفظت الإعداد.
- فتحت LiteSpeed Cache ثم Toolbox، وضغطت Purge All.
الخطوة الأخيرة تمسح الذاكرة المؤقتة، أي النسخ المحفوظة لتسريع تقديم الصفحات، حتى لا أتابع تقييم نسخة قديمة. وكررت Purge All بعد كل خطوة لاحقة.
قد تختلف تسمية الخيار بحسب إصدار MailPoet؛ وقد يظهر تحميل هذه الموارد ضمن Load 3rd-party libraries. لذلك من المهم قراءة وصف الإعداد وفهم نطاقه قبل تغييره.
إن كان موقعك مختلفًا: ابحث عن مصدر الخطوط غير المستخدمة في القالب أو الإضافة التي تحمّلها، وأوقفها من المصدر المناسب، مع الاحتفاظ بالخطوط التي يعتمد عليها تصميمك.
4. الخطوة الثانية: تأجيل ملفات JavaScript في LiteSpeed Cache لتسريع موقع ووردبريس على الجوال
بعد الخطوط، انتقلت إلى طريقة تشغيل JavaScript. التأجيل هنا لا يعني حذف الملفات، بل تغيير توقيت تنفيذها حتى لا تتقدم كلها على ظهور الصفحة.
اتبعت هذا المسار:
- فتحت LiteSpeed Cache ثم Page Optimization.
- دخلت إلى JS Settings.
- ضبطت Load JS Deferred على Deferred، وليس Delayed.
- أبقيت JS Minify وJS Combine على OFF.
- حفظت الإعدادات، ثم ذهبت إلى Toolbox وضغطت Purge All.
الفرق بين الخيارين مهم: Deferred يشغّل الملفات بعد اكتمال قراءة بنية الصفحة، بينما Delayed يؤخر تشغيلها إلى تفاعل المستخدم. اخترت الأول لأنني أردت تعديل توقيت التنفيذ دون ربطه بتفاعل الزائر.
أما JS Minify فيقلل حجم الشيفرة بإزالة أجزاء مثل المسافات والتعليقات، وJS Combine يجمع ملفاتها. فضلت إبقاءهما مطفأين لتقليل احتمالات مشكلات التوافق، وعدم تغيير عدة أشياء معًا.
إن كان موقعك مختلفًا: ابحث عن إعداد تأجيل JavaScript في أداة التحسين التي تستخدمها، ولا تجمع بين أدوات تؤدي الوظيفة نفسها. اختبر الوظائف الأساسية بعد التعديل.
5. مشكلة غير متوقعة: الوضع الليلي وكيف حللتها
لم يمر تأجيل الملفات دون أثر جانبي. سكربت الوضع الليلي تأجل أيضًا، فصارت الصفحة تظهر بيضاء لحظة قبل أن تتحول إلى اللون الداكن.
كان هذا مثالًا واضحًا على أن الإعداد المفيد للأداء قد يحتاج إلى استثناء. لا أريد تحسنًا في التقرير يقابله وميض مزعج عند فتح الصفحة.
عالجت المشكلة بهذه الخطوات:
- فتحت LiteSpeed Cache ثم Page Optimization.
- انتقلت إلى Tuning.
- أضفت كلمة
midad-modeفي حقل JS Deferred / Delayed Excludes. - حفظت الإعدادات، ثم ضغطت Purge All من Toolbox.
هذا الحقل يستثني الملفات المطابقة من التأجيل، فسمح لسكربت الوضع الليلي بالعمل في التوقيت المطلوب بدل انتظار بقية الملفات.
ولاحقًا أصلحنا المشكلة داخل القالب نفسه في الإصدار 1.1.0، فلم يعد هذا الاستثناء ضروريًا. أذكره هنا بوصفه الحل الذي استخدمته أثناء التجربة، لا إعدادًا دائمًا يجب إضافته في كل موقع.
إن كان موقعك مختلفًا: لا تنسخ كلمة الاستثناء نفسها؛ حدّد السكربت المسؤول عن الوظيفة المتأثرة، ثم استثنه عند الحاجة، أو عالج السبب داخل القالب أو الإضافة.
6. الخطوة الثالثة: تعطيل الإضافات غير المستخدمة
بعد ذلك عطّلت إضافات Hostinger التي لا أستخدمها. وكانت Hostinger Reach من الإضافات التي حمّلت سكربتًا خارجيًا بلا حاجة لديّ.
اتبعت خطوات مباشرة:
- فتحت Plugins ثم Installed Plugins.
- حددت إضافات Hostinger غير المستخدمة.
- ضغطت Deactivate للإضافات التي قررت تعطيلها.
- عدت إلى LiteSpeed Cache ثم Toolbox وضغطت Purge All.
لم يكن هدفي الوصول إلى أقل عدد ممكن من الإضافات. أردت أن تكون لكل إضافة وظيفة أحتاج إليها، وأن أفهم ما تضيفه إلى الصفحة.
إن كان موقعك مختلفًا: راجع الإضافات بحسب استخدامها واعتماد الموقع عليها، لا بحسب اسم الشركة المطورة. ابدأ بما تعرف أنك لا تستخدمه، واترك الإضافات الضرورية لوظائفك.
7. النتيجة النهائية بالأرقام
بعد هذه التعديلات، ارتفعت نتيجة الأداء على الجوال إلى 87. والأهم أن مؤشرات ظهور المحتوى تحسنت أيضًا؛ لم يكن التغير مقتصرًا على الدرجة الإجمالية.
| المؤشر | قبل التحسين | بعد التحسين |
|---|---|---|
| الأداء على الجوال | 75 | 87 |
| First Contentful Paint | 2.8 ثانية | 1.3 ثانية |
| Largest Contentful Paint | 4.7 ثانية | 3.8 ثانية |
| Speed Index | 5.1 ثانية | 2.9 ثانية |
| Total Blocking Time | 10 ملي ثانية | غير متاح في هذه المقارنة |
| Cumulative Layout Shift | 0 | غير متاح في هذه المقارنة |
وحصلت إمكانية الوصول وأفضل الممارسات وSEO، أي فحوص تحسين الظهور لمحركات البحث، على 100 بعد التحسين. اكتفيت بعرض النتيجة النهائية لهذه الفئات دون افتراض درجات سابقة لها.
هذه حصيلة التغييرات مجتمعة. الأرقام هنا تقارن البداية بالنهاية، ولا تحدد أثر كل إعداد منفردًا. وهي نتيجة تجربتي، وليست وعدًا بالنتيجة نفسها لكل موقع.
8. ما الذي بقي، ومتى تتوقف عن التحسين
بقيت jQuery تؤخر الصفحة نحو ثانية، لكن إضافة البريد تحتاج إليها. لذلك قررت ألا أؤجلها، لأن ذلك قد يكسر نموذج الاشتراك.
كان يمكنني الاستمرار في ملاحقة الدرجة، لكن نموذجًا يعمل أهم عندي من تحسين إضافي قد يعطله. هذه كانت حدود التجربة التي اخترت الوقوف عندها.
وبقي أيضًا توفير محتمل بنحو 98 كيلوبايت من خلال ضغط الصور إلى WebP، وهي صيغة صور تساعد على تقليل حجم الملفات. هذا تحسين متبقٍ، وليس إنجازًا احتسبته ضمن الأرقام السابقة.
بالنسبة إليّ، وقت التوقف يأتي حين يصبح التعديل التالي أقل وضوحًا في فائدته، وأعلى مخاطرة على وظيفة أحتاج إليها. أحتفظ به للمراجعة لاحقًا بدل تفعيله لمجرد وجود توصية في التقرير.
تعلمت من هذه الساعة أن تسريع الموقع يبدأ أحيانًا من تقليل ما يحمّله، قبل إضافة أدوات جديدة. والأهم أن أفهم التغيير وأعرف كيف أتراجع عنه.
هذه قائمة الفحص التي يمكن نسخها لتكرار الفكرة:
- أسجّل نتيجة الجوال والمؤشرات قبل التعديل.
- أحدد الخطوط والملفات التي لا أستخدمها.
- أوقف تحميل الخطوط غير الضرورية من مصدرها.
- أضبط تأجيل JavaScript وأختبر الوظائف.
- أراجع الوضع الليلي ونموذج الاشتراك.
- أعطّل الإضافات غير المستخدمة.
- أنفّذ Purge All بعد كل خطوة.
- أقارن النتائج وأترك الملفات الضرورية دون مجازفة.
هل تضمن هذه الخطوات الوصول إلى 87؟
لا. هذه نتيجة موقعي، ويتوقف التحسن في غيره على الملفات والإضافات التي يستخدمها.
لماذا اخترت Deferred بدل Delayed؟
أردت تأجيل التنفيذ إلى ما بعد قراءة بنية الصفحة، دون انتظار تفاعل الزائر.
هل يجب أن أضيف استثناء midad-mode؟
ليس تلقائيًا؛ كان حلًا لمشكلتي، ولم يعد ضروريًا بعد إصلاحها في الإصدار 1.1.0.
اترك تعليقاً