مقایسه CDN و هاست برای سرعت سایت
CDN یا هاست؛ کدام واقعاً سرعت سایت را بالا میبرد و چرا برخی سایتها بعد از اضافهکردن CDN کندتر میشوند؟ مقایسه عملی دو لایه سرعت که اغلب با هم اشتباه گرفته میشوند.
چند سال پیش، در پروژهای که سایتی خبری روی یک هاست اشتراکی خوب اجرا میشد، کارفرما با اطمینان گفت که «CDN را فعال کردم، پس سرعت باید عالی شود». یک هفته بعد، گزارش Search Console نشان میداد که TTFB (Time To First Byte) سایت در بعضی صفحات، بهجای بهتر شدن، بدتر شده است. آن روز فهمیدم که CDN (Content Delivery Network) و هاست، دو لایه متفاوت از سرعت هستند که گاهی با هم اشتباه گرفته میشوند؛ و این اشتباه، میتواند بهجای بهبود، به کندی منجر شود. تجربهام میگوید تفاوت این دو، از جنس «نقش» است، نه از جنس «قدرت». این نوشته، همان مقایسه لایهای است که در پروژههای واقعی بهکار میبرم.
CDN و هاست: دو لایه متفاوت
هاست (Hosting)، فضایی است که فایلها، دیتابیس و منطق اپلیکیشن سایت شما روی آن اجرا میشود. سرور هاست، درخواست کاربر را دریافت میکند، کد PHP را اجرا میکند، به دیتابیس کوئری میزند و پاسخ HTML را برمیگرداند. اگر با مفهوم پایه سرور آشنا نیستید، سرور چیست و چگونه کار میکند پیشنیاز این بحث است. هاست، پایه سرعت سایت شماست.
CDN (Content Delivery Network)، شبکهای از سرورهای توزیعشده در نقاط مختلف جهان است که نسخههای کششده محتوای سایت شما — عمدتاً فایلهای استاتیک مثل تصویر، CSS و JS — را در نزدیکترین نقطه به کاربر سرو میکند. مفهوم دقیقتر در CDN چیست و چگونه کار میکند آمده است. CDN، نه جایگزین هاست است و نه مستقل از آن؛ یک لایه تقویتکننده که روی هاست سوار میشود.
تفاوت را در یک جمله خلاصه کنم: هاست، کارخانه تولید است؛ CDN، شبکه توزیع. کارخانه باید سریع تولید کند و شبکه باید سریع تحویل دهد. اگر کارخانه کند باشد، شبکه توزیع سریع هم نمیتواند محصول را زودتر به دست مشتری برساند. همین جمله، دلیل بسیاری از ناامیدیها از CDN است. اگر میخواهید جایگاه کلی این دو را در انتخاب هاست ببینید، هاست چیست و چگونه انتخاب کنیم نقطه شروع خوبی است.
CDN، ضربکننده سرعت است، نه جایگزین آن؛ هر چه ضربکننده در عدد پایه بزرگتر باشد، اثرش بیشتر است. اگر عدد پایه کوچک باشد، ضرب هم کوچک میماند.
مکانیزم هرکدام: پایه و تقویتکننده
برای درک درست، باید بدانید هر کدام در کدام نقطه از زنجیره درخواست، وارد میشوند. وقتی کاربر آدرسی را در مرورگر میزند، این مسیر طی میشود:
- DNS (Domain Name System): آدرس دامنه به IP ترجمه میشود. اگر CDN فعال باشد، IP یکی از نودهای CDN است، نه هاست اصلی.
- درخواست به CDN: اگر محتوای درخواستی در کش CDN موجود باشد، همانجا پاسخ داده میشود. اگر نه، درخواست به هاست اصلی (origin) میرود.
- هاست اصلی: کد PHP اجرا میشود، دیتابیس کوئری میخورد و پاسخ HTML ساخته میشود.
- پاسخ: یا از کش CDN به کاربر میرسد، یا از هاست اصلی.
نکته کلیدی اینجاست: CDN فقط زمانی سریعتر از هاست است که محتوا را در کش داشته باشد. اگر نداشته باشد، درخواست به همان هاست اصلی برمیگردد و CDN نقش یک واسطه اضافه را بازی میکند — که میتواند کندتر باشد. تجربهام میگوید بیشتر شکایتهای «CDN سایتم را کند کرد»، ریشه در همینجا دارد: کش سرد (cold cache) و نبود ترافیک کافی برای گرم شدن کش.
تأثیر بر TTFB: تفاوت کلیدی
TTFB (Time To First Byte)، معیار کلیدی سرعت سرور است که در تأثیر TTFB بر سرعت بارگذاری تفصیل داده شده. تفاوت CDN و هاست در این شاخص، روشنکننده است:
| سناریو | هاست تنها | هاست + CDN |
|---|---|---|
| کاربر نزدیک به هاست | TTFB پایین | ممکن است کمی بالاتر |
| کاربر دور از هاست | TTFB بالا (تأخیر شبکه) | TTFB پایین (نود نزدیک) |
| محتوای کشنشده | TTFB پایه | TTFB پایه + تأخیر CDN |
| محتوای کششده | TTFB پایه | TTFB بسیار پایینتر |
در تجربه من، تأثیر CDN بر TTFB به سه عامل بستگی دارد. اول، فاصله کاربر از هاست: اگر کاربر و هاست در یک کشور باشند، CDN ممکن است تفاوت محسوسی نسازد و حتی کمی کندتر کند. دوم، وضعیت کش: اگر کش CDN گرم باشد، TTFB میتواند به چند ده میلیثانیه برسد. سوم، نوع محتوا: CDN روی محتوای استاتیک تفاوت بزرگی میسازد، روی محتوای داینامیک (مثل سبد خرید یا پنل کاربری) تفاوت ناچیز است، چون آن درخواستها باید به origin برسند. همین نکته در تحلیل تأثیر کش در نقش CDN در سرعت سایت هم آمده است.
TTFB سایت شما، سقف سرعت هاست است؛ CDN میتواند این سقف را فقط برای محتوای کششده بالاتر ببرد، نه برای همه درخواستها.
CDN واقعاً چه چیزی را سریعتر میکند؟
CDN در سه سناریو بیشترین اثر را دارد. اول، مخاطب جغرافیایی پراکنده: اگر سایت شما در تهران میزبانی میشود و مخاطب شما در اصفهان، مشهد و شیراز است، CDN میتواند فایلهای استاتیک را در نودهای نزدیکتر سرو کند. دوم، سایتهای پُرتصویر: فروشگاهها، سایتهای آموزشی و بلاگهای عکسمحور، بیشترین سود را از CDN میبرند، چون حجم اصلی صفحه از تصاویر میآید. سوم، پیکهای ترافیکی: در ساعات اوج یا کمپینها، CDN بار زیادی از هاست اصلی برمیدارد. مفهوم کلی این اثر در نقش CDN در سرعت سایت و راهاندازی عملی در راهاندازی CDN برای وردپرس آمده است.
یک قاعده تجربی که در پروژهها به آن رسیدهام: اگر بیش از شصت درصد مخاطبان سایت شما از یک کشور یا منطقه مشخص میآیند و هاست شما هم در همان منطقه است، CDN ممکن است بازده محدودی داشته باشد. اما اگر مخاطب شما حتی بیست درصد از خارج از کشور یا از شهرهای دور است، CDN در ساعات پیک میتواند تفاوت محسوسی بسازد.
هاست کجا تعیینکننده است؟
هاست در همه سناریوها تعیینکنندهتر از CDN است، چون پایه سرعت را میسازد. سه حالت که در آنها هاست، نقش اصلی را دارد:
- صفحههای داینامیک: هر درخواست به سبد خرید، حساب کاربری، یا صفحه نتیجه جستجو، باید به هاست برسد. اگر هاست کند باشد، CDN هیچ کمکی نمیکند.
- پاسخ سرور به رباتهای گوگل: خزش اولیه، همیشه از هاست اصلی اتفاق میافتد. اگر TTFB هاست بد باشد، خزش کند میشود و ایندکس کندتر پیش میرود. مسیر کامل در سئو تکنیکال از خزش تا ایندکس آمده است.
- پردازش کوئریهای سنگین: اگر افزونهای در سایت شما کوئری سنگین میزند، آن کوئری روی هاست اجرا میشود، نه روی CDN. مکانیزم دقیق در تأثیر دیتابیس بر سرعت سایت آمده است.
بههمین دلیل، در انتخاب و بهینهسازی هاست، باید همان جدیت CDN را بهکار برد. اگر هاست شما از نوع اشتراکی است، تفاوت هاست اشتراکی و اختصاصی و تأثیر هاست بر سرعت سایت را بخوانید. اگر هاست اشتراکی شما محدودیت منابع دارد، شاید ارتقای هاست (مثلاً به VPS) بیشتر از اضافهکردن CDN به سایت کمک کند.
آنچه CDN نمیتواند حل کند
در تجربه من، پنج مشکل رایج سایتها وجود دارند که CDN بهتنهایی هیچکدام را حل نمیکند. اول، کندی هاست: اگر TTFB روی هاست اصلی بالای ۸۰۰ میلیثانیه است، CDN فقط آن را برای محتوای کششده بهبود میدهد، نه برای محتوای داینامیک. دوم، کوئریهای سنگین دیتابیس: کوئری در لایه دیتابیس اجرا میشود و CDN نمیتواند در آن دخالت کند. سوم، کد PHP کند: افزونههای سنگین یا کدهای بهینهنشده روی هاست اجرا میشوند و CDN فقط بعد از اجرای کد وارد بازی میشود. چهارم، تصاویر بهینهنشده: CDN تصویر ۴ مگابایتی را سریعتر به کاربر میرساند، ولی همان ۴ مگابایت را منتقل میکند. فشردهسازی تصاویر در فشردهسازی تصاویر سایت آمده است. پنجم، فونتهای سنگین فارسی: فونتهای حجیم بدون sub-set، حتی با CDN هم بار صفحه را سنگین میکنند. همانطور که در یک بحث پشتیبانی معتبر هم تأکید شده، CDN تنها زمانی مزیت خود را نشان میدهد که سایت از قبل بهینه شده باشد[reference:0]. این نکته در بررسیهای معتبر دیگر هم تأکید شده است: CDN نمیتواند هاست کند یا ناپایدار را درمان کند[reference:1].
چرا CDN گاهی سایت را کندتر میکند؟
این پارادوکس، پرتکرارترین سؤال در پشتیبانی CDN است. در تجربهام، چهار دلیل اصلی برای این اتفاق وجود دارد:
- کش سرد: نودهای CDN، محتوای سایت شما را نمیشناسند تا وقتی که کاربری آن را درخواست کند. در سایتهای کمترافیک، این گرمشدن کش میتواند روزها طول بکشد. راهحل: Warm-up دستی کش یا اسکراپر[reference:2].
- کاربر و هاست در یک منطقه: اگر کاربر و هاست اصلی هر دو در تهران باشند، درخواست از طریق یک نود CDN در اروپا، مسیر طولانیتری طی میکند. این نکته در یک بحث معتبر مطرح شده است: «اگر اکثر بازدیدکنندگان سایت شما از کشور خودتان هستند، CDN منطقی نیست، چون سرور شما معمولاً سریعتر از یک نود CDN در کشور خودتان است»[reference:3].
- تنظیمات اشتباه کش: اگر قواعد کش برای همه URLها یکسان اعمال شود (مثلاً کش کردن صفحه ورود ادمین)، کاربر محتوای قدیمی میبیند و برای دیدن صفحه جدید باید چند بار refresh کند.
- مشکلات شبکه CDN: اگر نود CDN در ساعات اوج شبکه، بهدرستی در دسترس نباشد، تأخیر اضافه به هر درخواست تحمیل میشود.
در تجربه من، اگر TTFB سایت شما بعد از فعالسازی CDN بدتر شد، اول این چهار مورد را بررسی کنید، سپس بهسراغ تنظیمات پیشرفتهتر بروید. در صورت نیاز به توقف CDN، فرآیند برگشت به حالت قبل در تغییر بدون آسیب قابل قیاس است.
CDN، ابزار یکباره نیست؛ یک لایه فعال است که باید با رفتار سایت شما تنظیم شود. پیکربندی اشتباه، از نبود CDN بدتر است.
راهکار ترکیبی: هاست قوی + CDN درست
پس از مقایسه، فرمول واقعی من در پروژههای واقعی سهبخشی است:
- اول، هاست را به سطح قابل قبول برسانید: TTFB زیر ۵۰۰ میلیثانیه، حداقل. اگر هاست پایینتر از این سطح است، CDN را به بعد موکول کنید. مسیر ارتقای هاست در تأثیر هاست بر سرعت سایت آمده است.
- دوم، CDN را با تنظیمات دقیق راهاندازی کنید: فقط فایلهای استاتیک را کش کنید؛ صفحات پویا مثل سبد، حساب کاربری و فرمها را از کش استثنا کنید. راهنمای عملی در راهاندازی CDN برای وردپرس آمده است.
- سوم، بعد از راهاندازی، دو هفته پایش کنید: TTFB، LCP و نرخ کش (cache hit ratio) را در پنل CDN ببینید. اگر نرخ کش پایین است (زیر ۶۰ درصد)، تنظیمات کش را بازبینی کنید.
در تجربه من، این ترکیب، بیشترین بازدهی را در سایتهایی دارد که هم هاست مناسبی دارند و هم مخاطبشان کمی پراکنده است. برای سایتهای کوچک با مخاطب محلی، فقط هاست خوب کافی است و CDN میتواند هزینه اضافه باشد. تفاوت این دو سناریو، به همان سه سؤال اصلی برمیگردد: مخاطب کجاست، محتوا چقدر استاتیک است، و هاست در چه سطحی است.
CDN و هاست در سایتهای وردپرسی
در سایتهای وردپرسی، دو لایه دیگر هم روی این ترکیب اثر میگذارند: افزونه کش و نوع هاست. در تجربه من، ترتیب درست بهینهسازی بهشکل زیر است:
- اول، هاست: اگر هاست اشتراکی ضعیف دارید، ارتقای آن (به VPS یا هاست وردپرس مدیریتشده) پایه همه چیز است. انتخاب هاست در بهترین هاست وردپرس آمده است.
- دوم، کش سروری: افزونه کش (مثل LiteSpeed Cache یا WP Rocket) روی هاست اجرا میشود و سرعت بازدید تکراری را چند برابر میکند. مقایسه در بهترین افزونههای کش وردپرس.
- سوم، CDN: فقط بعد از این دو لایه، CDN وارد بازی میشود. اگر ترتیب را عوض کنید، در بهترین حالت، CDN فقط روی لایهای کار میکند که خودش پایه ضعیفی دارد.
یک نکته عملی که در پروژههای وردپرسی زیاد دیدهام: قالبهای سنگین، قبل از هر تلاشی برای CDN، باید بهینه شوند. تفاوت در قالب سبک وردپرس و چرا بعضی قالبها سایت را کند میکنند آمده است. اگر قالب شما سنگین است، CDN فقط هزینه اضافه است.
جدول مرجع
| معیار | هاست | CDN |
|---|---|---|
| نقش اصلی | تولید پاسخ (پایه) | توزیع محتوا (تقویتکننده) |
| محتوای تحت پوشش | همه درخواستها | عمدتاً استاتیک |
| تأثیر بر TTFB داینامیک | تعیینکننده | نقش کم |
| تأثیر بر TTFB استاتیک | محدود | تعیینکننده |
| مخاطب پراکنده جغرافیایی | ضعیف | عالی |
| مخاطب محلی | عالی | ممکن است کمی کندتر |
| هزینه ماهانه | ثابت | مصرفی (پویا) |
| نقش در سایتهای پُرترافیک | پایه | ضروری |
| نقش در سایتهای کوچک محلی | کافی | معمولاً غیرضروری |
| تنظیمات اشتباه | کندی مزمن | کندی ناگهانی یا محتوای قدیمی |
پرسشهای کوتاه
آیا CDN جایگزین هاست است؟ خیر. CDN یک لایه تقویتکننده روی هاست است. حتی با CDN فعال، هاست شما باید پاسخ درخواستهای داینامیک را تولید کند.
آیا برای سایت کوچک، CDN ارزش دارد؟ اگر مخاطب سایت شما محلی است و هاست شما در همان منطقه است، معمولاً نه. اگر سایت شما حتی بیست درصد مخاطب پراکنده دارد، بله. مفهوم کلی در نقش CDN در سرعت سایت آمده است.
چرا بعد از فعالسازی CDN، سایت کندتر شد؟ سه دلیل ممکن: کش سرد، مخاطب محلی، یا تنظیمات اشتباه. اول TTFB را در دو حالت قبل و بعد بسنجید؛ اگر TTFB بدتر شد، مشکل از تنظیمات است.
آیا CDN میتواند کندی هاست ضعیف را جبران کند؟ فقط برای محتوای استاتیک و فقط اگر کش گرم باشد. برای محتوای داینامیک، هیچ کمکی نمیکند. اگر هاست شما از نوع اشتراکی ضعیف است، اول ارتقای هاست را در نظر بگیرید.
آیا CDN رایگان برای شروع کافی است؟ برای سایتهای کوچک و متوسط، بله. طرحهای رایگان CDN مثل Cloudflare برای بسیاری از سایتها کافی است. مقایسه سرویسها در مقایسه سرویسهای CDN آمده است. اما اگر ترافیک شما بالا برود، طرح رایگان ممکن است محدودیتهایی داشته باشد که در همان مقاله آمده است.
ترتیب درست: اول هاست یا CDN؟ همیشه اول هاست را به سطح قابل قبول برسانید (TTFB زیر ۵۰۰ میلیثانیه)، سپس کش سروری و CDN را اضافه کنید. اگر ترتیب را عوض کنید، CDN فقط روی لایهای کار میکند که خودش ضعیف است.
از منظر معماری کارایی وب
برای معماران فنی که با زیرساختهای چندساله کار میکنند، تفاوت CDN و هاست را باید در چارچوب «تقسیم بودجه زمان پاسخ» دید. هر درخواست کاربر، بودجه محدودی از زمان دارد (مثلاً ۲ ثانیه برای تجربه مطلوب). این بودجه بین چهار لایه تقسیم میشود: تأخیر شبکه، تأخیر سرور، تأخیر دیتابیس و تأخیر رندر. CDN فقط لایه اول را بهبود میدهد؛ هاست، لایههای دوم و سوم؛ و قالب و کد، لایه چهارم. سه اصل معماری که در پروژههای سازمانی اثر مستقیم داشتهاند. اول، طبقهبندی محتوا: قبل از هر تصمیمی، محتوای سایت را به دو دسته «استاتیک» و «داینامیک» تقسیم کنید. CDN فقط برای دسته اول مفید است؛ برای دسته دوم، راهحل در بهینهسازی هاست، کش آبجکت و کاهش کوئریهاست. دوم، پایش تفکیکی: TTFB را برای محتوای استاتیک و داینامیک جداگانه بسنجید. تجربهام میگوید بیشتر تیمها یک TTFB میانگین میبینند و نمیدانند بخش استاتیک و داینامیک چه سهمی دارند. سوم، آمادگی برای حذف CDN: اگر بعد از سه ماه پایش، نرخ کش (cache hit ratio) زیر ۵۰ درصد ماند یا TTFB میدانی بهبود نیافت، CDN را حذف کنید. صرفهجویی در هزینه و پیچیدگی، بهتنهایی ارزش دارد. در تجربه من، تیمهایی که این سه اصل را رعایت میکنند، نهفقط در انتخاب CDN بلکه در همه تصمیمهای زیرساختی، دقیقتر و کمهزینهتر عمل میکنند.
آنچه در تصمیم نهایی میماند
CDN و هاست، دو لایه از یک سیستم هستند که هر کدام نقش خودشان را دارند. تجربهام میگوید اگر امروز فقط یک کار بکنید، TTFB سایت خود را در سه ساعت مختلف روز و از دو نقطه جغرافیایی (اگر میتوانید) بسنجید. اگر TTFB هاست پایدار و زیر ۵۰۰ میلیثانیه است و مخاطب شما محلی، هاست خوب کافی است. اگر مخاطب پراکنده است یا سایت شما پُرترافیک است، CDN با تنظیمات دقیق میتواند تفاوت محسوسی بسازد. اما در هر دو حالت، ترتیب درست این است: اول هاست، بعد کش سروری، بعد CDN. اگر تجربهای از اشتباه در ترتیب یا تنظیمات این دو لایه دارید که در منابع فارسی کمتر گفته شده، در دیدگاهها بنویسید؛ همان تجربهها، تصویر این بحث را کاملتر میکنند. ⚡