آزمایش تأثیر CDN بر عملکرد سایت چگونه انجام می‌شود؟

سال‌ها پیش روی یک پروژه فروشگاهی، CDN (Content Delivery Network) را فعال کردم و به مشتری وعده دادم زمان بارگذاری نصف می‌شود. یک ماه بعد، آمار تحلیلی نشان داد میانگین زمان بارگذاری تنها حدود دوازده درصد بهتر شده است. آن تجربه باعث شد از آن روز به بعد، هیچ CDN را بدون یک آزمایش کنترل‌شده پیشنهاد نکنم. این مقاله همان متدولوژی است.

چرا سنجش اثر CDN پیش از هر تصمیمی ضروری است؟

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

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

نکته دوم این که آزمایش CDN بدون درک تصویر کلی بهینه‌سازی، مثل تست موتور خودرو بدون سنجش وزن و آیرودینامیک بدنه است. پیشنهاد می‌کنم پیش از هر آزمایش، نگاهی به بهینه‌سازی سرعت سایت چیست و چرا مهم است؟ بیندازید؛ آنجا شش لایه سرعت را کنار هم دیده‌ام و CDN تنها یکی از آن‌هاست.

نکته سوم و مهم‌تر: بخش زیادی از منابع فارسی فقط از مزایای CDN می‌گویند و به شرایطی که CDN اثری نمی‌گذارد کمتر می‌پردازند. اگر سایت شما تماماً پویا است و کش‌پذیری صفحه پایین است، انتظار شما برآورده نمی‌شود. برای این که بدانید کدام سرویس‌ها برای نیازهای مختلف مناسب‌ترند، جدول مقایسه سرویس‌های CDN را ببینید که در آن هر سرویس از نظر پوشش جغرافیایی، قیمت و کیفیت کش مقایسه شده است.

در نهایت، یادمان باشد که CDN یکی از چند گزینه‌ای است که روی سرعت اثر می‌گذارد. تاثیر هاست بر سرعت سایت چقدر است؟ نشان می‌دهد گاهی انتخاب هاست درست، اثری به‌مراتب بزرگ‌تر از فعال‌کردن CDN دارد. اگر این ترتیب اولویت‌ها را در ذهن نداشته باشید، آزمایش شما فقط یک عدد تولید می‌کند بی‌آن‌که بدانید همان عدد در مقایسه با چه چیزی معنا می‌گیرد.

CDN در دست کسی که نداند چه چیزی را باید بسنجد، فقط یک لایه اضافه است که پول و پیچیدگی هزینه می‌کند.

CDN در لایه فنی دقیقاً چه کاری انجام می‌دهد؟

برای طراحی آزمایش، ابتدا باید بدانیم CDN چه چیزی را تغییر می‌دهد. Content Delivery Network شبکه‌ای از سرورهای لبه یا همان edge nodes است که محتوای استاتیک را نزدیک‌تر به کاربر نهایی نگه می‌دارد. اولین بار که کاربر صفحه‌ای را درخواست می‌کند، درخواست از سرور مبدأ عبور می‌کند و پاسخ در لبه کش می‌شود؛ بارهای بعدی مستقیماً از لبه پاسخ داده می‌شوند.

این مکانیزم باعث می‌شود سه چیز تغییر کند: فاصله فیزیکی میان کاربر و اولین پاسخ‌دهنده، بار پردازشی روی سرور مبدأ، و پهنای باند مصرفی برای محتوای استاتیک. اما توجه کنید که CDN به تنهایی محتوای پویا مثل خروجی PHP یا کوئری‌های دیتابیس را سریع نمی‌کند؛ مگر آن که از لایه‌ای مثل edge computing یا کش کامل صفحه استفاده شود، که خودش پروژه‌ای جداگانه است.

