بهترین افزونه کش وردپرس؛ کدام برای شما مناسب است؟

هفتهٔ گذشته در ممیزی دامنه‌ای با ۴۰۰ محصول، سه افزونهٔ کش هم‌زمان فعال دیدیم؛ صفحهٔ سبد خرید هم کش می‌شد و سفارش‌ها در لاگ گم شده بودند. صاحب سایت انتظار «سرعت» داشت و به‌جای آن، چند تماس مشتری عصبانی در هفته می‌گرفت. این مقاله انتخاب افزونهٔ کش را از یک رأی سلیقه‌ای به تصمیم زیرساختی تبدیل می‌کند: معیارهای آزمون، سه سناریوی هاست اشتراکی، سرور مجازی و فروشگاه پرترافیک، جدول مقایسه و اشتباه‌های رایج.

چرا کش، نخستین اهرم سرعت وردپرس است

کش یعنی پاسخ آماده. به‌جای اینکه وردپرس با هر بازدید چند پرس‌وجوی دیتابیس اجرا کند و صفحه را از صفر بسازد، نسخهٔ ساخته‌شده تحویل داده می‌شود؛ نتیجه در TTFB (زمان تا اولین بایت) دیده می‌شود و TTFB، سقف همهٔ شاخص‌های بعدی است.

طبق مستندات web.dev گوگل (گردآوری آبان ۱۴۰۵)، آستانهٔ «خوب» برای شاخص LCP (بزرگ‌ترین عنصر محتوایی) برابر ۲٫۵ ثانیه است. اگر سرور دو ثانیه را صرف ساخت صفحه کند، بهینه‌سازی تصویر و فونت جبرانش نمی‌کند؛ اول باید ساخت صفحه کوتاه شود، بعد بقیهٔ کارها.

میدان رقابت هم بزرگ است: طبق W3Techs (گردآوری آبان ۱۴۰۵) حدود ۴۳٪ کل سایت‌های وب با وردپرس ساخته شده‌اند. یعنی رقبای شما همان گلوگاه را دارند؛ برنده کسی است که پاسخش زودتر می‌رسد. چارچوب کلی‌تر سرعت را در راهنمای سرعت و کارایی وردپرس خوشهٔ ما بخوانید.

به تجربهٔ ما، پیش از نصب هر افزونه‌ای یک عدد پایه با PageSpeed Insights بگیرید و اسکرین‌شات ذخیره کنید؛ چون بدون عددِ قبل و بعد، بحث کش به حدس تبدیل می‌شود.

معیارهای انتخاب افزونهٔ کش در پنج آزمون

همهٔ افزونه‌های کش سه کار را ادعا می‌کنند؛ تفاوت در جزئیات اجراست. پنج آزمون زیر را روی هر گزینه اجرا کنید و هر گزینه‌ای که جواب روشن نداشت، از فهرست حذف شود.

• نوع کش: کش صفحه (Page Cache)، کش آبجکت (Object Cache) یا هر دو؛ روی هاست اشتراکی معمولاً فقط نوع صفحه ممکن است.
• سازگاری با ووکامرس: آیا سبد خرید و پرداخت را خودکار مستثنا می‌کند یا باید دستی پیدا و تنظیم کنید؟
• پاک‌سازی خودکار: وقتی مقاله یا محصول جدید منتشر می‌شود، کش کدام صفحات خالی می‌شود؟
• سربار پیکربندی: چند صفحه تنظیم دارد؟ اگر هفتهٔ بعد کسی سراغش نرود، چه چیزی می‌شکند؟
• لاگ و ابزار دیباگ: در خرابی، می‌توانید بفهمید کدام لایه پاسخ داده است؟

سناریو را پیش از گزینه مشخص کنید؛ ترتیب مهم است. اگر اول افزونه را انتخاب کنید و بعد دنبال توجیه فنی‌اش بگردید، دام «افزونهٔ چندکاره» می‌افتید؛ همان افزونه‌هایی که کش، مینیفای و بهینه‌سازی تصویر را یک‌جا ادعا می‌کنند و در خرابی هیچ‌کدام را درست انجام نمی‌دهند. روش ما در ممیزی‌ها سه سؤال است: سایت روی چه هاستی میزبان است؟ چند درصد بازدیدها کاربر واردشده است؟ و انتشار محتوا چه ریتمی دارد؟ جواب این سه سؤال، سناریو را تعیین می‌کند و سناریو، گزینه را.

جدول بخش بعد از سناریوها همین آزمون‌ها را به تصمیم تبدیل می‌کند؛ اول سناریوی خود را بشناسید، بعد گزینه را بچینید.

بهترین افزونه کش وردپرس در سناریوی هاست اشتراکی

هاست اشتراکی یعنی منابع مشترک، بدون دسترسی root و سقف مشخص برای پردازنده. در این محیط کش آبجکت معمولاً در دسترس نیست؛ تمرکز باید روی کش صفحهٔ سبک باشد و بس.

