ابزار CWV چیست؟

CWV یا Core Web Vital که در فارسی به المان‌های هستۀ حیاتی وب ترجمه شده، یکی از ابزارهای مهمی است که در چند سال اخیر بیشتر مورد توجه قرار گرفته است. دلیل به‌وجود آمدن این ابزار را در ادامه توضیح خواهیم داد.

یکی از اولین فاکتورها یا الگوریتم‌هایی که گوگل راه‌اندازی کرد تا با کمک اون سایت‌ها و صفحه‌ها رو ‌بسنجه، پیج رنکه. تاثیر این فاکتور این روزها به دلیل افزایش تعداد صفحه‌هایی که به پیج‌ها لینک داده می‌شن، کم شده. نکته‌ای که در مورد پیج رنک وجود داره اینه که افراد زیادی هستن که اونو دور می‌زنن. ما می‌دونیم که رپورتاژ در واقع دور زدن حساسیت‌های گوگل در مورد لینکه. به‌همین دلیل گوگل به سمت هوشمندانه‌ کردن الگوریتم‌ها رفته.

یکی از متریک‌های هوشمندی که این روزها گوگل استفاده می‌کنه CWV است. این الگوریتم در واقع تجربه‌های کاربر رو اندازه می‌گیره. منظور از تجربه، مدت زمانی است که کاربر در یک سایت می‌گذرونه. این تجربه‌ها از زمانی که فرد، آدرس سایت رو وارد می‌کنه شروع می‌شه. وقتی کاربر وارد سایت می‌شه، تمام مواردی که مشاهده می‌کنه، جزو تجربۀ کاربری اون محاسبه می‌شه. اینکه وقتی کاربر وارد شده، تصویر اولیه و رنگ‌بندی‌ها چقدر اونو جذب کرده، چقدر طول کشیده تا المان‌های مختلف کار کنن. آیا زمانی که مثلا یه فرمی توی سایت هست و کاربر می‌خواد پر کنه، کاراکترها مشخص هستن یا برای پر کردن تاخیر داره.

همۀ این تجربه‌ها تبدیل به فاکتورهای مختلفی شدن که اجزای CWV‌ را تشکیل می‌دن. در سال‌های مختلف این متریک‌ها بهبود پیدا کردن و حالا راحت‌تر و بهتر می‌تونن به گوگل در مورد تجربۀ کاربر اطلاعات بدن. یه پیوند کوچک بین CWV‌ و کانتنت مفید Helpful Content وجود داره. یه کانتنت اگه مفید باشه منو جذب می‌کنه. این مفید بودن باید در کنار عرضۀ خوب قرار بگیره. اگه یه کانتنت خوب، خیلی کند و با کیفیت پایین عرضه بشه، تجربۀ بدی برای من ایجاد می‌کنه.

فاکتورهای اندازه‌گیری Helpful Content

متریک‌هایی که می‌شه از اون‌ها کمک گرفت تا بفهمیم صفحۀ ما برای کاربر مفید هست یا نه شامل این موارد است:

• اینگیجمنت ثانیه‌ای

• اینگیجمنت ریت

• دیوریشن تایم Duration Time

این‌ها دم‌دستی‌ترین ابزارهای اندازه‌گیری مفید بودن محتوای ما هستن.

چطور باید CWV‌ رو اندازه‌گیری کنیم؟

سایت‌های مختلفی برای اندازه‌گیری CWV وجود دارن. بعضی از بهترین این سایت‌ها عبارتند از: 

1- WebPageTest.org: این سایت رو دست‌کم نگیرین. دیتاهای بسیار غنی داره.

2- GTmetrix.com

3- Pagespeed.web.dev‌

4- Lighthouse  

تفکیک دو واژه Render و Load

وقتی وارد مبحث پرفورمنس می‌شیم، باید این دو واژه رو تفکیک کنیم. Load یا دانلود رو می‌دونیم چیه. برای اینکه صفحۀ یه سایت لود بشه و ما بتونیم اونو ببینیم باید یه سری از منابع لود بشن. منابعی مثل عکس‌ها، html ،CSS، جاوا اسکریپت و بسیاری دیگه باید لود بشن و بیان سمت دستگاه ما، تا بتونیم صفحه رو ببینیم. این روندی که باید در این مسیر طی بشه تا ما صفحه رو ببینیم می‌شه Render یا Paint.