درک این تفکیک برای طراحی آزمایش حیاتی است. اگر تصویر بزرگ و CSS و JS و فونت شما به لبه منتقل شوند ولی TTFB (Time To First Byte) که توسط سرور مبدأ تولید می‌شود تغییر نکند، عدد کلی LCP فقط بخشی از بهبود را نشان می‌دهد. برای درک عمیق TTFB و این که چه بخشی از آن با CDN بهبود می‌یابد و چه بخشی نمی‌یابد، مقاله تأثیر TTFB بر سرعت بارگذاری صفحه را پیشنهاد می‌کنم.

از سمت زیرساخت، CDN در واقع بخشی از همان مفهوم کلی‌تر رایانش ابری چیست و چه مزایایی دارد؟ است که روی توزیع جغرافیایی تمرکز کرده. به همین دلیل، وقتی راجع به CDN صحبت می‌کنیم، در واقع راجع به یک لایه توزیع‌شده از پردازش و ذخیره‌سازی حرف می‌زنیم، نه یک افزونه سرعت.

پنج متغیری که باید در آزمایش اندازه‌گیری شوند

یک آزمایش CDN که فقط به LCP نگاه کند، تقریباً همیشه گمراه‌کننده است. در پروژه‌های واقعی، پنج متغیر را به‌طور موازی می‌سنجم و هر کدام داستان متفاوتی را روایت می‌کنند.

۱. TTFB پیش و پس از CDN

TTFB اولین عددی است که در آزمایش معنادار است. اگر سایت شما از قبل TTFB پایینی دارد، CDN روی این عدد تغییر چشمگیری ایجاد نمی‌کند. اگر TTFB بالاست، CDN می‌تواند بخشی از آن را با پاسخ از لبه بهبود بدهد، اما بخش کوئری دیتابیس و اجرای PHP همچنان روی سرور مبدأ می‌ماند. بهترین راه برای جدا کردن این دو بخش، اندازه‌گیری TTFB با ابزارهایی است که در مقاله ابزارهای تست سرعت سایت کدامند؟ معرفی کرده‌ام.

۲. LCP در دستگاه و شبکه واقعی

LCP (Largest Contentful Paint) عددی است که کاربر واقعاً حس می‌کند. اگر LCP سایت شما بنر هدر است و CDN آن بنر را از لبه می‌آورد، بهبود آن معمولاً محسوس است. اما اگر LCP به محتوای پویا وابسته باشد، ممکن است تغییر نکند. جزئیات تعریف و روش کاهش آن در LCP چیست و چگونه آن را بهینه کنیم؟ آمده است.

۳. نرخ کش شدن یا cache hit ratio

این عدد را باید از پنل خود CDN بگیرید، نه از ابزارهای بیرونی. نسبت hit به miss به شما می‌گوید چه بخشی از ترافیک واقعاً از لبه پاسخ می‌گیرد. اگر نرخ کش شدن زیر هفتاد درصد باشد، بخش عمده اثر CDN از دست رفته است.

۴. تأخیر شبکه از نقاط مختلف

ping و traceroute از چند نقطه جغرافیایی، تفاوت تأخیر پیش و پس از CDN را نشان می‌دهد. این عدد تقریباً همیشه بهترین شاهد برای اثبات اثر CDN بر کاربران دور از سرور مبدأ است.

۵. بار CPU و پهنای باند سرور مبدأ

اثر CDN همیشه در سرعت کاربر نیست؛ گاهی در آزادسازی منابع سرور است. اگر سرور مبدأ پیش از CDN در ساعات اوج به مرز پرش می‌رسید و پس از CDN به مرز آرام‌تری برگشته، ارزش CDN با شاخص مصرف منابع اثبات می‌شود.

ابزارهایی که در تست‌های واقعی به آن‌ها تکیه می‌کنم

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

دسته اول ابزارهای آزمایشگاهی هستند؛ Lighthouse، WebPageTest و PageSpeed Insights. این ابزارها برای تشخیص لایه‌ای که کند است بسیار خوب‌اند، اما برای سنجش اثر CDN روی کاربران واقعی، فقط نمای اولیه می‌دهند.

