CDN چیست و چگونه روی سرعت، پایداری و تجربه کاربر وب تأثیر می‌گذارد؟

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

این متن شبکهٔ تحویل محتوا (CDN) را لایهٔ توزیع و reverse proxy می‌داند: سرور مبدأ (origin)، لبه (edge)، کش، تأخیر (latency)، دارایی ایستا و محتوای پویا، TLS، حملهٔ منع سرویس توزیع‌شده (DDoS) و ابطال کش. «CDN یعنی سئوی بهتر» ادعا نیست؛ اثر عمدتاً از عملکرد و در دسترس بودن می‌آید.

پاسخ کوتاه

CDN شبکه‌ای از سرورهای توزیع‌شده است که بین کاربر و origin می‌نشیند و پاسخ را از نقطهٔ نزدیک‌تر، با اتصال بهینه‌تر، می‌دهد. طبق web.dev سود اصلی کم کردن تأخیر است: سرور لبه معمولاً از origin به کاربر نزدیک‌تر است، اتصال جدید نزدیک کاربر تمام می‌شود، و اگر پاسخ در کش باشد اصلاً به origin نمی‌رود.

دارایی ایستا — تصویر نسخه‌دار، CSS و JS با هش — بیشترین سود را از کش بلندمدت می‌برد. HTML عمومی را می‌توان کوتاه کش کرد؛ محتوای شخصی باید private یا no-store بماند. جهش ترافیک و بخشی از DDoS در لبه جذب می‌شود؛ TLS نزدیک کاربر تمام می‌شود.

CDN به‌تنهایی رتبهٔ جست‌وجو نمی‌سازد. گوگل Core Web Vitals را در سامانه‌های رتبه استفاده می‌کند و آستانهٔ خوب را توصیه می‌کند؛ نمرهٔ سبز رتبهٔ اول را تضمین نمی‌کند. اگر WAF همان CDN خزنده را ببندد، اثر می‌تواند منفی باشد.

CDN فاصله و بار origin را کم می‌کند. محتوا، صحت کش و اجازهٔ خزش را عوض نمی‌کند — مگر اینکه خودتان عوض کنید.

CDN چیست و چه چیزی نیست؟

web.dev شبکهٔ تحویل محتوا را مجموعهٔ سرورهای بهینه‌شده برای رساندن سریع منبع تعریف می‌کند. origin جایی است که CDN محتوا را می‌گیرد. کاربر به نزدیک‌ترین نقطهٔ حضور (PoP) وصل می‌شود. راهنمای Cloudflare همان را edge server می‌نامد: نسخهٔ کش‌شده نزدیک کلاینت تا رفت‌وبرگشت کم شود.

معماری رایج reverse proxy است: DNS با CNAME یا nameserver ترافیک را به CDN می‌دهد؛ لبه از کش جواب می‌دهد یا به origin می‌فرستد. این با آپلود دستی روی چند سرور یکی نیست. پایگاه داده، احراز هویت و موجودی روی origin می‌مانند. لبه پاسخ را تکرار می‌کند؛ منبع حقیقت را عوض نمی‌کند.

Origin، Edge و مسیر یک درخواست

بدون CDN هر درخواست به محل فیزیکی origin می‌رود. web.dev می‌گوید حتی منبع غیرقابل‌کش معمولاً از راه CDN سریع‌تر می‌رسد: اتصال جدید نزدیک کاربر تمام می‌شود و مسیر تا origin اغلب روی اتصال گرم است، نه لزوماً مسیر BGP کاربر.

1. DNS به IP لبه جواب می‌دهد، نه لزوماً به IP واقعی origin.
2. اتصال TCP یا QUIC و دست‌دهی TLS با لبه برقرار می‌شود؛ گواهی معمولاً برای نام سایت روی لبه است.
3. لبه کلید کش را از طرح، میزبان، مسیر و پارامتر یا هدر انتخابی می‌سازد.
4. HIT: پاسخ ذخیره‌شده. MISS: لبه از origin یا shield می‌گیرد، طبق هدر نگه می‌دارد، بعد به کاربر می‌دهد.

