مسئله: هر عکس محصول یک درخواست است
فروشگاه مد با عکاسی زنده است. صفحه اصلی همین فروشگاه بهتنهایی به بیش از 130 تصویر ارجاع میدهد — اسلایدرهای بالای 300 کیلوبایت، عکسهای محصول حدود 50 تا 350 کیلوبایت — و صفحات دسته و محصول همین الگو را تکرار میکنند. بدون CDN، هر بازدیدکننده تکتک آن فایلها را از سرور مبدأ میکشد: همان عکسها، هزاران بار در روز، در رقابت با همان workerهای PHP و پهنای باندی که باید سبد خرید و پرداخت را سرویس بدهند.
هدف چیز عجیبی نبود: ترافیک تکراری تصاویر بهطور کامل از دوش مبدأ برداشته شود، HTML بهاندازه یک فروشگاه تازه بماند، و همه اینها بدون دستزدن به قالب وردپرس انجام شود.
قانون تصاویر: یک سال کش کن، در چند میلیثانیه سرو کن
قلب این چیدمان یک قانون تحویل است که با پسوندهای تصویر (jpg، jpeg، png، gif، webp، svg، ico) تطبیق میکند. پاسخهای موفق را یک سال کامل در لبه کش میکند، یک هدر CORS اضافه میکند تا تصاویر هر جا لازم شد قابل جاسازی باشند، و آنچه را که از فشردهسازی سود میبرد با Brotli و gzip فشرده میکند.
یک سال تهاجمی به نظر میرسد تا وقتی یادتان بیاید تصاویر محصول در عمل چطور تغییر میکنند: تغییر نمیکنند. عکسی که برای یک محصول بارگذاری شده تا مرگ آن محصول همان URL را نگه میدارد؛ بازطراحی هم فایلهای جدید با نامهای جدید بارگذاری میکند. TTL بلند یعنی لبه تقریباً هرگز لازم نیست دوباره از مبدأ بپرسد — در نمونهگیری ما، تکتک تصاویر صفحه اصلی از قبل HIT بودند. و برای مورد نادری که یک تصویر باید سر جای خودش عوض شود، یک پاکسازی هدفمند دقیقاً همان ورودی را پاک میکند.
قانون HTML: یک روز، با یک ترفند برای ترافیک کمپین
با HTML متفاوت رفتار میشود: صفحه اصلی یک روز کش میشود — آنقدر بلند که لبه تقریباً همه ترافیک ناشناس را جذب کند، آنقدر کوتاه که تغییرات چیدمان محصولات همان روز دیده شود، و برای هر چیز فوری هم پاکسازی هست.
جزئیاتی که ارزش کپیکردن دارد نرمالسازی کوئری است. ترافیک کمپینهای اجتماعی با پارامترهای ردیابی میرسد — هر کلیک فیسبوک یک fbclid یکتا دارد. اگر سادهلوحانه کش شود، هر کلیک یک URL «متفاوت» است، هر بازدیدکننده کمپین یک MISS، و مبدأ بار کامل اوج تبلیغات را در بدترین لحظه به دوش میکشد. این قانون fbclid را از کلید کش کنار میگذارد، پس ده هزار کلیک کمپین یک ورودی کش است. پارامتر همچنان به آنالیتیکس میرسد؛ فقط دیگر کش را تکهتکه نمیکند.
چه چیزی اندازه گرفتیم
اعدادِ سایت زنده، اندازهگیریشده روی اینترنت عمومی (یعنی فاصله شبکه واقعی را هم در بر دارند، نه شرایط آزمایشگاهی). یک تصویر کششده با میانه زمان تا اولین بایت حدود 0.15 ثانیه جواب میدهد. وادار کردن لبه به واکشی همان فایل از مبدأ، میانه را به حدود 0.54 ثانیه میرساند — تقریباً 3.5 برابر کندتر. HTML صفحه اصلی، سروشده بهصورت کش HIT با فشردهسازی Brotli، در حدود 0.27 ثانیه شروع به رسیدن میکند.
این فاصله را در بیش از 130 تصویر در هر بازدید صفحه ضرب کنید و اثرش بر سرعت حسشده اصلاً جزئی نیست: مرورگر رسم عکسهای محصول را شروع میکند در حالی که یک چیدمان بدون کش هنوز منتظر اولینها بود. و هر HIT درخواستی است که مبدأ هرگز نمیبیند — در اوج یک کمپین، کار مبدأ به سرویسدادن سبد خرید کوچک میشود.
بقیه پشته: Redis و WAF بدون زحمت اضافه
دو قطعه دیگر کنار کش کار میکنند و هر دو روشن شدهاند، نه ساخته. در لایه هاستینگ، یک کش شیء Redis پشت وردپرس است و جستوجوهای تکراری پایگاه داده — گزینهها، منوها، متادیتای محصولات — را برای درخواستهایی که واقعاً به PHP میرسند به خواندن از حافظه تبدیل میکند. در جلو، preset WAF این حساب ترافیک ورودی را در همان لبهای بازرسی میکند که کش را سرو میکند، پس الگوهای حمله رایج پیش از آنکه اصلاً در صف مبدأ بایستند فیلتر میشوند.
پانوشت صادقانه: این مشتری از بهینهسازی تصویر WebP/AVIF ما استفاده نمیکند — اعداد بالا صرفاً حاصل کش و فشردهسازیاند. فضای بهبود قابل اندازهگیری هنوز روی میز مانده (فرمتهای مدرن معمولاً حجم تصاویر را بهطور چشمگیری کم میکنند)، و همین نتیجه را قابلانتقالتر میکند، نه کمتر: این همان کاری است که کش لبه بهتنهایی انجام میدهد.
برای فروشگاه خودتان چه چیزی را کپی کنید
این الگو با چهار قاعده سرانگشتی به هر سایت پرتصویری منتقل میشود. تصاویر را بر اساس پسوند با TTL بلند کش کنید و هنگام تغییر پاکسازی کنید، بهجای TTLهای کوتاه «برای احتیاط» — احتیاط همان چیزی است که پاکسازی برایش هست. HTML را چند ساعت یا یک روز کش کنید، نه صفر، و تازگی را به یک پاکسازی هنگام دیپلوی بسپارید. پارامترهای ردیابی (fbclid، و utm_* هر جا آنالیتیکس اجازه بدهد) را پیش از کمپین بعدی از کلید کش نرمالسازی کنید، نه بعد از اینکه مبدأ را ذوب کرد. و با اندازهگیری راستیآزمایی کنید، نه با حس و حال: یک curl با cache-buster در برابر یکی بدون آن، دقیقاً به شما میگوید لبه روی صفحات خودتان چقدر میارزد.
پرسشهای پرتکرار
آیا TTL یکساله تصاویر برای فروشگاه اینترنتی امن است؟
بله، چون URL تصاویر محصول پایدار است: محصول جدید نام فایل جدید میآورد. حالت پرریسک — جایگزینی یک تصویر در همان URL — با پاکسازی هدفمند حل میشود که در چند ثانیه اثر میکند.
چرا صفحه اصلی فقط یک روز کش میشود وقتی تصاویر یک سال میگیرند؟
HTML با چیدمان محصولات تغییر میکند — کمپینها، قیمتگذاری، محصولات ویژه. یک روز یعنی لبه همچنان تقریباً همه ترافیک خواندن را جذب میکند، در حالی که تغییرات همان روز بدون آنکه کسی به آن فکر کند ظاهر میشوند؛ تغییرات فوری هم فقط یک پاکسازی فاصله دارند.
کنار گذاشتن fbclid از کلید کش دقیقاً چه میکند؟
بدون آن، هر کلیک تبلیغ یک URL یکتا و در نتیجه یک MISS کش است — ترافیک پولی شما، گرانترین ترافیکی که دارید، یکجا روی مبدأ فرود میآید. با آن، همه کلیکها در یک ورودی کششده شریکاند. پارامتر همچنان دستنخورده به اسکریپتهای آنالیتیکس شما میرسد.
آیا WebP/AVIF این را باز هم سریعتر میکرد؟
حجم انتقال را باز هم کم میکرد (روی عکسها اغلب 30 تا 70 درصد)، و دقیقاً به همین دلیل تصریح میکنیم که این مشتری آن را خاموش دارد — رقم 3.5 برابر صرفاً حاصل کش است. فعالکردن بهینهسازی تصویر روی همه آنچه اینجا توضیح داده شد سوار میشود، نه بهجای آن.
برای هیچکدام از اینها لازم است قالب وردپرسم را عوض کنم؟
نه. همهچیز در این مطالعه موردی — قوانین کش، نرمالسازی کوئری، فشردهسازی، WAF، Redis — در لایه تحویل و هاستینگ پیکربندی شده است. اپلیکیشن دست نخورده است.