Core Web Vitals چیست و چرا مهم است؟
در دنیای وب، تجربه کاربری (UX) حرف اول را می‌زند. گوگل نیز در سال‌های اخیر توجه ویژه‌ای به تجربه کاربر داشته است؛ تا جایی که در سال ۲۰۲۱ سیگنالی به نام (Page Experience) را به‌عنوان یکی از فاکتورهای رتبه‌بندی سایت‌ها معرفی کرد.
بخش اصلی این سیگنال مجموعه‌ای از شاخص‌ها به نام Core Web Vitals (به معنی «معیارهای حیاتی وب») است که کیفیت تجربه کاربر در لحظات حیاتی هنگام بارگذاری و تعامل با صفحه را اندازه‌گیری میکند
این شاخص‌ها در واقع نشان می‌دهند وب‌سایت شما از نظر سرعت و راحتی استفاده تا چه حد بهینه است و گوگل نیز از همین‌ها به‌عنوان یک سیگنال رتبه‌بندی و سئو سایت ها استفاده میکند.
به زبان ساده، Core Web Vitals سه جنبه اساسی از تجربه کاربر را کمّی‌سازی میکند: سرعت بارگذاری صفحه، تعامل‌پذیری و واکنش‌گرایی صفحه، و ثبات بصری محتوا در حین بارگذاری. در ادامه ابتدا این سه معیار را معرفی می‌کنیم، سپس خواهیم دید چرا گوگل این اعداد و آستانه‌ها را برایشان در نظر گرفته است و چگونه می‌توانیم این شاخص‌ها را اندازه‌گیری کرده و بهبود دهیم.
معیارهای اصلی Core Web Vitals
گوگل از میان ده‌ها معیار عملکرد وب، سه مورد را به‌عنوان هسته تجربه کاربری وب برگزیده است. هر کدام از این معیارها جنبه خاصی از تجربه کاربر را می‌سنجند.
Largest Contentful Paint (LCP)
LCP یا زمان بارگذاری بزرگ‌ترین عنصر صفحه معیاری برای سنجش سرعت بارگذاری محتوای اصلی صفحه است. این شاخص مشخص میکند چه مدت طول می‌کشد تا بزرگ‌ترین المان محتوایی قابل مشاهده در صفحه (که معمولاً مهم‌ترین بخش صفحه است) بارگذاری و نمایش داده شودبه عنوان مثال، در یک صفحه محصول فروشگاه آنلاین معمولاً عکس اصلی محصول یا عنوان آن بزرگ‌ترین المان صفحه است و LCP زمان بارگذاری کامل همان عنصر خواهد بود. هرچه LCP کمتر باشد، کاربر سریع‌تر محتوای اصلی را می‌بیند و احساس میکند سایت شما پرسرعت است.
گوگل توصیه میکند LCP صفحات شما در حالت ایده‌آل حداکثر حدود ۲٫۵ ثانیه باشد LCP بیشتر از ۴ ثانیه معمولاً نشان‌دهنده سرعت پایین و تجربه کاربری ضعیف است.
First Input Delay (FID) / Interaction to Next Paint (INP)
FID یا تأخیر در اولین ورودی کاربر معیاری برای سنجش سرعت پاسخ‌دهی صفحه به اولین تعامل کاربر است. فرض کنید کاربر بلافاصله پس از بار شدن صفحه روی دکمه یا لینکی کلیک میکند؛ مدت زمانی که طول می‌کشد مرورگر به این کلیک واکنش نشان دهد (و مثلاً دکمه عمل کند) همان FID است. تجربه کاربری خوب ایجاب میکند این تأخیر بسیار کم باشد (مثلاً زیر ۱۰۰ یا ۲۰۰ میلی‌ثانیه)، در غیر این صورت کاربر احساس کند سایت «کند» است.
هرچند FID سال‌ها به‌عنوان شاخص اصلی سنجش تعامل‌پذیری استفاده می‌شد، اما تنها اولین تعامل را اندازه‌گیری میکند و تعاملات بعدی را نادیده می‌گیرد به همین خاطر گوگل اخیراً شاخص جامع‌تری به نام INP یا Interaction to Next Paint معرفی کرده که تمامی تعاملات کاربر در طول عمر صفحه را زیر نظر می‌گیرد و کندترین واکنش صفحه را گزارش میکند به بیان ساده, INP نشان می‌دهد بدترین تأخیری که کاربر ممکن است در کلیک‌ها، لمس‌ها یا فشار کلیدها تجربه کند چقدر است. این معیار از سال ۲۰۲۴ جایگزین FID به‌عنوان یکی از Core Web Vitals شده است
برای تجربه کاربری مطلوب، مقدار INP یک صفحه باید کمتر از ۰٫۲ ثانیه (۲۰۰ میلی‌ثانیه) باشد مقادیر بالاتر نشانگر آن است که اجرای کدهای JavaScript یا سایر عملیات صفحه آن‌قدر طولانی است که باعث کندی پاسخ به ورودی‌های کاربر می‌شود. (در بخش‌های بعدی خواهیم دید برای بهبود این وضعیت چه باید کرد.)
Cumulative Layout Shift (CLS)
CLS یا تغییر چیدمان تجمعی معیاری برای سنجش میزان پایداری بصری صفحه در حین بارگذاری و نمایش محتوا است حتماً برایتان پیش آمده که مشغول خواندن متنی در صفحه‌اید یا می‌خواهید روی دکمه‌ای کلیک کنید، اما ناگهان با لود شدن یک تصویر یا تبلیغ، چیدمان صفحه به هم می‌ریزد و متن‌ها و دکمه‌ها جابجا می‌شوند. این پدیده همان «پرش محتوا» یا Layout Shift است که می‌تواند تجربه کاربر را خراب کند. شاخص CLS با یک عدد بین ۰ تا ۱ اندازه می‌گیرد که مجموع همه جابجایی‌های غیرمنتظره عناصر صفحه چقدر بوده است. اگر هیچ عنصری جابجا نشود CLS برابر ۰ (عالی) خواهد بود؛ هرچه این عدد به ۱ نزدیک‌تر شود یعنی صفحه بی‌ثبات‌تر بوده است.
برای ارائه تجربه‌ای راحت، صفحات باید CLS کمتر از ۰٫۱ داشته باشند CLS بالاتر از ۰٫۲۵ نشانه بد بودن ثبات صفحه است و احتمالاً کاربران از جابجا شدن ناگهانی محتوا کلافه خواهند شد.
خلاصه آستانه‌های پیشنهادی
گوگل برای هر یک از این سه معیار، سه سطح «خوب»، «نیاز به بهبود» و «ضعیف» تعریف کرده است. جدول زیر خلاصه این آستانه‌ها را نشان می‌دهد
| معیار | خوب (تجربه مطلوب) | نیاز به بهبود | ضعیف (تجربه نامطلوب) |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ ۲٫۵ ثانیه | ۲٫۵ تا ۴٫۰ ثانیه | > ۴٫۰ ثانیه |
| Interaction to Next Paint (INP) | ≤ ۲۰۰ میلی‌ثانیه | ۲۰۰ تا ۵۰۰ میلی‌ثانیه | > ۵۰۰ میلی‌ثانیه |
| Cumulative Layout Shift (CLS) | ≤ ۰٫۱ | ۰٫۱ تا ۰٫۲۵ | > ۰٫۲۵ |
به بیان دیگر، اگر LCP یک صفحه زیر ۲٫۵ ثانیه باشد، از نظر گوگل سریع و خوب تلقی می‌شود؛ اما بالاتر از ۴ ثانیه کند محسوب شده و تأثیر منفی دارد. بازه بین ۲٫۵ تا ۴ ثانیه «قابل قبول اما جای کار دارد» در نظر گرفته می‌شود برای INP تأخیر کمتر از ۰٫۲ ثانیه عالی است و بیشتر از ۰٫۵ ثانیه بسیار بد و در مورد CLS، صفحه‌ای که مجموع پرش‌های layout آن زیر ۰٫۱ باشد پایدار است، اما اگر بالای ۰٫۲۵ باشد به‌شدت ناپایدار تلقی می‌شود
نکته مهم این است که ارزیابی این شاخص‌ها بر اساس بدترین تجربه‌های کاربر (در حد معقول) انجام می‌شود. به طور مشخص، گوگل معیار را این‌طور تعریف کرده که ۷۵٪ بازدیدهای یک صفحه باید به آستانه «خوب» برسند تا آن صفحه از نظر آن شاخص خوب محسوب شود مثلاً اگر ۷۵ درصد کاربران شما LCP زیر ۲٫۵ ثانیه را تجربه کنند، آنگاه صفحه شما از نظر LCP یک صفحه سریع به حساب می‌آید.
اما اگر حداقل ۲۵٪ از بازدیدها وضعیت «ضعیف» داشته باشند، آن صفحه در آن شاخص ضعیف ارزیابی می‌شود به این ترتیب چند بارگیری کند و استثنائی (Outlier) باعث نمی‌شود کل امتیاز صفحه خراب شود ولی در عین حال یک سایت زمانی واقعاً «سریع» تلقی خواهد شد که در اغلب بازدیدها سریع باشد نه فقط گاهی اوقات.
همچنین این آستانه‌ها برای همه دستگاه‌ها یکسان هستند و بین موبایل و دسکتاپ فرق ندارند شاید تعجب کنید چون معمولاً بارگذاری در موبایل کندتر است، اما گوگل اعتقاد دارد انتظار کاربران برای یک تجربه خوب در همه دستگاه‌ها مشابه است و برای ساده‌تر شدن گزارش‌دهی، تصمیم گرفته از یک استاندارد واحد استفاده کند
چرا این آستانه‌ها تعیین شده‌اند؟
ممکن است بپرسید گوگل این اعداد را بر چه اساسی انتخاب کرده است؟ مثلاً چرا ۲٫۵ ثانیه برای LCP خوب است و نه ۳ ثانیه یا ۲ ثانیه؟ پشت تعیین این آستانه‌ها تحقیق و تحلیل زیادی از داده‌های واقعی کاربری نهفته است هدف گوگل این بوده که:
- تجربه کاربری «خوب» واقعاً نمایانگر تجربه‌ای عالی باشد. به عبارتی سایتی که به محدوده سبز (خوب) می‌رسد، اکثریت کاربرانش از سرعت و کیفیت آن رضایت داشته باشند
- آستانه‌ها دست‌یافتنی باشند. یعنی فقط تعداد بسیار کمی از سایت‌های ایده‌آل نتوانند به آن برسند. به عنوان مثال، برای تعیین ۲٫۵ ثانیه به عنوان حد خوب LCP، داده‌های کروم نشان دادند که اگر معیار سخت‌گیرانه‌تری مثل ۲ ثانیه بگذاریم، درصد بسیار پایینی از سایت‌ها (شاید زیر ۱۰٪) قادر به کسب آن خواهند بود که واقع‌بینانه نیست . در حالی که ۲٫۵ ثانیه را درصد قابل‌قبولی از سایت‌ها می‌توانند به آن دست یابند و با بهبودهایی خود را به آن حد برسانند .
- اعداد تا حد ممکن با تجربه کاربر عادی هم‌خوانی داشته باشند. یعنی چیزی نباشد که فقط ابزارهای اندازه‌گیری متوجه آن شوند اما کاربر واقعی نه. مثلاً اگر صفحه‌ای LCP حدود ۳ ثانیه دارد، احتمالاً کاربر عادی آن را «خوب ولی نه خیلی سریع» تلقی میکند؛ به همین خاطر در بازه میانی (Needs Improvement) قرار می‌گیرد نه کاملاً خوب. ولی LCP پنج ثانیه به وضوح برای همه کند است و باید ضعیف در نظر گرفته شود.
با چنین ملاحظاتی، تیم کروم و گوگل صدها میلیون داده واقعی (گزارش تجربه کاربر کروم) را بررسی کردند و با آزمون سناریوهای مختلف، این اعداد (۲٫۵ ثانیه، ۰٫۱، ۲۰۰ میلی‌ثانیه و غیره) را به عنوان نقاط مرزی تعیین نمودند . البته این آستانه‌ها ممکن است در آینده با تغییر تکنولوژی و توقعات کاربران به‌روزرسانی شوند (همان‌طور که FID و INP جابجا شدند).
چگونه Core Web Vitals را اندازه‌گیری کنیم؟
حال که با این شاخص‌ها آشنا شدیم، سؤال مهم این است: چطور بفهمیم وضعیت سایت ما از نظر Core Web Vitals چگونه است؟ و اگر مشکلی وجود دارد، کجا باید دنبال علت بگردیم؟ برای این کار ابزارها و روش‌های متعددی وجود دارد که به دو دسته کلی تقسیم می‌شوند:
- داده‌های میدانی (Field Data): که از کاربران واقعی سایت شما جمع‌آوری می‌شود (اصطلاحاً RUM یا Real User Monitoring). این همان داده‌هایی است که گوگل نیز برای رتبه‌بندی از آن استفاده میکند ، چون منعکس‌کننده تجربه واقعی کاربران در شرایط متنوع (دستگاه‌ها، سرعت اینترنت، موقعیت جغرافیایی و غیره) است.
- داده‌های آزمایشگاهی (Lab Data): که از طریق تست‌های شبیه‌سازی شده در یک محیط کنترل‌شده به دست می‌آید. این روش توسط ابزارهای تست سرعت (مانند Lighthouse) انجام می‌شود و برای اشکال‌یابی و بهبود عملکرد مفید است، زیرا می‌توانیم در یک محیط ثابت (مثلاً مرورگر دسکتاپ با اینترنت 3G) صفحه را بارها تست کنیم و مشکلات را تحلیل کنیم.
هر کدام از این دو رویکرد مزایا و محدودیت‌هایی دارند. داده‌های واقعی (میدانی) تصویر دقیق‌تری از تجربه کاربر می‌دهد، اما همیشه به‌سرعت در دسترس نیست (مثلاً باید منتظر بمانید کاربران واقعی به صفحه شما مراجعه کنند و داده جمع شود). از سوی دیگر، تست‌های آزمایشگاهی را هر زمان بخواهید می‌توانید انجام دهید، اما نتایج آن ممکن است با واقعیت کاربر نهایی کمی تفاوت داشته باشد . بهترین حالت این است که هر دو نوع داده را جمع‌آوری کنید تا هم تصویری کلی از وضعیت سایت در دنیای واقعی داشته باشید و هم بتوانید در محیط آزمایشی تغییرات را سریع ارزیابی کنید .
در ادامه چند ابزار مهم برای دسترسی به این داده‌ها را معرفی می‌کنیم.
ابزارهای مبتنی بر داده‌های واقعی (RUM)
اگر هنوز سیستمی برای جمع‌آوری داده‌های میدانی کاربران واقعی خود ندارید، گوگل ابزارهای رایگانی فراهم کرده است که با کمک آنها می‌توانید به‌سرعت وضعیت Core Web Vitals سایتتان را بر اساس داده‌های واقعی ببینید :
Google Search Console (گزارش تجربه صفحه): اگر مالک سایت هستید، کنسول جستجوی گوگل بخشی به نام «Core Web Vitals» یا «تجربه صفحه» دارد که عملکرد صفحات سایت شما را بر اساس داده‌های ۲۸ روز گذشته‌ی کاربران واقعی گزارش میکند. این گزارش صفحات را در هر یک از سه شاخص LCP، INP و CLS به سه دسته «خوب»، «نیاز به بهبود» و «ضعیف» گروه‌بندی میکند و به شما نشان می‌دهد کدام صفحات نیازمند توجه هستند . توجه داشته باشید که این گزارش فقط برای سایت‌هایی قابل استفاده است که مالکیت آنها را در سرچ کنسول تأیید کرده باشید .
PageSpeed Insights (بینش سرعت صفحه): ابزار آنلاین گوگل که با وارد کردن آدرس صفحه‌ی موردنظر، گزارش کاملی از وضعیت عملکرد آن ارائه می‌دهد . PSI دو نوع داده نشان می‌دهد: داده‌های میدانی ۲۸ روز گذشته آن صفحه (از کروم) و داده‌های آزمایشگاهی آن صفحه (از Lighthouse) همراه با پیشنهادهایی برای بهبود. به عبارتی PageSpeed Insights هم‌زمان هم یک ابزار RUM است و هم Lab. (PSI علاوه بر وب‌سایت، از طریق API نیز قابل استفاده است .)
گزارش تجربه کاربر کروم (CrUX): مجموعه داده‌های عمومی گوگل از عملکرد میلیون‌ها سایت در کروم. ابزارهای مختلفی بر پایه این داده‌ها وجود دارند؛ از جمله CrUX Dashboard (یک داشبورد آماده در گوگل دیتا استودیو) که با چند کلیک می‌توانید روند تاریخی عملکرد سایت خود را در آن ببینید . همچنین مرورگر کروم در بخش DevTools خود (تب Performance) یک نمای زنده از web.devدارد که وضعیت صفحه فعلی را با داده‌های میدانی همان صفحه مقایسه میکند.
ابزارهای آزمایشگاهی (Lab)
برای بررسی عمیق‌تر و Debug کردن مشکلات عملکردی، استفاده از تست‌های آزمایشگاهی ضروری است. ابزارهای زیر از جمله معروف‌ترین‌ها هستند:
WebPageTest: یک پلتفرم آنلاین محبوب برای تست سرعت صفحات با جزئیات بسیار بالا. WebPageTest نیز در نتایج خود Core Web Vitals (از جمله CLS و LCP) را گزارش میکند و امکاناتی مثل انتخاب مکان جغرافیایی، سرعت شبکه و دستگاه‌های مختلف برای تست دارد. این ابزار برای بررسی شرایط خاص (مثلاً سرعت خیلی پایین شبکه یا موبایل قدیمی) و دیدن waterfall دقیق درخواست‌ها بسیار کاربردی است.
Chrome DevTools (تب Performance): مرورگر کروم دارای ابزار داخلی توسعه‌دهنده است که در تب Performance می‌تواند هنگام بارگذاری صفحه، شاخص‌های Core Web Vitals همان بار را اندازه‌گیری و نمایش دهد. این برای آزمایش سریع بسیار مفید است؛ مثلاً می‌توانید تغییرات کد خود را انجام دهید و بلافاصله ببینید LCP بهتر شد یا نه. DevTools همچنین در گزارش Performance خود بخش “Web Vitals” دارد که به‌صورت گرافیکی نشان می‌دهد آیا LCP/CLS/TBT (معادل آزمایشگاهی INP) در محدوده خوب بودند یا خیر.
Lighthouse: لایت‌هاوس موتور اصلی پشت بسیاری از ابزارهای تست سرعت (از جمله PSI) است. شما می‌توانید Lighthouse را از طریق DevTools، یا به‌صورت یک افزونه npm، و حتی در خط فرمان (Lighthouse CI) اجرا کنید. خروجی Lighthouse یک گزارش جامع از انواع معیارهای عملکردی است. توجه داشته باشید که Lighthouse در حال حاضر به‌جای INP، شاخص Total Blocking Time (TBT) را گزارش میکند که در محیط آزمایشگاهی نمایانگر میزان بلاک شدن واکنش صفحه توسط اسکریپت‌هاست . TBT در واقع جایگزین آزمایشگاهی INP محسوب می‌شود ، چون INP نیازمند تعاملات کاربر واقعی است و در تست خودکار قابل اندازه‌گیری مستقیم نیست.
چگونه امتیاز Core Web Vitals را بهبود دهیم؟
پس از شناسایی نقاط ضعف سایت در هر یک از این شاخص‌ها، گام بعدی بهبود آنهاست. بهبود Core Web Vitals به معنی بهبود تجربه کاربران شماست و قطعاً پاداشش رضایت کاربران و رتبه بهتر در گوگل خواهد بود. در این بخش راهکارهای کلی برای بهبود هر سه حوزه اصلی (سرعت بارگذاری، سرعت واکنش‌گرایی، و ثبات بصری) را مرور می‌کنیم:
بهبود سرعت بارگذاری (LCP)
هدف ما کاهش زمان LCP است تا کاربر سریع‌تر محتوای اصلی را ببیند. اقدامات زیر می‌تواند به این امر کمک کند:
- بهینه‌سازی سرور و شبکه: سرعت پاسخ‌دهی سرور را بالا ببرید. این کار با استفاده از هاست قوی‌تر، به‌کارگیری شبکه توزیع محتوا (CDN) و فعال‌سازی کش (Cache) امکان‌پذیر است .
- حذف یا کاهش منابع مسدودکننده رندر: فایل‌های حجیم CSS و JavaScript که بارگذاری صفحه را متوقف می‌کنند شناسایی و حذف یا بهینه کنید . مثلاً CSSهای استفاده‌نشده را پاک کنید، JavaScriptهای غیرضروری را حذف کنید، یا اسکریپت‌ها را تا حد امکان به حالت async/defer اجرا کنید تا جلوی رندر گرفته نشود.
- بهینه‌سازی محتوای اصلی صفحه: تصاویر را فشرده و کم‌حجم کنید و در صورت امکان از فرمت‌های جدیدتر (مانند WebP) استفاده کنید . محتوای متن را نیز فشرده‌سازی (Gzip/Brotli) کنید. همچنین می‌توانید از تکنیک‌هایی مثل preload برای لود سریع‌تر منابع اصلی (مثل تصویر بزرگ صفحه) بهره ببرید.
بهبود تعامل‌پذیری و سرعت واکنش (FID/INP)
برای اینکه کاربر در هنگام کلیک یا تعامل با صفحه با تأخیر مواجه نشود، باید جلوی بلاک شدن نخ اصلی مرورگر را بگیریم. مهم‌ترین راهکارها در این زمینه عبارتند از :
- شکستن وظایف سنگین به بخش‌های کوچک‌تر: اگر صفحه شما اسکریپت بسیار سنگینی اجرا میکند که مثلاً ۲ ثانیه CPU را مشغول میکند، کاربر تا پایان آن کار نمی‌تواند با صفحه تعامل کند. آن کار را به قسمت‌های کوچک‌تر تقسیم کنید تا بین آنها مرورگر فرصت رسیدگی به ورودی‌های کاربر را داشته باشد .
- بهینه کردن کدهای جاوااسکریپت: کدهای JS را طوری بهینه کنید که سریع‌تر اجرا شوند و از انجام کارهای غیرضروری بپرهیزند . به‌خصوص از انجام عملیات حجیم در هنگام لود اولیه صفحه خودداری کنید و آنها را به تعویق بیندازید (lazy-load) تا زمان تعاملی شدن صفحه زودتر برسد.
- استفاده از Web Workerها: وب‌ورکرها به شما اجازه می‌دهند برخی محاسبات سنگین را از نخ اصلی جدا کنید تا اجرای آنها باعث کندی رابط کاربری نشود .
- کاهش تاثیر کدهای شخص ثالث: اسکریپت‌های خارجی (مانند سرویس‌های آنالیتیکس، تبلیغات، و …) می‌توانند تأخیر ایجاد کنند. فقط از اسکریپت‌های ضروری استفاده کنید و نسخه بهینه آنها را به‌کار گیرید.
- افزایش سرعت واکنش به ورودی‌ها: اطمینان حاصل کنید که تمام رویدادهای کاربر (click, tap, keypress) به سریع‌ترین شکل پردازش می‌شوند. توابع handler را سبک و ساده نگه دارید تا سریعا اجرا شوند و تغییرات DOM ناشی از تعامل را به حداقل برسانید .
بهبود ثبات بصری (CLS)
برای جلوگیری از پرش و جابجایی محتوا در حین بارگذاری، می‌توان اقدامات زیر را انجام داد :
- تعیین ابعاد ثابت برای تصاویر و ویدیوها: همیشه برای المان‌های رسانه‌ای (img, video, canvas و …)، عرض و ارتفاع (یا نسبت ابعاد) مشخصی در HTML/CSS تعریف کنید تا مرورگر از قبل فضا را رزرو کند . این کار جلوی پریدن صفحه هنگام لود آن رسانه را می‌گیرد.
- رزرو فضا برای تبلیغات و المان‌های جاسازی‌شده: اگر از تبلیغات یا iframe استفاده می‌کنید، برای آنها یک جایگاه با اندازه مشخص در نظر بگیرید . به این ترتیب وقتی محتوای تبلیغ بارگذاری می‌شود، سایر اجزا جابجا نخواهند شد.
- اجتناب از درج محتوا به صورت ناگهانی بالای محتوای موجود: هر محتوای جدیدی که بعد از load اولیه اضافه می‌شود (مثلاً یک نوار اطلاع‌رسانی، فرم عضویت، محصولات پیشنهادی و غیره) را در انتهای صفحه یا در یک فضای از پیش‌تعریف‌شده قرار دهید، مگر اینکه کاربر با یک اقدام (مثل کلیک) آن را فراخوانی کرده باشد. اضافه کردن عناصر در بالای صفحه بدون اطلاع قبلی قطعاً باعث جابجایی سایر بخش‌ها می‌شود.
- پیش‌بارگذاری فونت‌های وب یا استفاده از سیستم‌فونت‌ها: تغییر فونت پس از بارگذاری متن می‌تواند باعث تغییر اندازه حروف و در نتیجه تغییر مکان متن شود. برای جلوگیری از این اتفاق می‌توانید فونت‌های وب را زودتر (با priority بالا) لود کنید یا از فونت‌های پیش‌فرض سیستم استفاده کنید تا صفحه با همان فونت نهایی رندر شود و نیازی به تغییر نداشته باشد.
با پیاده‌سازی موارد بالا، احتمال زیادی دارد که امتیاز Core Web Vitals سایت شما بهبود چشمگیری پیدا کند. البته بهینه‌سازی عملکرد وب یک فرآیند مستمر است؛ توصیه می‌شود پس از اعمال تغییرات، مجدداً با ابزارهایی که معرفی شد شاخص‌ها را اندازه‌گیری کنید تا اثر بهبودها را بسنجید. همچنین همواره خود را به‌روز نگه دارید؛ چرا که همان‌طور که گوگل اعلام کرده، امکان دارد در آینده معیارهای جدیدی به Core Web Vitals اضافه شوند یا استاندارد «خوب» و «ضعیف» تغییر کند. با این حال، فلسفه کلی روشن است: سایتی موفق است که برای کاربرانش سریع، واکنش‌گرا و پایدار باشد.