اولین درخواست هر URL کش را سرد می‌بیند. Search Central در Crawling December همین را برای خزنده می‌گوید: origin باید هر URL را حداقل یک‌بار سرو کند. shield کمک می‌کند صدها PoP همزمان هجوم نبرند؛ جایگزین گرم شدن نیست.

کش: دارایی ایستا، محتوای پویا و کلید کش

کش CDN با کش مرورگر یکی نیست؛ هر دو با RFC 9111 حرف می‌زنند. کش مرورگر خصوصی است، کش CDN اشتراکی. MDN برای محتوای شخصی private می‌گوید؛ no-store یعنی ذخیره نشود. no-cache یعنی قبل از استفاده باید بازاعتبارسنجی شود، نه «ذخیره ممنوع».

دارایی ایستا کم تغییر است: تصویر با نام نسخه‌دار، JS با هش، CSS بیلد. web.dev TTL بلند — چند ماه تا یک سال — و برای فایل نسخه‌دار immutable را پیشنهاد می‌کند. اگر نام فایل با بیلد عوض شود، همان URL کهنه نمی‌ماند.

محتوای پویا زیاد عوض می‌شود: خانه، API، قیمت. پویا بودن کش را ممنوع نمی‌کند. web.dev می‌گوید در ترافیک بالا حتی پنج ثانیه کش بار origin را کم می‌کند. HTML عمومی را هم می‌توان کوتاه کش کرد؛ web.dev به نقل از Web Almanac می‌گوید حدود ۳۳٪ درخواست HTML از CDN سرو شده است.

کلید کش اگر بیش از حد ریز باشد، نسبت برخورد (cache hit ratio) می‌میرد. پارامتر referral، ترتیب query و Vary شلوغ چند نسخه از یک پاسخ می‌سازند. web.dev حدود ۹۰٪ برخورد را برای بیشتر سایت‌ها هدف معقول می‌داند. Set-Cookie بی‌دلیل هم پاسخ را از کش اشتراکی خارج می‌کند.

اثر روی سرعت، پایداری و تجربهٔ کاربر

سرعت یعنی زمان رسیدن بایت. تأخیر با فاصله و ازدحام بالا می‌رود. لبهٔ نزدیک TTFB سند و دانلود تصویر LCP را کم می‌کند. Brotli یا gzip، HTTP/2 یا HTTP/3 و TLS 1.3 روی همان لبه هزینهٔ اتصال را باز کم می‌کنند؛ web.dev دست‌دهی TLS 1.3 را یک رفت‌وبرگشت ارزان‌تر از ۱٫۲ می‌داند.

پایداری دو چهره دارد. origin دیگر هر بایت تصویر را برای هر کاربر سرو نمی‌کند؛ جهش کمپین کمتر به ۵۰۳ می‌رسد. بعضی CDNها برای محتوای ایستا حتی با origin پایین از کش سرو می‌کنند — Search Central این را قابلیت اطمینان می‌نامد و به محتوای قابل‌کش محدود می‌کند. سبد و پرداخت روی کش کهنه زنده نمی‌مانند.

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

امنیت: TLS، DDoS و سطح حمله

اگر لبه reverse proxy باشد کاربر IP origin را نمی‌بیند. راهنمای TLS در CDN از Cloudflare می‌گوید مقیاس لبه حجمی را تحمل می‌کند که origin را از پا می‌اندازد. پست Search Central به کاهش خودکار حملهٔ حدود ۴٫۲ ترابیت‌برثانیه در ۲۱ اکتبر ۲۰۲۴ توسط Cloudflare اشاره می‌کند — رقم همان پست است، نه تضمین برای هر شبکه.