دسته دوم ابزارهای میدانی‌اند. CrUX یا همان Chrome User Experience Report و گزارش‌های Core Web Vitals در Search Console، داده‌ای از کاربران واقعی می‌دهند. اگر پیش از فعال‌سازی CDN این داده را ذخیره کنید، پس از فعال‌سازی می‌توانید تغییرات را با دقت بالاتری بسنجید. تعریف دقیق سه معیار LCP و CLS و INP در Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد؟ آمده است.

دسته سوم ابزارهای سفارشی هستند. یک اسکریپت کوچک با curl یا wget از سه نقطه جغرافیایی که کاربران اصلی شما در آنجا ساکن هستند. این اسکریپت باید قبل و بعد از فعال‌سازی CDN، حداقل بیست بار در بازه‌های زمانی مختلف اجرا شود. توجه کنید که در این اسکریپت باید هدر پاسخ سرور را هم ذخیره کنید تا بتوانید تشخیص دهید پاسخ از لبه آمده یا از سرور مبدأ.

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

طراحی سناریوی قبل و بعد از فعال‌سازی

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

گام اول: انجماد وضعیت پایه

پیش از هر تغییری، یک هفته کامل داده پایه جمع‌آوری می‌کنم. این داده شامل میانگین، میانه و صدک نود و پنجم برای هر پنج متغیر است. اگر داده پایه فقط از یک روز گرفته شود، نویز شبکه می‌تواند نتیجه آزمایش را کاملاً گمراه کند. پیشنهاد می‌کنم در این مرحله از چگونه مشکل سرعت سایت را عیب‌یابی کنیم؟ به‌عنوان چک‌لیست جانبی استفاده کنید تا مطمئن شوید پیش از آزمایش، گلوگاه‌های دیگری روی سایت شما فعال نیستند.

گام دوم: پاک‌سازی کش در همه لایه‌ها

پیش از فعال‌سازی CDN، کش افزونه، کش سرور و کش DNS را کامل پاک کنید. بدون این کار، بخشی از پاسخ‌های لبه در واقع پاسخ‌های کش قدیمی هستند و عدد شما غیرقابل اعتماد می‌شود. اگر از بهترین افزونه‌های کش وردپرس برای افزایش سرعت استفاده می‌کنید، پیش از آزمایش همه کش‌ها را disable و پس از فعال‌سازی CDN دوباره enable کنید.

گام سوم: فعال‌سازی و انتشار تدریجی

در پروژه‌های بزرگ، CDN را یک‌شبه فعال نکنید. اگر تنظیمات اشتباه باشد، ممکن است تصاویر یا فایل‌های استاتیک ناپدید شوند یا به نسخه قدیمی گیر کنند. توصیه من این است که ابتدا CDN را در حالت DNS-only یا Development Mode قرار دهید تا فقط مسیر ترافیک از لبه عبور کند، اما کش فعال نباشد. پس از اطمینان از پایداری، کش را مرحله‌به‌مرحله برای انواع فایل (تصویر، CSS، JS) فعال کنید.

گام چهارم: اندازه‌گیری پس از فعال‌سازی

حداقل هفت روز داده جمع‌آوری کنید. اگر ترافیک سایت کم است، این بازه را طولانی‌تر کنید. سه بازه ساعتی مختلف (صبح، عصر، شب) را جدا نگه دارید تا نویز ساعات اوج از داده‌های غیر اوج جدا شود. همچنین در این مرحله، نرخ cache hit را از پنل CDN بخوانید.

گام پنجم: آزمون تکرارپذیری

در پایان، پس از جمع‌آوری داده، CDN را موقتاً غیرفعال کنید و یک بار دیگر آزمایش را تکرار کنید. اگر نتایج مشابه با حالت پایه بود، آزمایش شما معتبر است. اگر نتایج متفاوت شد، یعنی متغیر خارجی وارد بازی شده که باید بررسی شود.

