صفحهٔ اصلی/راهنما/بهینه‌سازی وب‌سایت/جزئیات

اگر بهینه‌سازی عملکرد وردپرس را به سه لایه تقسیم کنیم:

  • لایه سرور اوریجینسرور / PHP / پایگاه داده / افزونهٔ کشینگ —— تعیین‌کنندهٔ TTFB و بار بک‌اند
  • لایهٔ منابعبهینه‌سازی تصویر — اندازه دانلود و سرعت بارگیری تصاویر بزرگ در صفحه اول را تعیین می‌کند
  • لایهٔ تحویل: CDN — تضمین نزدیک‌تر بودن منابع به کاربران، ضربات قابل‌اعتمادتر و بار کمتر بر روی سرورهای مبدأ

این مقاله به بحث می‌پردازد شتاب‌دهی CDN：

  • درک اینکه CDN چه مسائلی را می‌تواند حل کند و چه مسائلی را نمی‌تواند حل کند
  • طرح CDN و ارائه‌دهنده‌ای را که برای شما مناسب‌تر است انتخاب کنید (و تفاوت‌های بین نسخه‌های رایگان و استارتر را درک کنید)
  • اجرا را به ترتیب کمترین ریسک آغاز کنید، اطمینان حاصل کنید که سایت از کار نیفتد و از بروز مشکلات مربوط به کشینگ تجارت الکترونیک/عضویت جلوگیری کنید.
  • پس از استقرار، می‌تواند تأیید کند که “واقعاً مؤثر واقع شده است” و مشکلات را عیب‌یابی کند، مانند “چرا به‌روزرسانی نشده است/چرا سرعت کاهش یافته است/چرا محتوا با هم مخلوط می‌شود”.”

۱. اول مفاهیم را روشن کنیم: CDN چه چیزی را حل می‌کند و چه چیزی را حل نمی‌کند

۱.۱ CDN عمدتاً سه مسئله کلیدی را مورد توجه قرار می‌دهد

۱.۱.۱ تحویل سریع‌تر منابع ایستا
تصاویر، CSS، JS، فونت‌ها، آیکون‌ها و سایر منابع ایستا به بازدیدکنندگان نزدیک‌تر هستند که منجر به دانلود سریع‌تر و رندر پایدارتر صفحات می‌شود.
برای وردپرس، به‌ویژه منابع قالب و افزونه (wp-content/themes/、wp-content/plugins/) و تصاویر کتابخانهٔ رسانه (wp-content/uploads/) معمولاً از نظر حجم “سنگین‌وزن‌ها” هستند.

۱.۱.۲ کاهش بار بر روی سرور مبدأ
وقتی یک درخواست به کش لبه می‌رسد، دیگر نیازی به دریافت مکرر داده‌ها از سرور اصلی ندارد، که منجر به کاهش فشار بر پهنای باند سرور اصلی، اتصالات همزمان، ورودی/خروجی دیسک و نوسانات CPU می‌شود.
این امر به‌ویژه در شرایط اوج مانند “ترافیک بالا به صفحات تبلیغاتی، مقالات ویروسی و صفحات محصول” مشهود است.

۱.۱.۳ تقویت ثبات (مقاومت بیشتر در برابر نوسان)
در دوره‌های اوج ترافیک، گره‌های لبه حجم قابل‌توجهی از درخواست‌های تکراری را جذب می‌کنند و بدین ترتیب احتمال از کار افتادن سرور مبدأ کاهش می‌یابد.
شما “دسترسی روان‌تر” را مشاهده خواهید کرد: حتی زمانی که سرور اصلی با افزایش ناگهانی بار مواجه می‌شود، کش لبه به ارائه محتوا بدون وقفه ادامه می‌دهد.

۱.۲ سه نوع مسئله‌ای که CDN نمی‌تواند به‌طور خودکار حل کند

1.2.1 خود سرور اصلی کند است
عملکرد کند پایگاه داده، منطق کند افزونه، محاسبات کند PHP — این‌ها مشکلاتی در سطح سرور اصلی هستند.
CDN می‌تواند منابع ایستا را تسریع کند، اما اگر حتی HTML صفحهٔ اصلی شما مدت زیادی برای تولید نیاز داشته باشد، کاربران همچنان احساس خواهند کرد که سایت “بارگذاری کند” است. در این صورت باید به ترتیب اولویت‌بندی کنید: میزبانی، افزونه‌های کش و بهینه‌سازی پایگاه داده.

۱.۲.۲ خود تصویر خیلی بزرگ است
CDN نمی‌تواند به‌طور جادویی تصویر بزرگ 3MB را کوچک کند.
ابتدا باید تصاویر خود را بهینه کنید: یک استراتژی تعیین اندازه پیاده‌سازی کنید (از دانلود تصاویر بزرگ‌جثه خودداری کنید)، فشرده‌سازی را اعمال کنید، از فرمت‌های WebP/AVIF استفاده کنید و استراتژی‌های بارگذاری تنبل را پیاده‌سازی کنید.

1.2..3 اسکریپت‌های شخص ثالث کند هستند
تبلیغات، تحلیل‌ها، خدمات مشتری، اجزای رسانه‌های اجتماعی و غیره از دامنه‌های شخص ثالث سرچشمه می‌گیرند.
CDN معمولاً نمی‌تواند آن‌ها را “سریع‌تر” کند؛ شما تنها می‌توانید با کاهش یا به تعویق انداختن بارگذاری، تغییر تأمین‌کنندگان یا بهینه‌سازی سیاست‌های اسکریپت به این موضوع رسیدگی کنید.

توصیه

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

۲. راهنمای ۳۰ ثانیه‌ای: به کدام پیکربندی CDN نیاز دارید؟

برای وردپرس، گزینه‌های رایج در دو دسته قرار می‌گیرند. با انتخاب اول “فرم” و سپس “ارائه‌دهندهٔ خدمات”، رویکرد به‌طور چشمگیری واضح می‌شود.

۲.۱ نوع یکپارچه “پروکسی معکوس” (بدون دردسر بیشتر، مناسب برای اکثر سایت‌ها)

ویژگی‌ها: نه‌تنها CDN است، بلکه همچنین DNS / SSL / حفاظت امنیتی پایه (مثلاً DDoS/WAF) آنها را با هم بسته‌بندی کنید. وقتی وصل شدید، به‌عنوان یک پروکسی در مقابل وب‌سایت شما عمل می‌کند.