پایان TLS در لبه دست‌دهی را نزدیک کاربر تمام می‌کند و CPU رمز را از origin برمی‌دارد. بین لبه و origin معمولاً اتصال جدا، اغلب دوباره رمزشده، هست. HTTPS برای کاربر مسئولیت وصلهٔ origin را حذف نمی‌کند. WAF ترافیک بد را کم می‌کند و همزمان می‌تواند خزنده، webhook پرداخت یا API شریک را ببندد. لایه است، جایگزین رمز و به‌روزرسانی برنامه نیست.

ابطال کش: تازگی در برابر سرعت

ابطال کش (cache invalidation) یعنی نسخهٔ ذخیره‌شده را قبل از پایان TTL از لبه بردارید. web.dev این را purge می‌نامد و معمولاً با API انجام می‌شود. eviction جداست: کش جا کم می‌آورد و چیز کم‌استفاده را دور می‌ریزد. خالی شدن یک PoP تضمین همزمانی همهٔ لبه‌ها نیست.

اگر purge تقریباً آنی باشد می‌توان محتوای پویا را با TTL بلند کش کرد و هنگام ویرایش پاک کرد — hold-till-told. برچسب کش یا surrogate key اجازه می‌دهد مثلاً همهٔ صفحه‌های «فوتر» را یک‌جا پاک کنید. بدون این سازوکار یا TTL را کوتاه می‌کنید و برخورد می‌افتد، یا قیمت کهنه می‌ماند. فایل بدون نسخه با max-age یک‌ساله، یا HTML خصوصی با public، دو خطای کلاسیک‌اند.

CDN سئو را «بهبود» نمی‌دهد؛ عملکرد و دسترسی را عوض می‌کند

نصب CDN فاکتور رتبه نیست. گوگل در مستند تجربهٔ صفحه می‌گوید سامانه‌های رتبه به‌دنبال پاداش به تجربهٔ خوب‌اند و یک سیگنال واحد تجربه وجود ندارد. Core Web Vitals در این سامانه‌ها استفاده می‌شود. همان سند صریح است: نتیجهٔ خوب در Search Console یا ابزار سوم رتبهٔ بالا را تضمین نمی‌کند.

اثر، اگر باشد، غیرمستقیم است: صفحه زودتر می‌رسد، در اوج ترافیک بیشتر در دسترس است، خزنده کمتر ۵xx یا timeout می‌بیند. مستند کد وضعیت HTTP — به‌روزرسانی ۴ فوریهٔ ۲۰۲۶ — می‌گوید ۴۲۹ و ۵xx خزش را کند می‌کنند و ایندکس به‌تدریج می‌ریزد؛ timeout خطای سخت است و URL را از نمایه حذف می‌کند. کم شدن این خطاها شایستگی خزش را حفظ می‌کند، نه اینکه امتیاز CDN به صفحه اضافه شود.

مسیر معکوس هم واقعی است. پست «CDNs and crawling» می‌گوید WAF گاهی خزنده را مسدود می‌کند: ۵۰۳ یا ۴۲۹ (ترجیح موقت)، timeout (حذف از نمایه)، یا خطا با ۲۰۰. مسدود نرم میان‌صفحهٔ «آیا انسان هستید؟» است؛ خزنده همان را می‌بیند. گوگل در این حالت ۵۰۳ را توصیه می‌کند. راهنمای قابلیت‌های هوش مصنوعی جست‌وجو می‌گوید خزش باید در robots.txt و در CDN یا میزبانی مجاز بماند. بازرسی URL در Search Console تصویر رندر را نشان می‌دهد.

Core Web Vitals: چه چیزی واقعاً عوض می‌شود

Core Web Vitals تجربهٔ واقعی را می‌سنجد. آستانه‌های Search Central و web.dev یکسان‌اند و باید در صدک ۷۵، جدا برای موبایل و دسکتاپ، برقرار باشند:

