وقتی درباره سرعت سایت صحبت می‌کنیم، بسیاری از افراد فقط به این سؤال توجه می‌کنند که «صفحه در چند ثانیه باز می‌شود؟». اما تجربه واقعی کاربر بسیار پیچیده‌تر از یک عدد ساده برای سرعت بارگذاری است.
ممکن است یک صفحه در ظاهر سریع باز شود، اما تصویر اصلی آن دیر نمایش داده شود. ممکن است محتوای صفحه تقریباً کامل بارگذاری شده باشد، اما وقتی کاربر روی یک دکمه کلیک می‌کند، سایت برای چند لحظه هیچ واکنشی نشان ندهد. حتی ممکن است صفحه سریع نمایش داده شود، اما هنگام بارگذاری تبلیغات، فونت‌ها یا تصاویر، عناصر صفحه ناگهان جابه‌جا شوند و کاربر به‌اشتباه روی گزینه دیگری کلیک کند.
Core Web Vitals برای اندازه‌گیری همین بخش‌های مهم تجربه واقعی کاربر طراحی شده‌اند.
Core Web Vitals مجموعه‌ای از معیارهای عملکردی هستند که سه جنبه مهم تجربه کاربر یعنی سرعت نمایش محتوا، پاسخ‌گویی صفحه و ثبات بصری را بررسی می‌کنند. معیارهای اصلی فعلی این مجموعه عبارت‌اند از:
- LCP (Largest Contentful Paint) برای سنجش سرعت نمایش محتوای اصلی
- INP (Interaction to Next Paint) برای سنجش پاسخ‌گویی صفحه به تعاملات کاربر
- CLS (Cumulative Layout Shift) برای سنجش ثبات بصری صفحه
گوگل توصیه می‌کند سایت‌ها این معیارها را در محدوده مناسب قرار دهند؛ اما نکته مهم این است که Core Web Vitals یک «نمره واحد» نیست و رسیدن به یک امتیاز سبز در یک تست آزمایشگاهی نیز به‌تنهایی به معنی عملکرد مناسب سایت برای همه کاربران نیست.
برای بهبود واقعی Core Web Vitals باید بدانیم مشکل دقیقاً کجاست، چه چیزی باعث آن شده، آیا مشکل در داده‌های واقعی کاربران نیز دیده می‌شود، کدام تغییر فنی باید انجام شود و چگونه باید نتیجه را دوباره اندازه‌گیری کنیم.
در این راهنمای جامع، Core Web Vitals را از تعریف و معیارهای استاندارد تا روش اندازه‌گیری، عیب‌یابی و بهینه‌سازی عملی بررسی می‌کنیم؛ به‌خصوص برای سایت‌های وردپرسی.
Core Web Vitals چیست؟
Core Web Vitals یا شاخص‌های حیاتی وب مجموعه‌ای از معیارهای گوگل برای اندازه‌گیری بخش‌های مهم تجربه واقعی کاربران هنگام استفاده از صفحات وب هستند.
این معیارها صرفاً حجم صفحه، تعداد فایل‌ها یا زمان کامل دانلود همه منابع را بررسی نمی‌کنند؛ بلکه تلاش می‌کنند اتفاقی را که کاربر هنگام باز کردن و استفاده از صفحه تجربه می‌کند، به شاخص‌های قابل اندازه‌گیری تبدیل کنند.
سه سؤال اصلی Core Web Vitals این‌ها هستند:
محتوای اصلی صفحه چه زمانی برای کاربر قابل مشاهده می‌شود؟
این موضوع توسط LCP اندازه‌گیری می‌شود.
وقتی کاربر با صفحه تعامل می‌کند، مرورگر با چه سرعتی واکنش نشان می‌دهد؟
این موضوع توسط INP اندازه‌گیری می‌شود.
آیا عناصر صفحه در هنگام بارگذاری یا استفاده کاربر بدون دلیل جابه‌جا می‌شوند؟
این موضوع توسط CLS اندازه‌گیری می‌شود.
در نتیجه می‌توان Core Web Vitals را سه ضلع مهم عملکرد تجربه کاربری دانست:
Loading + Responsiveness + Visual Stability
یا به زبان ساده:
سرعت نمایش محتوا + سرعت واکنش سایت + ثبات صفحه
نکته مهم این است که معیارهای Core Web Vitals ثابت و همیشگی نیستند و ممکن است گوگل با تغییر فناوری وب و روش‌های اندازه‌گیری، معیارهای مورد استفاده را در آینده تغییر دهد. در حال حاضر LCP، INP و CLS سه معیار اصلی این مجموعه هستند.
معیارهای Core Web Vitals کدامند؟
1. LCP چیست؟
LCP مخفف Largest Contentful Paint است و سرعت نمایش بزرگ‌ترین عنصر محتوایی قابل مشاهده در viewport را اندازه‌گیری می‌کند.
این عنصر بسته به نوع صفحه می‌تواند یک تصویر اصلی، تصویر Hero، ویدئو، بلوک متنی بزرگ یا عنصر محتوایی مهم دیگری باشد.
هدف LCP این است که مشخص کند کاربر چه زمانی می‌تواند بخش اصلی و قابل توجه صفحه را مشاهده کند. بنابراین LCP با «زمان کامل شدن بارگذاری تمام صفحه» یکسان نیست.
برای تجربه کاربری خوب، مقدار LCP باید حداکثر حدود ۲.۵ ثانیه باشد. بازه ۲.۵ تا ۴ ثانیه نیازمند بهبود است و مقدار بیشتر از ۴ ثانیه در محدوده ضعیف قرار می‌گیرد. این ارزیابی در داده‌های میدانی معمولاً در صدک ۷۵ و به تفکیک موبایل و دسکتاپ بررسی می‌شود.
LCP دقیقاً چه چیزی را اندازه می‌گیرد؟
LCP فاصله زمانی از شروع بارگذاری صفحه تا زمانی را اندازه می‌گیرد که بزرگ‌ترین عنصر محتوایی قابل مشاهده، در وضعیت مناسب برای نمایش کاربر قرار می‌گیرد.
برای مثال فرض کنید صفحه اصلی یک سایت یک تصویر بزرگ Hero دارد. اگر سرور دیر پاسخ دهد، مرورگر منابع CSS را دیر دریافت کند یا تصویر اصلی دیر دانلود شود، LCP افزایش پیدا می‌کند.
بنابراین برای تحلیل LCP نباید فقط خود تصویر را بررسی کرد؛ باید کل زنجیره بارگذاری از درخواست کاربر تا نمایش عنصر LCP بررسی شود.
چرا LCP سایت بالا است؟
- پاسخ‌گویی کند سرور و TTFB بالا
- تصویر LCP با حجم یا ابعاد نامناسب
- منابع Render-Blocking
- CSS بیش از حد و غیرضروری
- JavaScript سنگین در مرحله اولیه بارگذاری
- فونت‌های سنگین یا نحوه بارگذاری نامناسب فونت
- شبکه یا فاصله زیاد میان کاربر و سرور
- پیکربندی نامناسب Cache یا CDN
- ریدایرکت‌های غیرضروری
2. INP چیست؟
INP مخفف Interaction to Next Paint است و پاسخ‌گویی صفحه به تعاملات کاربر را بررسی می‌کند.
تعامل می‌تواند شامل کلیک روی یک دکمه، لمس صفحه، انتخاب یک گزینه، باز کردن منو، افزودن محصول به سبد خرید یا تایپ در یک فیلد باشد.
تفاوت مهم INP با FID این است که FID فقط تأخیر اولین تعامل را بررسی می‌کرد، اما INP پاسخ‌گویی صفحه را در طول چرخه تعامل کاربر با صفحه مورد توجه قرار می‌دهد. به همین دلیل برای سایت‌های تعاملی معیار مناسب‌تری برای بررسی پاسخ‌گویی کلی صفحه است.
برای تجربه کاربری خوب، مقدار INP باید کمتر از ۲۰۰ میلی‌ثانیه باشد. مقدار بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه نیازمند بهبود و بیشتر از ۵۰۰ میلی‌ثانیه ضعیف محسوب می‌شود.
یک مثال برای درک INP
فرض کنید در یک فروشگاه اینترنتی روی دکمه «افزودن به سبد خرید» کلیک می‌کنید.
اگر دکمه بلافاصله واکنش نشان دهد و وضعیت سبد خرید تغییر کند، تعامل سریع احساس می‌شود. اما اگر روی دکمه کلیک کنید و برای مدتی هیچ اتفاقی رخ ندهد و بعد از چند لحظه صفحه واکنش نشان دهد، کاربر احساس می‌کند سایت کند یا حتی خراب است.
INP دقیقاً به همین بخش از تجربه کاربر توجه می‌کند.
چه چیزهایی INP را بد می‌کنند؟
- JavaScriptهای سنگین
- Long Taskهای طولانی روی Main Thread
- پردازش پیچیده هنگام کلیک یا تایپ
- Event Handlerهای ناکارآمد
- اسکریپت‌های Third-Party
- پردازش‌های سنگین سمت مرورگر
- رندر مجدد زیاد عناصر صفحه
- افزونه‌ها یا کتابخانه‌هایی که کدهای غیرضروری اجرا می‌کنند
آیا TBT همان INP است؟
خیر. TBT یا Total Blocking Time با INP یکی نیست، اما در محیط‌های آزمایشگاهی می‌تواند به‌عنوان یک شاخص کمکی برای شناسایی مشکلات JavaScript و مسدود شدن Main Thread استفاده شود.
INP به تعامل واقعی کاربر نیاز دارد و بنابراین در داده‌های واقعی کاربران اهمیت ویژه‌ای دارد. در مقابل، ابزارهای Lab مانند Lighthouse نمی‌توانند INP واقعی کاربر را اندازه‌گیری کنند و برای عیب‌یابی پاسخ‌گویی در محیط آزمایشگاهی، TBT را به‌عنوان یک معیار کمکی در نظر می‌گیرند.
3. CLS چیست؟
CLS مخفف Cumulative Layout Shift است و ثبات بصری صفحه را اندازه‌گیری می‌کند.
فرض کنید در حال خواندن یک مقاله هستید و ناگهان تبلیغی در بالای صفحه ظاهر می‌شود و متن را به پایین منتقل می‌کند. یا می‌خواهید روی دکمه «خرید» کلیک کنید اما درست در همان لحظه تصویر یا بنری بارگذاری می‌شود و دکمه جابه‌جا می‌شود.
این اتفاق‌ها نمونه‌هایی از Layout Shift هستند.
برای تجربه کاربری خوب، CLS باید کمتر از ۰.۱ باشد. مقدار بین ۰.۱ تا ۰.۲۵ نیازمند بهبود و بیشتر از ۰.۲۵ ضعیف محسوب می‌شود. CLS برخلاف LCP و INP واحد زمانی ندارد و یک امتیاز مربوط به میزان جابه‌جایی غیرمنتظره عناصر صفحه است.
جدول استاندارد Core Web Vitals
| معیار | چه چیزی را اندازه می‌گیرد؟ | خوب | نیازمند بهبود | ضعیف |
|---|---|---|---|---|
| LCP | سرعت نمایش بزرگ‌ترین محتوای قابل مشاهده | ≤ 2.5s | 2.5s تا 4s | > 4s |
| INP | پاسخ‌گویی صفحه به تعاملات کاربر | < 200ms | 200ms تا 500ms | > 500ms |
| CLS | ثبات بصری و میزان جابه‌جایی غیرمنتظره | < 0.1 | 0.1 تا 0.25 | > 0.25 |
در ارزیابی داده‌های واقعی، وضعیت Core Web Vitals معمولاً بر اساس صدک ۷۵ بررسی می‌شود و بهتر است موبایل و دسکتاپ جداگانه تحلیل شوند. به همین دلیل میانگین ساده اعداد همیشه تصویر دقیقی از تجربه کاربران ارائه نمی‌دهد.
صدک ۷۵ در Core Web Vitals یعنی چه؟
یکی از اشتباهات رایج این است که مالک سایت تصور کند اگر چند کاربر تجربه بسیار خوبی داشته باشند، وضعیت Core Web Vitals نیز خوب خواهد بود.
گوگل برای ارزیابی داده‌های میدانی از صدک ۷۵ استفاده می‌کند. به زبان ساده، به‌جای اینکه فقط بهترین یا بدترین تجربه را ببینیم، عملکرد بخش عمده کاربران بررسی می‌شود.
این موضوع اهمیت زیادی دارد؛ زیرا ممکن است سایت شما روی کامپیوتر شخصی بسیار سریع باشد، اما تعداد قابل توجهی از کاربران با گوشی‌های ضعیف‌تر، پردازنده‌های محدودتر یا شبکه‌های متفاوت تجربه کندتری داشته باشند.
به همین دلیل نباید فقط بر اساس تجربه شخصی خودتان بگویید «سایت سریع است»؛ باید داده کاربران واقعی را نیز بررسی کنید.
چرا Core Web Vitals اهمیت دارد؟
اهمیت Core Web Vitals فقط به سئو محدود نمی‌شود.
کاربری که با سایتی مواجه می‌شود که دیر محتوای اصلی را نمایش می‌دهد، هنگام کلیک پاسخ نمی‌دهد یا عناصر صفحه مدام جابه‌جا می‌شوند، تجربه خوبی نخواهد داشت.
این موضوع در سایت‌های فروشگاهی، خدماتی، خبری و تجاری اهمیت بیشتری دارد؛ زیرا هر تأخیر یا اختلال می‌تواند مسیر کاربر تا انجام یک اقدام مانند خرید، ارسال فرم یا تماس را دشوارتر کند.
از نگاه گوگل نیز Core Web Vitals بخشی از ارزیابی تجربه صفحه است. با این حال، نباید تصور کرد که صرفاً با سبز شدن Core Web Vitals رتبه سایت در نتایج جست‌وجو تضمین می‌شود. گوگل صراحتاً این معیارها را در کنار سایر عوامل تجربه صفحه و سیستم‌های رتبه‌بندی در نظر می‌گیرد.
بنابراین هدف اصلی باید ساخت یک سایت سریع، پایدار و پاسخ‌گو برای انسان‌ها باشد، نه صرفاً گرفتن یک نمره بالا در ابزارهای تست.
Core Web Vitals چه ارتباطی با سئو دارد؟
Core Web Vitals بخشی از سیگنال‌های مرتبط با تجربه صفحه در جست‌وجوی گوگل است. اما این موضوع به معنی آن نیست که Core Web Vitals جایگزین کیفیت محتوا، ارتباط موضوعی، اعتبار سایت یا سایر اصول سئو می‌شود.
به بیان ساده، اگر دو سایت از نظر محتوا و سایر عوامل شرایط متفاوتی داشته باشند، نمی‌توان فقط با نگاه کردن به LCP یا CLS نتیجه گرفت کدام صفحه حتماً رتبه بالاتری خواهد داشت.
بهینه‌سازی Core Web Vitals بهتر است بخشی از یک برنامه جامع باشد:
محتوای مفید + معماری مناسب + قابلیت دسترسی + ساختار فنی صحیح + تجربه کاربری + عملکرد مناسب + سایر عوامل سئو
بنابراین بهینه‌سازی سرعت جایگزین سئو نیست؛ بلکه یکی از بخش‌های ساخت یک سایت بهتر است.
تفاوت داده‌های Field و Lab در Core Web Vitals چیست؟
اگر فقط یک موضوع را از این مقاله به خاطر بسپارید، بهتر است همین تفاوت باشد. بسیاری از اختلاف‌هایی که بین گزارش PageSpeed، تجربه واقعی کاربران و گزارش Search Console مشاهده می‌شود، از تفاوت داده‌های Field و Lab ناشی می‌شود.
داده Field یا داده واقعی کاربران چیست؟
Field Data از تجربه کاربران واقعی به دست می‌آید. یکی از مهم‌ترین منابع این داده‌ها Chrome User Experience Report یا CrUX است.
در داده‌های واقعی، شرایط کاربران یکسان نیست. دستگاه‌ها، سرعت شبکه، موقعیت جغرافیایی، قدرت پردازنده و وضعیت کش مرورگر می‌توانند متفاوت باشند. به همین دلیل Field Data تصویر واقعی‌تری از تجربه کاربران ارائه می‌کند.
Lab Data چیست؟
Lab Data در یک محیط آزمایشگاهی و کنترل‌شده تولید می‌شود. ابزارهایی مانند Lighthouse برای شبیه‌سازی بارگذاری صفحه و پیدا کردن مشکلات عملکردی بسیار مفید هستند.
مزیت Lab Data این است که برای عیب‌یابی مناسب است. می‌توانید یک تغییر را اعمال کنید، دوباره تست بگیرید و تأثیر آن را سریع مشاهده کنید.
اما Lab Data لزوماً نشان‌دهنده تجربه تمام کاربران واقعی نیست.
Field و Lab را چگونه در کنار هم استفاده کنیم؟
یک رویکرد حرفه‌ای این است:
- Field Data برای فهمیدن اینکه کاربران واقعی چه تجربه‌ای دارند.
- Lab Data برای پیدا کردن علت‌های احتمالی و آزمودن تغییرات.
این دو داده رقیب یکدیگر نیستند؛ مکمل یکدیگرند.
برای مثال ممکن است Lighthouse نشان دهد صفحه شما عملکرد خوبی دارد، اما داده‌های واقعی کاربران موبایل نشان دهند LCP همچنان ضعیف است. در این حالت باید بررسی کنید کاربران واقعی با چه دستگاه‌ها و شرایط شبکه‌ای وارد سایت می‌شوند و آیا مشکل در سطح یک الگوی صفحه یا زیرساخت وجود دارد.
چگونه Core Web Vitals سایت را بررسی کنیم؟
PageSpeed Insights
Google PageSpeed Insights یکی از کاربردی‌ترین ابزارها برای شروع بررسی عملکرد یک صفحه است.
URL صفحه را وارد کنید و ابتدا به بخش داده‌های واقعی کاربران توجه کنید. سپس سراغ داده‌های آزمایشگاهی و بخش Diagnostics بروید.
در بررسی PageSpeed فقط به عدد Performance نگاه نکنید. ابتدا مشخص کنید کدام Core Web Vital مشکل دارد و سپس علت احتمالی را در گزارش‌های فنی پیدا کنید.
Google Search Console
در Search Console گزارش Core Web Vitals کمک می‌کند وضعیت صفحات سایت را بر اساس داده‌های کاربران واقعی بررسی کنید.
مزیت مهم Search Console این است که مشکل را فقط در یک URL نشان نمی‌دهد؛ می‌تواند گروهی از صفحات با الگوی عملکرد مشابه را مشخص کند.
اگر صدها صفحه یک سایت روی موبایل LCP ضعیفی داشته باشند، احتمال دارد مشکل از قالب، سرور، ساختار مشترک صفحات یا منابعی باشد که در همه آنها استفاده می‌شوند. در چنین شرایطی اصلاح تک‌تک URLها راه‌حل مناسبی نیست.
Lighthouse
Lighthouse برای عیب‌یابی فنی بسیار کاربردی است و می‌تواند مشکلاتی مانند منابع مسدودکننده رندر، JavaScript سنگین، تصاویر نامناسب و برخی مشکلات عملکردی را آشکار کند.
با این حال، به یاد داشته باشید که گزارش Lighthouse با تجربه واقعی تمام کاربران یکسان نیست.
Chrome DevTools
برای مشکلات پیچیده‌تر، Chrome DevTools ابزار مهمی است. در بخش Performance می‌توان فعالیت Main Thread، Long Taskها، رندر صفحه و اتفاقات مربوط به بارگذاری را بررسی کرد.
اگر INP ضعیف باشد، DevTools می‌تواند کمک کند بفهمید کدام پردازش JavaScript باعث اشغال شدن Main Thread شده است.
چگونه LCP را بهبود دهیم؟
بهبود LCP معمولاً با یک تغییر ساده انجام نمی‌شود؛ زیرا LCP نتیجه یک زنجیره از اتفاقات در فرایند بارگذاری است.
برای عیب‌یابی LCP بهتر است مسیر زیر را بررسی کنید:
Server Response → HTML → CSS/JS → LCP Resource → Render
1. TTFB و پاسخ‌گویی سرور را بررسی کنید
اگر سرور دیر پاسخ دهد، مراحل بعدی نیز دیرتر شروع می‌شوند. به همین دلیل TTFB بالا می‌تواند یکی از موانع رسیدن به LCP مناسب باشد.
- کیفیت هاست
- موقعیت سرور
- زمان پردازش درخواست
- کش سمت سرور
- بهینه‌سازی دیتابیس
- تعداد و پیچیدگی Queryها
- CDN در معماری مناسب
- ریدایرکت‌های غیرضروری
باید بررسی شوند. نکته مهم این است که TTFB خود یکی از Core Web Vitals نیست، اما برای تشخیص علت LCP بالا می‌تواند اطلاعات مهمی در اختیار شما قرار دهد.
2. عنصر LCP را شناسایی کنید
قبل از بهینه‌سازی باید بدانید دقیقاً کدام عنصر به‌عنوان LCP ثبت شده است.
اگر LCP یک تصویر Hero باشد، راه‌حل با حالتی که LCP یک بلوک متنی بزرگ است متفاوت خواهد بود. بنابراین ابتدا عنصر LCP را در گزارش ابزارهای توسعه و PageSpeed پیدا کنید.
3. تصویر اصلی را بهینه کنید
اگر عنصر LCP یک تصویر بزرگ است، تصویر باید با ابعاد مناسب و حجم منطقی ارائه شود.
استفاده از یک تصویر بسیار بزرگ برای فضایی کوچک باعث می‌شود کاربر داده بیشتری دانلود کند بدون اینکه کیفیت بصری متناسبی دریافت کند.
فرمت مناسب، فشرده‌سازی، ابعاد صحیح و نحوه بارگذاری تصویر را بررسی کنید.
4. تصویر LCP را بی‌دلیل Lazy Load نکنید
یکی از اشتباهات رایج در بهینه‌سازی تصاویر این است که Lazy Loading برای تمام تصاویر فعال شود.
تصویر خارج از viewport معمولاً گزینه مناسبی برای Lazy Loading است، اما اگر تصویر اصلی صفحه همان عنصر LCP باشد، به تعویق انداختن بارگذاری آن می‌تواند نمایش محتوای اصلی را عقب بیندازد.
5. منابع Render-Blocking را کاهش دهید
CSS و JavaScriptهایی که برای نمایش بخش ابتدایی صفحه ضروری نیستند نباید بدون دلیل مسیر رندر اولیه را مسدود کنند.
باید مشخص شود کدام منابع برای نمایش محتوای بالای صفحه ضروری هستند و کدام منابع می‌توانند بعداً بارگذاری شوند.
6. CSS غیرضروری را کاهش دهید
قالب‌های سنگین، Page Builderها و افزونه‌هایی که CSS زیادی وارد صفحه می‌کنند، می‌توانند حجم منابع اولیه را افزایش دهند.
هدف فقط کم کردن تعداد فایل‌ها نیست؛ باید منابعی را شناسایی کنید که واقعاً برای نمایش اولیه صفحه لازم نیستند.
7. فونت‌ها را فراموش نکنید
در سایت‌های فارسی، فونت‌های وب می‌توانند بخش قابل توجهی از منابع اولیه را تشکیل دهند. استفاده از وزن‌های متعدد، فایل‌های بزرگ و روش بارگذاری نامناسب فونت می‌تواند روی تجربه بارگذاری اثر بگذارد.
تعداد وزن‌های فونت را کنترل کنید، فرمت مناسب را انتخاب کنید و فقط فونت‌هایی را بارگذاری کنید که واقعاً در طراحی سایت استفاده می‌شوند.
چگونه INP را بهبود دهیم؟
بهینه‌سازی INP با بهینه‌سازی سرعت اولیه صفحه تفاوت دارد. ممکن است یک سایت LCP بسیار خوبی داشته باشد اما هنگام کلیک، تایپ یا باز کردن منو پاسخ‌گویی ضعیفی داشته باشد.
برای بهبود INP باید تمرکز اصلی روی JavaScript، Main Thread و نحوه پردازش تعاملات باشد.
1. JavaScriptهای سنگین را شناسایی کنید
JavaScript زیاد فقط باعث افزایش حجم دانلود نمی‌شود؛ اجرای آن نیز CPU و Main Thread را درگیر می‌کند.
بررسی کنید کدام اسکریپت‌ها واقعاً ضروری هستند و آیا می‌توان آنها را فقط در صفحاتی که به آنها نیاز دارند بارگذاری کرد.
2. Long Taskها را کاهش دهید
وقتی یک وظیفه طولانی Main Thread را برای مدت زیادی درگیر می‌کند، مرورگر نمی‌تواند به‌سرعت به ورودی جدید کاربر پاسخ دهد.
برای مثال ممکن است یک اسکریپت در حال پردازش سنگین باشد و درست در همان لحظه کاربر روی یک دکمه کلیک کند. تا زمانی که مرورگر فرصت پردازش تعامل را پیدا نکند، کاربر احساس تأخیر خواهد داشت.
3. کارهای سنگین را به وظایف کوچک‌تر تقسیم کنید
گاهی لازم نیست تمام پردازش در یک مرحله انجام شود. تقسیم پردازش‌های سنگین به وظایف کوچک‌تر می‌تواند فرصت بیشتری برای پاسخ‌گویی مرورگر به تعاملات کاربر ایجاد کند.
4. اسکریپت‌های Third-Party را کنترل کنید
- ابزارهای آمارگیری
- چت آنلاین
- تبلیغات
- Heatmap
- ابزارهای بازاریابی
- اسکریپت‌های شبکه‌های اجتماعی
- ابزارهای تست و رهگیری
هر کدام از این ابزارها می‌توانند هزینه عملکردی داشته باشند. بررسی کنید هر اسکریپت چه کاربردی دارد و آیا باید در تمام صفحات سایت بارگذاری شود یا خیر.
5. Event Handlerها را بهینه کنید
کدی که هنگام کلیک، اسکرول، تایپ یا سایر تعاملات اجرا می‌شود باید تا حد امکان سبک و کارآمد باشد.
چگونه CLS را کاهش دهیم؟
CLS معمولاً یکی از قابل مشاهده‌ترین مشکلات تجربه کاربری است؛ زیرا کاربر جابه‌جایی عناصر صفحه را مستقیماً مشاهده می‌کند.
یکی از اصول مهم برای کاهش CLS این است که مرورگر از ابتدا بداند هر عنصر قرار است چه مقدار فضا اشغال کند.
1. برای تصاویر ابعاد مشخص تعیین کنید
اگر مرورگر قبل از دریافت تصویر نداند تصویر چه فضایی نیاز دارد، ممکن است بعد از دریافت آن Layout تغییر کند.
استفاده صحیح از width و height یا روش‌های مناسب برای مشخص کردن نسبت تصویر می‌تواند فضای لازم را از ابتدا برای مرورگر مشخص کند.
2. برای تبلیغات فضای مشخص در نظر بگیرید
تبلیغاتی که بدون فضای رزروشده وارد صفحه می‌شوند، یکی از عوامل رایج Layout Shift هستند.
اگر فضای تبلیغ از ابتدا مشخص باشد، احتمال جابه‌جایی محتوای اطراف آن کاهش پیدا می‌کند.
3. iframeها را بدون فضای مشخص وارد نکنید
Embedهای ویدئو، نقشه، فرم یا سایر سرویس‌های خارجی نیز باید فضای مناسبی از ابتدا داشته باشند تا هنگام بارگذاری باعث تغییر ناگهانی Layout نشوند.
4. محتوای جدید را بدون برنامه به بالای صفحه تزریق نکنید
نمایش ناگهانی بنر، نوار اطلاع‌رسانی، پیشنهاد ویژه یا محتوای تبلیغاتی در بالای محتوایی که قبلاً نمایش داده شده، می‌تواند باعث جابه‌جایی بخش بزرگی از صفحه شود.
5. فونت‌ها را مدیریت کنید
بارگذاری Web Fontها می‌تواند در شرایط خاص روی نحوه نمایش متن اثر بگذارد. تعداد فونت‌ها، وزن‌های مختلف و روش بارگذاری آنها را بررسی کنید و مطمئن شوید تغییر ناگهانی Typography باعث جابه‌جایی قابل توجه محتوا نمی‌شود.
چگونه بفهمیم مشکل Core Web Vitals از کجاست؟
یکی از مهم‌ترین تفاوت‌های بین یک بررسی ساده و یک تحلیل حرفه‌ای این است که به‌جای دیدن عدد و اجرای یک راه‌حل عمومی، ابتدا علت ریشه‌ای مشکل مشخص شود.
برای مثال اگر LCP ضعیف است، فوراً سراغ نصب افزونه Cache نروید. ابتدا مشخص کنید آیا مشکل از TTFB است، تصویر LCP دیر دریافت می‌شود، CSS مسیر رندر را مسدود کرده، سرور کند است یا منابع دیگری باعث تأخیر شده‌اند.
برای INP نیز ابتدا باید مشخص شود آیا JavaScript سنگین، Long Task، اسکریپت Third-Party یا یک Event Handler خاص باعث تأخیر شده است.
در CLS نیز باید مشخص شود کدام عنصر جابه‌جا می‌شود؛ تصویر، تبلیغ، iframe، فونت یا محتوایی که به‌صورت پویا وارد صفحه می‌شود.
آیا داشتن LCP خوب ولی INP ضعیف مشکل محسوب می‌شود؟
بله.
Core Web Vitals را نباید به شکل یک نمره واحد دید. ممکن است یک صفحه:
LCP = خوب
INP = ضعیف
CLS = خوب
داشته باشد.
در چنین شرایطی نمایش اولیه صفحه مناسب است، اما هنگام تعامل کاربر مشکل وجود دارد. بنابراین بهینه‌سازی واقعی یعنی هر سه معیار را مستقل و در ارتباط با تجربه واقعی کاربر بررسی کنیم.
چرا PageSpeed Insights یک عدد می‌دهد اما Core Web Vitals چیز دیگری نشان می‌دهد؟
این یکی از رایج‌ترین سردرگمی‌هاست.
PageSpeed Insights مجموعه‌ای از معیارها و گزارش‌ها را نمایش می‌دهد، در حالی که Core Web Vitals فقط سه معیار مشخص یعنی LCP، INP و CLS را شامل می‌شود.
همچنین امتیاز کلی Performance در Lighthouse با Core Web Vitals یکسان نیست.
Performance Score ≠ Core Web Vitals
ممکن است یک صفحه امتیاز Performance متوسطی داشته باشد اما سه Core Web Vital آن در محدوده مناسب باشند، یا برعکس.
بنابراین در تحلیل حرفه‌ای ابتدا مشخص کنید کدام معیار مشکل دارد و چرا؛ سپس سراغ بهینه‌سازی بروید.
چرا وضعیت Core Web Vitals در موبایل بدتر از دسکتاپ است؟
این اتفاق بسیار رایج است. گوشی‌های موبایل ممکن است از نظر توان پردازشی محدودتر باشند و کاربران نیز از شبکه‌های متفاوتی استفاده کنند.
به همین دلیل سایتی که روی یک لپ‌تاپ قدرتمند سریع به نظر می‌رسد، ممکن است روی گوشی‌های ضعیف‌تر تجربه متفاوتی داشته باشد.
به همین دلیل داده‌های Core Web Vitals باید با تفکیک mobile و desktop بررسی شوند.
برای سایت‌هایی که بخش قابل توجهی از کاربرانشان از موبایل وارد می‌شوند، نادیده گرفتن عملکرد موبایل می‌تواند باعث شود تصویر اشتباهی از وضعیت واقعی سایت داشته باشند.
آیا Core Web Vitals فقط برای صفحه اصلی است؟
خیر. Core Web Vitals را باید در انواع صفحات و الگوهای مختلف سایت بررسی کرد.
ممکن است صفحه اصلی بسیار سریع باشد، اما صفحات محصول، دسته‌بندی، مقالات یا صفحات فرود عملکرد متفاوتی داشته باشند.
- صفحات محصول ممکن است JavaScript زیادی داشته باشند.
- صفحات دسته‌بندی ممکن است تصاویر و فیلترهای سنگین داشته باشند.
- مقالات ممکن است تبلیغات یا Embedهای زیادی داشته باشند.
- صفحات جست‌وجو ممکن است تعاملات پیچیده‌ای داشته باشند.
- صفحات Checkout ممکن است به دلیل اسکریپت‌های متعدد INP ضعیفی داشته باشند.
بنابراین در یک سایت حرفه‌ای بهتر است حداقل الگوهای اصلی صفحات بررسی شوند.
برای مثال در یک فروشگاه اینترنتی:
Homepage + Category + Product + Cart + Checkout
آیا CDN باعث بهبود Core Web Vitals می‌شود؟
CDN در شرایط مناسب می‌تواند به عملکرد سایت کمک کند، به‌خصوص برای تحویل منابع استاتیک و کاهش فاصله شبکه‌ای میان کاربر و محل ارائه محتوا.
اما CDN به‌تنهایی تضمین‌کننده Core Web Vitals خوب نیست.
برای مثال اگر مشکل سایت از JavaScript سنگین باشد، CDN نمی‌تواند INP را مستقیماً حل کند. اگر تبلیغات بدون فضای مشخص باعث CLS شوند نیز CDN علت اصلی مشکل را برطرف نمی‌کند.
بنابراین CDN را باید یکی از اجزای معماری Performance دانست، نه راه‌حل تمام مشکلات سرعت.
برای آشنایی دقیق‌تر با نحوه عملکرد CDN می‌توانید مقاله CDN را در پرشیا وب مطالعه کنید.
آیا کاهش حجم تصاویر روی Core Web Vitals اثر دارد؟
بله، به‌خصوص اگر تصویر بخش مهمی از محتوای بالای صفحه یا همان عنصر LCP باشد.
- ابعاد واقعی موردنیاز تصویر را مشخص کنید.
- تصویر بسیار بزرگ را برای فضای کوچک استفاده نکنید.
- از فرمت مناسب و فشرده‌سازی استفاده کنید.
- تصاویر خارج از viewport را در صورت مناسب بودن Lazy Load کنید.
- تصویر LCP را بدون بررسی به Lazy Load نسپارید.
- تصاویر Responsive را متناسب با دستگاه کاربر ارائه کنید.
آیا Lazy Load همیشه مفید است؟
خیر.
Lazy Loading برای منابعی که پایین‌تر از بخش قابل مشاهده صفحه قرار دارند می‌تواند مفید باشد، زیرا مرورگر مجبور نیست همه آنها را در همان ابتدای بارگذاری دریافت کند.
اما اگر تصویر اصلی و عنصر LCP را اشتباه Lazy Load کنیم، ممکن است دانلود آن به تأخیر بیفتد و LCP بدتر شود.
قاعده مهم این است:
منابع حیاتی بالای صفحه را زودتر و منابع غیرضروری پایین صفحه را در زمان مناسب‌تر بارگذاری کنید.
آیا افزونه‌های WordPress می‌توانند Core Web Vitals را بهبود دهند؟
برخی افزونه‌ها می‌توانند در زمینه Cache، بهینه‌سازی فایل‌ها، مدیریت تصاویر، Lazy Load و برخی تنظیمات Performance کمک کنند.
اما نصب افزونه‌های بیشتر لزوماً به معنی عملکرد بهتر نیست.
- JavaScript بیشتری به سایت اضافه کنند.
- CSS اضافی تولید کنند.
- درخواست‌های بیشتری ایجاد کنند.
- اسکریپت‌های Third-Party وارد سایت کنند.
- پردازش سمت سرور را افزایش دهند.
بنابراین سؤال درست این نیست که:
«چه افزونه‌ای نصب کنم تا نمره سبز شود؟»
بلکه باید پرسید:
«علت فنی مشکل چیست و کدام تغییر واقعاً همان علت را برطرف می‌کند؟»
Core Web Vitals را چگونه برای یک سایت وردپرسی بهبود دهیم؟
برای سایت WordPress بهتر است بهینه‌سازی را به‌صورت لایه‌ای انجام دهید؛ زیرا مشکل ممکن است از سرور، قالب، افزونه، تصویر، JavaScript یا سیستم Cache باشد.
لایه اول: سرور و هاست
TTFB بالا، منابع ناکافی سرور، پردازش کند PHP یا پیکربندی نامناسب Cache می‌تواند روی عملکرد کلی اثر بگذارد.
لایه دوم: قالب
قالب‌های سنگین، CSS و JavaScript اضافی و Page Builderهای پرحجم را بررسی کنید. زیبایی ظاهری نباید به قیمت بارگذاری تعداد زیادی منبع غیرضروری تمام شود.
لایه سوم: افزونه‌ها
افزونه‌های غیرضروری را حذف کنید و بررسی کنید هر افزونه چه منابعی به صفحات اضافه می‌کند. یک افزونه ممکن است فقط در یک صفحه خاص مورد نیاز باشد اما به‌صورت سراسری در تمام صفحات بارگذاری شود.
لایه چهارم: تصاویر
حجم، ابعاد، فرمت و نحوه بارگذاری تصاویر را بررسی کنید. به‌خصوص تصویر LCP را جداگانه تحلیل کنید.
لایه پنجم: JavaScript
کدهای غیرضروری، اسکریپت‌های Third-Party و فایل‌هایی که Main Thread را درگیر می‌کنند بررسی شوند.
لایه ششم: فونت‌ها
تعداد فونت‌ها و وزن‌های استفاده‌شده را کنترل کنید و بارگذاری آنها را متناسب با نیاز سایت بهینه کنید.
لایه هفتم: Cache
کش مرورگر، کش صفحه، کش سرور و در صورت نیاز CDN باید با یکدیگر هماهنگ باشند. فعال کردن چند سیستم Cache بدون شناخت معماری سایت می‌تواند باعث ایجاد رفتارهای پیش‌بینی‌نشده شود.
پیشنهاد مطالعه : برای تقویت سایت خود می توانید از خرید رپورتاژ آگهی هم استفاده نمایید تا نتایج بهتری در سرچ گوگل داشته باشید.
چرا بعد از بهینه‌سازی سایت هنوز Core Web Vitals خوب نشده است؟
تغییرات هنوز در داده‌های Field منعکس نشده‌اند
داده‌های واقعی کاربران با همان سرعتی که یک تست آزمایشگاهی تغییر می‌کند، تغییر نمی‌کنند. بنابراین ممکن است نتیجه یک اصلاح فنی بلافاصله در گزارش‌های Field مشاهده نشود.
مشکل مربوط به یک URL نیست
گاهی یک مشکل در قالب یا افزونه باعث می‌شود صدها صفحه عملکرد مشابهی داشته باشند. در این حالت اصلاح یک URL کافی نیست و باید الگوی مشترک صفحات را بررسی کرد.
مشکل فقط در موبایل وجود دارد
اگر دسکتاپ مناسب ولی موبایل ضعیف است، احتمالاً باید پردازش JavaScript، حجم منابع، تصاویر، شرایط شبکه و قدرت پردازشی دستگاه‌های موبایل را دقیق‌تر بررسی کنید.
مشکل مربوط به کاربران واقعی و شرایط شبکه است
ممکن است در محیط تست شما همه‌چیز مناسب باشد، اما کاربران واقعی با دستگاه‌ها و شبکه‌های متفاوت تجربه دیگری داشته باشند.
مشکل ریشه‌ای هنوز حل نشده است
برای مثال حذف یک افزونه ممکن است کمی حجم فایل‌ها را کاهش دهد، اما اگر مشکل اصلی TTFB بالا یا JavaScript سنگین باشد، تغییر ایجادشده اثر محدودی خواهد داشت.
بهترین ترتیب برای بهبود Core Web Vitals چیست؟
یکی از اشتباهات رایج این است که مالک سایت هم‌زمان ده‌ها تغییر ایجاد می‌کند و بعد نمی‌داند کدام تغییر نتیجه داده است.
مرحله اول: وضعیت فعلی را ثبت کنید
- LCP
- INP
- CLS
- موبایل
- دسکتاپ
- Field Data
- Lab Data
مرحله دوم: مشکل اصلی را مشخص کنید
برای مثال مشخص کنید مشکل اصلی LCP، INP یا CLS است و شدت مشکل چقدر است.
مرحله سوم: علت ریشه‌ای را پیدا کنید
به‌جای درمان علامت، علت را پیدا کنید. برای LCP سرور، منابع اولیه و عنصر LCP را بررسی کنید؛ برای INP سراغ JavaScript و Main Thread بروید؛ و برای CLS عنصر جابهجاشونده را پیدا کنید.
مرحله چهارم: یک تغییر مشخص انجام دهید
- بهینه‌سازی تصویر Hero
- کاهش JavaScript
- اصلاح ابعاد تصاویر
- حذف یک اسکریپت Third-Party
- بهبود Cache
- بهینه‌سازی سرور
مرحله پنجم: دوباره تست کنید
بعد از هر تغییر مهم، همان صفحه را دوباره آزمایش کنید و نتیجه را با وضعیت قبلی مقایسه کنید.
مرحله ششم: داده‌های واقعی را دنبال کنید
اگر تغییر واقعاً مؤثر بوده باشد، اثر آن باید در طول زمان در داده‌های کاربران واقعی نیز قابل مشاهده باشد.
یک روش حرفه‌ای برای عیب‌یابی LCP، INP و CLS
| مشکل | اول چه چیزی را بررسی کنیم؟ | علت‌های رایج |
|---|---|---|
| LCP بالا | TTFB، عنصر LCP، Network و Render | سرور کند، تصویر سنگین، CSS/JS مسدودکننده، منابع اولیه زیاد |
| INP بالا | Performance، Main Thread و Long Task | JavaScript سنگین، Event Handler، Third-Party Script |
| CLS بالا | Layout Shifts و عنصر جابهجاشونده | تصاویر بدون ابعاد، تبلیغات، iframe، فونت و محتوای پویا |
این جدول را می‌توان به‌عنوان نقطه شروع عیب‌یابی استفاده کرد؛ اما برای هر سایت باید علت واقعی بر اساس داده‌های همان سایت مشخص شود.
اشتباهات رایج در بهبود Core Web Vitals
اشتباه اول: تمرکز فقط روی امتیاز PageSpeed
هدف نباید فقط رسیدن به نمره ۹۰ یا ۱۰۰ باشد. امتیاز ابزار مهم است، اما باید بدانید کاربران واقعی چه تجربه‌ای دارند.
اشتباه دوم: تصور اینکه CDN همه مشکلات را حل می‌کند
CDN می‌تواند بخشی از مشکلات تحویل محتوا را کاهش دهد، اما مشکل JavaScript، Layout Shift یا معماری ضعیف صفحه را به‌صورت خودکار حل نمی‌کند.
اشتباه سوم: Lazy Load کردن همه تصاویر
تصویر LCP ممکن است به بارگذاری سریع نیاز داشته باشد و Lazy Load کردن آن نتیجه معکوس داشته باشد.
اشتباه چهارم: نصب افزونه‌های زیاد
افزونه‌ها می‌توانند خودشان JavaScript، CSS و درخواست‌های جدید به سایت اضافه کنند.
اشتباه پنجم: نادیده گرفتن موبایل
ممکن است دسکتاپ سریع باشد اما کاربران موبایل همچنان با LCP یا INP ضعیف مواجه باشند.
اشتباه ششم: توجه نکردن به Field Data
ممکن است تست آزمایشگاهی عالی باشد اما کاربران واقعی هنوز تجربه ضعیفی داشته باشند.
اشتباه هفتم: تغییر هم‌زمان چند عامل
اگر سرور، تصاویر، افزونه‌ها، JavaScript و قالب را هم‌زمان تغییر دهید، تشخیص اینکه کدام تغییر مؤثر بوده دشوار خواهد شد.
یک چک‌لیست عملی برای بهبود Core Web Vitals
چک‌لیست LCP
- آیا TTFB و پاسخ اولیه سرور مناسب است؟
- آیا عنصر LCP را شناسایی کرده‌اید؟
- آیا تصویر LCP بیش از حد بزرگ است؟
- آیا تصویر LCP به اشتباه Lazy Load شده است؟
- آیا منابع Render-Blocking کنترل شده‌اند؟
- آیا CSS غیرضروری کاهش یافته است؟
- آیا فونت‌ها و منابع اولیه بیش از حد زیاد هستند؟
- آیا Cache و CDN در صورت نیاز به‌درستی تنظیم شده‌اند؟
چک‌لیست INP
- آیا JavaScript غیرضروری حذف شده است؟
- آیا Long Taskها شناسایی شده‌اند؟
- آیا Main Thread بیش از حد درگیر است؟
- آیا Event Handlerها سبک هستند؟
- آیا اسکریپت‌های Third-Party کنترل شده‌اند؟
- آیا اسکریپت‌ها فقط در صفحات موردنیاز اجرا می‌شوند؟
چک‌لیست CLS
- آیا تصاویر ابعاد مشخص دارند؟
- آیا فضای تبلیغات از قبل مشخص شده است؟
- آیا iframeها فضای مناسب دارند؟
- آیا محتوای جدید بالای محتوای موجود تزریق نمی‌شود؟
- آیا فونت‌ها باعث تغییر ناگهانی Layout نمی‌شوند؟
- آیا عناصر پویا فضای موردنیاز خود را از ابتدا مشخص کرده‌اند؟
آیا باید همیشه به بهترین نمره ممکن برسیم؟
خیر. هدف اصلی، ارائه تجربه مناسب برای کاربران است؛ نه اینکه هر عدد را تا حد ممکن به صفر یا بهترین مقدار نظری نزدیک کنیم.
برای مثال، اگر CLS شما ۰.۰۳ باشد، تلاش برای رساندن آن به ۰.۰۰ ممکن است ارزش بسیار کمتری نسبت به حل یک LCP پنج‌ثانیه‌ای داشته باشد.
بنابراین ابتدا مشکلات شدید و پرتکرار را برطرف کنید و سپس سراغ بهینه‌سازی‌های ظریف‌تر بروید.
آیا Core Web Vitals باید همیشه سبز باشد؟
هدف واقعی، ارائه تجربه مناسب برای کاربران است.
اگر گزارش یک تست خاص سبز یا قرمز شده، نباید فقط همان تست را معیار نهایی قرار دهید. شرایط کاربران، دستگاه‌ها، شبکه‌ها و نوع صفحات متفاوت هستند.
به همین دلیل داده واقعی کاربران اهمیت زیادی دارد. در سایت‌های بزرگ نیز ممکن است یک نوع صفحه عملکرد ضعیف‌تری داشته باشد، در حالی که بیشتر صفحات وضعیت مناسبی دارند.
تحلیل حرفه‌ای باید بر اساس داده، الگوی صفحات و علت مشکل انجام شود، نه یک اسکرین‌شات از یک تست.
Core Web Vitals در سایت‌های فارسی چه نکاتی دارد؟
فارسی یا راست‌چین بودن سایت به‌تنهایی به معنی Core Web Vitals ضعیف نیست؛ اما در یک سایت فارسی باید چند عامل را با دقت بررسی کرد.
- حجم و تعداد فایل‌های فونت فارسی
- تعداد وزن‌های فونت مورد استفاده
- تصاویر Hero و بنرهای بزرگ
- اسکریپت‌های تبلیغاتی و سرویس‌های شخص ثالث
- هدرها و نوارهای اطلاع‌رسانی پویا
- Embedهای شبکه‌های اجتماعی
- عملکرد سایت روی دستگاه‌های موبایل کاربران
بنابراین برای یک سایت فارسی نیز باید دقیقاً همان رویکرد علت‌محور را اجرا کرد و صرفاً به این دلیل که سایت فارسی است، یک نسخه ثابت از تنظیمات Performance را روی آن اعمال نکرد.
Core Web Vitals در آینده چه اهمیتی خواهد داشت؟
Core Web Vitals بخشی از تلاش وب برای تبدیل مفاهیم فنی عملکرد به معیارهایی است که ارتباط بیشتری با تجربه واقعی کاربر دارند.
این حوزه ثابت نیست و معیارها، ابزارهای اندازه‌گیری و روش‌های عیب‌یابی در طول زمان تکامل پیدا می‌کنند. برای مثال، INP در سال ۲۰۲۴ جایگزین FID شد و در مستندات فعلی گوگل یکی از سه Core Web Vital اصلی است.
بنابراین هنگام بهینه‌سازی سایت نباید فقط به آموزش‌های قدیمی تکیه کرد؛ مخصوصاً مقالاتی که هنوز FID را به‌عنوان یکی از سه معیار فعلی معرفی می‌کنند.
جمع‌بندی؛ برای بهبود Core Web Vitals از کجا شروع کنیم؟
اگر بخواهیم تمام این راهنما را به یک فرایند عملی تبدیل کنیم، مسیر پیشنهادی این است:
- ابتدا داده‌های واقعی کاربران را بررسی کنید.
- مشخص کنید کدام معیار، یعنی LCP، INP یا CLS، مشکل دارد.
- موبایل و دسکتاپ را جداگانه تحلیل کنید.
- برای LCP عنصر LCP، TTFB و مسیر بارگذاری منابع را بررسی کنید.
- برای INP سراغ JavaScript، Main Thread و Long Taskها بروید.
- برای CLS عنصر جابهجاشونده و علت Layout Shift را پیدا کنید.
- هر بار یک تغییر مشخص انجام دهید و نتیجه را دوباره اندازه‌گیری کنید.
- بعد از اصلاحات، داده‌های Field را نیز در طول زمان بررسی کنید.
Core Web Vitals در نهایت درباره سه عدد نیست؛ درباره این است که کاربر هنگام باز کردن و استفاده از سایت چه تجربه‌ای دارد. سایت سریع، پاسخ‌گو و پایدار برای کاربر ارزشمندتر است و همین موضوع باید هدف اصلی بهینه‌سازی عملکرد باشد.
اگر در سایت شما LCP، INP یا CLS وضعیت مناسبی ندارد، بهتر است به‌جای نصب تصادفی افزونه‌ها یا دنبال کردن یک نمره خاص، ابتدا علت فنی مشکل را پیدا کنید و سپس متناسب با همان علت اقدام کنید.
اگر قصد دارید Core Web Vitals سایت خود را تقویت کنید می توانید از خدمات پشتیبانی و تعمیرات سایت در مجموعه پرشیا وب استفاده کنید. فقط کافیست با کارشناسان و متخصصین ما در تماس باشید.