آنچه دریافت خواهید کرد:

  • مدیریت ساده‌تر گواهی‌نامه و TLS با HTTPS
  • یک دروازهٔ امنیتی یکپارچه (حفاظت پایه در برابر DDoS، کنترل دسترسی، WAF و غیره)
  • کش‌گذاری در لبه و موتور قواعد (فراهم‌سازی سیاست‌های کش‌گذاری دقیق‌تر و راهبردهای دور زدن)
  • “دامنهٔ گسترده‌تر برای توسعه: اگر در آینده بخواهید ویژگی‌های امنیتی، محدودیت‌های سرعت یا محافظت در برابر ربات‌ها را اضافه کنید، معمولاً می‌توان آن‌ها را در همان سیستم ادغام کرد.

نمایندگان: Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

اگر مایل باشید:

  • تو آرزو می‌کنی HTTPS + CDN + امنیت پایه یک‌جا
  • آیا مایل هستید مدیریت لایه حل نام دامنه/پروکسی خود را به یک پلتفرم واحد بسپارید؟
  • شما بر “تجربه کلی و مقیاس‌پذیری آینده” تأکید بیشتری دارید و نمی‌خواهید DNS، گواهی‌ها، CDN و امنیت را به چندین مجموعه تقسیم کنید.

۲.۲ کشش ایستا خالص CDN (شروع با ریسک کم، عمدتاً بهینه‌سازی تصاویر/CSS/JS)

ویژگی‌ها: شما فقط منابع ایستا را در کش لبه CDN قرار می‌دهید؛ صفحات HTML همچنان توسط سرور اصلی (و افزونه کش سرور اصلی) مدیریت می‌شوند.

آنچه دریافت خواهید کرد:

  • ریسک عملیاتی بسیار کم: مادامی که کد HTML دستکاری نشود، وقوع موارد “تزریق محتوا/ربایش سبد خرید” بسیار بعید است.”
  • مدل‌های هزینه شهودی‌تر هستند: معمولاً بر اساس حجم ترافیک/درخواست/منطقه صورتحساب می‌شوند.
  • ساختاری پیشرفته‌تر: بیشتر شبیه به “خدمات توزیع منابع ایستا”

نماینده: bunny.net (مدل شفاف پرداخت به‌ازای مصرف)

اگر مایل باشید:

  • شما می‌خواهید ابتدا “پایدارترین گام” را بردارید—شتاب‌دهی منابع ایستا.
  • شما می‌خواهید قبل از تصمیم‌گیری دربارهٔ پیاده‌سازی کش مبتنی بر پروکسی یا کش کل سایت، بازگشت سریع سرمایه‌گذاری‌تان را ببینید.
  • شما ترجیح می‌دهید هزینه‌ها نزدیک‌تر به مدل “پرداخت به‌ازای مصرف” باشد.”

۳. چگونه انجام دهیم

  • سطح اول: مدل آژانس یکپارچه (ترجیحی): کلاودفلر / اج‌وان / ای‌اس‌ای
  • سطح ۲: کشش ایستا ۱TP219T (یک شروع ایمن): bunny.net / Cloudways / CDN و غیره

۴. ارائه‌دهندگان خدمات پیشنهادی

4.1 کلودفلریکپارچه‌سازی پروکسی معکوس (شروع رایگان، اکوسیستم بالغ)

این چیست؟
وقتی دامنه‌تان را متصل کردید، به‌عنوان یک پروکسی در مقابل وب‌سایت شما عمل می‌کند و CDN، گواهی‌ها، حفاظت امنیتی پایه و قواعد کشینگ را فراهم می‌آورد.

برای چه کسی مناسب است؟

  • به دنبال یک راه‌حل بدون دردسر: HTTPS + CDN + بسته امنیتی پایه جامع
  • برای دستیابی به یک اکوسیستم بالغ: افزودنی‌های بعدی شامل WAF، محدودسازی نرخ، قواعد لبه و غیره خواهند بود، با یک مسیر پیاده‌سازی بسیار روان.

نقطه‌های ریسک

  • به‌روزرسانی اعمال نشده است.پس از استقرار CDN، زنجیرهٔ کش طولانی‌تر شده است (کش مرورگر + کش CDN + کش سرور اصلی)؛ برای اطمینان از به‌روزرسانی‌های کنترل‌شده به “سیاست نسخه” نیاز است (درخت عیب‌یابی در زیر ارائه شده است)
  • کش کردن HTML نیازمند احتیاط است.اگر HTML در حافظه پنهان ذخیره شده باشد، صفحات تجارت الکترونیک/عضویت/شخصی‌سازی‌شده باید به‌طور قاطع دور زده شوند، در غیر این صورت ممکن است حوادث جدی رخ دهد (فهرست سناریوها در زیر ارائه شده است).

توضیح：

  • پیکربندی: پروکسی معکوس یکپارچه (SSL + CDN + حفاظت پایه)
  • مناسب برای: استقرار بدون دردسر با امکان گسترش فراوان در آینده
  • ارزش اصلی: نقطهٔ ورود یکپارچهٔ گواهی‌نامه/امنیت/پیش‌پوسته
  • خطر: به‌روزرسانی‌ها به استراتژی نسخه‌بندی بستگی دارند؛ کشینگ HTML باید به‌طور کامل دور زده شود.

4.2 اج یک بین‌المللی تِنسنت کلودیکپارچه‌سازی پروکسی معکوس

این چیست؟
پلتفرم به‌طور مشابه رویکرد یکپارچه “سرعت‌بخشی + امنیت + گواهی‌ها” را اتخاذ می‌کند و آن را برای قرار دادن وب‌سایت‌ها تحت مدیریت یکپارچه لایه پروکسی مناسب می‌سازد.

  • مانند کلودفلر، یک نسخهٔ رایگان ارائه می‌دهد، اما معمولاً سهمیه/محدودیت عملکردی(تعداد قوانین، تعداد وظایف لاگ، و غیره)، اما نیازی به تغییر DNS نیست؛ کافی است رکورد CNAME را برای اتصال به آن پیکربندی کنید.نسخه‌های رایگان برای وب‌سایت‌های تجاری توصیه نمی‌شوند.！
  • در عین حال، طرح‌های رایگان اغلب به معنای SLA تضمین نمی‌کند
    قابل استفاده است، اما نباید به‌عنوان یک “بسته SLA تجاری” در نظر گرفته شود.
  • اگر می‌خواهید هنگام حضور در سرزمین اصلی چین به‌طور خودکار به خطوط تلفن سرزمین اصلی چین منتقل شوید، معمولاً ابتدا باید موارد زیر را انجام دهید:پرونده ICP چینوقتی ثبت‌نام نشده باشید، فقط مسیرهای بین‌المللی قابل استفاده هستند.

