اگر بهینهسازی عملکرد وردپرس را به سه لایه تقسیم کنیم:
- لایهٔ سرور اورجینمیزبان / PHP / پایگاه داده / افزونه کش — تعیینکننده TTFB و فشار بکاند
- لایهٔ منابعبهینهسازی تصویر — تعیین اندازه دانلود و سرعت دانلود تصاویر بزرگ در اولین صفحه
- لایه تحویل：CDN —— تصمیم میگیرد منابع به بازدیدکننده نزدیکتر باشند، نرخ هیت پایدارتر باشد و فشار روی سرور مبدأ کمتر شود
این مقاله به بحث میپردازد شتاب CDN：
- بدانید CDN چه چیزی را میتواند حل کند و چه چیزی را نمیتواند حل کند
- شکل و ارائهدهنده خدمات مناسبِ خود را برای CDN انتخاب کنید و مرز نسخه رایگان/مقدماتی را درک کنید
- راهاندازی را بر اساس کمترین ریسک انجام دهید، اطمینان حاصل کنید که سایت از کار نیفتد و از بروز مشکلات مربوط به کشینگ تجارت الکترونیک/عضویت جلوگیری کنید.
- پس از استقرار، میتواند تأیید کند که “واقعاً اثر گذاشته است” و مشکلات مربوط به “چرا بهروزرسانی نشده است/چرا سرعت کاهش یافته است/چرا محتوا با هم مخلوط میشود” را عیبیابی کند.”
1. اول مفاهیم را روشن کنیم: CDN چه چیزی را حل میکند و چه چیزی را حل نمیکند
۱.۱ CDN عمدتاً ۳ موضوع را حل میکند
۱.۱.۱ تحویل سریعتر منابع ایستا
تصاویر، CSS، JS، فونتها، آیکونها و سایر منابع ایستا به بازدیدکنندگان نزدیکتر هستند که منجر به دانلود سریعتر و رندر پایدارتر صفحات میشود.
برای وردپرس، بهویژه منابع قالب و افزونه (wp-content/themes/、wp-content/plugins/) و تصاویر کتابخانه رسانه (wp-content/uploads/) معمولاً از نظر حجم “سنگینوزنها” هستند.
۱.۱.۲ کاهش بار بر روی سرور مبدأ
پس از اصابت به کش لبه، درخواستها دیگر بهطور مکرر به مبدأ بازنمیگردند و پهنای باند، اتصالهای همزمان، IO دیسک و نوسان CPU در سرور مبدأ سبکتر میشود.
این امر بهویژه در سناریوهای اوج مانند “ترافیک بالا به صفحات تبلیغاتی، مقالات ویروسی و صفحات محصول” مشهود است.
۱.۱.۳ افزایش پایداری (مقاومت بیشتر در برابر نوسان)
در دورههای اوج ترافیک، گرههای لبه حجم قابلتوجهی از درخواستهای تکراری را جذب میکنند و بدین ترتیب احتمال از کار افتادن سرور مبدأ را کاهش میدهند.
شما “دسترسی روانتر” را مشاهده خواهید کرد: حتی زمانی که سرور اصلی با افزایش ناگهانی بار مواجه میشود، کش لبه به ارائه محتوا بدون وقفه ادامه میدهد.
۱.۲ سه نوع مشکل که CDN بهطور خودکار حل نمیکند
۱.۲.۱ خود سرور اصلی کند است
کندی پایگاه داده، کندی منطق افزونه و کندی محاسبات PHP — اینها از مشکلات لایهٔ مبدأ هستند.
CDN میتواند منابع ایستا را سریعتر کند، اما اگر حتی HTML صفحه اصلی را هم خیلی کند تولید کنید، کاربر باز هم احساس میکند “باز شدنش کند است”. در این حالت اول برگردید به: هاست/افزونه کش/بهینهسازی پایگاه داده
۱.۲.۲ خود تصویر بیش از حد بزرگ است
CDN نمیتواند تصویر بزرگ 3MB را بهطور “جادویی” کوچک کند.
ابتدا باید تصاویر خود را بهینهسازی کنید: یک استراتژی اندازهبندی پیادهسازی کنید (از دانلود تصاویر با اندازه بزرگ خودداری کنید)، فشردهسازی را اعمال کنید، از فرمتهای WebP/AVIF استفاده کنید و استراتژیهای بارگذاری تنبل (lazy loading) را پیادهسازی کنید.
1.2..3 اسکریپتهای شخص ثالث کند هستند
تبلیغات، تحلیلها، خدمات مشتری، اجزای رسانههای اجتماعی و غیره از دامنههای شخص ثالث منشأ میگیرند.
معمولاً نمیتوان آنها را “سریعتر” کرد؛ فقط میتوانید با کاهش/تعویق بارگذاری، جایگزینی تأمینکننده یا بهینهسازی راهبرد اسکریپت با آنها برخورد کنید.
توصیه
اول لایهٔ مبدأ و لایهٔ منابع را درست انجام دهید، بعد CDN را انجام دهید؛ اثر آن واضحتر خواهد بود و مشکلات هم کمتر میشود.
۲. انتخاب در ۳۰ ثانیه: به کدام نوع فرم CDN نیاز دارید؟
برای وردپرس، گزینههای رایج در دو دسته قرار میگیرند. با انتخاب اول “فرم” و سپس “ارائهدهندهٔ خدمات”، رویکرد بهطور چشمگیری روشن میشود.
۲.۱ نوع “پراکسی معکوس” یکپارچه (بیدردسرتر، مناسبِ بیشتر وبسایتها)
ویژگیها: این فقط CDN نیست، بلکه همچنین... DNS / SSL / محافظت پایه امنیتی (مانند DDoS/WAF) آنها را با هم بستهبندی کنید. وقتی متصل شدید، بهعنوان یک پروکسی در مقابل وبسایت شما عمل میکند.
آنچه دریافت خواهید کرد:
- مدیریت گواهی و TLS سادهتر شد
- ورودی یکپارچه حفاظت امنیتی (DDoS پایه، کنترل دسترسی، WAF و غیره)
- کشگذاری در لبه و موتور قواعد (فراهمسازی سیاستهای کشگذاری دقیقتر و استراتژیهای دورزدن)
- “دامنهٔ گستردهتر برای توسعه: در صورتی که در آینده بخواهید ویژگیهای امنیتی، محدودیتهای سرعت یا محافظت در برابر رباتها را اضافه کنید، معمولاً میتوان آنها را در همان سیستم ادغام کرد.
ارائهدهنده: Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA
در صورت تمایل:
- آرزو کن HTTPS + CDN + امنیت پایه یکجا
- آیا مایلید مدیریت لایهٔ حل نام دامنه/پروکسی خود را به یک پلتفرم واحد بسپارید؟
- شما بیشتر برای “تجربه کلی و توسعهپذیری در آینده” ارزش قائل هستید و نمیخواهید DNS، گواهی، CDN و امنیت را به چند مجموعه جداگانه تقسیم کنید
۲.۲ فقط Pull ایستا CDN (شروع کمریسک، عمدتاً برای شتابدهی تصاویر/CSS/JS)
ویژگیها: شما فقط منابع ایستا را در کش لبه CDN قرار میدهید؛ صفحات HTML همچنان توسط سرور مبدأ (و همچنین افزونه کش سرور مبدأ) مدیریت میشوند.
آنچه دریافت خواهید کرد:
- ریسک عملیاتی بسیار کم: مادامی که کد HTML دستکاری نشود، وقوع موارد “تزریق محتوا/ربایش سبد خرید” بسیار بعید است.”
- مدلهای هزینه شهودیتر هستند: معمولاً بر اساس حجم ترافیک/درخواست/منطقه صورتحساب میشوند.
- ساختاری پالودهتر: بیشتر شبیه به “خدمات توزیع منابع ایستا”
نماینده: bunny.net (مدل شفاف پرداخت بهازای مصرف)
در صورت تمایل:
- شما میخواهید ابتدا “پایدارترین گام” را بردارید—شتابدهی منابع ایستا.
- شما میخواهید پیش از تصمیمگیری دربارهٔ پیادهسازی کش مبتنی بر پروکسی یا کش کل سایت، بازگشت سریع سرمایهگذاری خود را ببینید.
- شما ترجیح میدهید هزینهها به مدل “پرداخت بهازای مصرف” نزدیکتر باشند.”
۳. چگونه انجام دهیم
- سطح اول: مدل آژانس یکپارچه (ترجیحی)ابر / لبه / ESA
- لایه دوم: پول استاتیک CDN (شروع مطمئن)：bunny.net / Cloudways CDN و غیره
۴. ارائهدهندگان خدمات پیشنهادی
4.1 کلودفلریکپارچهسازی پروکسی معکوس (شروع رایگان، اکوسیستم بالغ)
این چیست؟
پس از اینکه دامنه را متصل کنید، بهعنوان یک پراکسی در جلوی وبسایت قرار میگیرد و قابلیتهای CDN، گواهی، حفاظت پایه و قوانین کش را ارائه میدهد.
برای چه کسی مناسب است؟
- میخواهید بیدردسر باشید: HTTPS + CDN + امنیت پایه یکجا
- برای دستیابی به یک اکوسیستم بالغ: افزودنیهای بعدی شامل WAF، محدودسازی نرخ، قواعد Edge و غیره خواهند بود، با یک مسیر پیادهسازی بسیار روان.
نقطههای ریسک
- بهروزرسانی اعمال نشده است.：پس از راهاندازی CDN، زنجیرهٔ کش طولانیتر میشود (کش مرورگر + کش CDN + کش سرور مبدأ) و به “راهبرد نسخهبندی” نیاز است تا بهروزرسانیها قابلکنترل باشند (در ادامه درخت عیبیابی آمده است)
- کش کردن HTML نیازمند احتیاط است.اگر HTML در حافظه پنهان ذخیره شده باشد، صفحات تجارت الکترونیک/عضویت/شخصیسازیشده باید بهطور کامل دور زده شوند، در غیر این صورت ممکن است حوادث جدی رخ دهد (فهرست سناریوها در زیر ارائه شده است).
توضیح：
- موقعیتیابی: یکپارچهسازی پروکسی معکوس (SSL + CDN + حفاظت پایهای)
- مناسب برای: استقرار بدون دردسر با امکان گسترش فراوان در آینده
- ارزش اصلی: نقطهٔ ورود یکپارچهٔ گواهینامه/امنیت/پیشپادگان
- ریسک: بهروزرسانیها به استراتژی نسخهبندی وابسته هستند؛ کشینگ HTML باید بهطور کامل دور زده شود.
4.2 اجدوان بینالمللی تِنسِنت کلودیکپارچهسازی پروکسی معکوس
این چیست؟
این پلتفرم بهطور مشابه رویکرد یکپارچهای از “شتابدهی + امنیت + گواهیها” را اتخاذ میکند که آن را برای قرار دادن وبسایتها تحت مدیریت یکپارچه لایه پروکسی مناسب میسازد.
- مانند Cloudflare نسخه رایگان دارد، اما معمولاً دارای محدودیت سهمی/کارکردی(تعداد قوانین، تعداد وظایف ثبت و غیره)، اما نیازی به تغییر DNS نیست، فقط کافی است از طریق cname متصل شود،نسخههای رایگان برای وبسایتهای تجاری توصیه نمیشوند.！
- در عین حال، طرحهای رایگان اغلب به معنای SLA تضمین نمیکند
قابل استفاده است، اما نباید بهعنوان یک “بسته SLA تجاری” در نظر گرفته شود.
- اگر میخواهید هنگام حضور در سرزمین اصلی چین بهطور خودکار به خطوط تلفن سرزمین اصلی چین منتقل شوید، معمولاً ابتدا باید موارد زیر را انجام دهید:ثبت ICP چیندر صورت ثبتنام نکردن، تنها مسیرهای بینالمللی قابل استفاده هستند.
توجه:
- موقعیتیابی: یکپارچهسازی پروکسی معکوس (شتابدهی + امنیت + گواهیها)
- مناسب برای: کسانی که به دنبال دسترسی یکپارچه هستند و ظرفیت گرههای سرزمین اصلی چین را مدنظر دارند.
- رایگان: یک طرح/نسخهٔ رایگان در دسترس است، اما با سهمیههای محدود و معمولاً بدون SLA تضمینشده.
- ریسکها: سهمیههای قوانین، لاگها و زیردامنهها نیازمند برنامهریزی قبلی هستند؛ کشینگ HTML نیز مستلزم احتیاط است.
4.3 معماری امنیت سازمانی بینالمللی علیبابا کلودیکپارچهسازی پروکسی معکوس
- مانند Cloudflare نسخه رایگان دارد، اما معمولاً دارای محدودیت سهمی/کارکردی(تعداد قوانین، تعداد وظایف ثبت و غیره)، اما نیازی به تغییر DNS نیست، فقط کافی است از طریق cname متصل شود،نسخههای رایگان برای وبسایتهای تجاری توصیه نمیشوند.！
- برای شروع استفاده، در سایت بینالمللی یک حساب کاربری ثبت کنید.
- به کنسول ESA دسترسی پیدا کنید تا یک سایت اضافه کنید و گزینهٔ رایگان را انتخاب کنید. ورودی دسترسی به بسته
- اگر میخواهید در داخل سرزمین اصلی چین بهطور خودکار به مسیرهای سرزمین اصلی چین سوئیچ کنید، معمولاً ابتدا باید ثبت ICP را تکمیل کنید؛ بدون ثبت، تنها میتوانید از مسیرهای بینالمللی استفاده کنید.
- پلنهای رایگان بیشتر برای اهداف توسعه، آزمایش و ارزیابی مناسب هستند و معمولاً معادل بستههای تجاری SLA نیستند.
- بستههای رایگان اغلب با محدودیتهای سرعت یا محدودیتهای پشتیبانی (مانند توافقنامههای سطح خدمات و غیره) همراه هستند.
در مورد مسیرهای سرزمین اصلی چین:
- برای فعالسازی گره سرزمین اصلی چین، معمولاً باید هم الزامات ثبت سوابق و هم الزامات منطقهای را برآورده کرد.
- ورود رایگان بهطور پیشفرض روی مسیر بینالمللی تنظیم شده است. برای استفاده از مسیر سرزمین اصلی چین، باید موارد زیر را تکمیل کنید:الزامات ثبت ICP چین
توجه:
- موقعیتیابی: یکپارچهسازی پروکسی معکوس (شتابدهی سایت + امنیت)
- رایگان: حسابهای بینالمللی سایت میتوانند بهطور رایگان به Entrance دسترسی داشته باشند؛ شتابدهی در سرزمین اصلی چین بهطور پیشفرض شامل نمیشود.
- مناسب برای: ارزیابی/آزمایش و استفاده سبک؛ یا ارتقاء بستههای بعدی.
- ریسکها: از محدودیتهای لایه رایگان (SLA/محدودسازی/گزینههای پشتیبانی) آگاه باشید؛ نیازمندیهای منطقهای و ثبتنام را از قبل برنامهریزی کنید.
4.4 یک تیپی ۳۶ تی: پول استاتیک CDN (شروع کمریسک، پرداخت شفاف بر اساس میزان مصرف)
اگر میخواهی “اول مطمئنترین سود را بگیری”، مدلهایی مثل bunny با Pull CDN خیلی مناسباند:
این بیشتر شبیه یک “سرویس توزیع منابع” عمل میکند: شما آن را مسئول توزیع منابع ایستا خود میسپارید، با هزینههایی که معمولاً به حجم ترافیک، تعداد درخواستها یا منطقه جغرافیایی بستگی دارد. این مدل شفاف و قابل مدیریت است.
مناسب برای:
- ابتدا انجامش بده تصاویر / CSS / JS / فونتها شتاب ایستا
- میخواهید اول به سودی کمریسک و پایدار برسید و عجلهای ندارید که کل سایت را به پلتفرم عاملی یکپارچه DNS/SSL/WAF بسپارید
- شما ترجیح میدهید مدل هزینه نزدیکتر به سیستم پرداخت بهازای مصرف باشد، تا اینکه از ابتدا وارد ساختار بستهای پیچیدهتر شوید.
نقطههای ریسک
تقریباً همیشه “بهروزرسانیِ منابعِ ثابت اعمال نمیشود” باگِ CDN نیستبلکه رفتار عادی سیستم کش:
وقتی در بکاند CSS/JS/تصاویر را بهروزرسانی میکنید، اماآدرس منبع بدون تغییر باقی میماند.(همان آدرس/نام فایل/مسیر)، CDN و مرورگر هر دو بهطور منطقی همچنان از کش قدیمی استفاده میکنند، بنابراین میبینید “چرا بهروزرسانی نشده”.
یک اصل روشن و قابل اجرا:
به نسخهها اولویت بدهید؛ پاکسازی بهعنوان راهحل پشتیبان.
چرا این قابلاعتمادترین رویکرد است:
- تغییرات شماره نسخه/نام فایل → تغییر URL → CDN بهعنوان منبع جدید کش میشود → نسخه جدید تقریباً بلافاصله اعمال میشود
- پاکسازی (پاک کردن کش) نیازمند آغاز دستی است که ممکن است منجر به دامنهٔ نامشخص و تأخیرهای انتشار در سراسر گرهها شود؛ پاکسازیهای مکرر همچنین میتواند به کاهش نرخ موفقیت دسترسی، افزایش ترافیک بازگشت به منبع و افزایش نوسان منجر شود.
یک مثال آسان برای درک:
style.cssمحتوا تغییر کرده است، اما نشانی اینترنتی بدون تغییر باقی مانده است.style.css→ CDN ادامه استفاده از کش قدیمی（منطقی）- URL تبدیل میشود
style.css?ver=20260103或style.abc123.css→ CDN بهعنوان منبع جدید در نظر گرفته میشود → نسخه جدید فوراً اعمال میشود
خرگوش بهعنوان بهترین رویه برای “گام اول CDN”
- در ابتدا فقط منابع ایستا را پوشش دهید.(تصاویر/CSS/JS/فونتها)، HTML را بلافاصله پس از بارگذاری کش نکنید.
- مزیت: حوادث جدی مانند مشاهده محتوای دیگران یا جزئیات سبد خرید توسط کاربران عملاً وجود ندارد.
- همچنین متوجه خواهید شد که تأیید مزایا آسانتر است: منابع ایستا سریعتر بارگذاری میشوند و بار سرور اصلی کاهش مییابد.
- استراتژی بهروزرسانی را بهطور مؤثر طراحی کنید
- CSS/JS: در صورت امکان از شمارههای نسخه یا تغییر نام فایل استفاده کنید.
- تصاویر: در صورت امکان از استفاده طولانیمدت از نامهای یکسان برای فایلها خودداری کنید؛ ترجیحاً از نامهای جدید فایل یا مسیرهای تغییر یافته استفاده کنید (بهویژه برای بنرهای صفحه اصلی و گرافیکهای تبلیغاتی).
- پس از راهاندازی، از چکلیست تأیید برای اطمینان از اجرای موفقیتآمیز استفاده کنید.
- آیا منابع ثابت از CDN هستند
- آیا نرخ موفقیت بهتدریج در حال افزایش است؟ آیا پهنایباند/حجم درخواستهای سرور مبدأ پایدارتر شده است؟ (فهرست بررسی در زیر ارائه شده است)
لطفاً توجه داشته باشید
اگر کسبوکار شما شامل سرزمین اصلی چین میشود، یا میخواهید دسترسی سریعتر به وبسایت خود از سرزمین اصلی چین را ممکن سازید.
هر دو سرویس ابری علیبابا چین و تنسنت کلاود چین شایستهٔ توجه شما هستند. اگر دامنهٔ شما پیش از این در سرزمین اصلی چین وضعیت ثبت ICP را داشته باشد، هنگام استفاده از EdgeOne یا ESA، ترافیکی که از سرزمین اصلی چین منشأ میگیرد بهطور خودکار به مسیرهای داخل سرزمین اصلی چین منتقل خواهد شد.
“از گرههای سرزمین اصلی چین استفاده کنید”معمولاً شامل ثبت ICP است.
برای مرجع
- اطلاعیه ثبت ICP برای EdgeOne در تَنسِنت کلاود بینالمللی
- راهنمای ثبت ICP برای ESA بینالمللی ابردین علیبابا
“بهینهسازی تجربه دسترسی به وبسایتهای فرامرزی”ممکن است یک قابلیت جداگانه باشد که معمولاً معادل “دسترسی آزاد به گرههای سرزمین اصلی چین” نیست.”
۵. طرح پیادهسازی مسیر: پیشرفت در سه فاز (از پایدار به مقاوم)
دلیل اینکه CDN در ابتدای راهاندازی بیشتر از همه “بههم میریزد”، این است که از همان اول میخواهند همه قابلیتها را تا آخر باز کنند.
مرحله ۱: فقط منابع ایستا CDN (اکیداً پیشنهاد میشود ابتدا انجام شود)
هدفتصویر/CSS/JS/فونت ابتدا از CDN عبور کند؛ HTML در کش CDN نباشد (یا فعلاً بدون تغییر بماند)
چرا ابتدا این کار را برای پایدارترین رویکرد انجام دهیم؟
- کمترین ریسک: اگر منابع استاتیک بهطور نادرست کش شوند، بدترین حالت این است که “سبکها/تصاویر بهروزرسانی نشوند”، که قابل مدیریت است.
- بر وضعیت ورود، فرآیندهای تجارت الکترونیک یا دقت اطلاعات حساب کاربری تأثیری نخواهد داشت.
- شما میتوانید مزایای آن را بهوضوح ببینید: دانلود سریعتر منابع ایستا و یک سرور مبدأ پایدارتر.
مشکلات رایج در این مرحله (عیبیابی درخت در ادامه)
- محتوای ترکیبی (صفحه HTTPS منبع HTTP را بارگیری میکند)
- بهروزرسانی منابع ایستا اعمال نمیشود (URL بدون تغییر)
مرحله ۲: استراتژی تازهسازی (اولویت شماره نسخه، بازگشت به پاکسازی/انقضا)
این همان نقطهٔ تمایز “حرفهای بودن یا نبودنِ CDN” است.
یک قانون سخت و سریع:
بهروزرسانیهایی که میتوان با تغییر شمارههای نسخه یا نام فایلها آنها را حل کرد، نباید به Purge متکی باشند.
چرا وقتی زنجیرهٔ کش طولانیتر میشود، مرموز میگردد؟
- کش مرورگر: ممکن است فایلهای CSS/JS قدیمی را بهصورت محلی ذخیره کرده باشید.
- کش CDN: ممکن است گرههای لبهای منابع قدیمی را ذخیره کرده باشند
- کش سرور Origin: افزونههای کش/کش سرور ممکن است همچنان محتوای منسوخ را ارائه دهند.
اگر استراتژی نسخهبندی نداشته باشید، استقرار به این صورت درمیآید:
“تغییرات اعمال شد → صفحه بازطراحی شد → کار نکرد → کش پاک شد → باز هم کار نکرد → لایه دیگری از کش پاک شد”
این دقیقاً بزرگترین نقطهضعف CDN برای خیلیهاست.
مرحله ۳ (پیشرفته): آیا HTML باید کش شود؟ (پاداش بالا، اما بالاترین ریسک)
کشگذاری HTML (کشگذاری در سطح سایت/کشگذاری در لبه) میتواند بهطور قابلتوجهی زمان تا اولین بایت (TTFB) را کاهش دهد، اما در سناریوهای وردپرس نیز یکی از حوزههای با وقوع بالای حوادث است.
اگر مطمئن نیستید، HTML را کش نکنید. اول CDN استاتیک + افزونه کش سرور مبدا.
هنگام کش کردن HTML، دو اصل اعمال میشوند:
- شروع صرفاً از “وضعیت بازدیدکننده”: صفحات را فقط برای بازدیدکنندگان ثبتنامنشده در حافظه پنهان ذخیره کنید
- ابتدا پیشنویس فهرست دورزدن را تهیه کنید.ابتدا دقت، سپس نرخ ضربه
۶. چکلیست قوانین سناریو: چگونه از حوادث در انواع مختلف سایتها جلوگیری کنیم
۶.۱ وبسایتها/وبلاگهای محتوا-محور (عمدتاً مقالات، ترافیک بالای بازدیدکنندگان)
توصیه شده
- منابع ایستا: بهطور کامل کش شدهاند
- HTML: صفحهی بازدیدکنندهی ثبتنامنشده را در کش در نظر بگیرید.“
معمولاً لازم است دور زدن انجام شود.
- پشتزمینه و ورود:
/wp-admin/*、/wp-login.php - پیشنمایش/پیشنویس
- صفحهٔ نتایج جستجو (پارامترها بهطور قابلتوجهی متفاوت هستند؛ عدم استفاده از کش در ابتدا سادهترین رویکرد است)
- درخواست POST برای ارسال فرم/ثبت نظر
کلید کش باید بهاندازهٔ کافی منحصر بهفرد باشد تا تمایز قائل شود.
- آیا وارد شده است (بعد کوکی)
- زبان (وبسایت چندزبانه)
۶.۲ وبسایتهای شرکتی / صفحات فرود بازاریابی (فرمها، کمپینها)
توصیه شده
- منابع ایستا: بهطور کامل کش شدهاند
- HTML: صفحات فرود عمومی ممکن است کش شوند (وضعیت بازدیدکننده)، اما صفحات نتیجه فرم باید با احتیاط مدیریت شوند.
رایجترین تله: ردیابی پارامترهایی که باعث تکهتکه شدن کش میشوند
صفحه فرود مشترک utm_* پارامترها:
- تمام کلیدهای شرکتکننده در کش → تکهتکه شدن کش، که منجر به نرخ برخورد پایین میشود
- نادیده گرفتن همه → تعداد کمی از صفحات که به رندر بر اساس پارامتر متکی هستند ممکن است طبق انتظار عمل نکنند.
۶.۳ سایتهای عضویت / پلتفرمهای دوره / جوامع (نسبت بالای کاربران واردشده)
نتیجهگیریکشگذاری HTML باید با احتیاط بسیار انجام شود.
روش مطمئن معمولاً این است: استاتیک CDN + کش مبدأ/کش شیء؛ HTML فقط برای حالت بازدیدکننده کش شود۔
باید دور زده شود
- ورود / ثبتنام / بازیابی رمز عبور
- مرکز حساب، سفارشات/اشتراکها، اطلاعات شخصی
- هر صفحه و رابط کاربری که وابستگیهای قوی به وضعیت کاربر داشته باشند
۶.۴ سایت تجارت الکترونیک (ووکامرس)
مهمترین فهرست بایپس
- سبد خرید، تسویهحساب، صفحه حساب کاربری
- صفحات مربوط به تأیید سفارش و فراخوانی پرداخت
- ورود/ثبتنام، کوپنها/امتیازها و سایر نقاط ورود مرتبط با وضعیت کاربر
چرا احتمال وقوع حوادث در تجارت الکترونیک بیشتر است؟
- به محض اینکه کاربر سبد خرید، جلسه یا وضعیت ورود به سیستم داشته باشد، صفحه به شدت شخصیسازی میشود.
- کشگذاری HTML، اگر دور زده شود یا بر اساس وضعیت تمایز داده نشود، معمولاً منجر به اختلافات سبد خرید، تعارض شمارههای حساب و نمایشهای غیرعادی قیمتها میشود.
دقت در اولویت است؛ دقت را به خاطر نرخ برخورد فدا نکنید.
۶.۵ سایتهای چندزبانه / چندارز
توصیه شده
- منابع ایستا: بهطور کامل کش شدهاند
- HTML: وضعیت بازدیدکننده ممکن است در حافظه پنهان ذخیره شود، اما کلیدهای حافظه پنهان باید بهطور صریح تفاوتهای نسخههای زبانی/واحدهای پولی را از هم متمایز کنند.
کلید کش باید در نظر گرفته شود.
- زبان (مسیر)
/en//zh/یا زیر دامنهen.） - وارد شده باشد (کوکی)
- واحد پول/نرخ مالیات (در صورت تأثیر بر نمایش)
۷. افشای ریسک
ریسک ۱: کش کردن محتوای نادرست (شدیدترین)
- خطای کش شدن منابع ایستا: معمولاً شامل سبکنامهها یا تصاویر منسوخ.
- خطای کش HTML: مشکلات احتمالی بین محتواها، بین سبد خریدها و بین حسابها — این یک حادثه بحرانی محسوب میشود.
ریسک ۲: اعمال نشدن بهروزرسانیها (شایعترین)
با طولانیتر شدن زنجیرهٔ کش، موارد “اعمال نشدن تغییرات” شایعتر میشوند:
- اولویت به تغییرات شماره نسخه/نام فایل داده میشود.
- پاکسازی/بازگشت از شکست
- فرآیند انتشار باید قابل بازتولید باشد (تا بدانیم در هر انتشار کدام آدرسهای URL تغییر کردهاند).
ریسک ۳: دامنه تعهدات برای نسخههای رایگان/شروعکننده
- ویژگیهای مشترک طرحهای رایگان: سهمیههای محدود، مستثنی شدن برخی قابلیتها، توافقنامههای سطح خدمات (SLA) و گزینههای پشتیبانی که معادل ارائههای تجاری کامل نیستند.
خطر ۴: قابلیتهای مرتبط سرزمین اصلی چین مستعد سوءتفاهم هستند.
- ESA: برای فعالیت در شبکه سرزمین اصلی چین، ثبتنام ICP در چین الزامی است.
- EdgeOne: برای استفاده از مسیرهای سرزمین اصلی چین، ثبت ICP در چین الزامی است.
۸. چکلیست تأیید: چگونه پس از راهاندازی تأیید کنیم که “واقعاً در حال کار است”
8.1 آیا منابع استاتیک واقعاً از CDN عبور کردهاند؟
- تصویر/CSS/JS از دامنه/گره لبه CDN است؟
- آیا میتوان نشانگرهای قابل تشخیصِ موفقیت در کش را مشاهده کرد (نشانگرها در پلتفرمهای مختلف متفاوت هستند)؟
۸.۲ آیا بار روی سرور مبدأ کاهش یافته است؟
- آیا پهنای باند سرور اصلی پایدارتر است؟
- آیا تعداد درخواستها/اتصالات به سرور اصلی کاهش یافته است (بهویژه درخواستهای منابع تکراری)؟
۸.۳ آیا بهروزرسانیها قابل کنترل هستند؟
- یکبار CSS/JS را ویرایش کنید یا یک تصویر را جایگزین کنید
- آیا میتوان نسخهٔ جدید را بهسرعت از طریق “تغییر شمارهٔ نسخه/تغییر نام فایل” پیادهسازی کرد؟
- اگر بهروزرسانیها تنها از طریق Purge قابل انجام باشند، نشان میدهد که استراتژی نسخهبندی همچنان ناکافی است (اصلاح استراتژی را در اولویت قرار دهید؛ Purge را بهعنوان یک عملیات روتین در نظر نگیرید).
۸.۴ آیا صفحات کلید دینامیک صحیح هستند؟
(ضروری برای سایتهای تجارت الکترونیک/عضویت)
- آیا محتوای صفحه پس از ورود/خروج صحیح است؟
- آیا صفحات سبد خرید، تسویه حساب و حساب کاربری همواره دقیق هستند؟
- آیا ناهنجاری “دیدن محتوای یکسان وضعیت کاربر توسط کاربران مختلف” رخ داده است (خطر بالا)؟
۸.۵ آیا نرخ خطا در حال افزایش است؟
- تایماوت منبع، خطاهای ۵xx، دسترسیناپذیری متناوب
- این موارد معمولاً نشاندهنده موارد زیر هستند: ظرفیت ناکافی در سرور مبدأ، قواعد نادرست، فعالسازی محدودسازی، یا مشکلات لینک بکهال.
۹. عیبیابی درخت برای بهروزرسانیهایی که اعمال نمیشوند (تبدیل “معما” به مراحل)
ابتدا مشخص کنید با کدام دسته از مشکلات مواجه هستید:
۹.۱ منابع ایستا بهروزرسانی نشدهاند (CSS/JS/تصاویر همچنان قدیمی هستند)
سناریو الف: فقط شما میتوانید نسخهٔ قدیمی را ببینید؛ وقتی حالت ناشناس را فعال میکنید یا دستگاه را عوض میکنید، نسخهٔ جدید نمایش داده میشود.
مظنون اصلی: کش مرورگر
- رویکرد رفع مشکل: انتشار منابع جدید با شمارههای نسخه/نامهای فایل بهروزرسانیشده.
سناریوی B: همه نسخه قدیمی را میبینند (در دستگاههای مختلف نامرئی/همچنین قدیمی)
ابتدا مشکوک شوید: CDN همچنان از کش قدیمی استفاده میکند
- 99% دلیل: URL منبع بدون تغییر
- راه حل ترجیحی: استراتژی نسخهبندی
- پاکسازی (بهعنوان یک اقدام موقت)
سناریو C: پس از بازنویسی یک تصویر با همان نام فایل، تصویر قدیمی همچنان نمایش داده میشود.
این مشکل کلاسیکِ همپوشانی کش مرورگر و کش CDN است
- راهنمای عملی: تلاش کنید با استفاده از نامهای فایل/مسیر جدید یا شمارههای نسخه، از برخورد نامهای طولانی مدت اجتناب کنید.
۹.۲ HTML بهروزرسانی نشده (محتوای صفحه/ماژولها همچنان قدیمی هستند)
سناریو الف: رابط پشتصحنه/پس از ورود جدید است، در حالی که بازدیدکنندگان نسخه قدیمی را میبینند.
فرض اولیه: HTML حالت بازدیدکننده کش شده است.
- ابتدا تأیید کنید: آیا HTML این نوع صفحه باید در حافظه پنهان ذخیره شود؟
- اگر کشینگ ضروری باشد، یک استراتژی بهروزرسانی قابل کنترل لازم است، در غیر این صورت انتشار غیرقابل مدیریت میشود.
سناریو ب: تنها در برخی مناطق/شبکهها محتوای قدیمی نمایش داده میشود.
شک اولیه: حالتهای کش در گرههای لبه با هم متفاوت هستند
- رویکرد حل: از استراتژیهای نسخهبندی/بهروزرسانی برای به حداقل رساندن اختلافات استفاده کنید؛ در صورت لزوم، مدیریت صریح خطا را پیادهسازی کنید.
سناریو C: ناهنجاری در کاربر واردشده/سبد خرید
سیگنال پرخطر: ممکن است کش حاوی محتوای نادرست باشد.
- فوراً بررسی کنید که آیا صفحات حالت کاربری (مانند سبد خرید، تسویه حساب، صفحات حساب کاربری و غیره) در حافظه پنهان ذخیره شدهاند یا خیر.
- تأیید کنید که آیا کلید کش، گزینههای حیاتی مانند “کوکیهای وضعیت کاربر/زبان/ارز” را نادیده میگیرد.
۱۰. توصیهشده
کلودفلر
- یکپارچهسازی پروکسی معکوس
- مناسب برای: مبتدیان بدون دردسر
- نکات کلیدی: استراتژی نسخهبندی بهروزرسانیها را حل میکند؛ کشینگ HTML از دیدگاه بازدیدکننده پیادهسازی میشود.
- خطر: صفحات پویا باید دور زده شوند.
اجدوان بینالمللی تِنسِنت کلود
- یکپارچهسازی پروکسی معکوس
- مناسب برای: در نظر گرفتن ظرفیت گره در سرزمین اصلی چین و دسترسی یکپارچه
- رایگان: یک طرح/نسخهٔ رایگان وجود دارد، اما حتماً کوتاها و تعهدات سطح سرویس را با دقت بررسی کنید.
- ریسکها: سهمیههای قوانین، لاگها و زیردامنهها نیازمند برنامهریزی هستند؛ در مورد کش کردن HTML با احتیاط عمل کنید.
معماری امنیت سازمانی بینالمللی علیبابا کلود
- یکپارچهسازی پروکسی معکوس
- رایگان: حسابهای بینالمللی سایت میتوانند بهطور رایگان به Entrance دسترسی داشته باشند.
- ریسکها: لایه رایگان (SLA/حمایت/محدودیتهای پهنای باند) و الزامات منطقهای/ثبتنام باید از قبل تأیید شوند.
- مناسب برای: ارزیابی/آزمایش با دسترسی سبک؛ یا ارتقاء بستههای بعدی؛ یا بررسی قابلیتهای گره سرزمین اصلی چین و دسترسی یکپارچه.
یک تیپی ۳۶ تی
- پول استاتیک CDN
- مناسب برای: شروع با شتابگیری ایستا با ریسک پایین
- نکات کلیدی: شماره نسخه در اولویت است و Purge بهعنوان گزینه پشتیبان در نظر گرفته میشود؛ از بازنویسی فایلهای با نامهای یکسان خودداری کنید.
- خطر: عدم اجرای صحیح استراتژیهای بهروزرسانی ممکن است منجر به مواجهه مکرر با “منابع منسوخ” شود.”
۱۱. توصیهها برای اقدام
- ابتدا نوع را انتخاب کنید: یکپارچهسازی پروکسی معکوس (Cloudflare/EdgeOne/ESA) یا Pull ایستای CDN (bunny)
- اجرا به صورت مرحلهای:ابتدا استاتیک → سپس استراتژی نسخهبندی → در نهایت به کشینگ HTML بپردازید.
- لیست بررسی پس از راهاندازی: نرخ موفقیت / بازیابی منبع / بهروزرسانیها / دورزنی پویا / نرخ خطا
- باید سریعتر انجام شود: به تنظیمات “پلاگین کش” و “بهینهسازی تصویر” بازگردید و لایهٔ سرور اصلی و لایهٔ منابع را یکبار دیگر فشرده کنید.
پرسشهای متداول WordPress CDN
1. چرا با وجود استفاده از CDN هنوز هم کند است؟
رایجترین دلیل این نیست که CDN بیفایده است، بلکه این است که گلوگاه در “لایه تحویل” نیست.
شما میتوانید این را به ترتیب زیر تعیین کنید:
- TTFB همچنان بالا است: نشاندهنده تولید کند HTML در سرور مبدأ (پیکربندی پایگاه داده/پلاگینها/پلاگین کش/عملکرد میزبانی) → بازگشت برای بهینهسازی در لایه سرور مبدأ
- تصویر بزرگ در صفحهٔ اول به کندی بارگذاری میشود.: نشاندهنده نادرستی حجم، ابعاد یا فرمت تصویر است → ابتدا بهینهسازی تصویر را انجام دهید (تراکم، WebP/AVIF، استراتژی اندازهدهی)
- اسکریپتهای شخص ثالث سرعت کار را کم میکنند.اسکریپتهای تبلیغات/آمار/پشتیبانی رایج → CDN معمولاً کمکی نمیکند؛ باید بارگذاری را کمتر یا بهتعویق انداخت
- فقط در برخی مناطق کند است.علل احتمالی شامل پوشش گره، اتصال بکهال یا خطاهای کش (نرخ هیت پایین) است ← نرخ هیت و وضعیت بکهال را بررسی کنید
CDN مسئول این است که “منابعِ از پیش بهینهشده” را سریعتر تحویل دهد؛ کندیِ سرور مبدأ، بزرگیِ تصاویر و کندیِ اسکریپتها باید جداگانه برطرف شوند.
۲. چرا کاربران پس از بهروزرسانی CSS/JS/تصاویر، همچنان نسخه قدیمی را میبینند؟
این رایجترین مشکل در سناریوی CDN است و علت اصلی آن معمولاً این است:آدرس منبع بدون تغییر باقی میماند.سیستم کش به استفادهٔ معقول از هیتهای قدیمی کش ادامه خواهد داد.
قابلاعتمادترین اصل دستکاری:
- شماره نسخه تقدم دارد.: تغییر URL منبع (برای مثال)
style.css?ver=xxxxیا هَش نام فایل) - پاکسازیوقتی هنوز استراتژی نسخهبندی را مشخص نکردهاید، پاک کردن کش را بهعنوان یک اقدام موقتی بهکار ببرید.
اگر بهطور مکرر بنرهای صفحهٔ اصلی یا تصاویر تبلیغاتی را تعویض میکنید، توصیه میشود از بازنویسی فایلهای با نام یکسان خودداری کنید. در عوض، اولویت را به استفاده از نامهای فایل جدید یا مسیرهای جدید (که کنترل بیشتری فراهم میکنند) بدهید.
۳. آیا لازم است HTML را کش کنم؟ آیا بیفایده نیست که آن را کش نکنم؟
ضروری نیست.
برای بسیاری از سایتها، بیشترین ارزش CDN از اینجا ناشی میشود:
- منابع ایستا (تصاویر/CSS/JS/فونتها) سریعتر بارگذاری میشوند.
- کاهش بار بر روی سرور مبدأ و پایداری افزایشیافته
کش HTML مزایا ممکن است واقعاً بیشتر باشد (با TTFB کمتر)، اما ریسکها نیز در بالاترین حد قرار دارند: تجارت الکترونیک، سیستمهای عضویت، محتوای شخصیسازیشده و راهاندازیهای چندزبانه/چندارزی همگی مستعد ذخیرهسازی اطلاعات نادرست هستند.
رویکرد محتاطانه:
- ابتدا استاتیک CDN را انجام دهید (ریسک کم، بازده بالا)
- استراتژی نسخهبندی و چکلیست اعتبارسنجی را مرور کنید.
- بازنگری کنید که آیا باید HTML را کش کنید (شروع از “وضعیت بازدیدکننده”)
۴. آیا سایت فروشگاهی میتواند از CDN استفاده کند؟ آیا باعث بههمریختن سبد خرید میشود؟
این کار شدنی است و در واقع باید انجام شود (حداقل برای منابع ایستا)، اما باید از کش کردن صفحات تولیدشده توسط کاربر اجتناب کرد.
- منابع ایستا میتوانند در حافظه پنهان ذخیره شوند.تصاویر، CSS، JS
- صفحات حالت کاربری باید دور زده شوند.HTML صفحات سبد خرید، تسویهحساب و حساب کاربری را کش نکنید.
- به شرط آنکه این صفحات را در قالب HTML کش نکنید، خطر وقوع خریدهای متقاطع بین سبدهای خرید یا حسابهای کاربری به طور قابل توجهی کاهش مییابد.
چطور سایت چندزبانه/چندارزی بسازیم که زبان/قیمت قاطی نشود؟
مهمترین نکته در کلید کش آیا درست است؟
- زبان (مسیر یا زیردامنه)
- ارز (در صورت تأثیر بر نمایش قیمت)
- وارد شده باشد (کوکی)
- منطقه/نرخ مالیات (اگر صفحه بسته به منطقه متفاوت باشد)
اگر این ابعاد در منطق کشگذاری گنجانده نشوند، به احتمال زیاد کاربر زبان A محتوای زبان B را خواهد دید یا با قیمتگذاری ناسازگار مواجه خواهد شد.
۶. باید یکپارچهسازی پروکسی معکوس (Cloudflare/EdgeOne/ESA) را انتخاب کنم یا Pull ایستا CDN (bunny)؟
شما میتوانید بر اساس “اهداف” و “تحمل ریسک” خود انتخاب کنید:
- میخواهید یکباره HTTPS + CDN + امنیت پایه را راهاندازی کنید و بعداً هم بتوانید قوانین/WAF را گسترش دهیدیکپارچهسازی پروکسی معکوس
- میخواهم پایدارترین گام اول را بردارم (منابع ایستا سریعتر) بدون تغییر کل پروکسی سایت:پول استاتیک CDN(مثلاً خرگوش)
اگر هنوز تصمیم نگرفتهاید، توصیهٔ پیشفرض این است:ابتدا ایستا CDN → استراتژی نسخهبندی و چکلیست اعتبارسنجی را مرور کنید → سپس تصمیم بگیرید که آیا باید کشینگ مبتنی بر پروکسی/HTML را پیادهسازی کنید یا خیر.
۷. آیا میتوان از نسخه رایگان مستقیماً روی یک وبسایت زنده استفاده کرد؟
میتوان از آن استفاده کرد، اما “رایگان” را به معنای “مصرف اولیه/ارزیابی/سبک” در نظر بگیرید، نه “راهحل رسمی با SLA تجاری”.
- آیا مایلید طرح رایگان را بپذیرید؟محدودیتهای ظرفیت، حذفهای عملکردی، تنوع در روشهای پشتیبانی و احتمالاً عدم وجود تعهدات SLA？
- اگر این امکان وجود ندارد، باید سرویس رایگان بهعنوان یک دوره آزمایشی در نظر گرفته شود و سپس به بستهای مناسبتر ارتقا یابد.
۸. چگونه مطمئن شوم که CDN واقعاً اثر کرده و فقط تلقین نیست؟
با استفاده از این سه مرحله تأیید کنید (نیازی به ابزارهای پیچیده نیست):
- بررسی بازگشت منابع ایستا از CDN(آیا منبع تصاویر/CSS/JS تغییر کرده است؟)
- مشاهده کنید که آیا نرخ موفقیت و عملکرد بازگشت به منبع بهبود یافتهاند.(فقط زمانی که نرخ ضربه افزایش یابد و بازسازی منابع کاهش یابد، میتوان آن را یک مزیت واقعی دانست)
- سیاست تأیید اعتبار CSS/تصویر را هنگام اصلاح بهروزرسانی کنید.(شماره نسخهٔ جاری، نشاندهنده قابلیت کنترل پیوند)
اگر نتوانید سومین نکته را پیادهسازی کنید، بهینهسازیهای بعدی بهطور فزایندهای با مشکل عدم اعمال بهروزرسانیها مواجه خواهند شد. توصیه میشود تکمیل استراتژی نسخهبندی را در اولویت قرار دهید.
۹. چرا فعالسازی قابلیت تسریع چین اصلی اغلب گیر میکند؟
شایعترین علل عبارتند از:منطقهٔ انتخابشده شرایط ثبت را ندارد.。
- اگر بخواهید ناحیه شتابی را که شامل سرزمین اصلی چین میشود انتخاب کنید، معمولاً باید تکمیل کنید ارائه درخواست ICPکاربران ثبتنامنشده فقط میتوانند مناطقی را انتخاب کنند که شامل سرزمین اصلی چین نباشند.
10. باید اول افزونهٔ کش را نصب کنم یا اول CDN را راهاندازی کنم؟
ترتیب معمولاً توصیهشده به شرح زیر است:
- لایه سرور Origin: ابتدا افزونههای کش/زیرساخت میزبانی پایدار شدند (TTFB کاهش یافت، بار بکاند کاهش یافت)
- لایهٔ منابع: تصاویر را برای کاهش اندازهٔ فایل بهینهسازی کنید
- لایه تحویل: CDN منابع را سریعتر و پایدارتر میرساند
اگر در حال حاضر فقط به یک چیز فکر میکنید و میخواهید از هرگونه خطری جلوگیری کنید:ابتدا استاتیک CDN (مرحله 1)بازده ثابت، ریسک حداقلی.
فارسی