تحلیل داده و دام‌های آماری

بیشتر گزارش‌های سرعت که به دست مدیریت می‌رسد، یک عدد میانگین است. اما میانگین در تحلیل سرعت تقریباً بی‌ارزش است، چون تحت تأثیر بیرون‌های کمی قرار می‌گیرد. صدک نود و پنجم و نود و نهم دقیقاً همان چیزی است که کاربر تجربه می‌کند.

به عنوان مثال، اگر میانگین LCP پیش از CDN ۲.۸ ثانیه و پس از آن ۲.۳ ثانیه بود، اما صدک نود و پنجم از ۵.۴ به ۳.۱ ثانیه رسید، معنای واقعی این تغییر، بهبود تجربه بخش بزرگی از کاربران است. این تفکیک، تفاوت میان یک گزارش تبلیغاتی و یک گزارش مهندسی است.

دام دوم، اندازه‌گیری در ساعات اوج است. اگر بخش بزرگی از داده پایه در ساعات اوج گرفته شده و داده پس از CDN در ساعات خلوت، نتیجه آزمایش شما نویز محض است. برای این که دام سوم را هم بشناسید، به یاد داشته باشید که DNS caching و TTL در چند ساعت اول پس از فعال‌سازی CDN باعث می‌شود بخشی از کاربران همچنان به سرور قدیمی برسند. داده‌های چهارده ساعت اول را از تحلیل خارج کنید.

دام چهارم، تغییرات همزمان است. اگر همزمان با فعال‌سازی CDN، افزونه جدیدی نصب کردید یا قالب را آپدیت کردید، اثر CDN با اثر آن تغییر مخلوط می‌شود. توصیه می‌کنم حداقل یک هفته پیش و پس از فعال‌سازی CDN، هیچ تغییر دیگری روی سایت اعمال نکنید. اگر ناچارید تغییر همزمان بدهید، حتماً پیش از آن، یک بکاپ قابل بازگشت داشته باشید تا در صورت ناهنجاری، تحلیل را روی نسخه تمیز تکرار کنید.

صدک نود و پنجم به شما می‌گوید کاربران واقعی چه تجربه‌ای دارند؛ میانگین فقط به شما می‌گوید اگر تمام کاربران را در یک نفر ادغام کنیم، چه چیزی می‌بینیم.

زمانی که CDN در آمار محلی اثری نمی‌گذارد

یک تصور غلط رایج این است که CDN همیشه سرعت سایت را زیاد می‌کند. در بعضی سناریوها این اثر نزدیک به صفر است و حتی ممکن است منفی شود.

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

دوم، سایت‌های کاملاً پویا. اگر خروجی صفحات شما به ازای هر کاربر متفاوت است و کش شدن صفحه ممکن نیست، CDN فقط فایل‌های استاتیک را از سرور مبدأ می‌گیرد که بخش کمی از حجم پاسخ است. در این حالت، بهبود اصلی باید از سمت چگونه سرعت سایت وردپرسی را افزایش دهیم؟ بیاید و CDN نقش جانبی دارد.

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

چهارم، سایت‌هایی که مسئله اصلی آن‌ها پهنای باند مصرفی سرور نیست و به‌عنوان مثال، منابع با گلوگاه دیتابیس محدود می‌شوند. در این سایت‌ها اثر CDN در TTFB نزدیک به صفر است و باید ابتدا به سراغ بهینه‌سازی کوئری و دیتابیس رفت.

اشتباهاتی که نتیجه آزمایش را بی‌اعتبار می‌کند

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

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

اشتباه سوم، اندازه‌گیری پشت VPN است. سرعت شما در این حالت بازتابی از سرعت کاربر واقعی نیست و ممکن است CDN را ناعادلانه بهتر یا بدتر نشان دهد.