اگر سرور شما LiteSpeed است، افزونهٔ رایگان LiteSpeed Cache انتخاب اول است؛ چون از کش سطح سرور استفاده می‌کند و بار PHP را واقعاً کم می‌کند، نه صرفاً صفحه را در یک پوشه ذخیره. اگر Apache هستید، یک افزونهٔ کش صفحهٔ معتبر با minify کافی است؛ تنظیم‌های تهاجمی مثل ترکیب همهٔ جاوااسکریپت‌ها را خاموش نگه دارید، چون با اسکریپت‌های پویا و فرم‌ها تداخل می‌سازد.

یک پیکربندی آرام و قابل‌اعتماد برای شروع: TTL دوازده ساعت برای صفحات عمومی، استثنای کامل برای سبد خرید و حساب کاربری، و پاک‌سازی خودکار هنگام انتشار.

به تجربهٔ ما روی هاست اشتراکی، افزونه‌های چندکاریِ سنگین بیشترین دردسر را می‌سازند؛ چون دو لایهٔ کش با تنظیم‌های متفاوت، دیباگ را به کاری چندروزه تبدیل می‌کند. یکی را انتخاب کنید و عمیق تنظیمش کنید.

سناریوی سرور مجازی: کش آبجکت با Redis

روی VPS دو چیز به شما می‌رسد: دسترسی root و حافظهٔ قابل مدیریت. حالا می‌توانید Redis یا Memcached را به‌عنوان کش آبجکت بگذارید تا پرس‌وجوهای تکراری دیتابیس از حافظه پاسخ بگیرند و دیتابیس نفس بکشد.

ترتیب پیشنهادی ما: اول کش صفحه، بعد افزونهٔ اتصال Redis Object Cache، بعد اندازه‌گیری. با دستور redis-cli روی سرور، نرخ hit را ببینید؛ به تجربهٔ ما نرخ سالم معمولاً بالای ۵۰ درصد است. اگر زیر این خط ماندید، یعنی کلیدها درست ساخته نمی‌شوند و باید افزونه‌های متضاد را حذف کنید.

پایش را هم از روز اول ساده نگه دارید: یک کرون هفتگی که مصرف حافظهٔ Redis را لاگ کند و هشدار بدهد اگر از ۷۰ درصد رم سرور گذشت. این عدد ساده، همان خطی است که میان «کش کمک می‌کند» و «سرور خفه شده» تفکیک قائل می‌شود. به تجربهٔ ما بیشتر مشکلات کش آبجکت از خود افزونه شروع نمی‌شود؛ از سقف حافظه شروع می‌شود.

کش آبجکت جایی می‌درخشد که صفحه برای هر کاربر فرق می‌کند: جستجوی داخلی، فیلتر محصولات، پنل کاربری. کش صفحه اینجا ساکت است؛ کش آبجکت همان‌جا کار می‌کند.

محدودیت را هم بپذیرید: Redis حافظه می‌خورد. روی سرور کوچک با ۱ گیگابایت رم، اول ارتقای رم را در بودجه بگذارید؛ کش ناقص، بدتر از بی‌کشی است.

فروشگاه پرترافیک: آرایش چندلایهٔ کش

فروشگاه پرترافیک دو چهره دارد: صفحات عمومی سنگین و صفحات شخصی‌شدهٔ حیاتی. پاسخ، سه لایهٔ هم‌زمان است؛ کش صفحه برای دسته‌ها و صفحات محصول، کش آبجکت برای پرس‌وجوهای فیلتر، و CDN لبه برای تصاویر و فایل‌های ثابت.

طبق مستندات رسمی WooCommerce (گردآوری آبان ۱۴۰۵)، صفحات سبد خرید و پرداخت نباید کش شوند. این استثنا را هم در افزونهٔ کش و هم در CDN باید صریح تنظیم کنید؛ وگرنه کاربر سبدِ کاربر دیگر را می‌بیند و اعتماد خرید، یک‌شبه می‌سوزد. تصمیم‌های فروشگاهی را در صفحهٔ سئو برای فروشگاه اینترنتی هم دنبال کنید.

یک ترتیب اجرایی که برای ما جواب داده: اول CDN با پلن پایه، بعد کش صفحه، آخر کش آبجکت؛ بین هر لایه یک روز فاصله و بررسی لاگ. سه تغییر هم‌زمان یعنی وقتی چیزی شکست، ندانید چه شکست.

جدول مقایسه: کدام سناریو برای کدام سایت؟

*طبق صفحهٔ قیمت‌گذاری WP Rocket (گردآوری آبان ۱۴۰۵)، نسخهٔ سالانهٔ این افزونهٔ کش صفحه ۵۹ دلار است؛ بقیهٔ ابزارهای جدول پلن رایگان دارند. زمان‌ها تخمین اجرای تیم ماست، نه آمار بازار.

هیچ سطر جدول یک نام واحد برای همه ندارد؛ معیار، زیرساخت است نه نام. ستون «برای چه کسی» را با وضعیت امروز سایت خودتان تطبیق دهید، نه با رؤیای شش ماه بعد.

