مدیر سایت می‌بیند صفحه دیر باز می‌شود، اما علت هنوز معلوم نیست. ممکن است سرور دیر پاسخ بدهد، تصویر اصلی دیر کشف شود یا فایل‌های مرورگر نمایش محتوا را عقب بیندازند. خرید هاست قوی‌تر در حالت دوم و سوم، لزوما مشکل را حل نمی‌کند. برای انتخاب اقدام موثر باید زمان بارگذاری را به بخش‌های قابل بررسی تقسیم کرد.
TTFB و LCP به دو قسمت متفاوت این مسیر نگاه می‌کنند. اولی به رسیدن اولین بایت پاسخ مربوط است و دومی زمان نمایش بزرگ‌ترین محتوای قابل مشاهده را اندازه می‌گیرد. کنار هم دیدن این دو شاخص، نقطه شروع خوبی برای عیب‌یابی وردپرس است، اما برای تصمیم نهایی باید صفحه و شرایط کاربر را هم شناخت.
TTFB چه چیزی را اندازه می‌گیرد؟
زمان تا اولین بایت، فقط زمان اجرای PHP نیست. در اندازه‌گیری ناوبری، ریدایرکت‌ها، اتصال و انتظار پاسخ هم می‌توانند در آن نقش داشته باشند. فاصله جغرافیایی، وضعیت شبکه، TLS، کش و پردازش سمت سرور روی نتیجه اثر می‌گذارند. به همین دلیل، TTFB بالا به‌تنهایی ثابت نمی‌کند CPU هاست ضعیف است.
برای بررسی دقیق‌تر، نمودار شبکه مرورگر را ببینید. آیا زمان زیادی پیش از شروع پاسخ سپری شده است؟ درخواست چند بار ریدایرکت می‌شود؟ صفحه برای کاربر مهمان از کش می‌آید یا هر بار وردپرس اجرا می‌شود؟ مقایسه یک مسیر عمومی و یک مسیر پویا می‌تواند تفاوت مهمی نشان دهد.
در راهنمای TTFB در web.dev، مقدار 800 میلی‌ثانیه یا کمتر به‌عنوان هدف خوب مطرح شده است. این شاخص از Core Web Vitals نیست و عدد آن باید با زمینه سنجش خوانده شود. نتیجه یک لپ‌تاپ کنار دیتاسنتر، نماینده همه کاربران موبایل فروشگاه نیست.
LCP کدام بخش تجربه را نشان می‌دهد؟
LCP زمان رندر بزرگ‌ترین عنصر محتوایی واجد شرایط در ناحیه قابل مشاهده را گزارش می‌کند. در بسیاری از صفحه‌ها این عنصر تصویر اصلی یا یک بلوک متن است. اگر تصویر دیر در HTML کشف شود، دریافت آن دیر آغاز می‌شود. اگر فونت یا CSS نمایش متن را عقب بیندازد، سرور سریع هم به‌تنهایی کافی نیست.
هدف خوب LCP طبق راهنمای رسمی web.dev، 2.5 ثانیه یا کمتر است و ارزیابی تجربه کاربران واقعی با صدک 75 انجام می‌شود. داده آزمایشگاهی برای پیدا کردن علت مفید است، اما با داده میدانی یکسان نیست. ممکن است بعد از اصلاح، نتیجه آزمایش سریع بهتر شود و گزارش میدانی به زمان بیشتری برای منعکس‌کردن شرایط تازه نیاز داشته باشد.
LCP خوب، به معنی کامل بودن تجربه نیست. جابه‌جایی ناگهانی محتوا و واکنش کند به تعامل هم اهمیت دارند. در یک فروشگاه، تکمیل مسیر خرید و صحت اطلاعات را در کنار شاخص‌ها بررسی کنید. امتیاز بهتر نباید با حذف قابلیت لازم یا خراب‌شدن فرم به دست بیاید.
اول عنصر LCP و آبشار شبکه را پیدا کنید
در ابزار سنجش، عنصر LCP را شناسایی کنید. اگر تصویر است، ابعاد واقعی نمایش، اندازه فایل، فرمت و زمان شروع دریافت را ببینید. تصویر بالای صفحه را بدون بررسی وارد صف lazy loading نکنید. تصویر پس‌زمینه CSS یا تصویری که فقط بعد از اجرای JavaScript اضافه می‌شود ممکن است دیر کشف شود.
اگر متن عنصر اصلی است، فونت و CSS را بررسی کنید. تعداد وزن‌های فونت، فایل‌های مسدودکننده و وابستگی به منابع بیرونی می‌تواند نمایش را عقب بیندازد. برای تصویر، width و height یا نسبت ابعاد مناسب داشته باشید تا فضای لازم از ابتدا مشخص باشد. هدف، تحویل منبع درست در زمان درست است، نه فقط فشرده‌سازی شدید و افت کیفیت.
برای یافتن علت، یک تغییر انجام دهید و دوباره بسنجید. حذف هم‌زمان چند افزونه، عوض‌کردن قالب و تغییر CDN تشخیص اثر هر کار را ناممکن می‌کند. شرایط آزمون و نسخه صفحه را ثبت کنید. در پایان باید بتوانید توضیح دهید چه تغییری کدام بخش زمان را کاهش داده است.
چه وقت باید سمت سرور را بررسی کنیم؟
اگر انتظار پاسخ روی مسیرهای مهم طولانی است، وضعیت کش صفحه، مصرف منابع و درخواست‌های بیرونی افزونه‌ها را بررسی کنید. یک افزونه ممکن است پیش از ساخت صفحه، به سرویس کند دیگری متصل شود. کوئری سنگین، صف پردازش یا کمبود ظرفیت هم می‌تواند زمان انتظار را بالا ببرد. بررسی لاگ و ابزار پروفایلینگ با دسترسی مناسب به شناخت علت کمک می‌کند.
| مشاهده | احتمال قابل بررسی | اقدام اول |
|---|---|---|
| TTFB بالا در همه مسیرها | اتصال، ریدایرکت یا پاسخ سرور | بررسی شبکه و لاگ |
| مهمان سریع، کاربر واردشده کند | تفاوت کش و اجرای پویا | بررسی PHP و دیتابیس |
| TTFB خوب، LCP ضعیف | کشف یا دریافت دیرهنگام منبع | شناسایی عنصر LCP |
| نتایج بسیار متغیر | شبکه، کش سرد یا بار لحظه‌ای | تکرار در شرایط ثابت |
| خرید کند ولی مقاله سریع | بار پویای فروشگاه | بررسی مسیر سبد و تسویه‌حساب |
برای ووکامرس، قواعد کش فروشگاه را بررسی کنید. فعال‌کردن کش عمومی برای حساب مشتری، راه کاهش TTFB نیست. Redis هم فقط در صورت تناسب با بار واقعی و تنظیم درست می‌تواند به بعضی درخواست‌ها کمک کند.
یک برنامه سنجش قبل و بعد بسازید
پنج صفحه نماینده انتخاب کنید و برای هرکدام وضعیت ورود، موقعیت آزمون و شرایط شبکه را ثبت کنید. کش گرم و سرد را جدا آزمایش کنید. چند اجرا انجام دهید و به میانه و پراکندگی نتایج توجه کنید. صفحه اصلی به‌تنهایی برای قضاوت درباره کل سایت کافی نیست.
بعد از هر اصلاح، همان صفحه‌ها را با شرایط مشابه بسنجید. در Search Console یا ابزار داده واقعی، روند کاربران را هم دنبال کنید. تغییرات محتوا، کمپین تبلیغاتی یا ورود کاربران از یک منطقه تازه می‌تواند ترکیب داده را عوض کند. پس هر تغییر نمودار را بدون بررسی به آخرین اصلاح فنی نسبت ندهید.
بودجه بهینه‌سازی را جایی خرج کنید که اثر دارد
اگر گلوگاه تصویر اصلی است، ابتدا تحویل تصویر و ترتیب بارگذاری را اصلاح کنید. اگر مسیر پویا به سقف منابع می‌رسد، روی کد، دیتابیس و ظرفیت کار کنید. راهنمای انتخاب هاست وردپرس و صفحه عملکرد روناتا برای شکل‌دادن این بررسی مفیدند.
برنامه خوب یک چرخه ساده دارد: اندازه‌گیری، پیدا کردن علت، یک اصلاح مشخص و آزمون دوباره. نتیجه‌ای ارزش دارد که برای صفحه‌های مهم و کاربران واقعی تکرار شود. بهبود تجربه، حاصل همین اصلاح‌های قابل توضیح است، نه رسیدن اتفاقی به یک امتیاز بالا.
