مقایسهٔ کامل CDN برای سایت‌های ایرانی؛ کدام برای شما مناسب است؟

فاصلهٔ جغرافیایی بین کاربر و سرور، در ایران یک متغیر جدی است: بخش بزرگی از هاست‌های مقرون‌به‌صرفه روی سرورهای خارج قرار دارند و مسیر دادهٔ بین‌المللی در ساعات شلوغ، نوسان زیادی دارد. نتیجه را در نمودارهای زمان بارگذاری می‌بینیم: سایتی که ساعت ۱۰ شب اولین بایت را در چند صد میلی‌ثانیه می‌فرستد، ساعتی بعد همان کار را با تأخیر چندبرابری انجام می‌دهد. CDN دقیقاً برای همین ساخته شده: پاسخ را نزدیک کاربر ببرد تا مسیر طولانی فقط یک‌بار — هنگام پرشدن کش — طی شود.

یک نکتهٔ زمینه‌ای قبل از مقایسه: حدود ۴۳ درصد از وب‌سایت‌های جهان وردپرسی‌اند (W3Techs، تاریخ گردآوری: آبان ۱۴۰۵) و سهم وردپرس در بازار ایران به تجربهٔ ما بالاتر از این میانگین است؛ برای همین راه‌اندازی را از دید وردپرس مرور می‌کنیم، هرچند منطق برای هر پلتفرمی یکسان است. هدف این است که بعد از خواندن، بدانید کدام معماری با ترکیب کاربران، نوع محتوا و بودجهٔ شما جور درمی‌آید.

CDN چیست و چه مشکلی را حل می‌کند؟

CDN شبکه‌ای از سرورهای واسط است که در نقاط مختلف جهان — و در سرویس‌های داخلی، در شهرهای ایران — مستقر شده‌اند. اولین بازدیدِ یک فایل از سرور اصلی (Origin) گرفته و در گره‌های نزدیک کاربر ذخیره می‌شود؛ بازدیدهای بعدی از همان گره سرو می‌شوند. برای همین اصطلاح «برخورد اول با کش» را جدی بگیرید: سود CDN بعد از پرشدن کش ظاهر می‌شود، نه در همان ثانیهٔ اول.

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

CDN برای سایت ایرانی: سه چالش خاص بازار

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

چالش دوم، محدودیت دسترسی به سرویس‌های خارجی در دوره‌هایی خاص است. به تجربهٔ ما اتکای کامل به یک CDN خارجی، ریسک در دسترس‌بودن برای کاربر ایرانی دارد؛ در طرح معماری همیشه سناریوی «اگر CDN خارج فردا در دسترس نبود» را داشته باشید. چالش سوم، ترکیب کاربران است: سایتی که هم مشتری ایرانی دارد و هم مشتری خارجی — فروشندهٔ صادراتی، رسانهٔ دوزبانه — با تک‌معماری به‌سختی هر دو طرف را راضی نگه می‌دارد؛ همین‌جاست که معماری ترکیبی معنا پیدا می‌کند.

مقایسهٔ سه معماری: داخلی، خارجی، ترکیبی

سه معماری را با پنج معیار مقایسه کنید: سرعت برای کاربر ایرانی، سرعت برای کاربر خارجی، ریسک محدودیت دسترسی، هزینه و پیچیدگی نگهداری. جدول زیر خلاصهٔ این مقایسه است:

بازهٔ هزینه، برآورد بازار آبان ۱۴۰۵ است؛ ترافیک ماهانه و سطح پلن، قیمت نهایی را تعیین می‌کند.

یک نکتهٔ فنی که در انتخاب اثر دارد: مسیر بازگشت به Origin. وقتی گرهٔ CDN فایل را در کش ندارد، باید از سرور اصلی بگیرد؛ اگر سرور اصلی کند باشد، برخوردهای اول هم کند می‌مانند. برای همین CDN را روی هاستی بگذارید که خودش پایهٔ سالمی دارد؛ کش سروری و CDN مکمل هم‌اند، نه جانشین.

به تجربهٔ ما اشتباه رایج این است که معماری را از روی تبلیغ انتخاب می‌کنند نه از روی ترکیب کاربر. گزارش جغرافیای کاربران در ابزارهای تحلیل (و در سرچ‌کنسول، تفکیک کشوری نمایش‌ها) عدد واقعی را می‌دهد؛ اگر ۹۰ درصد کاربران ایرانی‌اند، بحث «پوشش جهانی» برای شما اولویت نیست.

