اگر بعد از فعال کردن کش، سبد خرید مشتری خالی می شود یا عدد کنار آیکون سبد با محتویات صفحه فرق دارد، اول تنظیم کش ووکامرس را بررسی کنید. صفحات سبد خرید، پرداخت و حساب کاربری نباید مثل یک مقاله عمومی به همه بازدیدکنندگان تحویل داده شوند. درخواست های مربوط به سبد و نشست مشتری هم باید از مسیر درست عبور کنند؛ پاک کردن کش مرورگر به تنهایی این تنظیم را اصلاح نمی کند.
تصور کنید صفحه محصول خیلی سریع باز می شود، اما مشتری پس از افزودن یک کالا هنوز سبد قبلی را می بیند. خاموش کردن دائمی همه لایه های کش شاید ظاهر مشکل را عوض کند، ولی هزینه آن را روی سرعت بقیه فروشگاه می گذارد. راه بهتر این است که بفهمید کدام پاسخ عمومی است، کدام پاسخ به یک مشتری تعلق دارد و نسخه قدیمی دقیقا از کجا می آید.
قرار است چه چیزی را کش کنیم؟
در یک فروشگاه، همه درخواست ها کار یکسانی انجام نمی دهند. تصویر محصول، فایل CSS و یک صفحه معرفی معمولا برای تعداد زیادی کاربر مشترک اند. سبد خرید، آدرس مشتری و روش ارسال به وضعیت همان بازدیدکننده وابسته اند. یک قانون گسترده مانند کش کردن همه نشانی ها می تواند همین تفاوت مهم را از بین ببرد.
کش کامل صفحه، HTML آماده را نگه می دارد. کش اشیا، داده های مورد استفاده برنامه را برای مراجعه بعدی ذخیره می کند. کش مرورگر و CDN هم می توانند در مسیر باشند. وقتی یک گزینه را تغییر می دهید، نام لایه و محدوده اثر آن را یادداشت کنید. عبارت «کش را خالی کردم» بدون مشخص بودن لایه، برای پیگیری نتیجه چندان کمک کننده نیست.
| نوع پاسخ | سوال پیش از کش کردن | بررسی لازم |
|---|---|---|
| تصویر و فایل ثابت | آیا نشانی یا نسخه فایل با تغییر محتوا عوض می شود؟ | عمر کش و تازه شدن فایل پس از ویرایش |
| صفحه عمومی محصول | آیا قیمت یا نمایش برای مشتری ها متفاوت است؟ | سازگاری با مالیات، ارز و قیمت گذاری اختصاصی |
| سبد خرید و پرداخت | این پاسخ به نشست کدام مشتری وابسته است؟ | خروج از کش عمومی صفحه و لبه شبکه |
| حساب کاربری | آیا اطلاعات اختصاصی کاربر در پاسخ است؟ | جلوگیری از اشتراک پاسخ بین کاربران |
| درخواست سبد یا Store API | آیا درخواست خواندن عمومی است یا وضعیت مشتری را تغییر می دهد؟ | قواعد سازگار با همان مسیر و روش درخواست |
اول یک آزمایش کوچک و قابل تکرار بسازید
دو نشست مستقل آماده کنید؛ مثلا دو مرورگر با پروفایل جدا. در نشست اول یک کالای آزمایشی و در دومی کالای دیگری به سبد اضافه کنید. تعداد، جمع سبد و نتیجه باز کردن دوباره صفحه را مقایسه کنید. این کار را با حساب و داده آزمایشی انجام دهید تا اطلاعات مشتری واقعی وارد گزارش عیب یابی نشود.
اگر مشکل هنگام زدن دکمه ثبت سفارش دیده می شود، پیش از تکرار، فهرست سفارش ها را ببینید. ممکن است سفارش ساخته شده باشد و فقط پاسخ نهایی به مرورگر نرسیده باشد. برای بررسی فرایند پرداخت از روش آزمایشی مورد تایید درگاه استفاده کنید؛ چند بار زدن دکمه روی پرداخت واقعی، آزمایش مناسبی برای کش نیست.
نتیجه همین آزمایش را کوتاه بنویسید: کدام نشست، چه مسیری، بعد از کدام کار و در چه ساعتی مشکل داشت. اگر دو سبد مستقل درست می مانند ولی فقط آیکون بالای صفحه عدد قدیمی دارد، دامنه بررسی کوچک تر می شود. در این حالت، خود سبد ممکن است سالم باشد و بخش نمایش شمارنده یا درخواست به روز کردن آن نیاز به بررسی داشته باشد.
صفحه های واقعی فروشگاه را پیدا کنید
در بخش تنظیمات پیشرفته ووکامرس، صفحه های انتخاب شده برای سبد، پرداخت و حساب کاربری را ببینید. به نام های پیش فرض cart و checkout تکیه نکنید؛ ممکن است نشانی فارسی باشد، صفحه عوض شده باشد یا فروشگاه در زیرپوشه نصب شده باشد. استثنا باید با مسیر واقعی همان فروشگاه تطبیق داشته باشد.
حالا تنظیم افزونه کش، کش میزبان و CDN را جدا بررسی کنید. اگر افزونه، صفحه پرداخت را مستثنا کرده ولی CDN همچنان HTML آن را برای همه نگه می دارد، مشکل باقی می ماند. یک فهرست ساده از لایه ها و مسئول هرکدام بسازید تا معلوم باشد کدام تغییر را خودتان انجام می دهید و کدام را باید از میزبان بخواهید.
فقط URL صفحه کافی نیست
مرورگر برای به روز کردن سبد و پرداخت درخواست های دیگری هم می فرستد. در پرداخت کلاسیک ممکن است مسیرهای دارای wc-ajax را ببینید. در ساختار بلوکی، درخواست های Store API زیر مسیرهایی مانند /wp-json/wc/store/ مطرح می شوند. نتیجه یک نوع پرداخت را به همه فروشگاه ها تعمیم ندهید؛ ابتدا ساختار فعال سایت خودتان را مشخص کنید.
در Network مرورگر، درخواست مرتبط را بعد از افزودن کالا یا تغییر روش ارسال پیدا کنید. کد پاسخ، نشانی و نوع محتوای برگشتی را ببینید. اگر به جای پاسخ مورد انتظار، صفحه ورود یا یک صفحه HTML قدیمی برمی گردد، همان مسیر را با پشتیبانی کش یا میزبان بررسی کنید. قانون عمومی کش کردن تمام REST API، جای تنظیم سازگار با ووکامرس را نمی گیرد.
GET بودن درخواست به معنی عمومی بودن پاسخ نیست؛ پاسخ های /wc/store/v1/cart و /wc/store/v1/checkout به نشست و اطلاعات همان مشتری وابسته اند. این مسیرها، حتی برای درخواست GET، باید از کش مشترک CDN و کش عمومی پاسخ خارج باشند تا سبد یا اطلاعات پرداخت بین کاربران به اشتراک گذاشته نشود.
کوکی های سبد را با راهنمای سرویس تطبیق دهید
ووکامرس از کوکی هایی مانند woocommerce_items_in_cart، woocommerce_cart_hash و خانواده wp_woocommerce_session_ برای وضعیت خرید استفاده می کند. یکپارچه سازی درست کش باید با این نشست ها سازگار باشد. نام ها را با مستندات نسخه و راهکار فعال بررسی کنید؛ اضافه کردن چند عبارت به یک کادر نامرتبط، به معنی اعمال شدن استثنا نیست.
اگر افزونه کش شما بخش مخصوص ووکامرس دارد، از همان تنظیمات پشتیبانی شده شروع کنید. هم زمان چند افزونه مشابه نصب نکنید؛ این کار معلوم کردن مسئول پاسخ را سخت تر می کند. برای CDN هم از میزبان بپرسید آیا HTML کش می شود، چه شرطی نشست مشتری را تشخیص می دهد و چه پاسخی برای کاربر وارد شده تحویل داده می شود.
قیمت قدیمی همیشه به معنی خراب بودن سبد نیست
گاهی صفحه عمومی محصول قیمت قبلی را نشان می دهد، اما سبد قیمت تازه را دارد. در این حالت، تازه شدن کش صفحه محصول و وابستگی آن به تغییر قیمت را بررسی کنید. اگر قیمت بر اساس نقش کاربر، کشور، ارز یا افزونه قیمت گذاری تغییر می کند، سازگاری همان افزونه با کش اهمیت بیشتری پیدا می کند. یک صفحه مشترک ممکن است برای همه این حالت ها مناسب نباشد.
برای یک نمونه آزمایشی، قیمت یک محصول کم اهمیت را در محیط جدا تغییر دهید و ببینید کدام صفحه ها نسخه تازه را نشان می دهند. همه محصولات فروشگاه زنده را برای آزمایش ویرایش نکنید. مسیر محصول، دسته، جستجو و سبد را مقایسه کنید تا تغییر لازم به همان بخشی محدود شود که پاسخ قدیمی را نگه داشته است.
تازه کردن کش را به آخر کار موکول نکنید
پس از اصلاح قانون، نسخه قدیمی مسیرهای درگیر را در لایه های مربوط تازه کنید. پاک کردن کش افزونه، لزوما ذخیره CDN را حذف نمی کند. بعد آزمایش دو نشست را دوباره انجام دهید و نتیجه را کنار گزارش اولیه بگذارید. اگر فقط در یک مرورگر مشکل باقی مانده، داده همان سایت را در همان مرورگر بررسی کنید.
پاسخ نهایی را هم از نظر محتوا کنترل کنید. سریع باز شدن صفحه کافی نیست؛ کالای درست، تعداد درست و اطلاعات متعلق به همان حساب باید دیده شود. برای آزمون جداسازی نشست، کاربر مهمان و وارد شده را جدا ببینید. در محیط آزمایشی، ورود، خروج و برگشت به سبد کمک می کند ایرادهایی را پیدا کنید که در یک بار باز کردن صفحه دیده نمی شوند.
اگر با خروج از کش، پرداخت خیلی کند شد
درخواست پویا هنوز به اجرای PHP، دیتابیس و گاهی سرویس های بیرونی نیاز دارد. اگر این بخش کند است، همان عملیات را زمان بندی و لاگ آن را بررسی کنید. کش عمومی صفحه پرداخت را فقط برای پنهان کردن کندی فعال نکنید. میزبان باید بداند کدام درخواست، در چه ساعتی و برای کدام عملیات انتظار طولانی داشته است.
برای جمع کردن نشانه های اولیه از بررسی سلامت سایت آفاق هاست کمک بگیرید. بررسی قواعد میزبان و مسیر درخواست را می توان با خدمات مدیریت سایت و سرور پیگیری کرد. هنگام انتخاب هاست لینوکس هم درباره منابع و پشتیبانی عملیات بدون کش بپرسید، چون همه بخش های فروشگاه از کش یکسانی استفاده نمی کنند.
سه سوالی که موقع تنظیم کش پیش می آید
آیا باید کش تمام فروشگاه را خاموش کنم؟
معمولا لازم نیست. محدوده مشکل، صفحه های شخصی و درخواست های وابسته به نشست را مشخص کنید و قواعد همان بخش را اصلاح کنید. فایل های ثابت و بسیاری از صفحه های عمومی همچنان می توانند از کش مناسب استفاده کنند.
چرا پنجره ناشناس درست است ولی مرورگر معمولی مشکل دارد؟
ممکن است داده ذخیره شده همان سایت یا تفاوت نشست دخیل باشد. نتیجه را با یک پروفایل مستقل دیگر مقایسه کنید؛ سالم بودن یک پنجره، به تنهایی تنظیم تمام لایه های کش را تایید نمی کند.
آیا نصب Redis، مشکل سبد مشترک را حل می کند؟
Redis می تواند در معماری کش اشیا نقش داشته باشد. اگر لایه دیگری HTML شخصی را عمومی ذخیره کرده است، باید همان قانون اصلاح شود. افزودن یک سرویس جدید، جای پیدا کردن پاسخ اشتباه را نمی گیرد.
مستنداتی که در این بررسی به کار می آیند
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.