CDN و سئو: اثر واقعی روی TTFB، LCP و Core Web Vitals

اگر بیشتر کاربران سایت شما در ایران‌اند، رابطه‌ی CDN و سئو را باید با داده‌ی میدانی سنجید، نه با حدس. گوگل برای Core Web Vitals به تجربه‌ی واقعی کاربران کروم نگاه می‌کند. برای کاربر ایرانی، فاصله‌ی شبکه‌ای تا سرور، زمان نخستین پاسخ و حجم فایل‌ها تعیین می‌کند که صفحه کی دیده شود. CDN می‌تواند این عددها را بهتر کند؛ اما اگر بد تنظیم شود، ممکن است صفحه‌ی خطا را کش کند یا جلوی گوگل‌بات را بگیرد.

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

CDN و سئو: اثر از راه شاخص‌هاست، نه مستقیم

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

• LCP: زمان بار شدن بزرگ‌ترین بخش دیدنی صفحه
• INP: سرعت پاسخ‌گویی صفحه به تعامل کاربر
• CLS: میزان جابه‌جایی چیدمان هنگام بار شدن

گوگل هر شاخص را در صدک ۷۵ بازدیدهای واقعی ارزیابی می‌کند. TTFB جزو این سه نیست، اما همه‌چیز پس از نخستین بایت آغاز می‌شود؛ پس TTFB مستقیم روی LCP اثر می‌گذارد.

جدول زیر نشان می‌دهد انتظار از CDN برای هر شاخص چقدر واقع‌بینانه است:

نتیجه‌ی عملی: اگر مشکل سایت شما LCP یا TTFB است، CDN ابزار درستی است. اگر INP یا CLS ضعیف است، باید سراغ کد قالب بروید.

TTFB؛ نخستین عددی که پس از روشن کردن ابر جابه‌جا می‌شود

TTFB از سه بخش ساخته می‌شود:

1. پیدا کردن نشانی (DNS)
2. برقراری اتصال و دست‌دهی TLS
3. زمانی که سرور برای ساختن پاسخ صرف می‌کند

با CDN ایران ابر ویرا، که نودهای لبه‌اش در تهران، مشهد و کرمانشاه است، دست‌دهی TLS با لبه‌ای نزدیک‌تر به کاربر انجام می‌شود. اگر پاسخ در کش لبه باشد (HIT)، بخش سوم هم تقریباً حذف می‌شود. اما در حالت MISS، لبه باید پاسخ را از مبدأ بگیرد و TTFB دوباره به سرعت سرور شما وابسته می‌شود. پس صفحه‌ای که کش نمی‌شود، از CDN تنها بخشی از بهبود را می‌گیرد. در بحث CDN و سئو، همین تفاوت HIT و MISS بیشترین سوءتفاهم را می‌سازد.

سنجش TTFB لبه و مبدأ با curl

از یک سیستم داخل ایران، پاسخ لبه را چند بار پشت‌سرهم بسنجید. بار نخست اغلب MISS است:

for i in 1 2 3; do curl -o /dev/null -s -w 'dns:%{time_namelookup} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' https://example.ir/; done

سپس همان صفحه را مستقیم از مبدأ بخواهید. ORIGIN_IP را با آی‌پی سرورتان جایگزین کنید:

curl -o /dev/null -s -w 'ttfb:%{time_starttransfer}\n' --resolve example.ir:443:ORIGIN_IP https://example.ir/

اگر روی مبدأ گواهی معتبر ندارید، گزینه‌ی -k را بیفزایید. اگر فاصله‌ی عدد MISS و HIT زیاد باشد، یعنی سرور مبدأ کند است؛ در این حالت کش کردن مسیرهای بیشتر یا بهینه‌سازی پایگاه داده سود بیشتری دارد. برای دیدن وضعیت کش، سرآیندها را با curl -sI https://example.ir/ بخوانید و سرآیندهایی مانند Age یا سرآیند وضعیت کشی را که لبه برمی‌گرداند بررسی کنید.

