کش صفحه، CDN و بنرهای رضایت: چگونه از ارائه وضعیت رضایت اشتباه جلوگیری کنیم
صفحه‌های سریع، رضایت اشتباه
کش صفحه یکی از بهترین کارها برای سرعت و هزینه میزبانی است. همچنین یکی از ساده‌ترین راه‌ها برای خراب کردن تنظیمات رضایت بی‌آنکه متوجه شوید. کش دقیقاً همان کاری را می‌کند که به او گفته شده: یک پاسخ را یک بار ذخیره می‌کند و به هر کس با کلید یکسان ارائه می‌دهد. اگر آن پاسخ ذخیره‌شده چیزی مختص انتخاب رضایت یا موقعیت یک بازدیدکننده داشته باشد، بازدیدکننده بعدی هم آن را می‌گیرد.
این راهنما لایه‌های کشی را که معمولاً جلوی سایت ناشر قرار دارند — کش لبه CDN، افزونه‌های کش تمام‌صفحه، reverse proxyها، service workerها و خود مرورگر — و چگونگی جلوگیری از ارائه تجربه رضایت اشتباه توسط هر کدام را بررسی می‌کند.
قاعده اصلی: رضایت را از HTML کش‌شده دور نگه دارید
امن‌ترین معماری این است که صفحه HTML کش‌شده را خنثی نسبت به رضایت رندر کنید. صفحه شامل لودر CMP و تگ‌های شما در حالت مسدود یا منتظر است، اما هیچ تصمیمی درباره این بازدیدکننده خاص ندارد. سپس CMP در مرورگر اجرا می‌شود، انتخاب ذخیره‌شده را می‌خواند، تصمیم می‌گیرد بنر را نشان دهد یا نه و تگ‌ها را بر همان اساس آزاد می‌کند.
مشکل زمانی شروع می‌شود که سرور در زمان رندر تصمیم‌های رضایتی می‌گیرد، مثلاً:
- قالب یا افزونه‌ای که تگ‌های تبلیغات یا تحلیل را فقط وقتی کوکی رضایت وجود دارد چاپ می‌کند؛
- کد سمت سرور که نشانه‌گذاری بنر را برای بازدیدکنندگانی که قبلاً انتخاب کرده‌اند حذف می‌کند؛
- قالب‌هایی که وضعیت رضایت بازدیدکننده را در یک متغیر اسکریپت درون‌خطی جاسازی می‌کنند.
به محض اینکه آن صفحه کش شود، وضعیت اولین بازدیدکننده وضعیت همه می‌شود. بازدیدکننده‌ای که ردیابی را رد کرده ممکن است صفحه‌ای با تگ‌های از قبل فعال دریافت کند، یا بازدیدکننده‌ای جدید ممکن است هرگز بنری نبیند چون نسخه کش‌شده از کسی آمده که قبلاً آن را بسته بود.
چرا “Vary: Cookie” به‌ندرت پاسخ است
راه‌حل کتابی برای محتوای مختص هر بازدیدکننده این است که به کش‌ها بگویید بر اساس هدر کوکی تغییر کنند. در عمل، بازدیدکنندگان کوکی‌های زیادی با مقادیر یکتا دارند، پس تغییر بر اساس کل هدر کوکی معمولاً نرخ برخورد کش را به نزدیک صفر می‌رساند. بعضی CDNها اجازه می‌دهند کلید کش را به‌جای آن از مقدار یک کوکی بسازید، که اگر کوکی رضایت شما تعداد کمی وضعیت ممکن داشته باشد عملی است، اما پیچیدگی اضافه می‌کند و باز تعداد نسخه‌های کش‌شده را چندبرابر می‌کند. بردن تصمیم به مرورگر ساده‌تر است و کش را کارآمد نگه می‌دارد.
جغرافیا در لبه
بسیاری از ناشران بنرهای متفاوتی بر اساس منطقه نشان می‌دهند: بنر رضایت صریح برای اتحادیه اروپا و بریتانیا، اعلامیه انصراف برای ایالت‌های آمریکا و چیزی سبک‌تر در جاهای دیگر. اگر سرور گونه را از روی IP بازدیدکننده انتخاب کند و آن صفحه کش شود، خواننده‌ای اروپایی می‌تواند صفحه آمریکایی کش‌شده بگیرد، یا برعکس.
سه الگو از این جلوگیری می‌کنند:
- تشخیص جغرافیایی سمت کلاینت. بگذارید CMP منطقه را در مرورگر تعیین کند، تا HTML کش‌شده برای همه یکسان بماند.
- کشور در کلید کش. اگر باید در لبه تصمیم بگیرید، کد کشوری را که CDN شما فراهم می‌کند در کلید کش بگنجانید. یک نسخه کش‌شده برای هر کشور می‌گیرید که قابل پیش‌بینی است.
- منطق لبه بدون کش. تصمیم منطقه‌ای را در یک تابع لبه اجرا کنید که مقداری کوچک و بدون کش را به صفحه‌ای که در غیر این صورت کش شده تزریق می‌کند.
هر کدام را انتخاب کردید مستند کنید. باگ‌های جغرافیایی از سخت‌ترین موارد برای بازتولید هستند، چون فقط برای بازدیدکنندگان یک مکان ظاهر می‌شوند که اتفاقاً صفحه‌ای را گرفته‌اند که کسی در جای دیگر کش کرده است.
کش کردن خود اسکریپت CMP
کش طولانی لودر CMP برای عملکرد خوب است، اما وقتی پیکربندی تغییر می‌کند هزینه دارد. اگر فروشندگان، اهداف یا متن بنر را به‌روز کنید و اسکریپت یا فایل پیکربندی یک سال کش شده باشد، بعضی بازدیدکنندگان همچنان نسخه قدیمی را می‌بینند. بررسی کنید CMP شما فایل‌هایش را چگونه نسخه‌بندی می‌کند: نام فایل یا پارامتر نسخه متغیر به شما اجازه می‌دهد کش را شدید نگه دارید و در عین حال تغییرات را فوراً منتشر کنید. همچنین مطمئن شوید CDN خودتان اگر CMP به آن‌ها وابسته است رشته‌های پرس‌وجو را از URL اسکریپت‌های شخص ثالث حذف نمی‌کند.
Service workerها و کش‌های آفلاین
سایت‌هایی که لایه وب‌اپلیکیشن پیش‌رونده دارند اغلب HTML را در service worker کش می‌کنند. همان قاعده اعمال می‌شود: هرگز صفحه‌ای را که تصمیم رضایت مشخصی را منعکس می‌کند ذخیره نکنید. endpointهای مرتبط با رضایت و صفحه‌های مرکز ترجیحات را از کش service worker مستثنا کنید و مطمئن شوید همیشه می‌توان پیکربندی تازه CMP را واکشی کرد.
کش پس/پیش
مرورگرهای مدرن صفحه‌هایی را که اخیراً دیده‌اید در حافظه نگه می‌دارند تا دکمه بازگشت آن‌ها را فوراً بازیابی کند. اگر بازدیدکننده‌ای در یک صفحه مرکز ترجیحات را باز کند، رضایت را پس بگیرد و سپس بازگشت بزند، صفحه بازیابی‌شده ممکن است هنوز تگ‌هایی داشته باشد که از قبل اجرا می‌شدند. به رویداد pageshow گوش دهید و ویژگی persisted آن را بررسی کنید: وقتی صفحه از این کش بازیابی می‌شود، وضعیت رضایت ذخیره‌شده را دوباره بخوانید و تگ‌ها را متناسب با آن متوقف یا شروع کنید.
روال آزمایش
- صفحه‌ای را در نشست تمیز بارگذاری کنید، رد کنید، سپس صفحه دوم را بارگذاری کنید و تأیید کنید هیچ تگ ردیابی شلیک نمی‌شود.
- با یک مرورگر تمیز دوم تکرار کنید و تأیید کنید بنر ظاهر می‌شود، که نشان می‌دهد کش نشده است.
- هدرهای پاسخ را بررسی کنید که ببینید صفحه‌ها از کش ارائه می‌شوند یا نه، و HTML را با کوکی رضایت و بدون آن مقایسه کنید — باید یکسان باشد.
- پس از پاک کردن کش دست‌کم از دو منطقه آزمایش کنید و دوباره پس از گرم شدن کش.
- رضایت را پس بگیرید، دکمه بازگشت را بزنید و تأیید کنید تگ‌ها متوقف می‌شوند.
نکات کلیدی
- HTML کش‌شده باید نسبت به رضایت خنثی باشد؛ بگذارید CMP در مرورگر تصمیم بگیرد.
- از تغییر بر اساس کل هدر کوکی بپرهیزید؛ نرخ برخورد را نابود می‌کند.
- اگر بنرها بر اساس منطقه فرق می‌کنند، سمت کلاینت تصمیم بگیرید یا کشور را به کلید کش اضافه کنید.
- فایل‌های CMP را نسخه‌بندی کنید تا عمر کش طولانی تغییرات پیکربندی را به تأخیر نیندازد.
- service workerها و کش پس/پیش را مدیریت کنید و با کش گرم آزمایش کنید، نه فقط پس از پاک‌سازی.