• Largest Contentful Paint (LCP): بارگذاری. هدف: حداکثر ۲٫۵ ثانیه.
• Interaction to Next Paint (INP): تعامل. هدف: ۲۰۰ میلی‌ثانیه یا کمتر.
• Cumulative Layout Shift (CLS): پایداری دیداری. هدف: حداکثر ۰٫۱.

web.dev استفاده از CDN برای بهینه‌سازی TTFB را از توصیه‌های اصلی LCP می‌داند: محتوا را نزدیک کاربر سرو کنید و کش کنید. CDN روی LCP از دو جا وارد می‌شود: رساندن سند و رساندن منبع ایستای عنصر LCP — معمولاً تصویر. TTFB متریک کاربرمحور اصلی نیست؛ تشخیصی برای LCP است. TTFB بالا رسیدن به ۲٫۵ ثانیه را سخت می‌کند.

INP به کار رشتهٔ اصلی و جاوااسکریپت وابسته است؛ CDN handler کند را عوض نمی‌کند. CLS از ذخیرهٔ جا برای تصویر و فونت می‌آید؛ نزدیک بودن فایل بدون width و height شیفت را حذف نمی‌کند. دادهٔ میدان (CrUX) مبنای Search Console است. یک تست Lighthouse از یک شهر جایگزین صدک ۷۵ کاربران نیست.

مثال عملی: کاتالوگ محصول زیر فشار کمپین

فروشندهٔ قطعات صنعتی سایت را روی یک سرور مجازی نگه می‌دارد. صفحهٔ دسته و تصویر بزرگ محصول از همان origin می‌آیند. TTFB برای کاربر دور بالاست. تصویر LCP از HTML با src مشخص است، اما هر بار از origin دانلود می‌شود. در نمایشگاه، کمپین همزمان CPU را روی تصویر و TLS اشباع می‌کند؛ بخشی از کاربران ۵۰۳ می‌بینند و خزنده همان ۵xx را می‌گیرد. این تنبیه الگوریتم نیست؛ خطای زیرساخت است.

بعد از CDN به‌عنوان reverse proxy: تصویر و فایل نسخه‌دار با max-age بلند از لبه می‌آیند؛ HTML عمومی دسته ۳۰ تا ۶۰ ثانیه کش می‌شود؛ حساب و تسویه private, no-store می‌مانند؛ TLS در لبه تمام می‌شود. origin بیشتر موجودی و تسویه را می‌بیند. صفحهٔ دسته زودتر نقش می‌بندد. INP پیکربندی قطعه عوض نمی‌شود؛ همان اسکریپت سنگین است. CLS فقط اگر ابعاد تصویر درست شده باشد جدا بهتر می‌شود.

دو حادثه می‌آید. قیمت SKU عوض می‌شود اما HTML هنوز در لبه است؛ بدون purge کاربر قیمت کهنه می‌بیند. دوم: چالش ربات جلوی Googlebot می‌ایستد و بازرسی URL همان چالش را رندر می‌کند. اینجا CDN سئو را بهتر نکرده؛ خزش را خراب کرده است. خزنده باید محتوا را ببیند؛ انسداد موقت باید ۵۰۳ باشد نه ۲۰۰. رتبه فقط اگر تجربهٔ میدان و دسترسی خزنده عوض شود ممکن است حرکت کند — محتوا و نیت همچنان تعیین‌کننده‌اند.

اشتباهات رایج

• خرید CDN به‌عنوان دکمهٔ سئو، بدون اندازه‌گیری TTFB و LCP میدان.
• cache everything روی HTML شخصی، سبد و پرداخت.
• دارایی بدون نسخه با TTL یک‌ساله و بدون purge.
• چالش ربات بدون آزمون Googlebot در Search Console.
• افشای IP origin در پنل یا DNS مستقیم؛ یا ۵۰۳ لبه را «جریمهٔ گوگل» نامیدن.

جمع‌بندی