LCP؛ تصویر اصلی را به لبه بسپارید

در بیشتر صفحه‌ها، عنصر LCP یا تصویری بزرگ در بالای صفحه است یا بلوکی متنی با فونت سفارشی. عنصر دقیق را در گزارش PageSpeed Insights یا زبانه‌ی Performance ابزار توسعه‌ی کروم پیدا کنید. بعد این کارها را انجام دهید:

• تصویر را از همان دامنه‌ی پشت CDN سرو کنید. این‌طور تصویر از کش لبه و اتصال موجود بهره می‌برد. دامنه‌ی جداگانه یعنی DNS و دست‌دهی تازه.
• روی تصویر LCP هرگز loading="lazy" نگذارید. به‌جای آن fetchpriority="high" بدهید و ابعاد را صریح بنویسید:

<img src="/img/hero-v3.webp" width="1200" height="630" fetchpriority="high" alt="تصویر اصلی">

• تصویر پس‌زمینه را زودتر معرفی کنید. اگر تصویر اصلی پس‌زمینه‌ی CSS است، مرورگر دیر پیدایش می‌کند. با <link rel="preload" as="image" href="/img/hero-v3.webp"> آن را زودتر به مرورگر بشناسانید.
• فونت را روی همان دامنه بگذارید، با قالب woff2 و font-display: swap.
• HTML صفحه‌های عمومی را کوتاه‌مدت کش کنید. برای صفحه‌هایی که برای همه یکسان‌اند، مثل مقاله یا صفحه‌ی محصول بدون قیمت شخصی، کش کوتاه HTML روی لبه بیشترین اثر را روی LCP دارد. دلیلش این است که کاهش TTFB بار شدن همه‌ی فایل‌های بعدی را جلو می‌اندازد.

کش به نفع سئو؛ سرآیند درست برای هر نوع پاسخ

روشن کردن کش کافی نیست؛ هر نوع پاسخ رفتار خودش را لازم دارد:

1. فایل‌های نسخه‌دار (مثل app.3f9c.css): کش یک‌ساله با Cache-Control: public, max-age=31536000, immutable. با هر تغییر، نام فایل عوض می‌شود و نیازی به پاک کردن کش نیست.
2. تصویر و فایل بی‌نسخه: زمان کوتاه‌تر، مثلاً یک روز، تا جایگزینی تصویر دیر دیده نشود.
3. HTML عمومی: زمان کش لبه را با قوانین مسیر پنل، فقط برای همان مسیرها و کوتاه، تعیین کنید.
4. مسیرهای شخصی: سبد خرید، حساب کاربری، پرداخت و پیشخوان مدیریت را اصلاً کش نکنید.
5. robots.txt و sitemap.xml: بی‌کش یا با زمانی کوتاه، تا تغییرشان دیر به گوگل نرسد.

اگر همه‌ی فایل‌های CSS، جاوااسکریپت و فونت نام نسخه‌دار دارند، تنظیم بند ۱ روی مبدأ nginx این‌طور است:

location ~* \.(css|js|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

با نام‌گذاری نسخه‌دار، پس از هر انتشار نیازی به پاک کردن کل کش نیست. پاک کردن کامل کش یعنی همه‌ی درخواست‌ها تا پر شدن دوباره‌ی کش MISS می‌شوند و TTFB، درست در روزهایی که گوگل‌بات صفحه‌های تازه را می‌خزد، بالا می‌رود.

فشرده‌سازی؛ حجم کمتر برای LCP و برای صورتحساب

HTML، CSS، جاوااسکریپت، JSON و SVG متنی‌اند و با فشرده‌سازی کوچک می‌شوند. فشرده‌سازی را روی مبدأ فعال کنید:

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_types text/css application/javascript application/json image/svg+xml;

با gzip on، nginx پاسخ‌های text/html را خودبه‌خود فشرده می‌کند. Brotli معمولاً فایل کوچک‌تری از gzip می‌سازد، اما به ماژول ngx_brotli نیاز دارد. سپس مطمئن شوید پاسخ فشرده از پشت CDN به مرورگر می‌رسد:

curl -sI -H 'Accept-Encoding: br, gzip' https://example.ir/assets/app.css | grep -i content-encoding

خروجی خالی یعنی سرآیند Content-Encoding به کاربر نمی‌رسد؛ در این صورت تنظیم مبدأ و قوانین مسیر را بازبینی کنید. گزینه‌ی gzip_vary on سرآیند Vary: Accept-Encoding را می‌فرستد تا نسخه‌ی فشرده و نافشرده در کش با هم قاطی نشوند.

تصویرهای JPEG، PNG و WebP از پیش فشرده‌اند و gzip چیزی از حجمشان کم نمی‌کند. برای تصویرها، راه درست تبدیل به WebP یا AVIF و سرو در ابعاد واقعی نمایش است.

HTTPS پشت CDN بی‌آنکه سیگنال نشانی‌ها پخش شود

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

• یک هدایت ۳۰۱ تک‌مرحله‌ای از هر نسخه (http، با www یا بی www) به نسخه‌ی اصلی
• تگ canonical و نقشه‌ی سایت که تنها نشانی‌های https را نشان دهند
• نبود محتوای مختلط، یعنی فایل http در صفحه‌ی https

زنجیره‌ی هدایت را این‌طور ببینید:

curl -sIL http://www.example.ir/ | grep -iE '^(HTTP|location)'

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

گام‌به‌گام: سنجش اثر CDN روی Core Web Vitals

1. پایه را ثبت کنید: پیش از روشن کردن ابر، وضعیت گزارش Core Web Vitals در Search Console و داده‌ی میدانی PageSpeed را برای چند نشانی کلیدی یادداشت کنید. TTFB را هم با curl از داخل ایران بسنجید.
2. مبدأ را آماده کنید: سرآیندهای کش، فشرده‌سازی و هدایت‌ها را روی یک نسخه‌ی استیجینگ بیازمایید.
3. ابر را روشن کنید: نام‌سرور و رکوردها را مطابق راه اندازی CDN ایران گام‌به‌گام تنظیم کنید.
4. همان روز بسنجید: این چهار مورد را بررسی کنید: HIT شدن فایل‌های ایستا، TTFB لبه در برابر مبدأ، تک‌مرحله‌ای بودن هدایت، و دسترسی گوگل‌بات با «آزمایش نشانی زنده» در ابزار بازرسی نشانی Search Console.
5. صبر کنید: داده‌ی میدانی کروم بر پایه‌ی بازه‌ی ۲۸ روزه است و بهبود در Search Console تدریجی دیده می‌شود. حدود چهار هفته بعد مقایسه کنید.

هزینه‌ی بهینه‌سازی و آزمون؛ محاسبه با نرخ CDN و سرور

نرخ‌ها به تاریخ آبان ۱۴۰۵ است و بهای روز را ماشین‌حساب صفحه‌ی سفارش نشان می‌دهد. در CDN ابر ویرا گواهی SSL رایگان است و تنها ترافیک دانلود حساب می‌شود، با نرخ ۱٬۲۰۰ تومان برای هر گیگابایت. آپلود، مثل فرم‌ها و فایل‌هایی که کاربران می‌فرستند، رایگان است. بنابراین فشرده‌سازی و بهینه‌سازی تصویر، افزون بر بهبود LCP، صورتحساب را هم کم می‌کند.

فرض کنید سایتی ماهانه ۴۰۰ گیگابایت دانلود از لبه دارد:

• پیش از بهینه‌سازی: ۴۰۰ گیگابایت × ۱٬۲۰۰ تومان = ۴۸۰٬۰۰۰ تومان
• اگر فشرده‌سازی و تبدیل تصویرها حجم را به ۳۰۰ گیگابایت برساند: ۳۰۰ گیگابایت × ۱٬۲۰۰ تومان = ۳۶۰٬۰۰۰ تومان

عدد ۳۰۰ تنها برای مثال است. کاهش واقعی را با مقایسه‌ی مصرف پیش و پس از تغییر در پنل ببینید.

برای استیجینگ گام ۲، یک سرور ابری ساعتی کافی است. طرح «اقتصادی ۲» (۲ هسته‌ی پردازنده، ۲ گیگابایت رم و ۱۵ گیگابایت دیسک) بهای ساعتی ۱٬۶۴۴ تومان دارد. هزینه‌ی دو روز آزمون این‌طور حساب می‌شود: ۴۸ ساعت × ۱٬۶۴۴ تومان = ۷۸٬۹۱۲ تومان.

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

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

بستن راه گوگل‌بات با دیوار آتش وب

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

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

کش شدن پاسخ خطا یا صفحه‌ی شخصی‌شده

اگر قاعده‌های کش شما پاسخ خطا را هم نگه دارند، چند دقیقه خطای ۵xx هنگام به‌روزرسانی مبدأ به همه، از جمله گوگل‌بات، نشان داده می‌شود. خطای ۵xx پیوسته هم باعث می‌شود گوگل خزش را کم کند. از سوی دیگر، صفحه‌ای که Set-Cookie دارد و کش می‌شود ممکن است محتوای حساب یک کاربر را به دیگری نشان دهد.

راه پرهیز: پاسخ‌های دارای Set-Cookie و مسیرهای شخصی را از کش بیرون بگذارید. پایش سلامت مبدأ را هم در پنل CDN روشن کنید تا از خرابی مبدأ زود باخبر شوید.

زنجیره‌ی هدایت و canonical ناهماهنگ

پس از روشن کردن HTTPS روی لبه، گاهی مبدأ هنوز به http یا نسخه‌ی www هدایت می‌کند و canonical هم به نسخه‌ی دیگری اشاره دارد. در این وضعیت گوگل باید میان چند نشانی حدس بزند، و هر مرحله‌ی هدایت به TTFB صفحه‌ی نخست افزوده می‌شود.

راه پرهیز: هدایت را تنها در یک لایه، لبه یا مبدأ، تعریف کنید و آن را با curl -sIL بیازمایید. canonical، نقشه‌ی سایت و پیوندهای داخلی را هم به همان نسخه‌ی نهایی برسانید.

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

گوگل‌بات صفحه را از لبه‌ی CDN می‌خواند یا از سرور مبدأ؟

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

عوض شدن آی‌پی سایت پس از رفتن پشت CDN به رتبه آسیب می‌زند؟

تغییر آی‌پی به‌تنهایی رتبه را جابه‌جا نمی‌کند، چون گوگل نشانی‌ها را دنبال می‌کند، نه آی‌پی را. ممکن است گوگل سرعت خزش را مدتی با وضعیت تازه تطبیق دهد. آنچه واقعاً آسیب می‌زند، خطای ۵xx یا ۴۰۳ در روزهای انتقال است.

چرا PageSpeed بهبود را نشان می‌دهد ولی Search Console هنوز نه؟

بخش آزمایشگاهی PageSpeed همان لحظه اندازه می‌گیرد، اما گزارش Search Console بر داده‌ی میدانی کاربران واقعی در بازه‌ای ۲۸ روزه تکیه دارد. چند هفته طول می‌کشد تا بازدیدهای پس از روشن کردن ابر وزن کافی بگیرند.

برای سئو، HTML همه‌ی صفحه‌ها را کش کنم؟

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

جمع‌بندی

رابطه‌ی CDN و سئو در یک جمله این است: CDN رتبه نمی‌خرد، اما با کوتاه کردن TTFB و LCP برای کاربر ایرانی، داده‌ی میدانی Core Web Vitals را بهتر می‌کند. شرط این بهبود چهار چیز است:

• کش هر نوع پاسخ درست تعریف شود.
• فشرده‌سازی از مبدأ تا مرورگر برسد.
• HTTPS تنها یک نسخه‌ی نهایی از هر نشانی داشته باشد.
• گوگل‌بات پشت دیوار آتش نماند.

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