توجه:

  • موقعیت‌یابی: یکپارچه‌سازی پروکسی معکوس (شتاب‌دهی + امنیت + گواهی‌ها)
  • مناسب برای: کسانی که به دسترسی یکپارچه نیاز دارند و ظرفیت گره‌های سرزمین اصلی چین را مدنظر قرار می‌دهند.
  • رایگان: یک طرح/نسخهٔ رایگان موجود است، اما با سهمیه‌های محدود و معمولاً بدون تضمین SLA.
  • خطرات: سهمیه‌های قوانین، لاگ‌ها و زیردامنه‌ها نیازمند برنامه‌ریزی قبلی هستند؛ کشینگ HTML نیز مستلزم احتیاط است.

4.3 معماری امنیت سازمانی بین‌المللی علی‌بابا کلودیکپارچه‌سازی پروکسی معکوس

  • مانند کلودفلر، یک نسخهٔ رایگان ارائه می‌دهد، اما معمولاً سهمیه/محدودیت عملکردی(تعداد قوانین، تعداد وظایف لاگ، و غیره)، اما نیازی به تغییر DNS نیست؛ کافی است رکورد CNAME را برای اتصال به آن پیکربندی کنید.نسخه‌های رایگان برای وب‌سایت‌های تجاری توصیه نمی‌شوند.！
  • برای شروع استفاده، در سایت بین‌المللی یک حساب کاربری ثبت کنید.
  • به کنسول ESA دسترسی پیدا کنید تا یک سایت اضافه کنید و گزینهٔ رایگان را انتخاب کنید. ورودی دسترسی به بسته
  • اگر می‌خواهید در داخل سرزمین اصلی چین به‌طور خودکار به مسیرهای سرزمین اصلی چین سوئیچ کنید، معمولاً ابتدا باید ثبت ICP را تکمیل کنید؛ بدون ثبت، تنها می‌توانید از مسیرهای بین‌المللی استفاده کنید.
  • نقشه‌های رایگان برای اهداف توسعه، آزمایش و ارزیابی مناسب‌تر هستند و معمولاً معادل بسته‌های تجاری SLA نیستند.
  • بسته‌های رایگان اغلب با محدودیت‌های سرعت یا محدودیت‌های پشتیبانی عرضه می‌شوند (مثلاً توافق‌نامه‌های سطح خدمات و غیره).

در مورد مسیرهای سرزمین اصلی چین:

  • برای فعال‌سازی گره سرزمین اصلی چین، معمولاً باید هم الزامات ثبت سوابق و هم الزامات منطقه‌ای را برآورده کرد.
  • ورود رایگان به‌طور پیش‌فرض روی مسیر بین‌المللی تنظیم شده است. برای استفاده از مسیر سرزمین اصلی چین، باید موارد زیر را تکمیل کنید:الزامات ثبت ICP چین

توجه:

  • موقعیت‌یابی: یکپارچه‌سازی پروکسی معکوس (شتاب‌دهی سایت + امنیت)
  • رایگان: حساب‌های بین‌المللی سایت می‌توانند به‌طور رایگان به Entrance دسترسی داشته باشند؛ شتاب‌دهی در سرزمین اصلی چین به‌طور پیش‌فرض شامل نمی‌شود.
  • مناسب برای: ارزیابی/آزمون و استفاده سبک؛ یا ارتقاء بسته‌های بعدی.
  • خطرات: از محدودیت‌های لایه رایگان (SLA/محدودسازی/گزینه‌های پشتیبانی) آگاه باشید؛ نیازمندی‌های منطقه‌ای و ثبت‌نام را از قبل برنامه‌ریزی کنید.

4.4 bunny.netکشش ایستا CDN (نقطه ورود کم‌ریسک، قیمت‌گذاری شفاف پرداخت به‌ازای مصرف)

اگر می‌خواهید “ابتدا پایدارترین بازده‌ها را تضمین کنید”، استراتژی‌ای مانند «Pull CDN» روی bunny ایده‌آل است:
این بیشتر مانند یک “خدمات توزیع منابع” عمل می‌کند: شما آن را مسئول توزیع منابع ثابت خود می‌سپارید، با هزینه‌هایی که معمولاً به حجم ترافیک، تعداد درخواست‌ها یا منطقه جغرافیایی بستگی دارد. این مدل شفاف و قابل مدیریت است.

مناسب برای:

  • ابتدا آن را انجام بده تصاویر / سی‌اس‌اس / جی‌اس / فونت‌ها شتاب ایستا
  • شما می‌خواهید ابتدا “بازده‌های پایدار با ریسک کم” را تضمین کنید و در تحویل کل سایت به یک پلتفرم به سبک آژانس (راهکار همه‌کاره DNS/SSL/WAF) عجله ندارید.
  • شما ترجیح می‌دهید مدل هزینه نزدیک‌تر به سیستم پرداخت به‌ازای مصرف باشد، تا اینکه از ابتدا وارد ساختار بسته‌های پیچیده‌تر شوید.

نقطه‌های ریسک

مسئله‌ی به‌کارنفتادن به‌روزرسانی‌های منابع ایستا تقریباً هرگز در CDN باگ نیست.بلکه رفتار عادی سیستم کش:
وقتی شما CSS/JS/تصاویر را در بک‌اند به‌روزرسانی می‌کنید، امانشانی منبع بدون تغییر باقی می‌ماند.(همان آدرس/نام فایل/مسیر)، هر دو CDN و مرورگر به‌طور طبیعی همچنان کش قدیمی را ارائه می‌کنند، بنابراین شما تعجب خواهید کرد: “چرا به‌روز نشده است؟”

یک اصل روشن و قابل اجرا:

به نسخه‌های جدیدتر اولویت دهید؛ پاک‌سازی به‌عنوان راه‌حل پشتیبان.

