راهنمای نصب و پیکربندی Page Cache برای وردپرس در Windows Server و IIS

در وب‌سایت‌های برپایه وردپرس، پیش‌بافته‌سازی صفحات (Page Cache) یکی از کلیدی‌ترین اقدامات جهت بهینه‌سازی عملکرد محسوب می‌شود.

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

در سرورهای مبتنی بر لینوکس، بخش عمده‌ای از افزونه‌های کش وردپرس بر پایه قواعد .htaccess یا تنظیمات سروری اختصاصی برای Apache و Nginx عمل می‌کنند.

با این حال، در محیط‌های Windows Server که از وب‌سرور IIS استفاده می‌کنند، امکان اعمال مستقیم برخی از این قواعد وجود ندارد.

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

در نوشتار حاضر، فرآیند نصب و پیکربندی Page Cache با استفاده از افزونه WP-Optimize در محیطی متشکل از Windows Server، IIS، PHP، MySQL و WordPress به صورت عملی بررسی گردیده است.

در طول این فرآیند، پیکربندی موجود IIS حفظ شده و از افزودن قواعد غیرضروری یا تکراری به سرور خودداری شده است.

ارزیابی معماری فعلی سرور

بستر نرم‌افزاری و زیرساختی فرایند مذکور شامل مؤلفه‌های زیر است.

• سیستم‌عامل: Windows Server
• وب‌سرور: IIS Web Server
• محیط اجرا: PHP 8.5.9 و MySQL Community Server 26.7.0
• سیستم مدیریت محتوا: WordPress 7.0.3 (در ساختار شبکه/Multisite)
• بهینه‌سازی‌های سطح سرور: HTTPS، فشرده‌سازی Gzip در سطح IIS، کش فایل‌های استاتیک در سطح IIS

در فایل web.config فعلی روی IIS، کش مرورگر برای فایل‌های استاتیک از قبل با استفاده از ساختار زیر، فعال شده است.

<staticContent>
<clientCache
cacheControlMode="UseMaxAge"
cacheControlMaxAge="4.00:00:00" />
</staticContent>

به لطف این پیکربندی، فایل‌های استاتیک مانند CSS، JavaScript و تصاویر به مدت چهار روز در مرورگر کاربر ذخیره می‌شوند.

بنابراین، مدیریت کش فایل‌های استاتیک مستقیماً توسط IIS انجام می‌شود و نیازی به فعال‌سازی مجدد این قابلیت از طریق افزونه وجود ندارد.

استراتژی Page Cache و انتخاب افزونه

برای محیط Windows Server و IIS، اتخاذ راه‌حلی که وابستگی به فایل‌های پیکربندی Apache نداشته باشد مد نظر قرار گرفت.

بر همین اساس، افزونه WP-Optimize از مخزن رسمی وردپرس انتخاب شد.

با توجه به استفاده از ساختار چندسایته (Multisite) در وردپرس، افزونه در سطح شبکه فعال‌سازی گردید؛ اما تنظیمات مربوط به Page Cache به‌صورت ایزوله از پنل مدیریت هر سایت پیکربندی شد.

همچنین جهت پیش‌گیری از افت عملکرد، ویژگی‌های جانبی و غیرضروری موجود در مراحل نصب افزونه فعال نشدند.

فعال‌سازی Page Cache و پیکربندی WP_CACHE

با مراجعه به مسیر WP-Optimize ← Cache ← Page Cache در پنل مدیریت، گزینه “Enable page caching” فعال گردید.

پس از انجام این عملیات، هشدار زیر در فایل گزارش خطاهای PHP (Error Log) مشاهده شد:
[ERROR] : WP_CACHE constant is not present in wp-config.php

بررسی‌ها نشان داد که هنگام نصب افزونه، عبارت WP_CACHE به صورت خودکار در فایل wp-config.php اضافه شده بود، اما قرارگیری آن در همان خطِ مربوط به یک خط توضیحی (Comment)، مانع از پردازش صحیح آن توسط سیستم می‌شد.

با مجزا کردن این عبارت، مشکل برطرف گردید:

define('WP_CACHE', true);

پس از اعمال این اصلاحیه و فراخوانی مجدد صفحات، هشدار مربوطه از گزارش خطاهای PHP برطرف شد و تولید موفقیت‌آمیز فایل‌های کش (index.php, index.htm, index.html) در مسیر سرور (wp-content/cache/wpo-cache/…) تأیید گردید.

تنظیمات عملکرد و کش

در بخش تنظیمات افزونه WP-Optimize، پیکربندی به صورت زیر اعمال گردید تا بدون آسیب به ساختار پویا (Dynamic) سایت، بیشترین بازدهی حاصل گردد.

• Enable page caching:
  فعال.
  آغاز فرآیند پایه کش صفحات.
• Cache lifespan:
  ۱۰ ساعت.
  مقدار پیش‌فرض ۲۴ ساعته به‌منظور حفظ تازگی محتوا و جلوگیری از اختلال در مکانیسم nonce وردپرس، به ۱۰ ساعت کاهش یافت.
• Serve cached pages to logged-in users:
  غیرفعال.
  جهت اطمینان از دریافت محتوای کاملاً به‌روز و پویا توسط مدیران و کاربران واردشده به حساب کاربری.
• Generate separate files for mobile devices:
  غیرفعال.
  در طراحی‌های مدرن و واکنش‌گرا (Responsive) که ساختار HTML تغییر نمی‌کند، ایجاد فایل کش مجزا برای دستگاه‌های همراه غیرضروری است.
