وقتی کاربر روی نتیجه گوگل کلیک می‌کند، کیفیت تجربه او فقط به این بستگی ندارد که صفحه «بالا بیاید». مهم است محتوای اصلی چه زمانی دیده شود، صفحه بعد از لمس یا کلیک چقدر سریع واکنش نشان دهد و آیا عناصر هنگام بارگذاری جابه‌جا می‌شوند یا نه. Core Web Vitals دقیقاً برای سنجش همین سه بخش از تجربه واقعی کاربر طراحی شده است: سرعت نمایش محتوای اصلی، پاسخ‌گویی به تعامل و ثبات بصری.
برای مدیر یک سایت فروشگاهی، خبری، آموزشی یا خدماتی، این شاخص‌ها فقط اعداد فنی نیستند. صفحه‌ای که دیر واکنش می‌دهد، دکمه خریدش جابه‌جا می‌شود یا تصویر اصلی آن دیر ظاهر می‌شود می‌تواند کاربر را قبل از رسیدن به هدف اصلی صفحه از دست بدهد. از طرف دیگر، اصلاح Core Web Vitals معمولاً هم‌زمان چند نتیجه مثبت ایجاد می‌کند: تجربه بهتر، کاهش اصطکاک در مسیر تبدیل، کیفیت فنی بالاتر و سیگنال‌های بهتر برای ارزیابی تجربه صفحه.
| پاسخ کوتاه — Core Web Vitals مجموعه‌ای از سه معیار LCP، INP و CLS است. طبق مستندات فعلی Google، برای تجربه «خوب» بهتر است LCP حداکثر ۲.۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰.۱ باشد؛ ارزیابی معمولاً بر اساس صدک ۷۵ بازدیدها و جداگانه برای موبایل و دسکتاپ انجام می‌شود. [۱][۲] |
Core Web Vitals دقیقاً چیست و چرا اهمیت دارد؟
Core Web Vitals زیرمجموعه‌ای از Web Vitals است که سه جنبه بسیار ملموس از تجربه کاربر را اندازه می‌گیرد. LCP به این سؤال پاسخ می‌دهد که «محتوای اصلی چه زمانی دیده شد؟»، INP می‌پرسد «وقتی کاربر با صفحه تعامل کرد، رابط چقدر سریع پاسخ بصری داد؟» و CLS بررسی می‌کند «چقدر محتوای صفحه بدون انتظار کاربر جابه‌جا شد؟». این سه معیار به‌جای تمرکز صرف بر سرعت خام سرور، تلاش می‌کنند تجربه‌ای را اندازه بگیرند که کاربر واقعاً حس می‌کند.
Google توصیه می‌کند صاحبان سایت به Core Web Vitals خوب برسند؛ با این حال نباید آن را به‌عنوان یک فرمول تک‌عاملی برای رتبه تصور کرد. کیفیت محتوا، ارتباط با نیت جستجو، اعتبار، ساختار سایت و ده‌ها عامل دیگر همچنان مهم‌اند. بهترین نگاه این است که Core Web Vitals بخشی از کیفیت کلی تجربه صفحه است: اگر دو صفحه محتوای هم‌سطحی داشته باشند، تجربه سریع‌تر و پایدارتر مزیت واقعی برای کاربر ایجاد می‌کند.
| شاخص | چه چیزی را می‌سنجد | خوب | نیازمند بهبود | ضعیف |
| LCP | سرعت نمایش محتوای اصلی | خوب: ≤ ۲.۵ ثانیه | نیازمند بهبود: ۲.۵ تا ۴ ثانیه | ضعیف: > ۴ ثانیه |
| INP | پاسخ‌گویی به تعامل | خوب: ≤ ۲۰۰ ms | نیازمند بهبود: ۲۰۰ تا ۵۰۰ ms | ضعیف: > ۵۰۰ ms |
| CLS | ثبات بصری | خوب: ≤ ۰.۱ | نیازمند بهبود: ۰.۱ تا ۰.۲۵ | ضعیف: > ۰.۲۵ |
جدول ۱ — حدود رایج Core Web Vitals بر اساس مستندات web.dev و Google Search Central [۱][۲]
سه شاخص اصلی LCP، INP و CLS چه چیزی را اندازه می‌گیرند؟
LCP؛ کاربر چه زمانی محتوای اصلی را می‌بیند؟
Largest Contentful Paint زمان رندر شدن بزرگ‌ترین عنصر محتوایی قابل مشاهده در viewport را در طول بارگذاری اندازه می‌گیرد. در بسیاری از صفحات این عنصر می‌تواند تصویر Hero، بنر اصلی، تصویر محصول، تیتر بزرگ یا یک بلوک متن باشد. اگر سرور کند باشد، CSS مسیر رندر را مسدود کند یا تصویر اصلی دیر کشف و دانلود شود، LCP افزایش پیدا می‌کند.
نکته مهم این است که «سرعت سایت» با یک عدد واحد تعریف نمی‌شود. ممکن است TTFB خوب باشد اما تصویر Hero دیر برسد، یا فایل تصویر سریع دانلود شود ولی به‌خاطر CSS و فونت دیر رندر شود. بنابراین بهبود LCP باید به‌صورت زنجیره‌ای بررسی شود: پاسخ سرور، کشف منبع اصلی، دانلود آن و زمان رندر.
تصویر ۲ — مسیر ساده‌شده LCP؛ هر تأخیر در زنجیره می‌تواند نمایش محتوای اصلی را عقب بیندازد
INP؛ صفحه بعد از تعامل چقدر سریع واکنش نشان می‌دهد؟
Interaction to Next Paint پاسخ‌گویی صفحه به تعامل‌های کاربر مانند کلیک، لمس و فشردن کلید را ارزیابی می‌کند. INP به یک تعامل منفرد محدود نیست و هدفش نمایش پاسخ‌گویی کلی صفحه در طول بازدید است. اگر Thread اصلی مرورگر با JavaScript سنگین، رندرهای زیاد یا Taskهای طولانی درگیر باشد، کاربر روی دکمه کلیک می‌کند اما تغییر بصری با تأخیر اتفاق می‌افتد.
در سایت‌های مدرن، مشکل INP اغلب از «حجم فایل JavaScript» به‌تنهایی نمی‌آید؛ هزینه اجرای کد، Hydration، event handlerهای سنگین، رندرهای React، کارهای هم‌زمان و اسکریپت‌های Third-party نیز می‌توانند مؤثر باشند. بنابراین تنها کوچک‌کردن Bundle همیشه کافی نیست؛ باید Thread اصلی را در لحظه تعامل آزاد نگه داشت.
تصویر ۳ — Taskهای طولانی روی Thread اصلی می‌توانند پاسخ بصری به تعامل را عقب بیندازند
CLS؛ آیا صفحه هنگام بارگذاری زیر پای کاربر حرکت می‌کند؟
Cumulative Layout Shift میزان جابه‌جایی غیرمنتظره عناصر قابل مشاهده را اندازه می‌گیرد. نمونه آشنا: کاربر می‌خواهد روی یک دکمه بزند، ناگهان تبلیغ یا تصویر بالای آن ظاهر می‌شود و دکمه به پایین می‌رود. یا فونت دیر بارگذاری می‌شود و طول خطوط تغییر می‌کند. این جابه‌جایی‌ها علاوه بر آزاردهنده بودن، می‌توانند باعث کلیک اشتباه شوند.
تصویر ۴ — رزرو فضا برای تصاویر، بنرها و محتوای Async یکی از راه‌های کلیدی کنترل CLS است
چطور Core Web Vitals سایت را به‌درستی اندازه‌گیری کنیم؟
قبل از اصلاح، باید بدانیم کدام داده را می‌بینیم. ابزارهای Performance معمولاً دو نوع داده در اختیار ما می‌گذارند: داده آزمایشگاهی (Lab) و داده کاربران واقعی (Field/RUM). این دو را نباید با هم اشتباه گرفت. Lighthouse می‌تواند در یک محیط کنترل‌شده سرنخ بسیار خوبی برای عیب‌یابی بدهد، اما تجربه واقعی کاربران با دستگاه، شبکه، موقعیت جغرافیایی، کش و الگوی استفاده متفاوت است.
داده واقعی و داده آزمایشگاهی را کنار هم ببینید
- Search Console Core Web Vitals: برای دیدن گروه URLهای دارای مشکل و روند کلی سایت مناسب است.
- PageSpeed Insights: ترکیبی از داده‌های واقعی CrUX (در صورت وجود داده کافی) و آزمایش Lighthouse را ارائه می‌کند.
- Chrome DevTools Performance: برای پیدا کردن Long Task، Layout Shift، شبکه و مسیر رندر مناسب است.
- Real User Monitoring: اگر پلتفرم یا تیم فنی دارید، ثبت Web Vitals در محیط Production امکان مشاهده تفاوت قالب‌ها، صفحات و کاربران را فراهم می‌کند.
اگر صفحه‌ای در Lighthouse عالی است اما گزارش کاربران واقعی هنوز ضعیف است، احتمالاً مشکل در شرایط واقعی رخ می‌دهد: کاربران موبایل ضعیف، CDN، منابع Third-party، بازدیدهای بدون کش، یا مسیرهایی که در تست دستی بررسی نشده‌اند. برعکس، یک تست Lighthouse ضعیف الزاماً به معنی Field Data ضعیف نیست؛ اما یک هشدار جدی برای بررسی است.
| اصل تشخیص — اول صفحه یا گروه URL مشکل‌دار را از داده واقعی پیدا کنید؛ سپس با ابزار آزمایشگاهی علت را بازسازی و Debug کنید. این ترتیب از بهینه‌سازی‌های تصادفی جلوگیری می‌کند. |
راهنمای عملی بهبود LCP
بهبود LCP معمولاً از یک سؤال شروع می‌شود: «عنصر LCP این صفحه چیست؟» تا وقتی عنصر اصلی را نشناسیم، ممکن است منابع اشتباه را بهینه کنیم. در صفحه محصول معمولاً تصویر محصول یا Hero است؛ در مقاله ممکن است تیتر یا تصویر شاخص باشد؛ در صفحه لندینگ یک بنر یا بلوک متن بزرگ.
۱) زمان پاسخ اولیه را کنترل کنید
اگر HTML دیر به مرورگر برسد، تمام مراحل بعدی نیز دیر شروع می‌شوند. کش مناسب، CDN، بهینه‌سازی Queryها، جلوگیری از Middlewareهای غیرضروری و انتخاب محل سرور نزدیک‌تر به مخاطب می‌تواند کمک کند. در معماری‌هایی مثل Next.js نیز باید مشخص شود کدام صفحه واقعاً نیاز به رندر پویا در هر درخواست دارد و کدام بخش می‌تواند Cache یا Pre-render شود.
۲) منبع LCP را زود کشف و با اولویت بالا دریافت کنید
یکی از خطاهای رایج این است که تصویر Hero از طریق JavaScript یا CSS دیر کشف شود. منبع اصلی باید در HTML اولیه قابل شناسایی باشد و در صورت مناسب بودن از اولویت بارگذاری یا preload استفاده شود. البته preload بیش از حد خود می‌تواند پهنای باند را از منابع مهم‌تر بگیرد؛ بنابراین فقط منابع واقعاً بحرانی را اولویت دهید.
۳) تصویر اصلی را به اندازه واقعی و فرمت مناسب تحویل دهید
ارسال تصویر ۳۰۰۰ پیکسلی برای باکسی که روی موبایل ۶۰۰ پیکسل است، اتلاف شبکه و Decode ایجاد می‌کند. responsive image، تعیین dimensions، فشرده‌سازی و استفاده از فرمت‌های مدرن در صورت سازگاری مناسب، معمولاً اثر قابل‌توجهی دارد. در Next.js، کامپوننت Image می‌تواند بخش مهمی از این فرایند را استاندارد کند، اما همچنان انتخاب width/height، sizes و اولویت درست بر عهده طراح سیستم است.
۴) CSS و فونت‌های مسیر بحرانی را سبک کنید
CSS سنگین، چند فونت و چند وزن فونت می‌تواند رندر اولیه را عقب بیندازد. فونت‌هایی را که بالای صفحه استفاده می‌شوند محدود کنید، subset مناسب داشته باشید، روش نمایش فونت را آگاهانه انتخاب کنید و CSS غیرضروری را به مسیر اولیه تحمیل نکنید. هدف این نیست که همه چیز را inline کنیم؛ هدف کاهش منابعی است که بدون آن‌ها رندر عنصر اصلی ممکن نیست.
۵) Third-partyها را وارد مسیر بحرانی نکنید
چت آنلاین، آنالیتیکس‌های متعدد، Heatmap، تبلیغات و Widgetهای بازاریابی می‌توانند شبکه و Thread اصلی را در لحظات حساس اشغال کنند. هر اسکریپت Third-party باید پاسخ روشنی به این سؤال داشته باشد: آیا قبل از دیده شدن محتوای اصلی واقعاً لازم است؟ اگر نه، بارگذاری دیرتر یا پس از تعامل معمولاً تصمیم بهتری است.
راهنمای عملی بهبود INP
INP بیشتر از آنکه مشکل «لود» باشد، مشکل «کار هنگام تعامل» است. کاربر دکمه را لمس می‌کند؛ مرورگر باید Event را پردازش کند، کد مربوط را اجرا کند، تغییرات UI را محاسبه و Paint کند. اگر هر قسمت طولانی شود، پاسخ کند حس می‌شود.
Taskهای طولانی JavaScript را بشکنید
Task طولانی Thread اصلی را اشغال می‌کند و تعامل‌های جدید منتظر می‌مانند. کارهای بزرگ را به واحدهای کوچک‌تر تقسیم کنید، پردازش غیرضروری را به بعد موکول کنید و در صورت امکان محاسبات سنگین را خارج از Thread اصلی انجام دهید. هدف این نیست که JavaScript را حذف کنیم؛ هدف این است که کاربر هنگام تعامل مجبور نباشد پشت صف کارهای غیرضروری بماند.
Hydration و رندر Client را کنترل کنید
در اپلیکیشن‌های React و Next.js، هر بخشی که Client Component می‌شود، هزینه‌ای برای JavaScript و Hydration دارد. اگر یک بلوک صرفاً اطلاعات ثابت یا محتوای سروری نمایش می‌دهد، Client کردن آن بدون نیاز واقعی هزینه اضافه ایجاد می‌کند. مرز بین Server و Client Component را بر اساس نیاز تعامل طراحی کنید، نه بر اساس عادت.
Event handler را کوچک نگه دارید
گاهی مشکل از یک Handler به‌ظاهر ساده است که چند Query، محاسبه، تغییر State و رندر زنجیره‌ای را انجام می‌دهد. با Performance panel مشخص کنید زمان از کجا مصرف می‌شود. محاسبات تکراری را Cache کنید، به‌روزرسانی‌های غیرضروری State را حذف کنید و دامنه رندر مجدد را کاهش دهید.
اسکریپت‌های شخص ثالث را ارزیابی کنید
اگر بعد از اضافه کردن ابزار بازاریابی INP افت کرده، این اتفاق را تصادفی فرض نکنید. Third-partyها می‌توانند Taskهای طولانی تولید کنند. قبل و بعد از نصب هر ابزار، اثر آن را اندازه بگیرید و برای ابزارهای سنگین Strategy بارگذاری جداگانه داشته باشید.
راهنمای عملی کاهش CLS
برای تصویر و ویدئو از قبل فضا رزرو کنید
اگر مرورگر نسبت ابعاد عنصر را قبل از دانلود نداند، ابتدا صفحه را بدون آن می‌چیند و بعد از رسیدن فایل، محتوا جابه‌جا می‌شود. width/height یا aspect-ratio این مشکل را تا حد زیادی حل می‌کند. این اصل برای کارت محصول، Thumbnail، ویدئو و بنر اهمیت ویژه‌ای دارد.
فضای تبلیغ، بنر و محتوای Async را ثابت کنید
اگر جایگاه تبلیغ یا پیشنهاد ویژه بعداً اضافه می‌شود، از ابتدا حداقل ارتفاع یا Container مناسب برای آن در نظر بگیرید. نمایش یک نوار Promo در بالای صفحه بعد از Load کامل، یکی از الگوهای کلاسیک ایجاد CLS است.
فونت را بدون شوک بصری بارگذاری کنید
تغییر فونت می‌تواند طول متن و ارتفاع خط را عوض کند. انتخاب fallback نزدیک به فونت اصلی، کنترل font-display و کاهش تعداد Font Variantها کمک می‌کند. در Next.js می‌توان از سیستم مدیریت فونت استفاده کرد تا بارگذاری و Self-hosting ساختارمندتر شود.
محتوای موجود را بالاتر از موقعیت فعلی کاربر تزریق نکنید
اگر Notification، پیام سبد خرید یا Banner جدید باید ظاهر شود، بهتر است Overlay باشد یا فضایی از قبل برای آن رزرو شده باشد. اضافه کردن عناصر جدید به ابتدای Document Flow بعد از تعامل می‌تواند بخش بزرگی از صفحه را جابه‌جا کند.
Core Web Vitals در Next.js و سایت‌های مدرن
Next.js به‌خودی‌خود تضمین نمی‌کند که سایت سریع باشد؛ همان‌طور که هیچ Framework دیگری چنین تضمینی نمی‌دهد. اما ابزارها و الگوهایی مانند Server Rendering، Static Generation، Server Components، بهینه‌سازی Image و Font، Code Splitting و Strategy بارگذاری Script می‌توانند مسیر رسیدن به عملکرد خوب را کوتاه کنند؛ به شرطی که معماری درست استفاده شود.
Server Component را پیش‌فرض فکری بدانید، نه قانون مطلق
در بخش‌هایی که تعامل Client لازم نیست، نگه داشتن منطق روی سرور می‌تواند JavaScript ارسالی به مرورگر را کاهش دهد. برای فرم تعاملی، Builder، فیلتر زنده یا سبد خرید Client Component لازم است؛ اما Header اطلاعاتی، محتوای مقاله یا بخش‌های ثابت لزوماً نیاز به Hydration ندارند.
Image و Font optimization را در سطح پلتفرم استاندارد کنید
در یک سایت‌ساز، انتظار اینکه هر کاربر نهایی تمام جزئیات فنی Image sizing، lazy loading و font loading را بداند منطقی نیست. بهترین پلتفرم‌ها این تصمیم‌ها را تا حد امکان به‌صورت پیش‌فرض درست می‌کنند. در سازکد نیز ارزش اصلی معماری Next.js زمانی دیده می‌شود که Page Builder خروجی بهینه تولید کند: اندازه تصویر متناسب، ابعاد رزروشده، Lazy load برای تصاویر پایین صفحه و اولویت‌دهی درست به منابع بالای صفحه.
اندازه‌گیری در Production را فراموش نکنید
Next.js و اکوسیستم آن امکان گزارش Web Vitals و اتصال به ابزارهای مانیتورینگ را فراهم می‌کنند. یک بهینه‌سازی واقعی باید بعد از انتشار هم پایش شود؛ چون تغییر قالب، افزونه بازاریابی، فونت یا Widget جدید ممکن است عملکرد صفحات واقعی را عوض کند. مستندات Next.js نیز روی پایش مداوم Core Web Vitals تأکید می‌کند. [۳]
| به‌روزرسانی مهم ۲۰۲۶ — web.dev در اوت ۲۰۲۶ اعلام کرده Chrome 151 APIهای جدیدی برای سنجش Core Web Vitals در Soft Navigationهای SPA ارائه کرده است. استفاده این APIها تازه در ابزارها و کتابخانه‌ها شروع شده و ادغام کامل آن‌ها در CrUX هنوز زمان‌بندی عمومی مشخصی ندارد. این موضوع برای سایت‌های SPA/Next.js و ابزارهای Page Builder مهم است و باید در به‌روزرسانی‌های بعدی مقاله رصد شود. [۴] |
فروشگاه اینترنتی و صفحات پرترافیک؛ اولویت اصلاح کجاست؟
در فروشگاه اینترنتی، همه صفحات ارزش یکسانی ندارند. اگر منابع محدود است، از صفحاتی شروع کنید که بیشترین ورودی و بیشترین اثر تجاری دارند: صفحه دسته‌بندی، محصول، Landing کمپین، سبد خرید و Checkout. سپس الگوها را اصلاح کنید تا تغییر یک Template به صدها URL منتقل شود.
| نوع صفحه | ریسک‌های رایج | اولویت |
| صفحه محصول | LCP تصویر محصول، INP انتخاب تنوع/افزودن به سبد، CLS گالری و قیمت | خیلی بالا |
| دسته‌بندی | INP فیلتر و مرتب‌سازی، LCP بنر/لیست اولیه | بالا |
| Checkout | INP فرم و Validation، CLS پیام‌ها و خطاها | خیلی بالا |
| مقاله وبلاگ | LCP تصویر شاخص/تیتر، CLS تبلیغ و فونت | متوسط تا بالا |
| صفحه اصلی | LCP Hero، Third-partyها، Carousel و Widgetها | بالا |
برای یک سایت‌ساز یا فروشگاه‌ساز، این رویکرد یک مزیت دیگر دارد: وقتی Component مشترک بهینه شود، صدها سایت یا صفحه از آن سود می‌برند. به همین دلیل Performance باید بخشی از Design System و Page Builder باشد، نه کاری که بعد از طراحی انجام می‌شود.
چک‌لیست ۳۰ دقیقه‌ای برای پیدا کردن گلوگاه‌ها
- در PageSpeed Insights صفحه اصلی و یک صفحه مهم داخلی را بررسی کنید و Field Data را از Lab Data جدا بخوانید.
- در DevTools مشخص کنید عنصر LCP دقیقاً چیست؛ اگر تصویر است، اندازه فایل، زمان کشف و Priority آن را بررسی کنید.
- Long Taskهای Thread اصلی را در Performance panel پیدا کنید و ببینید کدام Script یا Component عامل آن است.
- Layout Shiftها را ثبت کنید و عناصر بدون width/height، Bannerهای Async و تغییر فونت را بررسی کنید.
- لیست Third-party scriptها را بنویسید و برای هرکدام ضرورت اجرای قبل از تعامل را مشخص کنید.
- روی موبایل واقعی یا Network/CPU محدودشده تست کنید؛ تست روی لپ‌تاپ سریع فقط بخشی از واقعیت است.
- پس از اصلاح، تغییر را در Production و داده کاربران واقعی پیگیری کنید؛ نه فقط در یک تست Lighthouse.
اشتباهات رایج در بهینه‌سازی Core Web Vitals
فقط دنبال امتیاز ۱۰۰ Lighthouse بودن
امتیاز Lighthouse ابزار هدف‌گذاری نیست؛ ابزار تشخیص است. ممکن است با حذف امکانات ضروری امتیاز را بالا ببرید اما تجربه محصول بدتر شود. هدف، تجربه سریع و قابل اعتماد برای کاربران واقعی است.
Preload کردن همه چیز
preload منابع را مهم اعلام می‌کند. اگر ده‌ها فایل را Preload کنید، مفهوم اولویت را از بین می‌برید و حتی منابع بحرانی با رقابت بیشتری روبه‌رو می‌شوند. فقط چیزهایی را Preload کنید که واقعاً در مسیر بحرانی هستند.
Lazy-load کردن تصویر LCP
تصویر بالای صفحه که احتمالاً LCP است معمولاً نباید مانند تصاویر پایین صفحه با تأخیر بارگذاری شود. Lazy Loading ابزار خوبی است، اما استفاده بی‌قاعده از آن می‌تواند LCP را بدتر کند.
اندازه‌گیری فقط یک URL
سایت از Templateهای مختلف ساخته شده است. صفحه مقاله ممکن است عالی باشد اما محصول یا Checkout مشکل داشته باشد. نمونه‌ای از هر Template مهم را تست کنید و داده Field را در سطح گروه URL دنبال کنید.
نادیده گرفتن تغییرات بعد از انتشار
Performance یک پروژه یک‌باره نیست. اضافه شدن Chat widget، فونت جدید، Tracking script یا Hero جدید می‌تواند نتیجه را تغییر دهد. Budget عملکرد و مانیتورینگ روندی، جلوی بازگشت مشکلات را می‌گیرد.
سازکد چه ارتباطی با Core Web Vitals دارد؟
کاربری که با سایت‌ساز کار می‌کند نباید برای هر صفحه از صفر درباره Cache، Responsive Image، Hydration و Layout Shift تصمیم بگیرد. بخشی از ارزش یک پلتفرم مدرن این است که خروجی فنی سالم را به‌عنوان پیش‌فرض ارائه دهد. سازکد با معماری مبتنی بر Next.js و صفحه‌ساز می‌تواند این بهینه‌سازی‌ها را در سطح Component و Template استاندارد کند؛ یعنی به‌جای اصلاح تک‌تک صفحات، رفتار درست در ابزار ساخت صفحه تعبیه شود.
این موضوع به‌خصوص برای سایت‌های فروشگاهی، آموزشی، خبری، دانلود و فیلم/سریال مهم است؛ چون تعداد صفحه زیاد می‌شود و مشکلات تکرارشونده مانند تصویر بدون ابعاد، اسلایدر سنگین یا JavaScript اضافه می‌تواند در صدها URL تکرار شود. اگر پلتفرم از ابتدا محدودیت‌ها و پیش‌فرض‌های درست داشته باشد، کاربر نهایی با دانش فنی کمتر هم خروجی باکیفیت‌تری می‌گیرد.
پیشنهاد CTAهای طبیعی
| محل | متن پیشنهادی | انکر/دکمه |
| بعد از بخش اندازه‌گیری | اگر هنوز سایت ندارید، از همان ابتدا پلتفرمی انتخاب کنید که سرعت و ساختار فنی را بخشی از طراحی بداند. | مشاهده امکانات سایت‌ساز سازکد |
| بعد از بخش فروشگاه | برای فروشگاه، Performance باید در قالب محصول، دسته‌بندی و Checkout از ابتدا دیده شود. | آشنایی با فروشگاه‌ساز سازکد |
| انتهای مقاله | اگر می‌خواهید بدون درگیری با جزئیات زیرساخت، سایت خود را با یک صفحه‌ساز مدرن راه‌اندازی کنید، امکانات سازکد را بررسی کنید. | شروع ساخت سایت با سازکد |
سوالات متداول
آیا Core Web Vitals مستقیماً روی رتبه گوگل اثر دارد؟
Google توصیه می‌کند Core Web Vitals خوب داشته باشید و آن را در چارچوب تجربه صفحه و سیستم‌های رتبه‌بندی مطرح می‌کند؛ اما این معیارها جای کیفیت و ارتباط محتوا با نیت جستجو را نمی‌گیرند. بهینه‌سازی آن‌ها باید بخشی از یک استراتژی سئو و تجربه کاربری کامل باشد.
LCP خوب چند ثانیه است؟
هدف پیشنهادی فعلی برای تجربه خوب، LCP حداکثر ۲.۵ ثانیه در صدک ۷۵ بازدیدها است.
INP خوب چقدر است؟
برای تجربه خوب، INP باید حدود ۲۰۰ میلی‌ثانیه یا کمتر باشد. اگر بیش از ۵۰۰ میلی‌ثانیه شود، در محدوده ضعیف قرار می‌گیرد.
CLS خوب چه عددی است؟
CLS حدود ۰.۱ یا کمتر به‌عنوان محدوده خوب شناخته می‌شود. رزرو ابعاد تصویر، جلوگیری از تزریق محتوای جدید در بالای صفحه و مدیریت فونت از راهکارهای مهم کاهش آن هستند.
آیا Next.js خودکار Core Web Vitals را خوب می‌کند؟
خیر. Next.js ابزارهای مفیدی برای Rendering، Image، Font، Code Splitting و Server Components فراهم می‌کند، اما معماری و نحوه استفاده تعیین‌کننده است. یک اپلیکیشن Next.js با JavaScript زیاد و Third-party سنگین همچنان می‌تواند INP یا LCP ضعیف داشته باشد.
برای شروع بهینه‌سازی کدام شاخص را اول اصلاح کنیم؟
شاخصی را که داده واقعی کاربران در صفحات مهم به‌عنوان مشکل نشان می‌دهد. اگر چند مشکل دارید، صفحاتی را اولویت دهید که بیشترین ترافیک یا ارزش تبدیل را دارند و اصلاح Template آن‌ها روی URLهای بیشتری اثر می‌گذارد.
جمع‌بندی
Core Web Vitals زمانی مفید است که از یک مسابقه امتیاز به یک فرایند مهندسی تجربه کاربر تبدیل شود. LCP می‌گوید کاربر چه زمانی محتوای اصلی را می‌بیند، INP نشان می‌دهد رابط هنگام تعامل چقدر پاسخ‌گو است و CLS میزان ثبات صفحه را می‌سنجد. برای رسیدن به نتیجه واقعی، ابتدا داده کاربران واقعی را ببینید، سپس با ابزارهای آزمایشگاهی علت را پیدا کنید، اصلاح را در Template یا Component انجام دهید و بعد از انتشار دوباره اندازه‌گیری کنید.
در پلتفرم‌هایی مانند سازکد که سایت‌ها با Page Builder و معماری Next.js ساخته می‌شوند، فرصت مهم این است که بخش بزرگی از Performance در سطح سیستم حل شود: تصویرها ابعاد مشخص داشته باشند، منابع اصلی اولویت درست بگیرند، JavaScript فقط جایی ارسال شود که تعامل نیاز دارد و Componentهای مشترک از ابتدا با بودجه عملکرد طراحی شوند. نتیجه، سایتی است که نه فقط در تست فنی، بلکه در استفاده روزمره سریع‌تر و قابل اعتمادتر احساس می‌شود.
اگر می‌خواهید بدون درگیری با جزئیات زیرساخت، سایت خود را با یک صفحه‌ساز مدرن راه‌اندازی کنید، امکانات سازکد را بررسی کنید.