چرا این قابل‌اعتمادترین رویکرد است:

  • تغییرات شمارهٔ نسخه/نام فایل → تغییر URL → CDN به‌عنوان یک منبع جدید در حافظه پنهان ذخیره شد → نسخه جدید تقریباً بلافاصله اعمال می‌شود
  • پاکسازی (پاک کردن کش) نیازمند آغاز دستی است که ممکن است منجر به دامنه نامشخص و تأخیرهای انتشار در سراسر گره‌ها شود؛ پاکسازی‌های مکرر همچنین می‌تواند به کاهش نرخ موفقیت دسترسی، افزایش ترافیک بازگشت به منبع و افزایش نوسان منجر شود.

یک مثال آسان برای فهمیدن:

  • style.css محتوا تغییر کرده است، اما نشانی اینترنتی بدون تغییر باقی مانده است. style.css → CDN ادامه استفاده از کش قدیمی (منطقی)
  • URL می‌شود style.css?ver=20260103 或 style.abc123.css → CDN به‌عنوان یک منبع جدید محسوب می‌شود → نسخهٔ جدید فوراً اجرایی می‌شود

خرگوش به‌عنوان بهترین روش برای “گام ۱ CDN”

  1. در ابتدا تنها منابع ایستا را پوشش دهید.(تصاویر/CSS/JS/فونت‌ها)، HTML را بلافاصله پس از بارگذاری در حافظه پنهان ذخیره نکنید.
    • مزیت: حوادث جدی مانند مشاهده محتوای دیگران یا جزئیات سبد خرید توسط کاربران عملاً وجود ندارد.
    • همچنین متوجه خواهید شد که تأیید مزایا آسان‌تر است: منابع ایستا سریع‌تر بارگذاری می‌شوند و بار سرور اصلی کمتر می‌شود.
  2. استراتژی به‌روزرسانی را به‌طور مؤثر طراحی کنید
    • CSS/JS: هر جا که ممکن است از شماره‌های نسخه یا تغییر نام فایل‌ها استفاده کنید.
    • تصاویر: تا حد امکان از استفاده طولانی‌مدت از نام‌های یکسان برای فایل‌ها خودداری کنید؛ ترجیحاً از نام‌های جدید فایل یا مسیرهای تغییر یافته استفاده کنید (به‌ویژه برای بنرهای صفحه اصلی و گرافیک‌های تبلیغاتی).
  3. پس از راه‌اندازی، از چک‌لیست تأیید برای تصدیق اجرای موفقیت‌آمیز استفاده کنید.
    • آیا منابع ایستا از CDN می‌آیند؟
    • آیا نرخ موفقیت به تدریج در حال افزایش است؟ آیا پهنای باند/حجم درخواست‌های سرور اصلی در حال پایدارتر شدن است؟ (فهرست بررسی در زیر ارائه شده است)

لطفاً توجه داشته باشید

اگر کسب‌وکار شما شامل سرزمین اصلی چین می‌شود، یا می‌خواهید دسترسی سریع‌تر به وب‌سایت خود از سرزمین اصلی چین ممکن شود.

هر دو سرویس ابری علی‌بابا چین و تنسنت کلاود چین شایستهٔ توجه شما هستند. اگر دامنهٔ شما پیش از این در سرزمین اصلی چین وضعیت ثبت ICP را داشته باشد، هنگام استفاده از EdgeOne یا ESA، ترافیکی که از سرزمین اصلی چین منشأ می‌گیرد به‌طور خودکار به مسیرهای داخل سرزمین اصلی چین سوئیچ خواهد شد.

“از گره‌های سرزمین اصلی چین استفاده کنید”معمولاً شامل ثبت ICP است.

برای مرجع

“بهینه‌سازی تجربه دسترسی به وب‌سایت‌های فرامرزی”ممکن است یک قابلیت جداگانه باشد که معمولاً معادل “دسترسی آزاد به گره‌های سرزمین اصلی چین” نیست.”

۵. طرح پیاده‌سازی مسیر: پیشرفت در سه مرحله (از پایدار به مقاوم)

دلیل اصلی اینکه CDN هنگام راه‌اندازی اول تمایل دارد از کنترل خارج شود این است که مردم از همان ابتدا سعی می‌کنند همه قابلیت‌های آن را به حداکثر برسانند.

مرحلهٔ ۱: فقط منابع ایستا (CDN) (به‌شدت توصیه می‌شود ابتدا آن را تکمیل کنید)

هدفتصاویر، CSS، JS و فونت‌ها ابتدا ارائه می‌شوند (CDN)؛ HTML در CDN کش نمی‌شود (یا موقتاً بدون تغییر باقی می‌ماند).

چرا ابتدا این کار را انجام دهیم تا پایدارترین رویکرد باشد؟

  • کمترین ریسک: اگر منابع ایستا به‌طور نادرست کش شوند، بدترین حالت این است که “سبک‌ها/تصاویر به‌روزرسانی نشوند”، که قابل مدیریت است.
  • بر وضعیت ورود، فرآیندهای تجارت الکترونیک یا دقت اطلاعات حساب کاربری تأثیری نخواهد داشت.
  • شما می‌توانید به‌وضوح مزایا را ببینید: دانلود سریع‌تر منابع ایستا و یک سرور مبدأ پایدارتر.

مسائل رایج در این مرحله (عیب‌یابی درخت به زودی)

  • محتوای مختلط (بارگذاری صفحه HTTPS، منابع HTTP)
  • به‌روزرسانی‌های منابع ایستا اعمال نمی‌شوند (URL بدون تغییر)

مرحلهٔ ۲: استراتژی تازه‌سازی (اولویت شمارهٔ نسخه، بازگشت به پاک‌سازی/انقضا)

این خط تمایز را مشخص می‌کند که آیا “CDN” به‌طور حرفه‌ای انجام شده است یا خیر.

یک قانون سخت و قطعی:

به‌روزرسانی‌هایی که می‌توان با تغییر شماره‌های نسخه یا نام‌های فایل آن‌ها را حل کرد، نباید به Purge متکی باشند.

چرا زنجیرۀ کشش وقتی دراز می‌شود، اسرارآمیز می‌گردد؟

  • پیش‌ذخیرهٔ مرورگر: ممکن است فایل‌های CSS/JS قدیمی را به‌صورت محلی ذخیره کرده باشید.
  • CDN کش: ممکن است گره لبه یک منبع منسوخ را در کش ذخیره کرده باشد
  • کش‌گذاری سرور Origin: افزونه‌های کش/کش‌گذاری سرور ممکن است هنوز محتوای منسوخ را ارائه دهند.

