NGINX 1.30 شاخه Stable جدید این وبسرور است که در ۱۴ آوریل ۲۰۲۶ منتشر شد و قابلیتهایی از شاخه 1.29.x را وارد نسخه پایدار کرد. یکی از مهمترین آنها برای مدیران سرور و سایت، پشتیبانی از HTTP 103 Early Hints است؛ قابلیتی که اجازه میدهد مرورگر پیش از آماده شدن پاسخ نهایی، بارگذاری بعضی فایلهای حیاتی مثل CSS و فونت را شروع کند.
اگر سایت شما پشت NGINX و یک بکاند نسبتاً کند مثل WordPress، Laravel، Node.js یا یک اپلیکیشن پویا قرار دارد، Early Hints میتواند زمان بیکار ماندن مرورگر هنگام تولید پاسخ را به فرصت برای دریافت منابع ضروری تبدیل کند. البته این قابلیت «جادوی افزایش سرعت» نیست و باید درست پیکربندی و اندازهگیری شود.
NGINX 1.30 چه زمانی منتشر شد و چه چیزهایی تغییر کرد؟
طبق خبر رسمی NGINX، نسخه 1.30.0 Stable در ۱۴ آوریل ۲۰۲۶ منتشر شد. این نسخه مجموعهای از قابلیتها و اصلاحات شاخه 1.29.x را وارد Stable کرد؛ از جمله Early Hints، قابلیت HTTP/2 به سمت backend، پشتیبانیهای جدید در TLS و شبکه و تغییرات مرتبط با upstreamها. برای اکثر مدیران وب، مهمترین نکته این است که NGINX جدید فقط یک بهروزرسانی نگهداری نیست و چند قابلیت عملی برای کاهش latency و بهبود معماری reverse proxy دارد.
103 Early Hints چیست؟
کد وضعیت 103 Early Hints یک پاسخ موقت HTTP است. سرور میتواند قبل از پاسخ نهایی 200 یا سایر پاسخهای اصلی، اطلاعاتی درباره منابعی که مرورگر احتمالاً به آنها نیاز دارد ارسال کند. معمولاً این اطلاعات در هدر Link و با مقادیری مثل rel=preload یا rel=preconnect قرار میگیرند.
به زبان ساده، مرورگر به جای اینکه برای تولید کامل HTML منتظر بماند، میتواند زودتر دانلود CSS، فونت یا برقراری اتصال به یک origin مهم را شروع کند. این روش زمانی ارزش بیشتری دارد که تولید پاسخ HTML در backend چند ده یا چند صد میلیثانیه زمان میبرد.
Early Hints در NGINX چگونه کار میکند؟
NGINX توضیح میدهد که این وبسرور میتواند پاسخهای 103 تولیدشده توسط backend را دریافت و در صورت اجازه پیکربندی، به client عبور دهد. دایرکتیو جدید early_hints تعیین میکند که این پاسخهای موقت تحت چه شرایطی به کاربر ارسال شوند. بهصورت پیشفرض، عبور دادن Early Hints فعال نیست.
سادهترین شکل مفهومی تنظیم در یک location پروکسیشده چنین است:
location / {
early_hints 1;
proxy_pass http://backend;
}این مثال صرفاً منطق اصلی را نشان میدهد. در محیط Production بهتر است Early Hints را فقط برای clientهای مدرن و سناریوهایی که تست شدهاند فعال کنید. خود NGINX نیز درباره فعالسازی بیقیدوشرط برای کلاینتهای قدیمی HTTP/1.1 هشدار میدهد.
چه چیزی باید در backend ارسال شود؟
Backend باید بتواند پیش از پاسخ نهایی، هدرهای مناسب را به شکل 103 برگرداند. هدف معمولاً preload کردن منابع حیاتی است، برای مثال:
Link: </assets/app.css>; rel=preload; as=style
Link: </assets/app.woff2>; rel=preload; as=font; crossoriginمنابعی را preload کنید که تقریباً همیشه در همان صفحه لازم هستند. preload کردن فایلهای زیاد یا منابع غیرضروری میتواند پهنای باند و اولویتبندی مرورگر را بدتر کند.
تفاوت 103 Early Hints با preload داخل HTML چیست؟
در preload معمولی، مرورگر باید ابتدا بخشی از HTML را دریافت و parse کند تا تگهای مربوط به preload را ببیند. Early Hints یک مرحله زودتر عمل میکند: مرورگر میتواند قبل از آماده شدن پاسخ نهایی، hintها را دریافت کند. بنابراین بیشترین سود زمانی به دست میآید که TTFB به دلیل پردازش backend قابلتوجه باشد.
اگر سایت شما HTML را تقریباً آنی از cache تحویل میدهد، سود Early Hints ممکن است کم یا حتی نامحسوس باشد. در مقابل، سایتهای پویا، صفحات شخصیسازیشده و اپلیکیشنهایی که قبل از تولید HTML چند query یا API call دارند، کاندیدای بهتری هستند.
آیا Early Hints جای HTTP/2 یا HTTP/3 را میگیرد؟
خیر. Early Hints یک مکانیزم مکمل است. HTTP/2 و HTTP/3 روش انتقال داده را بهینه میکنند، در حالی که 103 تلاش میکند زمان قبل از پاسخ نهایی را بهتر استفاده کند. اگر میخواهید درباره لایه انتقال و تفاوت QUIC با HTTP/2 بیشتر بدانید، مقاله بررسی HTTP/3 و QUIC را ببینید.
مزایای عملی Early Hints برای سایت
- شروع زودتر دانلود منابع حیاتی: CSS، فونتها و connectionها میتوانند قبل از HTML نهایی شروع شوند.
- کاهش زمان تلفشده در server think-time: مخصوصاً در صفحات پویا.
- احتمال بهبود LCP در سناریوی مناسب: اگر منبع LCP یا CSS حیاتی زودتر قابل دریافت شود.
- سازگاری با معماری reverse proxy: NGINX میتواند hintهای backend را به client منتقل کند.
چه زمانی Early Hints فایده کمی دارد؟
اگر TTFB بسیار پایین است، صفحه از full-page cache سرو میشود یا منابع حیاتی از قبل در cache مرورگر هستند، فضای زیادی برای بهبود باقی نمیماند. همچنین اگر backend منابع اشتباه را hint کند، ممکن است مرورگر فایلهایی را دانلود کند که اصلاً لازم نیستند.
پیشنیازهای راهاندازی روی VPS
- نسخه NGINX خود را با
nginx -vبررسی کنید. - از نسخهای استفاده کنید که دایرکتیو
early_hintsرا پشتیبانی میکند؛ این قابلیت از شاخه 1.29 وارد NGINX شد و در 1.30 Stable قرار دارد. - قبل از تغییر Production، کانفیگ را روی staging تست کنید.
- با
nginx -tصحت syntax را بررسی کنید و سپس reload انجام دهید. - مطمئن شوید backend واقعاً 103 و Link headerهای درست تولید میکند.
اگر NGINX شما نقش reverse proxy دارد، مقالههای مرتبط با معماری پروکسی و HTTP/3 میتوانند برای طراحی مسیر درخواست مفید باشند.
روش تست 103 Early Hints
برای تست، فقط به حس سریعتر شدن صفحه اکتفا نکنید. با ابزارهای توسعه مرورگر و ابزارهای خط فرمان پاسخهای interim را بررسی کنید. سپس قبل و بعد از فعالسازی، متریکهای TTFB، LCP و waterfall شبکه را با چند اجرای تکراری مقایسه کنید.
curl -I --http2 https://example.com/بسته به نسخه curl و مسیر شبکه، نمایش پاسخهای interim ممکن است متفاوت باشد. DevTools مرورگر نیز برای مشاهده زمان شروع درخواست منابع preloadشده مفید است.
Early Hints و Core Web Vitals
Early Hints بهطور مستقیم «فاکتور رتبهبندی مستقل» نیست. ارزش آن از بهبود تجربه کاربر و در بعضی صفحات، کاهش زمان دریافت منابع مهم میآید. اگر نتیجه واقعی آن کاهش LCP یا بهتر شدن سرعت ادراکشده باشد، از نظر تجربه کاربری و سئوی فنی مفید است. اما فعال کردن 103 بدون اندازهگیری، تضمینی برای افزایش امتیاز Lighthouse یا Core Web Vitals ندارد.
NGINX 1.30 برای WordPress و Laravel چه کاربردی دارد؟
در WordPress، اگر صفحه از cache کامل تحویل نشود و PHP برای ساخت HTML زمان مصرف کند، Early Hints میتواند preload فایل CSS اصلی یا فونت حیاتی را زودتر اعلام کند. در Laravel یا سایر backendهای اپلیکیشنی هم منطق مشابه است: وقتی route قبل از تولید HTML نیاز به query یا پردازش دارد، 103 میتواند بخشی از آن زمان انتظار را پنهان کند.
برای سایتهایی که cache بسیار قدرتمند دارند، ابتدا بررسی کنید گلوگاه واقعاً backend است یا شبکه، دیتابیس، تصویر و JavaScript. بهینهسازی باید بر اساس bottleneck واقعی انجام شود.
ریسکها و اشتباهات رایج
- فعال کردن feature بدون اطمینان از پشتیبانی نسخه NGINX.
- ارسال preload برای تعداد زیادی فایل.
- preload کردن فایلهایی که در همه درخواستها استفاده نمیشوند.
- عدم تست رفتار CDN یا proxy میانی.
- قضاوت بر اساس یک اجرای Lighthouse به جای چند تست کنترلشده.
- فعالسازی بیقیدوشرط برای کلاینتهای قدیمی HTTP/1.1.
چکلیست پیشنهادی برای مدیر سرور
- نسخه NGINX را بررسی و در صورت نیاز ارتقا دهید.
- TTFB صفحات مهم را قبل از هر تغییر ثبت کنید.
- فقط منابع حیاتی و قابل پیشبینی را به عنوان hint انتخاب کنید.
- Early Hints را ابتدا روی staging یا بخشی از ترافیک تست کنید.
- رفتار HTTP/2، HTTP/3، CDN و مرورگرهای اصلی را مقایسه کنید.
- نتایج LCP و waterfall را قبل و بعد از تغییر ثبت کنید.
سؤالات متداول
آیا NGINX 1.30 از 103 Early Hints پشتیبانی میکند؟
بله. پشتیبانی Early Hints ابتدا در NGINX 1.29.0 mainline معرفی شد و با انتشار NGINX 1.30.0 در ۱۴ آوریل ۲۰۲۶ وارد شاخه Stable شد.
آیا Early Hints برای همه سایتها سرعت را بیشتر میکند؟
خیر. بیشترین فایده زمانی است که backend برای آمادهسازی HTML تأخیر قابلتوجه دارد و مرورگر میتواند در همان فاصله منابع مهم را زودتر شروع کند.
آیا باید همه CSS و JavaScriptها را preload کنیم؟
خیر. فقط منابع واقعاً حیاتی و تقریباً قطعی را preload کنید؛ preload بیش از حد میتواند اولویتبندی شبکه را بدتر کند.
آیا 103 Early Hints با Cloudflare قابل استفاده است؟
بله، Cloudflare نیز Early Hints را در محصولات خود پشتیبانی میکند و میتواند Link headerهای مناسب را برای پاسخ 103 استفاده کند. با این حال رفتار دقیق به معماری CDN و origin شما بستگی دارد.
جمعبندی
NGINX 1.30 یک Stable مهم برای مدیران وب است و 103 Early Hints یکی از قابلیتهایی است که در سناریوی مناسب میتواند زمان انتظار مرورگر را به زمان مفید تبدیل کند. اگر سایت شما TTFB قابلتوجهی دارد، Early Hints ارزش تست دارد؛ اما آن را مرحلهای فعال کنید و نتیجه را با داده واقعی بسنجید. برای زیرساختهای VPS، انتخاب منابع سرور مناسب، تنظیم درست NGINX و مانیتورینگ همچنان پایه اصلی عملکرد هستند.