• Gzip compression:
  غیرفعال در افزونه.
  به دلیل فعال بودن این قابلیت در سطح IIS، جهت جلوگیری از تداخل و فشرده‌سازی دوباره، در افزونه فعال نگردید.
• Automatically preload content…:
  فعال.
  بازسازی خودکار محتوای کش پس از پاک‌سازی آن را تضمین می‌کند.

استثناها (Cache Exclusion) و عدم استفاده از IIS Output Cache

گزینه‌های پیشرفته استثناسازی در افزونه (بر اساس URL، کوکی و مرورگر) بررسی شدند.

به منظور حفظ رفتار استاندارد کش در وردپرس و جلوگیری از پیچیدگی‌های بی‌مورد، قوانین استثنای گسترده تعریف نگردید.

همچنین بهره‌گیری از مکانیسم داخلی “Output Caching” در IIS ارزیابی شد.

با این حال، از آنجا که WP-Optimize لایه کش HTML مطلوب را به صورت کامل فراهم می‌کرد، ایجاد لایه دوم کش HTML غیرضروری تشخیص داده شد؛ چرا که می‌توانست موجب تداخل در عملکرد سیستم شود.

مرحله ارزیابی و تأیید صحت عملکرد

جهت اطمینان از کارکرد صحیح سیستم، بررسی‌های جامع زیر انجام گرفت.

۱. کنترل سیستم فایل: تشکیل فایل‌های استاتیک با پسوند .html در مسیر مربوطه روی سرور تأیید شد.

۲. بررسی کد منبع (Source Code): در انتهای کد منبع صفحات بازدیدشده، امضای تأیید WP-Optimize به صورت زیر مشاهده گردید:

<!– Cached by WP-Optimize (gzip) – https://teamupdraft.com/wp-optimize/ – Last modified: 11 August 2026 07:50 (UTC:3) –>

۳. بررسی گزارش‌های سرور: پاک بودن فایل گزارش خطاهای PHP و عدم تکرار خطای WP_CACHE احراز گردید.

نتیجه‌گیری و نمودار معماری

پیاده‌سازی Page Cache برای وردپرس در محیط Windows Server و IIS بدون وابستگی به قواعد .htaccess و با رعایت اصل تفکیک وظایف در لایه‌های مختلف، با موفقیت انجام شد.

نمودار متنی زیر فرآیند پردازش درخواست‌های کاربران را در لایه‌های مختلف این معماری نشان می‌دهد:

[ Windows Server / IIS ]

• مدیریت HTTPS
• فشرده‌سازی Gzip
• کش فایل‌های استاتیک در مرورگر (۴ روز)

[ WP-Optimize ]

• (Page Cache)
• [ Cache HIT ] [ Cache MISS ]
• ارائه مستقیم پردازش وردپرس
• HTML استاتیک و PHP

[ MySQL ]

تشریح تفصیلی جریان پردازش درخواست‌ها

۱. لایه سرور (IIS):

با ورود درخواست به سرور، IIS مسئولیت مدیریت ارتباط امن (HTTPS)، ارائه فایل‌های استاتیکِ کش‌شده (نظیر رسانه‌ها، CSS و JS) و فشرده‌سازی عمومی Gzip را بر عهده می‌گیرد و سپس درخواست را جهت پردازش به وردپرس ارجاع می‌دهد.

۲. لایه کش (WP-Optimize):

حالت Cache HIT (یافت‌شده در کش): اگر نسخه استاتیک HTML صفحه درخواستی قبلاً ساخته شده باشد، درخواست بدون درگیر کردن لایه‌های PHP و پایگاه داده، مستقیماً از طریق IIS به کاربر تحویل داده می‌شود.

این سناریو مصرف منابع سرور را به حداقل ممکن می‌رساند.

حالت Cache MISS (یافت‌نشده در کش): اگر صفحه هنوز کش نشده باشد، محتوا تغییر کرده باشد یا زمان اعتبار کش به پایان رسیده باشد، درخواست به فرآیند “پردازش و تولید” هدایت می‌شود.

۳. لایه پردازش و کامپایل پویا (PHP + WordPress + MySQL):

ارجاع درخواست: درخواست صفحه به مفسر PHP منتقل شده و هسته وردپرس بارگذاری می‌شود.

استعلام داده‌ها: وردپرس جهت شکل‌دهی به محتوای صفحه، تنظیمات پوسته، داده‌های افزونه‌ها و دسترسی‌های کاربران، استعلام‌های SQL را به پایگاه داده MySQL ارسال می‌کند.

تولید خروجی HTML: داده‌های دریافتی از پایگاه داده توسط PHP پردازش شده و به یک سند HTML پویا تبدیل می‌شوند.

ذخیره‌سازی در کش: یک نسخه از این خروجی نهایی HTML توسط WP-Optimize در مسیر wp-content/cache/wpo-cache/… به‌صورت فایل .html ذخیره می‌شود (تا در بازدید بعدی، حالت Cache HIT رخ دهد. )

ارسال پاسخ: محتوای تولیدشده برای کاربر ارسال می‌گردد.

ساختار نهایی مورد نظر با واگذاری مدیریت فایل‌های استاتیک و فشرده‌سازی به IIS، سپردن پیش‌بافته‌سازی صفحات پویا به WP-Optimize، و محدود کردن پردازش‌های سنگین PHP و MySQL تنها به موارد ضروری، موجب بهره‌وری حداکثری از منابع سخت‌افزاری سرور (CPU و RAM) خواهد شد…

نسخه ترکی