اگر شما فاقد یک استراتژی نسخه‌بندی باشید، استقرار به این صورت درمی‌آید:
“تغییرات انجام شد → صفحه تازه‌سازی شد → کار نکرد → کش پاک شد → هنوز کار نکرد → یک لایه دیگر از کش پاک شد”
این مشکل اصلی است که بسیاری از مردم با CDN دارند.

مرحله ۳ (پیشرفته): آیا HTML باید در حافظه پنهان ذخیره شود؟ (پاداش بالا، اما بالاترین ریسک)

کش‌گذاری HTML (کش‌گذاری در سراسر سایت/کش‌گذاری در لبه) می‌تواند به‌طور قابل‌توجهی زمان تا اولین بایت (TTFB) را کاهش دهد، اما در سناریوهای وردپرس نیز یکی از حوزه‌های با وقوع بالای حوادث است.

اگر مطمئن نیستید، HTML را کش نکنید. با نسخهٔ استاتیک CDN و افزونهٔ کش‌کردن سرور اصلی شروع کنید.

هنگام کش کردن HTML، دو اصل اعمال می‌شوند:

  1. شروع صرفاً از “وضعیت بازدیدکننده”: صفحات را فقط برای بازدیدکنندگان ثبت‌نام‌نشده کش کنید
  2. ابتدا فهرست بای‌پس را پیش‌نویس کنید.ابتدا دقت، سپس نرخ ضربه

۶. چک‌لیست قوانین سناریو: چگونه از حوادث در انواع مختلف سایت‌ها جلوگیری کنیم

۶.۱ وب‌سایت‌ها/وبلاگ‌های متمرکز بر محتوا (عمدتاً مقالات، ترافیک بالای بازدیدکنندگان)

توصیه شده

  • منابع ایستا: به‌طور کامل در حافظه پنهان نگهداری می‌شوند
  • HTML: صفحه‌ی بازدیدکننده‌ی ثبت‌نام‌نشده را در حافظه پنهان در نظر بگیرید.“