این دو واژه رو ما در کنار هم می‌بینیم و تقریبا به یه معنا استفاده می‌شن و در فارسی اونو ترسیم کردن ترجمه می‌کنیم. همۀ این منابعی که گفتیم توسط کدهای html‌ کنار هم چیده می‌شن و توسط کدهای CSS رنگ و لعاب می‌گیرن و تبدیل می‌شن به چیزی که ما به‌عنوان یه وب‌سایت ازش استفاده می‌کنیم.

نکته‌ای که باید بهش توجه کنین اینه: اینکه یه منابعی لود بشه، لزوما رندر نمی‌شه. اینکه منابعی رندر بشه، حتما لود شده است. این اتفاق توی منابع مختلف متفاوته. مثلا توی جاوا اسکریپت، اول باید دانلود بشه و بعد خونده بشه و بعد اجرا بشه تا شما بتونی خروجی رو ببینی. مثلا وقتی شما یه گالری عکس توی سایت دارین، این اسکرول کردن عکس‌ها، بالا و پایین شدنشون، چپ و راست شدن، تپ کردن و این‌ها، توسط جاوا اسکریپت انجام می‌شه. جاوا اسکریپت‌ها عملا فایل‌های اجرایی تحت وب هستن که کلی از منابع سیستم شما (حجم اینترنت، حافظه و ...) رو اشغال می‌کنن.

کدوم ابزار برای سنجش بهتره؟

Light House‌ از همه بهتره. به این دلیل که ما توی ایران هستیم، سایت‌های دیگه تقریبا تحریم هستن. سایت‌هایی که org خارجی هستن، معمولا زیر هیچ عامل تحریمی نمی‌رن چون زیر نظر فاندیشن‌ها هستن. پس از این سایت‌ها می‌تونین استفاده کنین.

وضعیت‌های مختلف Blocking/Connecting/Waiting/Receiving/DNS Lookup

توی جی‌تی متریکس، یه سربرگ به اسم Waterfall داریم. اگه می‌خواین CWV رو خوب یاد بگیرین،‌ باید این بخش واترفال رو عمیق بشید. یه چیزی هست به اسم HAR file، که باید آنالیزش رو یاد بگیرین. برای توضیحش من اینو به یه آقای کارمند بانک پیوند می‌زنم. قدیما وقتی بانک می‌رفتیم این تجهیزات الان وجود نداشت. یه صندوق‌دار بود که کار سختی داشت و وضعیت‌های مختلفی رو تجربه می‌کرد. ما می‌خوایم این استیت‌های مختلف رو با کارمند شبیه‌سازی کنیم.

توی بانک، افراد توی صف بودن تا به صندوق‌دار برسن. وقتی شما نوبتتون می‌شد، ممکن بود که یه زمان کوتاهی صندوق‌دار متوجه شما نشه و مشغول کار قبلی باشه. عملا اون زمانی که شما به سر صف رسیدین و نوبتتون هست و تا وقتی که اون صندوق‌دار به شما بگه که کارتون چیه، شما کارتون انجام نمی‌شد. به این زمان ما Blocking Time می‌گیم.

شما آدرس سایت رو می‌نویسی و اینتر رو می‌زنی. درخواستت رفته، این وسط کلی اتفاق میفته تا این درخواست به سرور یا هاست شما برسه. سرور همون لحظه نمی‌گه بفرمایید این همون چیزی که می‌خواین. ممکنه سرور هنوز داره کار قبلی رو انجام می‌ده. این زمان، خیلی کوتاهه در حد میلیونیوم ثانیه. ولی شما معطل می‌شی. اونجا شما در بلاکینگ تایم هستی و چیز خیلی بدی هم در CWV‌ است.

حالا یه تایم دیگه به اسم Connecting Time هست. اون لحظه‌ای که شما با کارمند بانک چشم‌توچشم می‌شین، همین لحظۀ تماسه. وقتی که شما داری کارتو براش توضیح می‌دی، اون زمان کلی پردازش ذهنی برای دوطرف پیش میاد. که بهش زمان تماس می‌گیم. زمان تماس یه پروسه داره. با فرض اینکه تمام این پردازش‌ها انجام شد، مرحله‌ای که من دارم قبضم رو به کارمند می‌دم، Sending Data اتفاق میفته. در صفحات وب، ما بسیاری وقت‌ها از سمت کلاینت، ارسال دیتا نداریم. اما وقتی که ارسال دیتا داشته باشیم، این یه زمانی رو می‌گیره.

