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

چرا دکمه‌ی «بررسی سرعت» را زدید و هنوز سایتتان کند است؟

همین الان یک تست سرعت از سایت خودتان بگیرید. احتمالاً عددی بین ۴۰ تا ۷۰ از ۱۰۰ می‌بینید و گزارش می‌گوید «تصاویر را فشرده کنید» یا «جاوااسکریپت را به تأخیر بیندازید». این توصیه‌ها درست‌اند، اما ترتیب‌شان اشتباه است. شما دارید به حلقه‌هایی از زنجیره حمله می‌کنید که اصلاً گلوگاه نیستند.

سرعت سایت یک زنجیره است، نه یک عدد. از لحظه‌ای که کاربر آدرس را تایپ می‌کند تا لحظه‌ای که صفحه کامل رندر می‌شود، حداقل هفت حلقه وجود دارد: DNS، اتصال TCP/TLS، تحویل HTML، بارگذاری CSS، اجرای جاوااسکریپت، دریافت تصاویر و فونت‌ها، و در نهایت رندر نهایی. هر حلقه چند میلی‌ثانیه می‌برد، اما مجموع آن‌هاست که تجربه کاربر را می‌سازد.

بیشتر مدیران سایت فقط دو حلقه آخر را می‌بینند و بقیه را نادیده می‌گیرند. این اشتباه پرهزینه‌ای است.

زنجیره سرعت: هر حلقه چند میلی‌ثانیه می‌برد؟

بیایید با اعداد واقعی صحبت کنیم. این ارقام میانگین‌هایی هستند که در عمل دیده‌ام، نه اعداد آزمایشگاهی:

جمع این ارقام در حالت بد به ۳.۵ ثانیه می‌رسد. گوگل می‌گوید ۵۳٪ بازدیدهای موبایل با بارگذاری بیش از ۳ ثانیه رها می‌شوند. این عدد را جدی بگیرید.

حلقه اول: DNS — جایی که همه فراموشش می‌کنند

قبل از اینکه حتی یک بایت از سایت شما ارسال شود، مرورگر باید آدرس دامنه را به IP تبدیل کند. اگر DNS شما با TTL (Time To Live) بالا و Nameserver ضعیف باشد، همین حلقه ۸۰ میلی‌ثانیه هدر می‌دهد.

برای بررسی، از دستور dig +trace example.com استفاده کنید و ببینید هر مرحله چقدر طول می‌کشد. اگر پاسخ از Nameserver شما بالای ۵۰ میلی‌ثانیه است، مشکل دارید. راه‌حل: DNS با هرس‌کردن (Anycast) انتخاب کنید و TTL را برای رکوردهای اصلی روی ۳۰۰ ثانیه تنظیم کنید، نه ۸۶۴۰۰.

حلقه دوم: TTFB — جایی که هاستینگ تصمیم می‌گیرد

TTFB یعنی فاصله بین درخواست مرورگر و دریافت اولین بایت پاسخ. این عدد مستقیماً به قدرت پردازنده، نوع دیسک و تنظیمات وب‌سرور شما بستگی دارد. اگر TTFB شما بالای ۳۰۰ میلی‌ثانیه است، مشکل از کد شما نیست؛ از زیرساخت است.

با curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null https://example.com دقیقاً اندازه بگیرید. اگر عدد بالاست، اول PHP-FPM را بررسی کنید: pm.max_children را بر اساس حافظه هر فرآیند تنظیم کنید. فرمول ساده: حافظه کل تقسیم بر حافظه هر فرآیند PHP. اگر هر فرآیند ۱۲۸MB مصرف می‌کند و سرور ۴GB رم دارد، pm.max_children = 30.

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

اولویت‌بندی بر اساس نسبت هزینه به اثر

شما زمان و بودجه محدود دارید. هر اقدامی که انجام می‌دهید باید بیشترین اثر را با کمترین هزینه داشته باشد. این ترتیب را پیشنهاد می‌کنم:

1. فعال‌سازی HTTP/2 و Brotli — یک تغییر در تنظیمات وب‌سرور، ۲۰ تا ۳۰ درصد کاهش حجم انتقال. هزینه: ۱۵ دقیقه.
2. کش مرورگر با Cache-Control — برای بازدیدکننده‌های برگشتی، ۵۰٪ کاهش زمان بارگذاری. هزینه: ۱۰ دقیقه.
3. بهینه‌سازی تصاویر با WebP — کاهش ۳۰ تا ۷۰ درصدی حجم تصاویر بدون افت کیفیت محسوس. هزینه: یک ساعت.
4. حذف جاوااسکریپت غیرضروری — بزرگ‌ترین برد ممکن، اما پرهزینه‌ترین. نیاز به بازبینی کد دارد.

این ترتیب بر اساس این واقعیت است که ۸۰٪ از بهبود سرعت با ۲۰٪ از تلاش به دست می‌آید. کارهای سخت را برای آخر بگذارید.

کش مرورگر: ساده‌ترین بردی که نمی‌گیرید

تنظیم هدرهای کش در nginx فقط چند خط است:

