طراحی UX برای CWV: چگونه تصمیمات طراحی مستقیماً بر Core Web Vitals تأثیر میگذارند؟

برای «سارا»، مدیر بازاریابی فنی، Core Web Vitals (CWV) اغلب به عنوان مجموعهای از متریکهای فنی ترسناک به نظر میرسد که در حوزه کاری توسعهدهندگان (Devs) قرار میگیرد. ما در مورد بهینهسازی Core Web Vitals صحبت میکنیم و بلافاصله به مفاهیمی مانند فشردهسازی جاوا اسکریپت، Caching سرور و Preload کردن فونتها فکر میکنیم. اما این تنها نیمی از ماجراست.
آنچه در این مقاله میخوانید
- طراحی UX برای CWV: چگونه تصمیمات طراحی مستقیماً بر Core Web Vitals تأثیر میگذارند؟
- Core Web Vitals: ترجمه فنی «احساس» کاربر
- ارتباط طراحی UX و LCP: طراحی برای «سرعت درکشده»
- چگونه تصمیمات طراحی UX مستقیماً LCP را «تخریب» میکنند؟
- اصول UX برای سرعت سایت: چگونه برای LCP سریع طراحی کنیم؟
- ارتباط طراحی UX و CLS: طراحی برای «ثبات بصری»
- چگونه تصمیمات طراحی UX مستقیماً CLS را «ایجاد» میکنند؟
- اصول UX برای سرعت سایت: چگونه برای CLS صفر طراحی کنیم؟
- ارتباط طراحی UX و INP: طراحی برای «پاسخگویی»
- چگونه تصمیمات طراحی UX مستقیماً INP را «تخریب» میکنند؟
- اصول UX برای سرعت سایت: چگونه برای INP پایین طراحی کنیم؟
- نتیجهگیری: طراحی UX، خط مقدم بهینهسازی CWV
واقعیت فنی این است: Core Web Vitals اساساً متریکهای تجربه کاربری (UX) هستند که به صورت فنی اندازهگیری میشوند. هر خطای LCP, CLS, و INP که توسعهدهندگان به سختی در حال رفع آن هستند، ریشه در یک «تصمیم طراحی» (Design Decision) دارد که هفتهها یا ماهها قبل، در نرمافزاری مانند Figma گرفته شده است.
این مقاله به «سارا» کمک میکند تا این پل حیاتی را بسازد. ما به طور عمیق بررسی خواهیم کرد که چگونه طراحی UX برای CWV فقط یک عبارت جذاب نیست، بلکه یک فرآیند ضروری در طراحی UI/UX مدرن است. ما نشان خواهیم داد که چگونه انتخابهای طراحان در مورد چیدمان، تصاویر و انیمیشنها مستقیماً بر تاثیر UX بر Core Web Vitals تأثیر میگذارد.
Core Web Vitals: ترجمه فنی «احساس» کاربر
تا پیش از این، «تجربه کاربری» (UX) یک مفهوم «نرم» (Soft) بود که از طریق مصاحبه با کاربر، پرسونا و نقشههای همدلی اندازهگیری میشد. اما گوگل با معرفی Core Web Vitals، این مفاهیم نرم را به اعداد «سخت» (Hard) و قابل اندازهگیری تبدیل کرد. CWV، تلاش گوگل برای «کمیسازی» (Quantify) ناامیدی کاربر در مقیاس وب است.
طراحی UX برای CWV یعنی درک اینکه هر متریک، مستقیماً به یک اصل اساسی طراحی UI/UX متصل است:
- LCP (Largest Contentful Paint):
- متریک فنی: سرعت بارگذاری بزرگترین عنصر در Viewport.
- اصل UX معادل: «سرعت بارگذاری درکشده» (Perceived Load Speed). به کاربر چقدر «سریع» احساس میشود؟ آیا سایت «احساس» شکستگی و کندی دارد؟
- CLS (Cumulative Layout Shift):
- متریک فنی: مجموع تمام پرشهای چیدمان غیرمنتظره.
- اصل UX معادل: «ثبات بصری» (Visual Stability). آیا استفاده از سایت «آزاردهنده» است؟ آیا عناصر در حین خواندن جابجا میشوند؟
- INP (Interaction to Next Paint):
- متریک فنی: مدت زمان پاسخگویی به تعامل کاربر (کلیک، تپ، تایپ).
- اصل UX معادل: «پاسخگویی» (Responsiveness). آیا سایت «کلنگی» (Clunky) و «گیرکرده» (Janky) احساس میشود؟ آیا دکمهها کار میکنند؟
بنابراین، تجربه کاربری و CWV دو روی یک سکه هستند. یک طراح UX که این ارتباط را درک نکند، به طور فعال در حال ایجاد بدهی فنی (Technical Debt) برای تیم توسعه است.
ارتباط طراحی UX و LCP: طراحی برای «سرعت درکشده»
LCP (Largest Contentful Paint) یکی از واضحترین نقاط تلاقی بین طراحی و عملکرد است. این متریک، لحظهای را اندازهگیری میکند که کاربر احساس میکند صفحه «بارگذاری شده است»، زیرا بزرگترین (و احتمالاً مهمترین) قطعه محتوا ظاهر شده است.
چگونه تصمیمات طراحی UX مستقیماً LCP را «تخریب» میکنند؟
«سارا» اغلب میبیند که بهینه سازی LCP به عنوان یک کار فنی (فشردهسازی تصویر، فعال کردن CDN) تلقی میشود. اما ریشه مشکل اغلب در فایل Figma است:
۱. وسواس «Hero Image» تمامصفحه
این رایجترین مقصر است. طراحان عاشق هدرهای (Hero Section) بزرگ، تمامصفحه و با یک تصویر پسزمینه خیرهکننده هستند. این تصویر تقریباً *همیشه* عنصر LCP است. اگر این تصویر یک فایل JPEG 2 مگابایتی و بهینهنشده باشد، LCP فاجعهبار خواهد بود. این یک «تصمیم طراحی» است که عملکرد را قربانی زیباییشناسی کرده است.
۲. استفاده از اسلایدرها و کاروسلها (Carousels) در ATF
دومین مقصر بزرگ. طراحان اسلایدرها را دوست دارند زیرا به آنها اجازه میدهد چندین پیام بازاریابی را در یک فضا «فشرده» کنند.
مشکل فنی: اسلایدرها تقریباً همیشه به جاوا اسکریپت (JS) سنگین برای اجرا نیاز دارند. این بدان معناست که مرورگر نمیتواند عنصر LCP (اولین اسلاید) را تا زمانی که آن فایل JS حجیم را دانلود، تجزیه و اجرا نکرده است، رندر کند. این یک فاجعه برای طراحی UX و LCP است.
۳. پنهان کردن محتوای اصلی پشت عناصر دیگر
گاهی اوقات عنصر LCP (مانند تیتر H1 یا تصویر اصلی) آماده رندر شدن است، اما یک «تصمیم طراحی» دیگر جلوی آن را میگیرد:
- پاپآپ GDPR/Cookie: یک بنر کوکی که به محض ورود، روی صفحه ظاهر میشود و LCP اصلی را پنهان میکند.
- اسپینر بارگذاری (Loading Spinner): طراح تصمیم میگیرد که کل صفحه را پنهان کند و یک انیمیشن لودینگ نشان دهد تا “تجربه یکپارچه” شود. این کار به طور مصنوعی LCP را به تأخیر میاندازد.
اصول UX برای سرعت سایت: چگونه برای LCP سریع طراحی کنیم؟
طراحی UX برای CWV به معنای تغییر فرآیند فکری طراح است:
- فلسفه طراحی Mobile-First را بپذیرید: این مهمترین اصل است. وقتی شما طراحی Mobile-First را اجرا میکنید، «مجبور» هستید که با محدودیت شروع کنید. شما به طور طبیعی یک تصویر هیرو سبکتر و بهینهتر را انتخاب خواهید کرد. مشکلات LCP اغلب ناشی از رویکرد «Desktop-First» و کوچک کردن یک طرح سنگین برای موبایل است.
- اولویتبندی بیرحمانه Above-the-Fold (ATF): «سارا» باید از تیم طراحی بپرسد: “مطلقاً ضروریترین عنصری که کاربر باید در ۵۰۰ میلیثانیه اول ببیند چیست؟” پاسخ باید «یک» چیز باشد (مثلاً تیتر H1 یا یک تصویر محصول کوچک). تمام عناصر دیگر باید از نظر بصری و فنی (از طریق
loading="lazy") به «بعداً» موکول شوند. - LCP استاتیک طراحی کنید: عنصر LCP باید «ساده» باشد. باید HTML و CSS خالص باشد (یک
<h1>یا یک<img>). هرچه LCP برای رندر شدن به JS کمتری وابسته باشد، سریعتر خواهد بود.
طراحی UX و LCP یعنی پذیرش این واقعیت که «تجربه» یک بارگذاری سریع، بسیار قدرتمندتر از «تجربه» یک تصویر هیروی سنگین است که اصلاً بارگذاری نمیشود.
— پایان بخش ۱ —
ارتباط طراحی UX و CLS: طراحی برای «ثبات بصری»
CLS (Cumulative Layout Shift) آزاردهندهترین متریک تجربه کاربری و CWV است. این متریک، آن لحظه ناامیدکنندهای را اندازهگیری میکند که شما میخواهید روی یک دکمه کلیک کنید، اما ناگهان یک تبلیغ بارگذاری میشود و همه چیز را به پایین هل میدهد و شما روی لینک اشتباهی کلیک میکنید. این متریک، اندازهگیری مستقیم «ناامیدی» کاربر است.
برخلاف LCP، رفع خطای CLS تقریباً ۱۰۰٪ یک «مشکل طراحی» است که در فرآیند طراحی و توسعه ایجاد میشود.