در وردپرس چه چیزهایی را روی CDN بگذاریم؟

در وردپرس، اولین کاندیدای CDN فایل‌های ایستا هستند: تصاویر آپلودی، فایل‌های قالب و افزونه (css و js) و فونت‌ها. این‌ها به‌ازای هر بازدید تغییری نمی‌کنند و کش‌شدنشان بی‌خطر است. راه‌اندازی معمولاً با یک افزونه یا تنظیم آدرس استاتیک‌ها انجام می‌شود؛ نکتهٔ مهم این است که آدرس‌های تولیدی سایت، دامنهٔ CDN را درست بگیرند و گواهی SSL روی هر دو طرف معتبر باشد.

سؤال بعدی همیشه همین است: HTML صفحه را هم کش کنیم؟ پاسخ سنجیده است: برای بازدیدکنندهٔ ناشناس، کش‌کردن HTML با عمر کوتاه — چند دقیقه تا چند ساعت — سود بزرگی دارد و سایت‌های پربازدید خبری روی همین منطق پیک ترافیک را جذب می‌کنند؛ اما هیچ بخشی از مسیر سبد خرید، تسویه‌حساب، پنل کاربر و نتایج جستجوی داخلی نباید در کش عمومی بنشیند. تنظیمات پیش‌فرض سرویس‌های معتبر این مسیرها را دور می‌گیرند، ولی بعد از هر تغییر، خودتان یک خرید آزمایشی را از صفر تا رسید تأیید کنید.

سومین نکته، هدرهای کش است: Cache-Control و عمر اعتبار فایل‌ها تعیین می‌کنند گره‌ها چقدر نگه دارند. برای فایل‌های قالب که با نسخه‌بندی آدرس عوض می‌شوند، عمر طولانی بی‌خطر است؛ برای تصاویر محصول که مشخصات‌شان عوض می‌شود، سازوکار ابطال کش (Purge) را قبل از اینکه یک تغییر محصول، هفته‌ها نسخهٔ قدیمی را نشان دهد، بفهمید و تست کنید.

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

جدول تصمیم: کدام معماری برای چه سایتی؟

این جدول نقطهٔ شروع تصمیم است، نه حکم نهایی؛ دو عددِ ترکیب کاربران و سهم استاتیک‌ها را همیشه کنارش بگذارید.

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

پیاده‌سازی گام‌به‌گام و تست پس از اتصال

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

تست پس از اتصال را سه‌بار تکرار کنید: قبل از تغییر (پایه)، بلافاصله بعد از اتصال و دو هفته بعد. سنجه‌ها: زمان اولین بایت، زمان بارگذاری کامل در اتصال موبایل و نرخ خطای ۵xx. اگر سنجه‌ها بدتر شدند برگردید؛ CDN یک تنظیم برگشت‌پذیر است و افت اولیه معمولاً یعنی قانون کش یا SSL اشتباه تنظیم شده.

دو هفته اول را خطاهای خزش و ایندکس هم رصد کنید: گزارش‌های سرچ‌کنسول باید بدون جهش خطا بمانند و فایل‌های استاتیک روی دامنهٔ CDN درست سرو شوند. به تجربهٔ ما بیشترین مشکل‌های گزارش‌شده، نه از خود CDN، از تنظیم‌نشده‌بودن مستثناها و هدرها آمده است.

هزینهٔ واقعی CDN در ۱۴۰۵

هزینهٔ CDN دو جزء دارد: پلن پایه و ترافیک. در سرویس‌های خارجی، پلن‌های پایه از رایگان تا ده‌ها دلار در ماه پیش می‌روند؛ در سرویس‌های داخلی، هزینه معمولاً از حدود ۱ میلیون تومان در ماه برای ترافیک متوسط شروع می‌شود و با پهنای باند مصرفی بالا می‌رود — همهٔ این‌ها بازهٔ برآورد بازار آبان ۱۴۰۵ است و با نرخ ارز و ترافیک شما تغییر می‌کند.

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

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

جمع‌بندی

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

رصد ما، رشد شما.