سه اشتباهی که کش را به دشمن سایت تبدیل می‌کند

اشتباه اول، کش کردن صفحات شخصی‌سازی‌شده است. سبد خرید، پرداخت و حساب کاربری باید در همهٔ لایه‌ها مستثنا باشند؛ یک استثنای جاافتاده در CDN، همهٔ تنظیم درست افزونه را بی‌اثر می‌کند.

اشتباه دوم، TTL نامرتبط با ریتم انتشار است. اگر روزی دو مقاله منتشر می‌کنید و کش صفحه ۴۸ ساعت است، خواننده نسخهٔ کهنه می‌بیند؛ گوگل هم همین‌طور.

اشتباه سوم، تست‌نکردن بعد از تغییر است. با ابزار Query Monitor ببینید کدام کوئری‌ها اجرا می‌شوند و با مرورگر ناشناس صفحات کلیدی را چک کنید؛ کش برای کاربر واردشده رفتار متفاوتی دارد.

برای اینکه TTL بی‌حس‌ومار نشود، آن را به ریتم تقویم محتوا گره بزنید: هفته‌ای یک مقاله یعنی TTL دوازده تا بیست‌وچهار ساعت؛ ماهی یکی یعنی چهل‌وهشت ساعت. این عدد را در تقویم محتوایی بنویسید تا نفر بعدی تیم حدس نزند. آزمون سریعش هم ساده است: بعد از انتشار، صفحهٔ تازه را در پنجرهٔ ناشناس باز کنید؛ اگر نسخهٔ کهنه دیدید، پاک‌سازی خودکار درست کار نمی‌کند. اعتراف روش‌شناسانه: این بازه‌ها تجربهٔ اجرایی ما هستند، نه استاندارد بازار؛ سایتی با ویرایشگری پرتعداد ممکن است ترکیب دیگری بخواهد.

به تجربهٔ ما بیشتر خرابی‌های کش در ساعات اول انتشار محتوای جدید رخ می‌دهد؛ ساعت انتشار را به ساعت کاری منتقل کنید تا دیباگ در بیداری انجام شود، نه در نیمه‌شب با چای سرد.

سوئیت چطور کنار کش شما می‌ایستد

ویژن‌پرایم سوئیت جانشین افزونهٔ کش شما نیست و چنین ادعایی هم ندارد؛ لایهٔ دیگرِ زنجیره را می‌پوشاند: رصد، فرصت‌های شماره‌دار، تولید و انتشار امن، گزارش هفتگی. جزئیات هر ماژول در صفحهٔ امکانات پلتفرم ویژن‌پرایم سوئیت آمده است.

در سمت زیرساخت، افزونهٔ اتصال وردپرس نسخهٔ ۱٫۶٫۴ با کلید اختصاصی هر سایت، توقف اضطراری و ۳۰ گیت امنیتی کار می‌کند تا انتشار، وضعیت سایت را به‌هم نریزد. در سمت تولید، خط کیفیت ۳۱ گایته و ۹۰۰+ تست خودکار، محتوای تأییدشده را قبل از ورود به سایت آماده می‌کند.

در پلن پیشرو با ۷٫۹ میلیون تومان در ماه، انتشار خودکار محتوای تأییدشده و پایش مستمر اپراتور اضافه می‌شود؛ یعنی ریتم انتشار منظم جای شوک ناگهانی را می‌گیرد و پیکربندی کش شما آرام‌تر می‌ماند. اثر همین نظم را در مطالعات موردی سوئیت با اعداد ببینید.

یک نکته از عمل: در کیس ثبت‌شدهٔ سوئیت liuna، در بازهٔ اندازه‌گیری سه‌ماهه، ۲۸۶ صفحهٔ محصول به صفحهٔ اول رسید؛ زیرساخت آن کار، همین نظم انتشار برنامه‌ریزی‌شده بود، نه شوک محتوایی یک‌روزه. کش پایدار و ریتم انتشار منظم، دو روی همان سکه‌اند.

جمع‌بندی: تصمیم پنج‌دقیقه‌ای

سه قدم برای امروز: اول، عدد پایهٔ سرعت را با PageSpeed Insights بگیرید و ذخیره کنید. دوم، سناریوی خود را از جدول مقایسه انتخاب کنید؛ هاست اشتراکی، سرور مجازی یا فروشگاه پرترافیک. سوم، پیکربندی را با استثناهای ووکامرس و یک TTL منظم اجرا کنید و یک هفته لاگ را زیر نظر بگیرید.

اگر گره اصلی شما کش نیست و به زنجیرهٔ رصد، تولید و انتشار امن نیاز دارید، نمی‌دانید از کجا شروع کنید؟ ممیزی رایگان دامنه گلوگاه‌ها را شماره‌دار نشان می‌دهد؛ سپس دموی پلتفرم را ببینید.

رصد ما، رشد شما.