مشخص کنید کاربر دقیقاً منتظر چه چیزی است
صفحه ممکن است برای DNS، اتصال، ساخت HTML، فونت یا مرورگرِ درگیر منتظر بماند. خرید سرور بزرگ‌تر پیش از پیدا‌کردن این انتظار لزوماً مشکل را حل نمی‌کند. آدرس عمومی دقیق، دستگاه، شبکه، زمان و اولین یا تکراری‌بودن بازدید را ثبت کنید. برای سنجش، صفحهٔ عمومی را به‌جای پاسخ شخصی حساب کاربری انتخاب کنید.
پیش از تغییر زیرساخت، زمان‌های HTTP را بخوانید
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://example.com/این نمونه برای شل Linux/macOS یک GET می‌فرستد و بدنه را کنار می‌گذارد. در ویندوز curl.exe را اجرا و مسیر خروجی را متناسب کنید. زمان‌ها برحسب ثانیه و تجمعی از آغاز درخواست‌اند: تفاضل connect و dns تقریب مرحلهٔ TCP و تفاضل tls و connect تقریب TLS در اتصال مستقیم ساده است. first_byte شامل مراحل قبلی نیز هست و صرفاً زمان PHP یا دیتابیس نیست. اتصال مجدد، پروکسی و انتقال آدرس تفسیر را عوض می‌کنند؛ انتقال‌ها را جدا بررسی و آدرس نهایی را هم آزمایش کنید.
چند نمونهٔ قابل‌مقایسه از شبکهٔ مشکل‌دار و یک محل دیگر بگیرید و میانه و پراکندگی را بسنجید. بهترین عدد را به‌تنهایی انتخاب نکنید. Ping از ICMP استفاده می‌کند و ممکن است فیلتر یا متفاوت پردازش شود؛ یک آستانهٔ ثابت برای Ping یا Jitter تشخیص کافی برای HTTPS نیست.
اگر اولین بایت دیر می‌رسد
- زمان مسیر کند را با فایل استاتیک کوچکی از همان میزبان مقایسه کنید. فایل سریع و صفحهٔ پویا کند، نشانهٔ بررسی برنامه است؛ آن را با زمان درخواست و لاگ تأیید کنید.
- مصرف CPU، صف اجرا، حافظهٔ در دسترس، فعالیت Swap و تأخیر دیسک را در زمان مشکل ببینید. ابزارهای موجود مثل top، vmstat و iostat کمک می‌کنند. حافظهٔ کش‌شده الزاماً فشار حافظه نیست و درصد استفادهٔ دیسک به‌تنهایی معیار قطعی اشباع نیست.
- کوئری‌های کند و برنامهٔ اجرای آن‌ها را بررسی کنید. ایندکس باید برای الگوی واقعی جست‌وجو ساخته شود و هزینهٔ نوشتن آن هم سنجیده شود. پیمایش کامل جدول کوچک لزوماً ایراد ندارد.
- اگر فقط بعضی شبکه‌ها مشکل دارند، IPv4، IPv6 و پاسخ DNS را مقایسه کنید و پیش از تغییر رکوردها از راهنمای آزمون DNS استفاده کنید.
ابتدا بررسی‌های فقط‌خواندنی را انجام دهید. آزمون فشار به محیط کنترل‌شدهٔ مجاز، محدودیت و پایش نیاز دارد؛ فرستادن تعداد حدسی درخواست به سایت زنده می‌تواند به کاربران فعلی آسیب بزند.
اگر HTML سریع می‌آید اما نمایش دیر است
بخش Performance و Network مرورگر یا گزارش موبایل PageSpeed را باز کنید. عنصر واقعی LCP و وابستگی‌هایش را پیدا کنید. برای متن، CSS مسدودکننده یا فونت دیررس می‌تواند عامل باشد. برای تصویر، زمان کشف، حجم انتقال و اولویت را بررسی کنید؛ تصویر اصلی بالای صفحه نباید Lazy Load شود. ابعاد تصاویر را مشخص کنید و جابه‌جایی ناشی از تعویض فونت را هم بسنجید.
برای تعامل کند، کارهای نخ اصلی، تأخیر شروع ورودی، اجرای پاسخ و زمان نمایش بعدی را جدا ببینید. ارتقای سرور، اجرای طولانی JavaScript را حذف نمی‌کند. کار اضافی را کم و پردازش سنگین را تقسیم کنید، سپس رفتار واقعی را آزمایش کنید. پنهان‌کردن محتوای اصلی برای کم‌کردن عدد LCP بهبود مناسبی نیست.
یک نمونهٔ اندازه‌گیری‌شده از ServerNet
در ۱۰ اکتبر ۲۰۲۶، یک آزمون آزمایشگاهی موبایل صفحهٔ اصلی ServerNet، LCP را ۲٫۷۶۲ ثانیه، TBT را ۷۱ میلی‌ثانیه و CLS را ۰٫۰۰۱ ثبت کرد. آزمایش پیشینِ بارگذاری غیرهم‌زمان CSS باعث CLS برابر ۰٫۵۳۸ شد و کنار گذاشته شد. این نتیجهٔ یک صفحه در شرایط آزمون است، نه تضمین برای همهٔ کاربران یا نشانهٔ تغییر رتبه. گزارش ثبت‌شده نشان می‌دهد چرا باید چند معیار را هم‌زمان کنترل کرد.
چرخه را با اصلاح قابل‌بازگشت کامل کنید
عامل مشکوک و اثر موردانتظار را بنویسید. یک عامل مرتبط را تغییر دهید، نسخهٔ قبلی را نگه دارید و همان سنجش‌ها را تکرار کنید. کارکرد و جابه‌جایی صفحه را کنار سرعت بسنجید؛ اگر نتیجه پایدار نیست یا رفتار خراب شد، برگردانید. بازدید اول را از استفادهٔ مجدد از کش جدا کنید و روند بلندتر را با دادهٔ کاربران واقعی بررسی کنید.
منابع: زمان‌های curl و تشخیص تأخیر LCP.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!