افزایش سرعت سایت با اندازهگیری شروع میشود، نه نصب همزمان چند افزونه یا وعدهٔ سه تا هشت برابر شدن سرعت. ابتدا مشخص کنید مشکل در پاسخ سرور، نمایش محتوای اصلی، واکنش به کلیک یا جابهجایی عناصر است. هرکدام روش بررسی متفاوتی دارد.
برای افزایش سرعت سایت چه چیزی را اندازه بگیریم؟
چند صفحهٔ نماینده، مانند خانه، مقاله و صفحهٔ سرویس را در موبایل و دسکتاپ بررسی کنید. PageSpeed Insights دادهٔ آزمایشگاهی Lighthouse و در صورت وجود دادهٔ کاربران واقعی CrUX را نشان میدهد. دادهٔ واقعی بازهٔ ۲۸روزه دارد و ممکن است بهجای یک صفحه در سطح مبدأ نمایش داده شود.
نبود دادهٔ واقعی به معنی خوب یا بد بودن سایت نیست. نتیجهٔ یک تست هم میتواند با شبکه و شرایط اجرا تغییر کند. URL، زمان، نوع دستگاه و وضعیت کش را ثبت کنید تا مقایسهٔ قبل و بعد منصفانه باشد.
سه معیار اصلی تجربهٔ صفحه
| معیار | چه چیزی را نشان میدهد؟ | مرز وضعیت خوب |
|---|---|---|
| LCP | زمان نمایش بزرگترین محتوای اصلی | حداکثر ۲٫۵ ثانیه |
| INP | پاسخگویی به تعامل | حداکثر ۲۰۰ میلیثانیه |
| CLS | بیثباتی بصری چیدمان | حداکثر ۰٫۱ |
این مرزها در Core Web Vitals با صدک ۷۵ تجربهها سنجیده میشوند. امتیاز آزمایشگاهی، معیار واقعی کاربر و رتبهٔ جستجو را یکی ندانید. عدد بالاتر در یک ابزار، سالم بودن فرم خرید یا محتوای صفحه را تضمین نمیکند.
تصویرها و محتوای بالای صفحه
تصویر را متناسب با اندازهٔ نمایش و کیفیت موردنیاز خروجی بگیرید. ابعاد مشخص به جلوگیری از پرش چیدمان کمک میکند. عکس چندمگابایتی برای یک کارت کوچک، حتی با هاست قوی هزینهٔ انتقال و پردازش اضافه ایجاد میکند.
برای تصاویر پایین صفحه میتوان از بارگذاری تنبل استفاده کرد، اما تصویر مهم ابتدای صفحه و نامزد LCP را بیدلیل lazy نکنید. پس از تبدیل فرمت، شفافیت، کیفیت نوشتههای داخل تصویر و نسخهٔ موبایل را کنترل کنید.
جاوااسکریپت، قالب و افزونهها
اسلایدر، چت، ابزار تحلیل و افزونهها میتوانند کار پردازنده را زیاد کنند. بخشهای غیرضروری را بر اساس نیاز واقعی کم کنید. بهتعویقانداختن همهٔ اسکریپتها بدون آزمون ممکن است منو، فرم یا پرداخت را از کار بیندازد.
برای هر اصلاح، یک مسیر مهم کاربر را آزمایش کنید؛ مثلاً ورود به مقاله، باز کردن منو و ارسال فرم آزمایشی. هدف فقط کاهش حجم فایل نیست، بلکه قابل استفاده ماندن صفحه با تأخیر کمتر است.
کش، CDN و زمان پاسخ
کش HTTP از استفادهٔ دوبارهٔ پاسخ کمک میگیرد. محتوای خصوصی، سبد خرید و پاسخ وابسته به کاربر را بدون قاعده در کش مشترک قرار ندهید. CDN نیز باید با مخاطب، کش و ساختار سایت هماهنگ باشد.
TTFB فقط زمان اجرای برنامه نیست؛ اتصال، شبکه و ریدایرکت هم در آن اثر دارند. برای پاسخ کند، لاگ خطا، درخواستهای سنگین و پایگاه داده را بررسی کنید. پس از اصلاح، همان صفحهها و شرایط قبلی را بسنجید و نتیجه را با دادهٔ تازه گزارش کنید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شدهاند.