چگونه تصمیمات طراحی UX مستقیماً CLS را «ایجاد» میکنند؟
طراحی UX و CLS مستقیماً به مفهومی به نام «رزرو فضا» (Space Reservation) گره خورده است.
۱. خطای «جعبه بدون ابعاد» (Dimensionless Box)
این مقصر شماره یک است. طراح در Figma یک «جعبه» برای یک تصویر، یک ویدئو، یا یک بنر تبلیغاتی قرار میدهد. اما در سند «تحویل طراحی» (Design Handoff) به توسعهدهنده، «ابعاد» (Dimensions) یا «نسبت ابعاد» (Aspect Ratio) آن جعبه را مشخص نمیکند.
مشکل فنی: توسعهدهنده یک تگ <img> بدون width و height قرار میدهد. مرورگر شروع به رندر کردن صفحه میکند، متن را نمایش میدهد (فضای صفر را برای تصویر در نظر میگیرد)، و *سپس* فایل تصویر دانلود میشود. به محض رسیدن تصویر، مرورگر میفهمد که به ۳۰۰ پیکسل ارتفاع نیاز دارد و کل چیدمان صفحه را به پایین «هل» میدهد (Shift) تا فضا باز کند. این یک CLS عظیم است که ریشه در یک «خلاء ارتباطی» بین طراح و توسعهدهنده دارد.
۲. تزریق محتوای دینامیک (Dynamic Content Injection)
این یک تصمیم طراحی UX بسیار رایج است:
- “بیایید یک بنر کوکی در بالای صفحه نشان دهیم.”
- “بیایید یک اعلان ‘ارسال رایگان’ را در بالای هدر تزریق کنیم.”
مشکل فنی: اگر این بنرها پس از رندر شدن محتوای اصلی بارگذاری شوند و خود را به بالای DOM «تزریق» (Inject) کنند، کل صفحه را به پایین هل میدهند و باعث CLS فاجعهبار میشوند.
۳. فونتهای وب و FOUT/FOIT
طراح یک فونت سفارشی سنگین را برای تیترها انتخاب میکند. مرورگر ابتدا تیتر را با فونت سیستمی (مثلاً Arial) رندر میکند. چند ثانیه بعد، فونت سفارشی سنگین دانلود میشود. این فونت جدید ممکن است «بلندتر» یا «پهنتر» از فونت سیستمی باشد. مرورگر فونتها را «جایگزین» (Swap) میکند و این جایگزینی باعث «پرش» متن و تغییر چیدمان (CLS) میشود.
اصول UX برای سرعت سایت: چگونه برای CLS صفر طراحی کنیم؟
طراحی UX برای CWV در اینجا به معنای «طراحی برای پایداری» است.
- قانون شماره ۱: هرگز عنصری را بدون ابعاد رها نکنید. طراح UX *باید* در سند طراحی، نسبت ابعاد (Aspect Ratio) (مانند ۱۶:۹ یا ۴:۳) را برای *تمام* عناصر رسانهای (تصاویر، ویدئوها، iFrameها، تبلیغات) مشخص کند. این به توسعهدهنده اجازه میدهد تا با استفاده از CSS (مانند
aspect-ratio) فضا را «رزرو» کند، حتی قبل از بارگذاری محتوا. - قانون شماره ۲: بنرها را «تزریق» نکنید، «روکش» کنید. تمام عناصر غیرمنتظره (بنر کوکی، پاپآپ) باید به عنوان «روکش» (Overlay) طراحی شوند (با استفاده از
position: fixedیاabsolute) که روی محتوا شناور میشوند، نه اینکه محتوا را هل دهند. - قانون شماره ۳: اصول طراحی UI مبتنی بر ثبات را اجرا کنید. استفاده از «سیستمهای طراحی» (Design Systems) و گریدبندی (Grids) ثابت، ذاتاً به کاهش CLS کمک میکند، زیرا چیدمانها قابل پیشبینی هستند.
ارتباط طراحی UX و INP: طراحی برای «پاسخگویی»
INP (Interaction to Next Paint) جدیدترین و شاید پیچیدهترین متریک تجربه کاربری و CWV است. این متریک، «احساس کلنگی بودن» (Clunkiness) یک سایت را اندازهگیری میکند. وقتی کاربر روی دکمهای کلیک میکند، منویی را باز میکند یا در فرمی تایپ میکند، چقدر طول میکشد تا یک «پاسخ بصری» (Visual Feedback) دریافت کند؟
چگونه تصمیمات طراحی UX مستقیماً INP را «تخریب» میکنند؟
INP به شدت به جاوا اسکریپت (JS) گره خورده است. طراحی UX و INP یعنی درک اینکه «ویژگیهای» فانتزی طراحی، هزینه عملکردی دارند.

