کش و زیرساخت

کش وردپرس چیست؟ تفاوت کش صفحه، مرورگر و آبجکت

انواع کش وردپرس را با مثال بشناسید؛ استثناهای ورود و پرداخت، پاکسازی پس از تغییر محتوا و روش بررسی کش صحیح را یاد بگیرید.

پاسخ کوتاه

کش، استفادهٔ دوباره از نتیجهٔ آماده است. کش صفحه HTML را نگه می‌دارد، کش مرورگر فایل‌ها را نزدیک کاربر ذخیره می‌کند و آبجکت کش بعضی نتایج محاسبه یا داده را بازاستفاده می‌کند. انتخاب درست به نوع درخواست و شخصی‌بودن محتوا وابسته است.

کش را با یک درخواست واقعی تصور کنید

فرض کنید یک مقالهٔ عمومی بارها خوانده می‌شود. وردپرس برای هر درخواست ممکن است تنظیمات، محتوا و قالب را ترکیب کند تا HTML ساخته شود. اگر نسخهٔ آمادهٔ همان خروجی برای بازدیدکنندهٔ بعدی معتبر باشد، می‌توان بخشی از این کار تکراری را حذف کرد.

حالا همان مثال را برای صفحهٔ «سفارش‌های من» در نظر بگیرید. خروجی به هویت کاربر وابسته است؛ نسخه‌ای که برای یک نفر درست است، برای دیگری درست نیست. بنابراین سؤال اول در طراحی کش این نیست که چه مدت ذخیره کنیم؛ این است که آیا این پاسخ اصولاً قابل اشتراک است.

برای هر مسیر مهم، سه ویژگی را یادداشت کنید: عمومی یا شخصی بودن، فاصلهٔ تغییر محتوا و رویدادی که نسخهٔ ذخیره‌شده را نامعتبر می‌کند. همین یادداشت ساده پایهٔ تصمیم دربارهٔ کش است.

هر لایه چه چیزی را نگه می‌دارد؟

کش صفحه خروجی یک صفحه را نگه می‌دارد و می‌تواند بار تولید HTML عمومی را کم کند. کش مرورگر معمولاً با هدرهای HTTP کنترل می‌شود و فایل‌هایی مثل CSS، JavaScript و تصویر را برای درخواست‌های بعدی روی دستگاه نگه می‌دارد.

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

وجود چند لایه الزاماً اشتباه نیست، اما هر لایه باید مسئولیت روشن داشته باشد. اگر CSS جدید را می‌بینید ولی HTML قدیمی است، یا برعکس، ممکن است اعتبار دو لایه با هم هماهنگ نباشد. یک نقشهٔ کوچک از مرورگر، لبه، سرور و برنامه تهیه کنید.

ورود، سبد و پرداخت را از ابتدا مشخص کنید

در پروژهٔ خودتان مسیرهای حساب کاربری، سبد، تسویه، پاسخ پرداخت، آزمون و داشبورد را پیدا کنید. صرفاً به یک فهرست عمومی اعتماد نکنید؛ ممکن است آدرس‌های سفارشی داشته باشید. درخواست‌های تغییردهندهٔ داده نیز نباید با پاسخ عمومی کش‌شده جایگزین شوند.

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

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

پاکسازی کش بخشی از انتشار محتواست

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

برای فایل‌های ثابت، نسخه‌گذاری آدرس می‌تواند مرورگر را به دریافت نسخهٔ تازه هدایت کند. برای HTML، سیاست پاکسازی باید با رویدادهای واقعی سایت هماهنگ باشد. پاکسازی کامل پس از هر کار کوچک می‌تواند هزینهٔ بازسازی کش را زیاد کند.

در یک فروشگاه فرضی، تغییر موجودی فقط مسئلهٔ سرعت نیست؛ نمایش وضعیت معتبر بخشی از درستی سایت است. سیاست زمان نگهداری را با حساسیت داده هماهنگ کنید و صحت را فدای نسبت برخورد کش نکنید.

از کجا بفهمیم کش درست کار می‌کند؟

هدرهای پاسخ و گزارش‌های خود ابزار را بررسی کنید، ولی تنها به وجود کلمهٔ HIT تکیه نکنید. پاسخ باید محتوای درست، زبان درست و وضعیت کاربری درست را داشته باشد. یک پاسخ سریع ولی اشتباه، موفقیت محسوب نمی‌شود.

آزمون را برای اولین بازدید، بازدید تکراری، پس از ویرایش و پس از ورود تکرار کنید. اگر نتیجه‌ها متفاوت است، وضعیت هر لایه را ثبت کنید. پاک‌کردن همهٔ لایه‌ها بدون ثبت شرایط، بازسازی خطا را سخت می‌کند.

در کاتالوگ NexoraPlug، امکانات HyperCache را با فهرست نیازهای پروژه تطبیق دهید. انتخاب یک ابزار با مسئولیت روشن و مسیر بازگشت مشخص، نگهداری را ساده‌تر می‌کند. نتیجهٔ واقعی به قالب، میزبانی، محتوا و تنظیمات بستگی دارد.

چک‌لیست اجرای این راهنما

برای مرور کارها علامت بزنید. انتخاب‌ها فقط تا زمان بازبودن همین صفحه باقی می‌مانند.

پرسش‌های رایج

آیا Redis جای کش صفحه را می‌گیرد؟

این دو می‌توانند مسئولیت متفاوتی داشته باشند. استفاده از Redis برای آبجکت کش به معنای ذخیره‌شدن خروجی HTML همهٔ صفحات نیست.

چرا بعد از تغییر CSS هنوز نسخهٔ قبلی دیده می‌شود؟

ممکن است مرورگر یا یکی از لایه‌های واسط نسخهٔ قبلی را نگه داشته باشد. آدرس نسخه‌دار فایل، هدرها و سیاست پاکسازی را بررسی کنید.

منابع و مطالعهٔ بیشتر

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