إعدادات LiteSpeed Cache في WordPress 2026: ضبط الكاش بدون تعارض

إعدادات LiteSpeed Cache في WordPress تحتاج فهم نوع الخادم قبل تشغيل الخيارات. الإضافة نفسها مجانية ومفتوحة المصدر، لكن Page Cache على مستوى الخادم تعتمد على LiteSpeed Web Server أوOpenLiteSpeed أوLiteSpeed Web ADC أوQUIC.cloud. أما كثير من وظائف التحسين مثل الصور وCSS/JS فتعمل حتى على خوادم أخرى.

الخلاصة: لا تبدأ بتشغيل كل الخيارات. تأكد أولًا أن Server Cache متاحة، فعّل Cache للزوار، اترك Cache Logged-in Users مغلقة ما لم تكن لديك حالة واضحة، اضبط Purge بعناية، ثم اختبر Object Cache والصور وCSS/JS كل مجموعة على حدة. في متجر WooCommerce اختبر Cart وCheckout وMy Account بعد أي تغيير.

إذا كنت تريد شرح الإضافة من الصفر ومزاياها العامة، راجع شرح LiteSpeed Cache الشامل. هذه الصفحة مخصصة لـالإعدادات والضبط العملي حتى لا تنافس الدليل العام.

الحالة الحالية للإضافة في 2026

وقت تحديث هذا الدليل، WordPress.org تعرض LiteSpeed Cache بإصدار 7.9 الصادر في أغسطس 2026. الإصدار رفع الحد الأدنى المدعوم إلى WordPress 6.0 وPHP 7.4، وحسّن WebP/AVIF وObject Cache وتكامل Cloudflare.

1. هل Server Cache تعمل عندك؟

هذه أول نقطة يجب حسمها. LiteSpeed توضح أن وظائف Page Cache تحتاج محرك LiteSpeed server-level cache. يمكن أن تعمل عبر:

• LiteSpeed Web Server.
• OpenLiteSpeed.
• LiteSpeed Web ADC.
• QUIC.cloud CDN في السيناريوهات المدعومة.

لو الاستضافة Apache أوNginx بدون طبقة LiteSpeed، ستظل بعض Optimization features متاحة، لكن لا تفترض أنك تحصل على نفس Server Cache.

2. Cache → Enable Cache

إذا البيئة تدعم LSCache، اجعل Enable Cache = ON للبدء. بعد التفعيل:

1. افتح الموقع كزائر غير مسجل.
2. افحص Response headers أوأدوات LiteSpeed للتأكد من HIT/MISS.
3. حدث الصفحة أكثر من مرة.
4. تأكد أن الصفحات الديناميكية الحساسة مستثناة.

3. Cache Logged-in Users

لا أفعّلها افتراضيًا. الإصدار 7.9 غيّر القيمة الافتراضية لـCache Login إلى false. المستخدم المسجل قد يرى محتوى شخصيًا أوAdmin bar أوأسعارًا/حالات تختلف حسب الحساب.

فعّلها فقط إذا:

• تعرف لماذا تحتاج Private Cache.
• اختبرت WooCommerce/Membership.
• لا توجد بيانات شخصية يمكن أن تختلط بين Sessions.

4. Cache Commenters وREST وLogin

لا تنقل إعدادات جاهزة من موقع آخر. موقع Blog بتعليقات نشطة يختلف عن متجر أوMembership. راقب Routes التي تنتج محتوى متغيرًا وCookies التي يعتمد عليها الموقع.

5. TTL: لا تطارد أرقامًا سحرية

TTL تحدد مدة صلاحية النسخة المخزنة. القرار يعتمد على معدل تغير المحتوى:

6. Purge: أهم من TTL في المواقع الديناميكية

الموقع يجب أن يمسح النسخة الصحيحة عندما:

• يتم تحديث Post/Product.
• يتغير Category archive.
• يتغير Stock أوPrice.
• يتغير Menu أوWidget مؤثر.

لا تستخدم Purge All بعد كل تعديل صغير إذا تستطيع استهداف الصفحات المتأثرة.

7. WooCommerce: الصفحات التي يجب اختبارها

• Cart.
• Checkout.
• My Account.
• Mini Cart.
• Variable products.
• Coupons.
• Stock.

LiteSpeed لديها تكاملات مع WooCommerce، لكن Plugins أخرى قد تضيف Cookies أوAJAX behavior يحتاج اختبارًا فعليًا.

8. Browser Cache

Browser Cache مفيدة للملفات الثابتة مثل الصور وCSS وJS. لكن لا تضع مدة ضخمة لملف يتغير بنفس الاسم إذا لا تستخدم Versioning/Cache busting.

9. Object Cache: Redis أوMemcached

Object Cache تختلف عن Page Cache. فائدتها تظهر عندما الموقع ينفذ Queries متكررة ويستطيع Redis/Memcached الاحتفاظ بنتائج Objects بين الطلبات.

قبل التفعيل:

• تأكد أن Redis/Memcached متاحة من الاستضافة.
• اختبر الاتصال.
• راقب Hit rate وDatabase load.
• لا تشغل Object Cache إضافية من Plugin ثانية.

10. Database Optimization

لا تجعل زر Clean All جزءًا من Routine يومية. قبل حذف Revisions أوTransients أوبيانات قديمة:

• خذ Backup.
• افهم ما سيُحذف.
• لا تحذف Tables/Options لا تعرف مصدرها.

Database cleanup ليست علاجًا تلقائيًا للبطء.

11. CSS Minify

Minify تقلل الحجم لكنها لا تعني أن الصفحة ستصبح أسرع دائمًا. اختبر:

• Frontend visual regression.
• Elementor/Woodmart CSS.
• Critical CSS.
• Cache purge بعد التغيير.

12. CSS Combine

في HTTP/2 وHTTP/3، Combine ليست ضرورة تلقائية. قد تزيد ملفًا واحدًا ضخمًا وتضر Cache granularity. اتركها OFF مبدئيًا، ثم اختبر إذا لديك سبب واضح.

13. Remove Unused CSS / UCSS

UCSS قد تقلل CSS غير المستخدمة، لكنها تحتاج QA على:

• Menus.
• Popups.
• WooCommerce states.
• Responsive breakpoints.
• Dynamic classes.

لا تعتمد على Screenshot للHomepage فقط.

14. JS Minify وDefer/Delay

هذه من أكثر الإعدادات التي تكسر وظائف الموقع. طبّق واحدة في كل مرة، ثم اختبر:

• Menu.
• Search.
• Forms.
• Slider.
• Add to Cart.
• Checkout.
• Payment gateway.

15. Delay JavaScript

Delay قد تحسن Lab metrics لكنها قد تؤخر Interaction مهمة. لا تؤخر Script لازمة لأول Click أوCheckout فقط للحصول على Score أعلى.

16. Lazy Load للصور

فعّل Lazy Load للصور خارج Above-the-fold، لكن استثنِ صورة LCP إذا Lazy loading تؤخر ظهورها.

17. WebP وAVIF

LiteSpeed Cache تدعم Workflows لتحسين الصور وصيغ حديثة، والإصدار 7.9 حسّن التعامل مع WebP/AVIF. راقب:

• جودة الصورة.
• Fallback.
• Cache بعد توليد الصيغ الجديدة.
• مساحة التخزين.

18. QUIC.cloud

QUIC.cloud يمكن أن تضيف CDN وخدمات Optimization مرتبطة بـLiteSpeed. لا تربطها تلقائيًا إذا لديك Cloudflare/CDN قائمة دون فهم من المسؤول عن DNS وCache وPurge.

19. Cloudflare + LiteSpeed Cache

يمكن استخدامهما معًا، لكن تجنب ازدواجية:

• Page rules/Cache rules متعارضة.
• Minify من الطرفين بلا اختبار.
• Purge غير متزامن.
• Cache HTML في Cloudflare لصفحات User-specific بلا Rules دقيقة.

20. Crawler

Cache Crawler قد تستهلك موارد كبيرة. لا تشغلها على Shared hosting أوCatalog ضخم بدون معرفة Limits الخادم.

21. Guest Mode / Guest Optimization

أي Feature تغير طريقة تقديم الصفحة للزيارة الأولى يجب اختبارها مع:

• Consent banners.
• Geo/currency.
• Personalization.
• Analytics.

22. Export/Import Settings

ميزة Export مفيدة قبل تجربة إعدادات جديدة أوعند إدارة Sites متشابهة، لكن لا تستورد Preset من موقع مختلف وتفترض أنها مناسبة؛ Theme وPlugins والاستضافة تختلف.

23. أفضل ترتيب للضبط

1. Server/Page Cache.
2. Purge وExclusions.
3. Browser Cache.
4. Object Cache إذا متاحة.
5. Image optimization.
6. CSS تحسين واحد في كل مرة.
7. JS تحسين واحد في كل مرة.
8. CDN.
9. قياس Field Data بعد الاستقرار.

24. كيف أعرف أن Cache تعمل؟

لا تعتمد على إحساس السرعة فقط. استخدم Response headers وأدوات LiteSpeed، وقارن TTFB للزيارة الأولى والثانية، وافحص أن المستخدم المسجل لا يحصل على Public cache غير مناسبة.

25. أخطاء شائعة

• تشغيل كل Page Optimization مرة واحدة.
• Cache Logged-in Users بدون حاجة.
• تشغيل أكثر من Cache Plugin.
• Combine + Minify + Delay ثم البحث عن سبب كسر Checkout.
• Lazy Load لصورة LCP.
• تفعيل Redis بدون Server Redis.
• استخدام Preset من YouTube بدون Staging.

إعدادات بداية محافظة

أسئلة شائعة

هل LiteSpeed Cache مجانية؟

نعم، Plugin مجانية ومفتوحة المصدر. بعض خدمات QUIC.cloud لها أنظمة حصص/خدمات مستقلة، لكنها ليست “نسخة Pro من Plugin”.

هل تعمل على Apache وNginx؟

وظائف Optimization كثيرة تعمل، لكن Server-level Page Cache تحتاج LiteSpeed server technology أوحل متوافق مذكور في وثائق LiteSpeed.

هل أفعّل Cache للمستخدمين المسجلين؟

ليس افتراضيًا. فعّلها فقط لحالة مدروسة واختبر Private content جيدًا.

هل أفضل إعدادات LiteSpeed واحدة لكل المواقع؟

لا. WooCommerce وMembership وElementor ومواقع الأخبار تختلف في الديناميكية والScripts والCache exclusions.

الخلاصة

أفضل إعداد LiteSpeed Cache ليس أكثر إعدادات ON؛ بل أقل مجموعة تحقق تحسنًا قابلًا للقياس بدون Regression. ثبّت Server Cache أولًا، ثم Purge وObject Cache والصور، وبعدها CSS/JS تدريجيًا. احتفظ بنسخة إعدادات قبل التجارب واختبر Critical flows بعد كل تغيير.

مصادر رسمية

• LiteSpeed Cache — WordPress.org
• LiteSpeed Cache Documentation
• Cache Settings Documentation