ژرف تکنو
سرعت سایت دیگر یک ویژگی لوکس نیست؛ بخشی از تجربهٔ محصول است. کاربری که چند ثانیه منتظر می‌ماند، معمولاً قبل از دیدن محتوا برمی‌گردد و این بازگشت، هم به کسب‌وکار و هم به رتبهٔ صفحه آسیب می‌زند. به همین دلیل گوگل تجربهٔ بارگذاری را با شاخص‌های مشخصی می‌سنجد که به آن‌ها Core Web Vitals می‌گویند.
سه شاخص اصلی امروز عبارت‌اند از LCP، INP و CLS. شاخص LCP می‌گوید بزرگ‌ترین عنصر قابل‌مشاهدهٔ صفحه چه زمانی نمایش داده می‌شود و هدف، زیر دو و نیم ثانیه است. شاخص INP کیفیت پاسخ‌گویی به تعامل‌های کاربر را می‌سنجد و مقدار خوب آن زیر دویست میلی‌ثانیه است. شاخص CLS هم میزان جابه‌جایی ناخواستهٔ عناصر را اندازه می‌گیرد و مقدار خوب آن زیر یک‌دهم است.
یک نکتهٔ مهم روش‌شناسی: دادهٔ میدانی و دادهٔ آزمایشگاهی را با هم اشتباه نگیرید. ابزارهایی مثل Lighthouse روی یک دستگاه و یک شرایط شبکه اجرا می‌شوند و برای تشخیص گلوگاه عالی‌اند، اما قضاوت نهایی باید بر اساس دادهٔ کاربران واقعی باشد. اگر دادهٔ میدانی خوب است ولی آزمایشگاه ضعیف، اولویت اصلاح کمتر می‌شود؛ برعکسش هم صادق است.
برای بهبود LCP، ابتدا مشخص کنید بزرگ‌ترین عنصر صفحه چیست؛ در بیشتر سایت‌ها تصویر هیرو یا تیتر اصلی است. تصویر سنگین، فشرده‌نشده، فونت مسدودکننده و زمان پاسخ کند سرور، رایج‌ترین علت‌ها هستند. استفاده از فرمت‌های AVIF یا WebP، تعیین ابعاد و اندازه‌های واکنش‌گرا، بارگذاری اولویت‌دار تصویر اصلی و کش لبه، معمولاً بیشترین اثر را دارد.
شاخص INP معمولاً قربانی جاوااسکریپت زیاد است. هر اسکریپتی که رشتهٔ اصلی مرورگر را مشغول کند، پاسخ به کلیک و تایپ را عقب می‌اندازد. تقسیم کد، بارگذاری تنبل بخش‌های غیرضروری، حذف کد مرده، انتقال محاسبات سنگین به Web Worker و بازبینی اسکریپت‌های شخص ثالث، از مؤثرترین راه‌هاست. کم‌کردن حجم DOM هم کمک می‌کند، چون رندر و محاسبهٔ چیدمان ارزان‌تر می‌شود.
برای CLS، ریشهٔ مشکل تقریباً همیشه فضای رزرونشده است. تصویری که بدون عرض و ارتفاع مشخص بارگذاری می‌شود، تبلیغی که بالای محتوا تزریق می‌شود یا فونتی که دیر می‌رسد و متن را جابه‌جا می‌کند، باعث پرش می‌شود. تعیین ابعاد تصاویر، رزرو فضا برای اجزای پویا و استفاده از font-display مناسب، این شاخص را به‌سرعت بهتر می‌کند.
سایت‌های فارسی چالش ویژهٔ خودشان را دارند: فونت‌های فارسی سنگین‌اند و اغلب چند وزن از آن‌ها بارگذاری می‌شود. راه‌حل، محدودکردن وزن‌ها به دو یا سه وزن، تبدیل به woff2، زیرمجموعه‌سازی فونت بر اساس حروف مورد استفاده و بارگذاری اولویت‌دار تنها فونت اصلی است. بارگذاری پنج وزن فونت برای یک صفحه، به‌تنهایی می‌تواند LCP را خراب کند.
تصاویر را به‌عنوان بخشی از معماری ببینید، نه فایل ضمیمه. هر تصویر باید اندازهٔ نمایش واقعی داشته باشد، نسخهٔ بزرگ‌تر فقط در صورت نیاز بارگذاری شود و تصاویر پایین صفحه به‌صورت تنبل بیایند. استفاده از تصاویر تزئینی سنگین در بالای صفحه، بدون پیش‌بارگذاری و بهینه‌سازی، یکی از پرهزینه‌ترین اشتباهات رایج است.
معماری تحویل محتوا هم تعیین‌کننده است. تولید ایستا یا بازتولید دوره‌ای صفحات، همراه با کش مرورگر و شبکهٔ توزیع محتوا، زمان پاسخ سرور را به‌شدت کم می‌کند. فشرده‌سازی Brotli، نسخه‌بندی فایل‌های استاتیک و استفاده از HTTP/2 یا HTTP/3 هم در عمل تفاوت محسوسی می‌سازند. اگر سرور هر بار صفحه را از ابتدا بسازد، بهینه‌سازی تصویر تنها نصف راه است.
اندازه‌گیری باید مستمر باشد، نه یک‌باره. دادهٔ میدانی را جمع کنید، آن را به نسخه‌های انتشار و مسیرهای کاربری گره بزنید و برای افت ناگهانی هشدار بگذارید. سرعت، ویژگی‌ای است که با هر قابلیت جدید کمی عقب می‌رود؛ تیمی که فقط هر شش ماه یک‌بار سرعت را می‌سنجد، همیشه در حال تعمیر است، نه پیشگیری.
فراموش نکنید که سرعت لازم است اما کافی نیست. صفحهٔ سریع با محتوای بی‌ارزش رتبه نمی‌گیرد و صفحهٔ کند با محتوای عالی هم فرصت دیده‌شدن را از دست می‌دهد. ساختار معنایی درست، لینک‌سازی داخلی، عنوان و توضیح دقیق و تجربهٔ کاربری روان، در کنار شاخص‌های فنی، تصویر کامل سئو را می‌سازند.
چک‌لیست کوتاه برای شروع: تصویر هیرو را بهینه و اولویت‌دار کنید، فونت‌ها را محدود و فشرده کنید، جاوااسکریپت غیرضروری را حذف یا تنبل کنید، برای همهٔ تصاویر ابعاد تعیین کنید و دادهٔ کاربران واقعی را هفتگی بررسی کنید. همین پنج کار، در بیشتر سایت‌ها بخش عمدهٔ فاصله تا وضعیت مطلوب را پر می‌کند.