location ~* \.(jpg|jpeg|png|webp|svg|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

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

مشکل رایج: بعد از تغییر CSS یا JS، کاربران نسخه قدیمی را می‌بینند. راه‌حل، افزودن هش فایل به نام آن است: style.a3f2b9.css. با هر تغییر، نام عوض می‌شود و مرورگر مجبور به دریافت نسخه جدید است.

تصاویر WebP: بدون افت کیفیت محسوس

فرمت WebP به طور میانگین ۳۰٪ سبک‌تر از JPEG و ۵۰٪ سبک‌تر از PNG است. تبدیل با دستور زیر انجام می‌شود:

cwebp -q 80 input.jpg -o output.webp

کیفیت ۸۰ معمولاً از نظر بصری غیرقابل تشخیص از نسخه اصلی است. برای تصاویر محصول، کیفیت ۸۵ را انتخاب کنید. برای بنرها و پس‌زمینه‌ها، ۷۵ کافی است.

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

جاوااسکریپت: قاتل خاموش Core Web Vitals

جاوااسکریپت بزرگ‌ترین تهدید برای معیارهای Core Web Vitals است، به‌ویژه LCP (Largest Contentful Paint) و INP (Interaction to Next Paint). هر اسکریپت اضافی، زمان اجرا را افزایش می‌دهد و هر کتابخانه سنگین، حافظه بیشتری مصرف می‌کند.

اولین قدم، اندازه‌گیری است. در Chrome DevTools، تب Performance را باز کنید و بارگذاری صفحه را ضبط کنید. ببینید کدام اسکریپت بیشترین زمان را می‌برد. معمولاً مقصرها کتابخانه‌های jQuery قدیمی، اسلایدرها و اسکریپت‌های تحلیل هستند.

راه‌حل عملی: اسکریپت‌های غیرضروری را با defer یا async بارگذاری کنید. تفاوت مهم است: defer ترتیب اجرا را حفظ می‌کند، async نه. برای اسکریپت‌های مستقل، async بهتر است. برای اسکریپت‌های وابسته، defer.

یک قانون سرانگشتی: اگر اسکریپتی برای رندر اولیه صفحه لازم نیست، نباید در HTML اصلی باشد. آن را با defer بارگذاری کنید یا به‌صورت شرطی بعد از تعامل کاربر اجرا کنید.

فونت‌ها: ۲۰۰ میلی‌ثانیه پنهان

فونت‌های وب معمولاً نادیده گرفته می‌شوند، اما هر فایل فونت می‌تواند ۱۰۰ تا ۳۰۰ کیلوبایت باشد. اگر سه فونت با چهار وزن مختلف استفاده کنید، حجمی معادل یک تصویر بزرگ اضافه کرده‌اید.

راه‌حل: از font-display: swap استفاده کنید تا متن با فونت پیش‌فرض نمایش داده شود و فونت وب بعداً جایگزین شود. همچنین فقط وزن‌های لازم را بارگذاری کنید. اگر فقط از Bold و Regular استفاده می‌کنید، فایل‌های Italic و Black را حذف کنید.

اندازه‌گیری درست؛ نیمی از درمان

قبل از هر اقدامی، یک baseline ثبت کنید. از PageSpeed Insights استفاده کنید و اعداد LCP، INP و CLS را یادداشت کنید. بعد از هر تغییر، دوباره اندازه بگیرید. اگر عدد بهبود نیافت، تغییر شما بی‌اثر بوده است.

ابزار رایگان دیگر، WebPageTest است که waterfall کامل بارگذاری را نشان می‌دهد. این ابزار دقیقاً مشخص می‌کند کدام درخواست گلوگاه است و چقدر طول می‌کشد.

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

این‌جا اشتباه می‌کنند: بهینه‌سازی بدون اندازه‌گیری

رایج‌ترین اشتباهی که دیده‌ام: مدیر سایتی که یک هفته وقت صرف فشرده‌سازی تصاویر کرده، اما TTFB سایتش ۸۰۰ میلی‌ثانیه بوده و هیچ تغییری در سرعت احساس نکرده است. چرا؟ چون گلوگاه اصلی زیرساخت بوده، نه تصاویر.

نشانه این اشتباه: گزارش PageSpeed بهبود یافته، اما کاربران همچنان از کندی سایت شکایت دارند. اگر این وضعیت را تجربه می‌کنید، اول TTFB را اندازه بگیرید. اگر بالای ۳۰۰ میلی‌ثانیه است، مشکل از هاستینگ یا تنظیمات وب‌سرور است و هیچ‌ amount از بهینه‌سازی فرانت‌اند آن را حل نمی‌کند.

راه‌حل: هاستینگ را ارتقا دهید یا به سرور با NVMe و PHP 8.2+ مهاجرت کنید. تفاوت بین هاست اشتراکی و سرور اختصاصی در TTFB معمولاً ۳ تا ۵ برابر است.

پرسش‌های پرتکرار

چرا سرعت سایت من در PageSpeed Insights کم است اما در عمل سریع به نظر می‌رسد؟

PageSpeed Insights از یک دستگاه شبیه‌سازی‌شده با اتصال 4G و سخت‌افزار ضعیف استفاده می‌کند. این سناریو عمداً سخت‌گیرانه است تا بدترین حالت را نشان دهد. اگر کاربران شما عمدتاً با اینترنت پرسرعت و دستگاه‌های مدرن وارد می‌شوند، تجربه واقعی آن‌ها بهتر از عدد گزارش است. اما این بهانه‌ای برای نادیده گرفتن گزارش نیست؛ گوگل از همین معیار برای رتبه‌بندی استفاده می‌کند.

تفاوت TTFB و LCP چیست و کدام مهم‌تر است؟

TTFB زمان تا دریافت اولین بایت از سرور است و LCP زمان تا نمایش بزرگ‌ترین عنصر صفحه. TTFB زیرمجموعه LCP است؛ اگر TTFB بالا باشد، LCP هم بالا خواهد بود. اما LCP می‌تواند بالا باشد حتی با TTFB پایین، اگر تصویر اصلی دیر بارگذاری شود. برای بهینه‌سازی، اول TTFB را زیر ۲۰۰ میلی‌ثانیه برسانید، بعد سراغ LCP بروید.

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

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

چند بار باید سرعت سایت را بررسی کنم؟

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