معمولاً لازم است دور زدن انجام شود.

  • پشت‌زمینه و ورود:/wp-admin/*、/wp-login.php
  • پیش‌نمایش/پیش‌نویس
  • صفحهٔ نتایج جستجو (پارامترها به‌طور قابل‌توجهی متفاوت‌اند؛ عدم استفاده از کش در ابتدا ساده‌ترین روش است)
  • POST درخواست ارسال فرم/ارسال نظر

کلید کش باید به اندازه کافی منحصر به فرد باشد تا تمایز قائل شود.

  • آیا کاربر وارد شده است؟ (بعد cookie)
  • زبان (وب‌سایت چندزبانه)

۶.۲ وب‌سایت‌های شرکتی / صفحات فرود بازاریابی (فرم‌ها، کمپین‌ها)

توصیه شده

  • منابع ایستا: به‌طور کامل در حافظه پنهان نگهداری می‌شوند
  • صفحات فرود عمومی ممکن است در حافظه پنهان ذخیره شوند (وضعیت بازدیدکننده)، اما صفحات نتیجه فرم باید با احتیاط پردازش شوند.

رایج‌ترین تله: ردیابی پارامترهایی که باعث تکه‌تکه شدن کش می‌شوند
صفحه فرود مشترک utm_* پارامترها:

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

۶.۳ سایت‌های عضویت / پلتفرم‌های دوره / جوامع (نسبت بالای کاربران واردشده)

نتیجه‌گیریکش‌گذاری HTML باید با احتیاط بسیار انجام شود.
رویکرد استاندارد معمولاً عبارت است از: فایل‌های ایستا CDN + کش‌کردن منشأ/کش‌کردن اشیاء؛ HTML تنها برای بازدیدکننده کش می‌شود.

باید دور زده شود

  • ورود / ثبت‌نام / بازیابی رمز عبور
  • مرکز حساب، سفارشات/اشتراک‌ها، جزئیات شخصی
  • هر صفحه و رابط کاربری که به شدت به وضعیت کاربر وابسته باشد

۶.۴ سایت تجارت الکترونیک (ووکامرس)

مهم‌ترین فهرست بای‌پس

  • سبد خرید، تسویه‌حساب، صفحهٔ حساب کاربری
  • صفحات مربوط به تأیید سفارش و بازگشت تماس پرداخت
  • ورود/ثبت‌نام، کوپن‌ها/امتیازها و سایر نقاط ورود مرتبط با وضعیت کاربر

چرا حوادث در تجارت الکترونیک بیشتر احتمال دارد رخ دهند؟

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

۶.۵ سایت‌های چندزبانه / چندارزی

توصیه شده

  • منابع ایستا: به‌طور کامل در حافظه پنهان نگهداری می‌شوند
  • HTML: وضعیت بازدیدکننده ممکن است در حافظه پنهان ذخیره شود، اما کلیدهای حافظه پنهان باید به‌طور صریح بین گونه‌های زبانی/واحدهای پولی تمایز قائل شوند.

کلید کش باید در نظر گرفته شود.

  • زبان (مسیر) /en/ /zh/ یا زیر دامنه en.）
  • آیا وارد شده‌اید؟ (cookie)
  • واحد پول/نرخ مالیات (اگر بر نمایش تأثیر داشته باشد)

۷. افشای ریسک

خطر ۱: کش کردن محتوای نادرست (شدیدترین)

  • خطای کش‌کردن منابع ایستا: معمولاً شامل صفحات سبک یا تصاویر منسوخ.
  • خطای کش HTML: مشکلات احتمالی بین محتوا، بین سبد خرید و بین حساب‌ها — این یک حادثه بحرانی است.

خطر ۲: به‌روزرسانی‌ها که اعمال نمی‌شوند (رایج‌ترین)

با طولانی‌تر شدن زنجیرهٔ کش، موارد “اثر نکردن تغییرات” شایع‌تر می‌شوند:

  • اولویت به تغییرات شمارهٔ نسخه/نام فایل داده می‌شود.
  • پاکسازی/بازگشت در صورت شکست
  • فرآیند انتشار باید قابل بازتولید باشد (تا بدانیم در هر انتشار کدام آدرس‌های اینترنتی تغییر کرده‌اند).

ریسک ۳: دامنه تعهدات برای نسخه‌های رایگان/شروع‌کننده

  • ویژگی‌های مشترک طرح‌های رایگان: سهمیه‌های محدود، مستثنی شدن برخی قابلیت‌ها، توافق‌نامه‌های سطح خدمات (SLA) و گزینه‌های پشتیبانی که معادل ارائه‌های تجاری کامل نیستند.

خطر ۴: توانایی‌های مرتبط سرزمین اصلی چین مستعد سوءتفاهم هستند.

  • ESA: برای فعالیت در شبکه سرزمین اصلی چین، ثبت ICP در چین الزامی است.
  • EdgeOne: برای استفاده از مسیرهای سرزمین اصلی چین، ثبت ICP در چین الزامی است.

۸. چک‌لیست تأیید: چگونه پس از راه‌اندازی تأیید کنیم که “واقعاً در حال کار است”

۸.۱ آیا منابع ایستا واقعاً ۱ ترابایت و ۲۱۹ ترابایت فضا اشغال کردند؟

  • آیا فایل‌های تصاویر، CSS و JavaScript از دامنه CDN می‌آیند یا از یک گره حاشیه‌ای؟
  • آیا می‌توان هرگونه شاخص قابل تشخیص برای موفقیت در کش را مشاهده کرد (نشانگرها در پلتفرم‌های مختلف متفاوت هستند)؟

8.2 آیا بار روی سرور مبدأ کاهش یافته است؟

  • آیا پهنای باند سرور اصلی پایدارتر است؟
  • آیا تعداد درخواست‌ها/اتصالات به سرور اصلی کاهش یافته است (به‌ویژه درخواست‌های منابع تکراری)؟

۸.۳ آیا به‌روزرسانی‌ها قابل کنترل هستند؟

  • یک‌بار CSS/JS را ویرایش کنید یا یک تصویر را جایگزین کنید
  • آیا می‌توان نسخهٔ جدید را از طریق “تغییر شمارهٔ نسخه/تغییر نام فایل” به‌سرعت پیاده‌سازی کرد؟
  • اگر به‌روزرسانی‌ها تنها از طریق Purge قابل انجام باشند، این نشان می‌دهد که استراتژی نسخه‌بندی همچنان ناکافی است (اصلاح استراتژی را در اولویت قرار دهید؛ Purge را به‌عنوان یک عملیات روتین در نظر نگیرید).

۸.۴ آیا صفحات کلیدی پویا صحیح هستند؟

(ضروری برای سایت‌های تجارت الکترونیک/عضویت)

  • آیا محتوای صفحه پس از ورود/خروج صحیح است؟
  • آیا صفحات سبد خرید، تسویه‌حساب و حساب کاربری همواره دقیق هستند؟
  • آیا ناهنجاری “دیدن محتوای یکسان وضعیت کاربر توسط کاربران مختلف” رخ داده است (خطر بالا)؟

۸.۵ آیا نرخ خطا در حال افزایش است؟

  • تایم‌اوت منبع، خطاهای ۵xx، دسترسی‌ناپذیری متناوب
  • این‌ها معمولاً نشان‌دهنده موارد زیر هستند: ظرفیت ناکافی در سرور مبدأ، قواعد نادرست، فعال‌سازی محدودسازی، یا مشکلات لینک برگشتی.

۹. عیب‌یابی درخت برای به‌روزرسانی‌هایی که اعمال نمی‌شوند (تبدیل “معما” به مراحل)

ابتدا مشخص کنید که با کدام دسته از مشکلات مواجه هستید:

۹.۱ منابع ایستا به‌روز نشده‌اند (CSS/JS/تصاویر همچنان قدیمی هستند)

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

  • رویکرد رفع مشکل: انتشار منابع جدید با شماره‌های نسخه/نام‌های فایل به‌روز شده.

سناریو ب: همه نسخه قدیمی را می‌بینند (در دستگاه‌های مختلف نامرئی/همچنین قدیمی)
مشکوک اصلی: CDN هنوز به کش قدیمی ضربه می‌زند

  • 99% دلیل: نشانی منبع بدون تغییر
  • راه حل ترجیحی: استراتژی نسخه‌بندی
  • پاکسازی (به‌عنوان یک اقدام موقت)

سناریو C: پس از بازنویسی یک تصویر با همان نام فایل، تصویر قدیمی همچنان نمایش داده می‌شود.
این یک مشکل کلاسیک است که ناشی از کش مرورگر در ترکیب با کش CDN است.

  • راهنمایی عملی: تلاش کنید با به‌کارگیری نام‌های جدید فایل/مسیرها یا شماره‌های نسخه از برخوردهای طولانی‌مدت نام‌ها جلوگیری کنید.

۹.۲ HTML به‌روز نشده است (محتوای صفحه/ماژول‌ها هنوز قدیمی هستند)

سناریو الف: رابطۀ پشتیبان/پس از ورود جدید است، در حالی که بازدیدکنندگان نسخۀ قدیمی را می‌بینند.
شبههٔ قبلی: HTML حالت بازدیدکنندهٔ ذخیره شده است.

  • ابتدا تأیید کنید: آیا HTML برای این نوع صفحه باید در حافظه پنهان ذخیره شود؟
  • اگر کشینگ ضروری باشد، یک استراتژی قابل کنترل برای تازه‌سازی لازم است، در غیر این صورت انتشار غیرقابل مدیریت می‌شود.

سناریو ب: تنها در برخی مناطق/شبکه‌ها محتوای قدیمی نمایش داده می‌شود.
شک اولیه: حالت‌های کش در گره‌های لبه با هم متفاوت هستند.

  • رویکرد حل: از استراتژی‌های نسخه‌بندی/تازهسازی برای به حداقل رساندن اختلافات استفاده کنید؛ در صورت لزوم، مدیریت صریح خطا را پیاده‌سازی کنید.

سناریو C: ناهنجاری در کاربر واردشده/سبد خرید
سیگنال پرخطر: ممکن است کش حاوی محتوای نادرست باشد.

  • فوراً بررسی کنید که آیا صفحات حالت کاربری (مانند سبد خرید، تسویه حساب، صفحات حساب کاربری و غیره) در حافظه پنهان ذخیره شده‌اند یا خیر.
  • بررسی کنید که آیا کلید کش، گونه‌های کلید مانند “حالت کاربری cookie/زبان/ارز” را نادیده می‌گیرد.

۱۰. توصیه‌شده

کلودفلر

  • یکپارچه‌سازی پروکسی معکوس
  • مناسب برای: مبتدیان بدون دردسر
  • نکات کلیدی: استراتژی نسخه‌بندی به‌روزرسانی‌ها را حل می‌کند؛ کشینگ HTML از دیدگاه بازدیدکننده پیاده‌سازی می‌شود.
  • خطر: صفحات پویا باید دور زده شوند.

اج یک بین‌المللی تِنسنت کلود

  • یکپارچه‌سازی پروکسی معکوس
  • مناسب برای: در نظر گرفتن ظرفیت گره در سرزمین اصلی چین و دسترسی یکپارچه
  • رایگان: یک طرح/نسخهٔ رایگان وجود دارد، اما حتماً کوتاها و تعهدات سطح خدمات را با دقت بررسی کنید.
  • خطرات: سهمیه‌های قوانین، لاگ‌ها و زیردامنه‌ها نیازمند برنامه‌ریزی هستند؛ در کشینگ HTML با احتیاط عمل کنید.

معماری امنیت سازمانی بین‌المللی علی‌بابا کلود

  • یکپارچه‌سازی پروکسی معکوس
  • رایگان: حساب‌های بین‌المللی سایت می‌توانند به‌طور رایگان به Entrance دسترسی پیدا کنند.
  • خطرات: سطح رایگان (SLA/حمایت/محدودیت‌های پهنای باند) و الزامات منطقه‌ای/ثبت‌نام باید از قبل تأیید شوند.
  • مناسب برای: ارزیابی/آزمایش با دسترسی سبک؛ یا ارتقای بعدی بسته‌ها؛ یا بررسی قابلیت‌های گره‌های سرزمین اصلی چین و دسترسی یکپارچه.

bunny.net

  • کشش ایستا CDN
  • مناسب برای: شروع با شتاب‌دهی ایستا با خطر کم
  • نکات کلیدی: شماره نسخه در اولویت است و Purge به‌عنوان گزینه پشتیبان در نظر گرفته می‌شود؛ از بازنویسی فایل‌هایی با نام‌های یکسان خودداری کنید.
  • خطر: عدم اجرای صحیح استراتژی‌های به‌روزرسانی ممکن است منجر به مواجهه‌های مکرر با “منابع منسوخ” شود.”

۱۱. توصیه‌ها برای اقدام

  1. ابتدا معماری را انتخاب کنید: یکپارچه‌سازی پروکسی معکوس (Cloudflare/EdgeOne/ESA) یا استاتیک Pull CDN (bunny)
  2. اجرا به صورت مرحله‌ای:ابتدا استاتیک → سپس استراتژی نسخه‌بندی → در نهایت به کشینگ HTML توجه کنید.
  3. فهرست بررسی پس از راه‌اندازی: نرخ موفقیت / بازیابی منبع / به‌روزرسانی‌ها / دورزنی پویا / نرخ خطا
  4. باید سریع‌تر انجام شود: به تنظیمات “پلاگین کش” و “بهینه‌سازی تصویر” بازگردید و لایهٔ سرور اصلی و لایهٔ منابع را یک‌بار دیگر فشرده کنید.

پرسش‌های متداول وردپرس CDN

۱. با اینکه از CDN استفاده می‌کنم، چرا هنوز کند است؟

رایج‌ترین دلیل این نیست که CDN بی‌اثر باشد، بلکه این است که گلوگاه در “لایه تحویل” قرار ندارد.

شما می‌توانید این را به ترتیب زیر تعیین کنید:

  • TTFB همچنان بالا است: نشان‌دهنده تولید کند HTML در سرور مبدأ (پایگاه داده/پلاگین‌ها/تنظیمات پلاگین کش/عملکرد میزبانی) → بازگشت برای بهینه‌سازی در لایه سرور مبدأ
  • تصویر بزرگ در صفحهٔ اول به کندی بارگذاری می‌شود.: نشان می‌دهد حجم، ابعاد یا فرمت تصویر نادرست است → ابتدا بهینه‌سازی تصویر را انجام دهید (فشرده‌سازی، WebP/AVIF، استراتژی تنظیم اندازه)
  • اسکریپت‌های شخص ثالث کار را کند می‌کنند.مشکلات رایج در اسکریپت‌های تبلیغات/آمار/خدمات مشتری → CDN معمولاً کمکی نمی‌کند؛ باید بارگذاری را کاهش دهید یا به تأخیر بیندازید.
  • فقط در برخی مناطق کند است.علل ممکن شامل پوشش گره، اتصال بک‌هال یا خطاهای کش (نرخ هیت پایین) است ← نرخ هیت و وضعیت بک‌هال را بررسی کنید

CDN مسئول ارائهٔ “منابع بهینه‌شده” با سرعت بیشتر است؛ سرورهای مبدأ کند، تصاویر بزرگ و اسکریپت‌های کند باید به‌طور جداگانه رسیدگی شوند.

۲. چرا کاربران پس از به‌روزرسانی CSS/JS/تصاویر هنوز نسخهٔ قدیمی را می‌بینند؟

این رایج‌ترین مشکل در سناریوی CDN است؛ علت اصلی معمولاً:نشانی منبع بدون تغییر باقی می‌ماند.سیستم کش به استفاده معقول از هیت‌های قدیمی کش ادامه خواهد داد.

قابل‌اعتمادترین اصل دست‌کاری:

  • شمارهٔ نسخه اولویت دارد.: آدرس منبع را تغییر دهید (برای مثال) style.css?ver=xxxx یا هَشِ نام فایل
  • پاکسازیوقتی هنوز استراتژی نسخه‌بندی را تعیین نکرده‌اید، پاک کردن کش را به‌عنوان یک اقدام موقت به‌کار ببرید.

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

۳. آیا لازم است HTML را پنهان‌سازی کنم؟ اگر آن را پنهان‌سازی نکنم، آیا بی‌فایده نخواهد بود؟

ضروری نیست.

برای بسیاری از وب‌سایت‌ها، بزرگ‌ترین ارزش CDN در این است:

  • منابع ایستا (تصاویر/CSS/JS/فونت‌ها) سریع‌تر بارگذاری می‌شوند
  • کاهش بار بر روی سرور مبدأ و پایداری افزایش‌یافته

پیش‌بین HTML مزایا ممکن است واقعاً بیشتر باشد (با TTFB کمتر)، اما خطرات نیز در بالاترین حد قرار دارند: تجارت الکترونیک، سیستم‌های عضویت، محتوای شخصی‌سازی‌شده و راه‌اندازی‌های چندزبانه/چندارزی همگی مستعد ذخیره‌سازی نادرست اطلاعات هستند.

رویکرد محتاطانه:

  1. با یک موقعیت ثابت شروع کنید: CDN (ریسک کم، بازده بالا)
  2. استراتژی نسخه‌بندی و چک‌لیست اعتبارسنجی را مرور کنید.
  3. بازبینی کنید که آیا باید HTML را در حافظه پنهان ذخیره کنید (شروع از “وضعیت بازدیدکننده”)

۴. آیا سایت تجارت الکترونیک می‌تواند از CDN استفاده کند؟ آیا این کار سبد خرید را به هم می‌ریزد؟

این کار امکان‌پذیر است و در واقع باید انجام شود (حداقل برای منابع ایستا)، اما باید از کش کردن صفحات تولیدشده توسط کاربر اجتناب کرد.

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

۵. چگونه می‌توانم با استفاده از CDN یک سایت چندزبانه/چندارزی راه‌اندازی کنم تا زبان‌ها و قیمت‌ها با هم مخلوط نشوند؟

نکتهٔ اصلی در کلید کش آیا درست است؟

  • زبان (مسیر یا زیردامنه)
  • ارز (در صورت تأثیر بر نمایش قیمت)
  • آیا وارد شده‌اید؟ (cookie)
  • منطقه/نرخ مالیات (اگر صفحه بسته به منطقه متفاوت باشد)

اگر این ابعاد در منطق کش‌گذاری گنجانده نشوند، به احتمال زیاد کاربر زبان A محتوای زبان B را خواهد دید یا با قیمت‌گذاری ناسازگار مواجه خواهد شد.

۶. آیا باید یک راه‌حل پروکسی معکوس (Cloudflare/EdgeOne/ESA) را انتخاب کنم یا یک سرور استاتیک (bunny)؟

شما می‌توانید بر اساس “اهداف” و “تحمل ریسک” خود انتخاب کنید:

  • می‌خواهم HTTPS + CDN + امنیت پایه را یکجا پوشش دهم، با امکان گسترش به قواعد و WAF بعداً:یکپارچه‌سازی پروکسی معکوس
  • می‌خواهم پایدارترین گام اول را بردارم (منابع ایستا سریع‌تر) بدون تغییر کل پروکسی سایت:کشش ایستا CDN(مثلاً خرگوش)

اگر شما مردد هستید، توصیهٔ پیش‌فرض این است:اولین استاتیک CDN → استراتژی نسخه‌بندی و فهرست بررسی اعتبارسنجی را مرور کنید → سپس تصمیم بگیرید که آیا باید کشینگ مبتنی بر پروکسی/HTML را پیاده‌سازی کنید یا خیر.

۷. آیا نسخهٔ رایگان را می‌توان مستقیماً روی یک وب‌سایت زنده استفاده کرد؟

می‌توان از آن استفاده کرد، اما “رایگان” را به معنای “استفادهٔ اولیه/ارزیابی/سبک” در نظر بگیرید، نه “راه‌حل رسمی با SLA تجاری”.

  • آیا مایل هستید طرح رایگان را بپذیرید؟محدودیت‌های ظرفیت، حذف‌های عملکردی، تفاوت‌ها در روش‌های پشتیبانی و احتمالاً نبود تعهدات SLA？
  • اگر این امکان وجود نداشته باشد، باید خدمات رایگان به‌عنوان یک دوره آزمایشی در نظر گرفته شود و سپس به بسته‌ای مناسب‌تر ارتقا یابد.

۸. چگونه می‌توانم مطمئن شوم که CDN واقعاً کار می‌کند و نه صرفاً اثر دارونما؟

با استفاده از این سه مرحله تأیید کنید (بدون نیاز به ابزارهای پیچیده):

  1. بررسی کنید که آیا منابع ایستا از CDN بازگردانده می‌شوند.(آیا منبع تصاویر/CSS/JS تغییر کرده است؟)
  2. مشاهده کنید که آیا نرخ موفقیت و عملکرد بازگشت به منبع بهبود یافته‌اند.(فقط زمانی که نرخ ضربه افزایش یابد و بازسازی منابع کاهش یابد، می‌توان آن را یک دستاورد واقعی دانست)
  3. سیاست تأیید اعتبار CSS/تصویر را هنگام تغییر به‌روزرسانی کنید.(شماره نسخهٔ جاری، که قابلیت کنترل پیوند را نشان می‌دهد)

اگر نتوانید سومین نکته را اجرا کنید، بهینه‌سازی‌های بعدی به طور فزاینده‌ای با مشکل عدم اعمال به‌روزرسانی‌ها مواجه خواهند شد. توصیه می‌شود تکمیل استراتژی نسخه‌بندی را در اولویت قرار دهید.

۹. چرا فعال‌سازی قابلیت تسریع چین اصلی اغلب گیر می‌کند؟

شایع‌ترین علل عبارتند از:منطقهٔ انتخاب‌شده شرایط ثبت را ندارد.。

  • اگر بخواهید یک منطقه شتاب‌دهی را که شامل سرزمین اصلی چین می‌شود انتخاب کنید، معمولاً باید تکمیل کنید ارائه اظهارنامه ICPکاربران ثبت‌نام‌نشده تنها می‌توانند مناطقی را انتخاب کنند که شامل سرزمین اصلی چین نباشند.

۱۰. آیا باید اول افزونهٔ کش را نصب کنم یا اول CDN را راه‌اندازی کنم؟

ترتیب معمولاً توصیه‌شده به شرح زیر است:

  1. لایه سرور Origin: ابتدا افزونه‌های کش و زیرساخت میزبانی تثبیت شدند (TTFB کاهش یافت، بار بک‌اند کاهش یافت)
  2. لایهٔ منابع: تصاویر را بهینه‌سازی کنید تا اندازهٔ فایل کاهش یابد.
  3. لایه تحویل: CDN – تحویل منابع سریع‌تر و قابل‌اعتمادتر

اگر در حال حاضر فقط برای یک کار آماده‌اید و می‌خواهید از هرگونه حادثه ناخواسته جلوگیری کنید:ابتدا پیکربندی ایستا: CDN (فاز ۱)بازده ثابت، ریسک حداقلی.