CDN لایهٔ توزیع است: edge نزدیک کاربر، origin منبع حقیقت، کش برای تکرار پاسخ عمومی. سرعت را با کم کردن تأخیر و HIT می‌سازد، پایداری را با کم کردن بار، امنیت را با مقیاس لبه. هیچ‌کدام بدون هدر درست و سیاست ابطال جادو نیست.

برای جست‌وجو جملهٔ دقیق این است: CDN رتبه نمی‌فروشد. ممکن است LCP را از راه TTFB بهتر کند و خزش را پایدارتر کند. ممکن است با WAF همان خزش را ببندد. منبع تصمیم Search Central و web.dev است.

اگر یک کار کنید، دارایی نسخه‌دار را با TTL بلند در لبه بگذارید، HTML عمومی را کوتاه کش کنید، خزنده را با بازرسی URL بسنجید، و origin را از منطق و داده معاف نکنید.

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

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

خیر. فاکتور جدا به نام CDN در مستندات رتبه نیست. اثر، اگر باشد، از عملکرد — از جمله Core Web Vitals — و در دسترس بودن برای کاربر و خزنده است. نمرهٔ خوب Vital هم رتبه را تضمین نمی‌کند.

آیا هر سایتی به CDN نیاز دارد؟

نه. سایت کم‌ترافیک با کاربر نزدیک origin و دارایی سبک ممکن است سود کمی ببیند. وقتی فاصله، تصویر زیاد، جهش ترافیک یا لایهٔ DDoS مطرح است، بررسی منطقی است. web.dev سرو شدن کل سایت از CDN را توصیهٔ عملکرد می‌داند، نه اجبار کسب‌وکار کوچک.

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

معمولاً نه به‌صورت اشتراکی. private یا no-store. کش کردن پاسخ کاربر A برای کاربر B حادثهٔ حریم خصوصی است.

اگر origin پایین بیاید سایت زنده می‌ماند؟

فقط برای آنچه در کش است و سیاست stale اجازه می‌دهد. Search Central همین را به محتوای ایستا محدود کرده. تسویه بدون origin کار نمی‌کند.

چرا بعد از CDN هنوز LCP بد است؟

اغلب منبع LCP دیر کشف می‌شود، lazy روی تصویر اصلی است، HTML کش نمی‌شود، یا تصویر بزرگ است. web.dev کشف منبع از HTML را مقدم می‌داند. INP و CLS را از CDN انتظار نداشته باشید.

منابع و مراجع

• web.dev — Content delivery networks: https://web.dev/articles/content-delivery-networks
• web.dev — The most effective ways to improve Core Web Vitals: https://web.dev/articles/top-cwv
• web.dev — Optimize Largest Contentful Paint: https://web.dev/articles/optimize-lcp
• web.dev — HTTP Cache: https://web.dev/articles/http-cache
• web.dev — Web Vitals: https://web.dev/articles/vitals
• Google Search Central — Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central — Page experience: https://developers.google.com/search/docs/appearance/page-experience
• Google Search Central — AI features: https://developers.google.com/search/docs/appearance/ai-features
• Google Search Central Blog — CDNs and crawling (۲۴ دسامبر ۲۰۲۴): https://developers.google.com/search/blog/2024/12/crawling-december-cdns
• Google Search Central — HTTP status codes (۴ فوریه ۲۰۲۶): https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• Google crawlers — HTTP caching / ETag: https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers
• MDN — HTTP caching: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching
• MDN — Cache-Control: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
• RFC 9111 — HTTP Caching: https://www.rfc-editor.org/rfc/rfc9111
• Cloudflare Learning — What is a CDN?: https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
• Cloudflare Learning — CDN edge server: https://www.cloudflare.com/learning/cdn/glossary/edge-server/
• Cloudflare Learning — CDN SSL/TLS: https://www.cloudflare.com/learning/cdn/cdn-ssl-tls-security/