خب من به کارمند زمان می‌دم که فرایند کار من رو انجام بده،‌ در این مدت که من منتظرم که کارم انجام بشه، من عملا در Waiting Time هستم. یعنی زمانی که شما آدرس رو وارد کردین، دیتا رفته و منتظری که خروجی بگیری. ممکنه یه سری واکنش هم داشته باشی. مثلا فکر کن که کارمند وسط کار تو رفته برای ناهار، شما یه زمان انتظار طولانی و یه Experience بد داری. معمولا این زمان انتظار طولانی، منجر به تجربۀ بد می‌شه.

حالا کارمند کارشو انجام داده و می‌خواد قبض رو به من برگردونه. این Receiving Time ماست. یعنی زمانی که شما دیتاها یا فایل‌ها رو دریافت می‌کنین. مثلا مطلب شما 2 کیلو بایته،‌ انقدر زمان طول می‌کشه که دریافت کنین.

مرحله DNS Lookup زمانیه که من آدرس رو نوشتم،‌ اینتر زدم و می‌خواد از مرورگر من به هاست یا سرور برسه. همۀ دستگاه‌های درون اینترنت یه آدرس به اسم آی‌پی دارن. ما عددهای این آی‌پی رو نمی‌دونیم ولی اسم دامنه‌ها رو می‌دونیم. یه جدول رو در نظر بگیرین که یه سمتش دامنه‌ها نوشته شده و یه سمت دیگه آی‌پی‌ها. یه زمانی لازمه تا پردازش بشه که آی‌پی دامنۀ شما کدومه. به این پردازش DNS Lookup می‌گیم. عموما وقتی ما توی هر جدول دوتایی داریم جست‌وجو می‌کنیم، بهش Lookup کردن می‌گیم. DNS Lookup عملا چیزیه که دامنه و آی‌پی رو لوکاپ می‌کنه و به ما نشون می‌ده.

نکته اینه که هر کدام از این مراحل زمان بسیار کوتاهی دارن. مثلا مجموع این زمان‌ها 1.7 میلی‌ثانیه طول می‌کشه. این یعنی 1.7 ثانیه طول می‌کشه تا کد html این سایتی که شما آدرسشو وارد کردی، بیاد. این‌ها رو می‌تونین توی جی‌تی‌ متریکس ببینین. گاهی یه عکس برای اینکه باکیفیت خوب لود بشه به CSS نیاز داره. این باعث می‌شه که زمان لودش طولانی‌تر بشه.

زیرساخت‌های حیاتی برای بهبود CWV چیست و چه باید کرد؟

• وب‌سرور باید آپدیت باشه.

• آی‌او‌اس باید ورژن جدید باشه.

• هاست و سرور بسیار مهمه. بهتره که داخل ایران باشه که راحت در دسترس باشه.

• کلودفلر راه‌اندازی کنین.

• CDN حتما داشته باشین. خودتون هم می‌تونین راه‌اندازی کنین.

• کش‌سرور داشته باشین. بهترین کش‌سروری که می‌تونین استفاده کنین، ردیس و وارنیش هستن که به‌ هاست فروشتون بگین براتون راه‌اندازی می‌کنن.

• اگه وردپرس استفاده می‌کنین حتما WP راکت استفاده کنین. کانفیگش خیلی مهمه.

• از کش‌های مدل مموری بیشتر استفاده کنین. 

بهبود TTFB

اولین بایتی که از سمت سرور به کلاینت می‌رسه، TTFB است. همۀ سئوکارها و دولوپرا وقتی بهشون می‌گی که TTFB من بده، می‌گن که هاست خوب نیست. اما قسمت اعظم TTFB به مسائل و مشکلات داخلی کد و کانفینگ برمی‌گرده. بهبود TTFB‌ به 3 عامل بستگی دارد:

1- ریدایرکت تایم: این باید زیر 30 میلی‌ثانیه باشه. ریدایرکت به 5 وسیله انجام می‌شه:

• DNS

• وب‌ سرور

• بک‌اند

• فرانت‌اند

• جاوا اسکریپت

بهترین حالت به‌وسیلۀ DNS‌ و وب‌سروره و کندترین حالت به‌وسیلۀ فرانت‌اند.

2- کانکت تایم: این به سرور شما برمی‌گرده. باید زیر 50 میلی‌ثانیه باشه.

3- بک‌اند تایم: به کدنویسی بستگی داره.

جمع این‌ها باید در TTFB‌ زیر 500 میلی‌ثانیه باشه. سایت‌های خوب دنیا، زیر این عدد هستن. حل‌ کردن TTFB با سرور، سی‌دی‌ان و کش شما انجام می‌شه.

بهبود LCP و داستان‌های بهینه‌سازی تصاویر

یادتون باشه که سرچ کنسول رو ملاک خودتون قرار بدین. ملاک شما برای اینکه CWV روی سایتتون تاثیر بذاره، سرچ کنسوله. مهم نیست جی‌تی‌متریکس شما چیه. جی‌تی متریکس به CLS ،LCP و IMP اهمیت می‌ده. یکی از فاکتورهای مهم که در رتبه‌بندی‌ها امتیاز بالایی داره، LCP است. امتیاز خوب 28 تا 30 است. در کم شدن LCP مقصر اصلی عکسه.

فرمت عکس‌هاتون رو AVIF یا WEBP کنین. AVIF اولویت بیشتری داره و همۀ مرورگرها هم ساپورتش می‌کنن. بزرگترین عکسی که توی صفحۀ شما داره رندر می‌شه، بیشترین زمان رو روی سیستم می‌گیره. حجمش رو با تغییر فرمت پایین بیارین. سایزش رو هم با توجه به دستگاهتون پایین بیارین.

عکس رو اسکیل (Scale) نکنین. برای اینکه عکس‌ها بهینه‌تر بشن، عکس‌هایی که برای کانتنت اصلیتون هستن رو این فرمت‌هایی که گفتم بذارین. لوگو و آیکون و این‌ها رو یا svg کنین یا از فونت استفاده کنین و تبدیل به فرمت‌های عکس نکنین. در مورد Losless و loosely بخونین تا در فشرده‌سازی تصاویر و منطقش اطلاعات پیدا کنین.

عکس‌هایی که قبل از اسکرول کردن صفحه قرار دارن رو باید پریوریتی‌شون (priority) رو بالا ببرین. این کار رو با پری‌لود، پری کانکت و پری فتچ کردن، می‌تونین انجام بدین. هر کدوم از این‌ها رو نهایتا 3 تا 5 تا بیشتر نداشته باشین. عکس‌هایی که از اسکرول پایین‌ترن، رو حتما از لودینگ مساوی لیزی <img loading=lazy> کنین. لزومی نداره همۀ عکس‌ها همون اول لود بشه. به دولوپر اجازه ندین که لیزی لودینگ رو به‌وسیلۀ جاوا اسکریپت یا CSS انجام بده چون خودش بار می‌ندازه. همۀ بروزرها این خاصیت رو دارن. 

بهبود CLS

برای عکس‌ها حتما طول و عرض بذارین که اسکیل نشن. عکسی که اسکیل بشه عملا باعث CLS می‌شه. اگه عکس‌ها رو درست کردین، اون‌جاهایی که صفحۀ شما به‌وسیلۀ جاوا اسکریپت، یه باکسی یهو لود می‌شه، اون‌جا جاوا اسکریپت مشکل‌ساز می‌شه. می‌تونین برای اون باکسی که کانتنت توش قرار می‌گیره، ویدوهایت فیکس شده قرار بدین.

بهبود TBT

TBT یا Total Blocking Time، بدترین چیزیه که اشک شما رو توی درست کردن پرفورمنس درمیاره. هروقت چشمتون به Minimize Main Trade Work خورد، بدونین که یه پای قضیه، جاوا اسکریپته. یه پای قضیه html شماست. Main Trade در واقع اِلمان‌های اساسی از صفحه که ترسیم صفحه رو به‌عهده دارن. در مجموع کلا سعی کنید جاوا اسکریپت رو کمتر استفاده کنین.