اشتباه چهارم، نگاه کردن به عدد PageSpeed بدون توجه به ساختار سایت. برای طراحی دقیق آزمایش و تطبیق عدد با معماری سایت، پیشنهاد می‌کنم رویکرد توصیه‌شده در راه‌اندازی CDN برای سایت وردپرسی را به‌عنوان پایه استفاده کنید. اشتباه پنجم که شایع‌ترین است، نادیده گرفتن این که کاربر موبایل تفاوت بیشتری از کاربر دسکتاپ از CDN می‌گیرد، چون فاصله شبکه در موبایل معمولاً بیشتر است.

پرسش‌های پرتکرار درباره آزمایش CDN

آیا CDN می‌تواند روی همه سایت‌ها اثر یکسان بگذارد؟

خیر. اثر CDN به ترکیبی از مخاطب جغرافیایی، نسبت محتوای استاتیک به پویا، سرعت پایه سرور مبدأ و کیفیت پیکربندی کش بستگی دارد. روی یک سایت با مخاطب تک‌شهر و سرور محلی، اثر تقریباً صفر است؛ روی سایتی با مخاطب بین‌قاره‌ای، اثر غالباً محسوس است.

چقدر داده کافی است تا بتوان درباره CDN قضاوت کرد؟

حداقل هفت روز داده پیوسته، در سه بازه ساعتی مختلف و از سه نقطه جغرافیایی. کمتر از این، نتیجه تحت تأثیر نویز شبکه یا تغییرات ترافیکی روزانه است.

آیا فعال‌سازی CDN روی رتبه گوگل اثر مستقیم دارد؟

اثر CDN روی رتبه، غیرمستقیم و از مسیر تجربه کاربری است. اگر CDN منجر به بهبود واقعی LCP و سایر معیارهای Core Web Vitals شود، رتبه هم می‌تواند بهبود پیدا کند. اما اگر همان معیارها پیش از CDN خوب بوده باشند، اثر CDN روی رتبه نزدیک به صفر است.

آیا آزمایش CDN برای همه پروژه‌ها لازم است؟

برای پروژه‌های کوچک با ترافیک محدود و مخاطب محلی، احتمالاً نه. اما برای پروژه‌هایی که هزینه CDN بخشی از بودجه ماهانه است، آزمایش پیش از تصمیم و بازآزمایی پس از فعال‌سازی، هزینه‌ای به‌مراتب کمتری از تصمیم اشتباه دارد.

چه زمانی بعد از فعال‌سازی می‌توان نتیجه گرفت؟

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

آنچه پیش از هر گزارش مدیریتی باید بدانید

آزمایش CDN بیشتر از این که یک تست فنی باشد، یک تمرین تفکر مهندسی است. هیچ عددی از آزمایش به‌تنهایی معنا ندارد؛ معنای عدد، در مقایسه با وضعیت پایه، در ارتباط با یک متغیر مشخص، و در شرایط تکرارپذیر است. اگر می‌خواهید نتیجه آزمایش به گزارش مدیریتی تبدیل شود، سه اصل را رعایت کنید: اول، همیشه وضعیت پایه را در همان بازه زمانی و همان شرایط اندازه بگیرید. دوم، نه میانگین بلکه صدک نود و پنجم را به‌عنوان عدد کلیدی گزارش کنید. سوم، اثر CDN را در کنار سایر متغیرهای سرعت مثل هاست، قالب، افزونه‌ها و دیتابیس ببینید، نه به‌صورت جدا شده.

تجربه من این است که وقتی این متدولوژی رعایت می‌شود، تصمیم‌گیری درباره CDN به یک تصمیم آرام و مستند تبدیل می‌شود، نه به یک شرط‌بندی روی تبلیغات. اگر روی پروژه خودتان این آزمایش را انجام داده‌اید و نکته‌ای در داده‌ها دیدید که در این مقاله نبود، خوشحال می‌شوم تجربه‌تان را بخوانم؛ به‌خصوص اگر به یک نتیجه خلاف انتظار رسیده باشید، چون همان موارد معمولاً از هر گزارش استانداردی آموزنده‌ترند. 🚀