۱. وسواس انیمیشنهای پیچیده (Over-Animation)
طراحان عاشق انیمیشنهای ورودی (Fade-in on scroll)، افکتهای پارالاکس (Parallax scrolling) و هاورهای (Hover effects) پیچیده هستند.
مشکل فنی: بسیاری از این انیمیشنها (اگر به درستی با CSS Transforms بهینهسازی نشوند) بر روی «رشته اصلی» (Main Thread) مرورگر اجرا میشوند. این همان رشتهای است که مسئول پاسخگویی به کلیکهای کاربر است. در نتیجه، مرورگر آنقدر مشغول اجرای انیمیشن پارالاکس است که نمیتواند به کلیک کاربر بر روی دکمه «خرید» پاسخ دهد. این باعث INP بالا میشود.
۲. طراحی اجزای سنگین (Heavy Components)
یک «مگامنو» (Mega Menu) با صدها لینک و تصویر، یا یک «فیلتر محصول» در صفحه دستهبندی که با هر کلیک روی یک چکباکس، کل صفحه را رفرش میکند. اینها «تصمیمات طراحی» هستند که به JS بسیار سنگینی برای اجرا نیاز دارند و باعث میشوند تعامل، کند و طاقتفرسا احساس شود.
۳. عدم طراحی «حالتهای بازخورد» (Feedback States)
این یک خطای کلاسیک طراحی UX و INP است. کاربر روی دکمه «ارسال» در یک فرم کلیک میکند. ارسال فرم به سرور ۳ ثانیه طول میکشد. در این ۳ ثانیه، *هیچ اتفاق بصری* رخ نمیدهد. دکمه به همان شکل باقی میماند.
مشکل UX: کاربر فکر میکند دکمه «شکسته است». او دوباره و دوباره کلیک میکند (Rage Clicks). این «احساس» عدم پاسخگویی، دقیقاً همان چیزی است که متریک INP اندازهگیری میکند.
اصول UX برای سرعت سایت: چگونه برای INP پایین طراحی کنیم؟
طراحی UX برای CWV در اینجا به معنای «طراحی برای تعامل آنی» است.
- قانون شماره ۱: بازخورد فوری بصری (Instant Visual Feedback). این مهمترین اصل است. طراح UX *باید* حالتهای مختلفی را برای عناصر تعاملی طراحی کند:
- حالت Loading: دکمه «ارسال» پس از کلیک باید *بلافاصله* به “در حال ارسال…” با یک اسپینر تغییر کند.
- حالت Disabled: دکمه باید تا زمان تکمیل فرآیند، غیرفعال شود تا از کلیکهای مکرر جلوگیری شود.
- قانون شماره ۲: انیمیشنهای «عملکردی» به جای «تزئینی». «سارا» باید تیم طراحی را به چالش بکشد: “آیا این انیمیشن به کاربر کمک میکند تا بفهمد چه اتفاقی افتاده است (مثلاً یک آیتم که به سبد خرید پرواز میکند) یا فقط تزئینی است؟” انیمیشنهای تزئینی سنگین باید حذف شوند.
- قانون شماره ۳: تعاملات را «Debounce» کنید. در طراحی فیلترهای جستجو، طراح نباید درخواست کند که نتایج با «هر ضربه به کلید» (on keypress) بهروز شوند. طراحی باید بر اساس «Debouncing» باشد (یعنی پس از توقف تایپ کاربر به مدت ۳۰۰ میلیثانیه، جستجو را اجرا کن). این یک تصمیم طراحی UX است که بار روی Main Thread را به شدت کاهش میدهد.

نتیجهگیری: طراحی UX، خط مقدم بهینهسازی CWV
طراحی UX برای CWV به معنای بازگرداندن مسئولیت عملکرد به جایی است که به آن تعلق دارد: مرحله طراحی. «سارا» به عنوان مدیر بازاریابی فنی، باید این ارتباط را درک کند و به عنوان پلی بین طراحان و توسعهدهندگان عمل کند.
همانطور که مراجع معتبری چون web.dev خود گوگل و Nielsen Norman Group (NN/g) تأیید میکنند، تجربه کاربری و CWV جداییناپذیرند. یک طراحی ضعیف که اصول طراحی UX و LCP (اولویتبندی ATF)، طراحی UX و CLS (رزرو فضا)، و طراحی UX و INP (بازخورد فوری) را نادیده میگیرد، نه تنها یک تجربه کاربری بد ایجاد میکند، بلکه مستقیماً به رتبهبندی سئوی سایت آسیب میزند.
در نهایت، یک طراحی UI/UX عالی، طراحیای است که «نامرئی» احساس شود—سریع، پایدار و پاسخگو. Core Web Vitals ابزارهایی هستند که به ما کمک میکنند تا این «نامرئی بودن» را به صورت فنی اندازهگیری کنیم.

