راهنمای فنی Core Web Vitals گوگل

به جمع‌آوری اطلاعات  Core Web Vitals و همچنین نکات و ابزارهایی که می‌توانند بهبود عملکرد وبسایت شما را افزایش دهند و تجربه کاربری بهتری ارائه دهند،در این مقاله پرداخته و بهره‌برداری نمایید.

جمع‌آوری اطلاعات مربوط به عملکرد وبسایت شما، اولین گام مهم در بهبود تجربه کاربری است. در طول سال‌ها، گوگل ابزارهای متعددی را برای ارزیابی و گزارش عملکرد وبسایت‌ها ارائه کرده است.

یکی از این ابزارها Core Web Vitals است که شامل مجموعه‌ای از شاخص‌های عملکردی است که گوگل آن‌ها را برای تمام تجربیات وب به عنوان عناصر حیاتی تلقی می‌کند. این اطلاعات مهم به شما کمک می‌کنند تا مشکلات عملکردی را شناسایی کرده و بهینه‌سازی‌های لازم را برای ارائه تجربه کاربری بهتری انجام دهید.

در این مقاله، به مجموعه فعلی Core Web Vitals و نکات و ابزارهای کلیدی برای بهبود عملکرد وب‌سایت خود به منظور ارائه یک تجربه خوب برای کاربران پرداخته شده است.

نگاهی به تکامل عملکرد وب

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

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

امروزه، سرعت اتصالات به شدت افزایش یافته است. بیشتر منابع به طور پیش‌فرض فشرده می‌شوند و افزونه‌های زیادی فشرده‌سازی تصاویر، استفاده از حافظه نهان و موارد مشابه را به عهده دارند.

تلاش‌های گوگل برای بهبود سرعت وبسایت‌ها همچنان ادامه دارد. ابزار PageSpeed Insights (PSI) هنوز هم در وب‌سایت web.dev فعال است و به عنوان بهترین ابزار برای ارزیابی زمان بارگیری صفحات وب سایت‌های شخصی شناخته می‌شود.

اگرچه بسیاری اعتقاد دارند که امتیازهای PSI بی‌لازم تشدید کننده‌اند، اما همچنان PSI نزدیک‌ترین ابزاری است که ما می‌توانیم از طریق آن نحوه ارزیابی و رتبه‌بندی وب‌سایت‌ها بر اساس سیگنال‌های سرعت صفحه را درک کنیم.

برای موفقیت در آزمون آخرین بررسی سرعت صفحه توسط گوگل، شما باید نیازمندی‌های مرتبط با Core Web Vitals را اجرا کنید.

مقاله مرتبط : چطور سرعت سایت را اندازه گیری کنیم

درک عملکرد Core Web Vitals

Core Web Vitals مجموعه‌ای از استانداردهایی هستند که در سیگنال‌های جستجو برای ارزیابی تجربه صفحه وب در سال ۲۰۲۱ به یکپارچه شده‌اند. بر طبق اظهارات گوگل، این معیارها از اهمیت بسیاری برخوردار هستند و در تعیین نتایج جستجو مؤثر هستند.

مجموعه فعلی معیارهای Core Web Vitals عبارتند از:

۱. First Contentful Paint (FCP: زمانی که مرورگر اولین محتوایی را در صفحه وب نمایش می‌دهد، به عنوان FCP شناخته می‌شود. این معیار به نمایش زمان بارگیری اولین محتوا در صفحه اشاره دارد.

۲. First Input Delay (FID): این معیار نشان‌دهنده تأخیری است که کاربران احساس می‌کنند زمانی که تا زمانی که مرورگر به واکنش به ورودی کاربر می‌پردازد. این معیار به عنوان Interaction to Next Paint نیز شناخته می‌شود.

۳. Interaction to Next Paint: این معیار مرتبط با زمانی است که طول می‌کشد تا پس از ورودی کاربر، نقطه‌ای دیگر از صفحه وب تا زمانی که مرورگر به رسمیت اولین پیکسل مربوط به آن نقطه را نشان دهد، رسیده شود.

۴. Time to First Byte (TTFB): این معیار به مدت زمانی اشاره دارد که می‌گذرد تا مرورگر از سرور اولین بایت اطلاعات را دریافت کند. این معیار به عنوان یکی از عوامل کلان در سرعت بارگیری صفحه در نظر گرفته می‌شود.

۵. Largest Contentful Paint (LCP): زمانی که بزرگترین محتوایی که در نمایش صفحه وب شامل متن، تصویر یا ویدئو است، به نمایش درآید، به عنوان LCP شناخته می‌شود. این معیار نشان‌دهنده زمان بارگیری محتوای مهم و مرئی در صفحه است.

۶. Cumulative Layout Shift (CLS): این معیار مرتبط با تغییرات لایه‌بندی در صفحه وب است و نمایانگر تغییراتی است که ممکن است باعث ایجاد ازمایشی برای کاربران شود. CLS به عنوان یک شاخص از پایداری تجربه کاربری در نظر گرفته می‌شود.

این معیارها بهبود تجربه کاربری و سرعت بارگیری صفحات وب را اندازه‌گیری و ارزیابی می‌کنند و در بهینه‌سازی سایت‌ها و ارتقاء عملکرد آن‌ها مورد استفاده قرار می‌گیرند.

First Contentful Paint (FCP)

First Contentful Paint (FCP) یکی از معیارهای اصلی در اندازه‌گیری عملکرد یک وب‌سایت است که به زمانی اشاره دارد که مرورگر وب صفحه اولین محتوایی را که به نمایش درآمده، نشان می‌دهد. این محتوا می‌تواند متن، تصویر، ویدئو یا هر عنصر دیگری باشد که به چشم کاربران ظاهر می‌شود.

FCP یکی از شاخص‌های مهم تجربه کاربری (UX) است و به شما می‌گوید که چقدر زمان می‌برد تا کاربران اولین تجربه گرافیکی از وب‌سایت شما را ببینند. زمان FCP باید کم باشد تا کاربران تجربه سریع و تنظیم شده را با وب‌سایت شما داشته باشند، و این می‌تواند بر ترکیبی از عوامل مانند اندازه فایل‌های تصویری، فشرده‌سازی مناسب و بهینه‌سازی کد منابع وب‌سایت بستگی داشته باشد.

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

درست است، متریک First Contentful Paint (FCP) به معنای زمانی است که طول می‌کشد از زمانی که کاربر یک صفحه وب را درخواست می‌کند تا زمانی که محتوای ابتدایی واقعی و قابل مشاهده از صفحه برای او نمایش داده شود. این محتوا می‌تواند متن، تصاویر (شامل تصاویر پس‌زمینه)، عناصر SVG یا عناصر Canvas بدون پس‌زمینه سفید باشد.

FCP یک معیار کلیدی در اندازه‌گیری سرعت بارگیری و تجربه کاربری وب‌سایت است. زمان FCP مشتریان و بازدیدکنندگان را در مورد اینکه وب‌سایت به چه سرعتی برای آنها قابل مشاهده و مفهوم است، آگاه می‌کند. بهبود زمان FCP معمولاً با بهینه‌سازی تصاویر، بهینه‌سازی منابع وب، و کاهش زمان بارگیری کلی صفحه ممکن است دست‌یافته شود.

FCP به نسبت آسان برای درک است. هنگامی که یک صفحه وب بارگیری می‌شود، برخی از عناصر قبل از دیگران وارد می‌شوند (یا به عبارتی "رندر می‌شوند"). در این سیاق، "رندر" به معنای نمایش روی صفحه است.

هرگاه بخشی از صفحه به طور کامل رندر شود - به عنوان مثال، فرض کنید نوار ناوبری اصلی قبل از سایر عناصر بارگیری می‌شود - در آن نقطه FCP ثبت می‌شود.

از آن به عنوان آغازی تا چهار چشم کردن صفحه برای کاربران فکر کنید. بارگذاری کامل صفحه نشده است، اما شروع شده است.

First Input Delay (FID)

"FID میزان زمانی را اندازه گیری می کند که از زمانی که یک کاربر برای اولین بار با یک صفحه تعامل می کند (به عبارتی وقتی روی یک لینک کلیک می کند، روی یک دکمه ضربه می زند یا از یک کنترل سفارشی و قدرت‌بخش‌شده با جاوااسکریپت استفاده می کند) تا زمانی که مرورگر در واکنش به آن تعامل قادر به آغاز پردازش کننده‌های رویدادی مربوط به آن تعامل می‌شود را اندازه گیری می‌کند."

First Input Delay (FID) یک معیار در اندازه‌گیری تجربه کاربری وب است که به زمانی اشاره دارد که از زمانی که کاربر برای اولین بار با یک صفحه تعامل می‌کند (به عبارتی وقتی روی یک لینک کلیک می‌کند، روی یک دکمه ضربه می‌زند، یا از یک کنترل سفارشی و قدرت‌بخش‌شده با جاوااسکریپت استفاده می‌کند) تا زمانی که مرورگر واکنش به آن تعامل قادر به آغاز پردازش کننده‌های رویدادی مربوط به آن تعامل می‌شود، می‌گذرد. به عبارت دیگر، FID نشان‌دهنده تاخیری است که کاربر احساس می‌کند بین زمان تعامل اولیه و واکنش مرورگر به آن تعامل. این معیار مهم در تجربه کاربری وبسایت‌ها بوده و نقش مهمی در ارزیابی سرعت و پاسخگویی وبسایت‌ها ایفا می‌کند.

Interaction to Next Paint (INP)

INP به معنای زمانی است که از زمان تعامل اولیه یک کاربر با یک صفحه وب می‌گذرد (به عبارت دیگر، وقتی کاربر روی یک لینک کلیک می‌کند، روی یک دکمه ضربه می‌زند یا از یک کنترل ویژه با توانایی جاوااسکریپت استفاده می‌کند) تا زمانی که مرورگر واکنش به آن تعامل می‌کند و به رندر کردن بخشی دیگر از صفحه می‌پردازد. به عبارت ساده‌تر، INP نشان‌دهنده تاخیری است که در بین تعامل کاربری و واکنش مرورگر به آن تعامل ایجاد می‌شود و زمانی را نشان می‌دهد که تا زمان رندر کردن بخشی دیگر از صفحه می‌گذرد. این معیار در ارتقاء تجربه کاربری و سرعت بارگیری وبسایت‌ها نقش دارد.

Time to First Byte (TTFB)

TTFB به معنای زمانی است که از زمانی که درخواستی برای یک صفحه وب ارسال می‌شود تا زمانی که مرورگر اولین بایت از پاسخی که از سرور دریافت می‌کند، می‌گذرد. این معیار نشان‌دهنده سرعت پاسخگویی سرور به درخواست کاربران است و زمانی را نشان می‌دهد که سرور به کار کاربر پاسخ می‌دهد. TTFB یکی از عوامل مهم در تعیین سرعت بارگیری یک صفحه وب است و از اهمیت زیادی در بهبود کارایی وب‌سایت‌ها برخوردار است.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) یکی از معیارهای کلیدی در اندازه‌گیری تجربه کاربری وب سایت‌ها است. این معیار به معنای زمانی است که بزرگترین و مهم‌ترین محتوا یک صفحه وب به نمایش درآمده و برای کاربران قابل مشاهده می‌شود. این محتوا معمولاً شامل تصاویر، ویدئوها، متن‌ها یا عناصر گرافیکی دیگر می‌شود که برای تجربه کاربری اساسی و ارتقاء نهایی صفحه بسیار حیاتی هستند.

زمان LCP نقطه ای را نشان می‌دهد که کاربران بزرگترین و مهم‌ترین محتوا را بر روی صفحه مشاهده می‌کنند. این معیار به عنوان یکی از مؤلفه‌های اصلی تجربه کاربری وب در نظر گرفته می‌شود و بهبود آن می‌تواند منجر به بهبود رتبه‌بندی در موتورهای جستجو و جلب کاربران بیشتر شود. برای بهبود LCP، معمولاً نیاز به بهینه‌سازی تصاویر، بهینه‌سازی بارگیری منابع وب و افزایش سرعت بارگیری صفحه داریم.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) یکی از معیارهای کلیدی در اندازه‌گیری تجربه کاربری وب است که مرتبط با پایداری لایه‌بندی صفحه می‌باشد. این معیار نشان‌دهنده تغییراتی است که در طراحی و ظاهر یک صفحه وب رخ می‌دهد و ممکن است باعث ایجاد ازمایش‌ها یا ناخواسته‌هایی برای کاربران شود. CLS اهمیت زیادی در تجربه کاربری وب دارد، زیرا کاربران ممکن است به عنوان ناخواسته به عناصر جدید یا تغییرات ناگهانی در صفحه برخورد کنند که می‌تواند تجربه آنها را تحت تأثیر قرار دهد.

CLS به عنوان یک شاخص از تغییرات لایه‌بندی در نظر گرفته می‌شود. این تغییرات ممکن است به دلیل بارگذاری تأخیری عناصر، تغییر اندازه عناصر یا مشکلات در طراحی وبسایت ایجاد شوند. بهبود CLS معمولاً با بهبود مدیریت عناصر روی صفحه وب، استفاده از ابزارهای بهینه‌سازی تصویر و عناصر چندرسانه‌ای، و رعایت اصول طراحی وب مرتبط با پایداری لایه‌بندی صفحه امکان‌پذیر است.

کاربران تمایل دارند تا صفحاتی که تجربه CLS بهتری دارند را بیشتر از آن‌هایی که تغییرات غیر منتظره و ناگهانی در ظاهر صفحه دارند، ترجیح دهند. بنابراین، بهینه‌سازی CLS می‌تواند به بهبود نهایی تجربه کاربری و افزایش رضایت کاربران کمک کند.

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

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

اگر CSS شما - که تمام استایل‌دهی صفحه شما را کنترل می‌کند - به تعویق افتد، آنگاه محتواهای صفحه ممکن است قبل از اعمال قوانین CSS بارگیری شوند.

این به این معناست که محتواهای صفحه شما بدون استایل بارگیری می‌شوند و سپس کمی به اطراف حرکت می‌کنند در حالی که CSS در حال بارگیری است.

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

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

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

وارد Cumulative Layout Shift (CLS) می‌شویم. این معیاری پیچیده است که اگر سعی کنید افزایش‌های سرعت صفحه را بدون در نظر گرفتن کاربران خود به عنوان یک تغییر عمده اعمال کنید، به شما مشکل وارد می کند

CLS در واقع بارگیری صفحه‌های شما را برای جابجایی‌های آزاردهنده و قوانین CSS تأخیری تجزیه و تحلیل می‌کند.

اگر تعداد زیادی از این مشکلات وجود داشته باشد، شما در ارزیابی Core Web Vitals علامت منفی دریافت می‌کنید، به رغم اینکه تمام معیارهای مرتبط با سرعت را پاس می‌دهید.

ارزیابی Core Web Vitals برای نتایج بهتر UX و SEO

یکی از بهترین روش‌ها برای تجزیه و تحلیل عملکرد یک صفحه وب، اجرای آن در ابزار PageSpeed Insights است. نمره این ابزار به ترکیبی از داده‌های زیر تقسیم می‌شود:

۱. داده‌های سطح URL: این بخش به تجزیه و تحلیل عملکرد یک صفحه خاص در URL مشخص اختصاص دارد. این داده‌ها نمایانگر مسائل مرتبط با صفحه مشخصی هستند و می‌توانند شامل اطلاعاتی مانند زمان بارگیری صفحه، بهینه‌سازی تصاویر، فشرده‌سازی منابع و موارد مشابه باشند.

۲. داده مبدا (سطح دامنه): این بخش به تحلیل عملکرد تمامی صفحات موجود در یک دامنه خاص می‌پردازد. این داده‌ها به تصویر کلی عملکرد دامنه و تأثیر بهینه‌سازی‌های مشابه در تمام صفحات مرتبط با آن اشاره دارند.

۳. داده‌های آزمایشگاهی: این داده‌ها نشان‌دهنده عملکرد صفحه در محیطی متفاوت (معمولاً محیط‌های شبیه‌سازی شده) هستند. این آزمون‌ها معمولاً برای تخصیص امتیازات و ارائه پیشنهادات بهینه‌سازی به مالکان وب‌سایت‌ها انجام می‌شوند.

۴. داده‌های میدانی: این بخش به تحلیل عملکرد واقعی صفحه بر روی دستگاه‌ها و مرورگرهای واقعی کاربران در دسترس می‌پردازد. این داده‌ها از نصب افزونه‌ها و ابزارهای مرورگر برای اندازه‌گیری عملکرد واقعی بر روی وب‌سایت‌ها به دست می‌آیند و به تصویر واقعی‌تری از تجربه کاربری کمک می‌کنند.

با تلفیق این داده‌ها، می‌توانید عملکرد وب‌سایت خود را بهبود دهید و بهینه‌سازی‌های مورد نیاز را اعمال کنید تا تجربه کاربری بهتری را فراهم کنید.

برای درک این موضوع، باید به یک مثال نگاه کنیم:

در اینجا، می‌توانیم رتبه‌بندی‌ها و معیارهای سرعت صفحه را برای صفحه اصلی TechCrunch مشاهده کنیم.

در متن فوق آمده است که ارزیابی Core Web Vitals شکست خورده است و برای تحلیل عملکرد در وب موبایل، باید برگه نتایج موبایل را انتخاب کنید که به طور پیش‌فرض ارائه می‌شود و اهمیت دارد. سپس باید جابجایی مبدا را انتخاب کنید تا بتوانید میانگین داده‌های عمومی در دامنه سایت خود را مشاهده کنید به جای صفحه اصلی یا هر صفحه دیگری که انتخاب کرده‌اید.

در پایین صفحه، ممکن است رتبه‌بندی سرعت صفحه را با یک عدد قدیمی و آشنا مشاهده کنید.

پس تفاوت بین ارزیابی جدید Core Web Vitals و ارزیابی قدیمی سرعت صفحه چیست؟

در واقع، ارزیابی جدید Core Web Vitals (که به صورت عبور/ناموفقیت اعلام می‌شود) بر اساس داده‌های میدانی (کاربران واقعی) استوار است. اما ارزیابی عددی قدیمی بر اساس مدل‌های شبیه‌سازی شده بر روی موبایل و داده‌های آزمایشگاهی تأسیس شده بود که تنها تخمینی از عملکرد وب‌سایت ارائه می‌کردند.

به طور معنایی، گوگل به ارزیابی Core Web Vitals در اصلاح رتبه‌بندی در جستجوها منتقل شده است و به داده‌های واقعی کاربران توجه بیشتری دارد. این تغییر نشان از تمرکز بر تجربه واقعی کاربران در وب‌سایت‌ها دارد و نهایتاً به بهبود کیفیت و سرعت تجربه کاربری منجر می‌شود.

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

به طور معکوس، ارزیابی Core Web Vitals اطلاعات گسترده‌تری ارائه نمی‌دهد، اما این ارزیابی در الگوریتم‌های رتبه‌بندی گوگل تأثیر دارد.

بنابراین، هدف اصلی شما این است که از تشخیص‌های دقیقتر آزمایشگاهی استفاده کنید تا در نهایت به ارزیابی Core Web Vitals (برگرفته از داده‌های میدانی) برسید و مشکلات موجود را رفع کنید. این کمک می‌کند تا تجربه کاربری بهبود یابد و رتبه‌بندی سایت شما در نتایج جستجوی گوگل بهتر شود.

به یاد داشته باشید که هنگامی که تغییراتی در وب‌سایت خود اعمال می‌کنید، اگرچه امتیاز عددی ممکن است تغییرات را به‌سرعت مشاهده کند، اما شما باید منتظر باشید تا گوگل داده‌های میدانی بیشتری را جمع‌آوری کرده و در نهایت ارزیابی Core Web Vitals را پاس کنید.

لازم به ذکر است که ورودی‌های Core Web Vitals و امتیاز عددی قدیمی به برخی از معیارهای یکسان اشاره می‌کنند. به عنوان مثال، هر دوی آنها به First Contentful Paint (FCP)، Largest Contentful Paint (LCP) و Cumulative Layout Shift (CLS) ارجاع داده‌اند.

در واقع، نوع معیارهای مورد بررسی در هر سیستم ارزیابی به نسبت مشابهی است. اما سطح جزئیات و منبع داده‌های مورد بررسی متفاوت است.

شما باید هدف خود را از ارزیابی Core Web Vitals مبتنی بر داده‌های میدانی (واقعی) قرار دهید. اما از آنجا که داده‌های این ارزیابی خیلی گسترده نیستند، ممکن است بخواهید از داده‌های آزمایشگاهی سنتی و تشخیص‌های معمولی برای پیشرفت استفاده کنید.

امید این است که با رفع مسائل مشخص شده در آزمایش‌های آزمایشگاهی و تشخیص‌ها، بتوانید ارزیابی Core Web Vitals را پاس کنید. اما به یاد داشته باشید که این دو آزمون به طور ذاتی به یکدیگر متصل نیستند و هر کدام ویژگی‌ها و معیارهای خود را دارند.

ارزیابی معیارهای وب اصلی (CWV) از طریق ابزار PageSpeed Insights

حالا که معیارهای اصلی Core Web Vitals و نحوه تکنیکی که می‌تواند آن‌ها را برآورده کند را می‌دانید، وقت آن است که یک مثال را مرور کنیم.

بیایید به مرور ما از وب‌سایت TechCrunch برگردیم:

در اینجا، معیار FID بدون مشکل است، و معیار INP فقط با حاشیه‌های باریک مشکل دارد.

CLS برخی از مشکلات را دارد، اما مسائل اصلی به LCP و FCP منتقل می‌شوند.

حالا بیایید بررسی کنیم که PageSpeed Insights چه اطلاعاتی از نظر فرصت‌ها و تشخیص‌ها ارائه می‌دهد.

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

در بالا، می‌توانید یک پیغام کوچک در گوشه بالا سمت راست با رنگ سبز مشاهده کنید.

این پیغام به شما اجازه می‌دهد تا به معیارهای اصلی وب و محدودیت‌ها و تشخیص‌های مختلفی اعمال کنید.

با این حال، در این مورد، داده‌ها یک داستان کاملاً واضح و بدون پیچیدگی دارند.

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

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

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

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

بنابراین، منطقی است که شروع به ایجاد CSS و JavaScript بحرانی و مسیر رندر بحرانی کنیم. انجام این کار به معنای تضمین این است که JavaScript و CSS مورد نیاز بالای صفحه به صورت داخلی (inline) قرار داده شوند در حالی که بقیه به تأخیر انداخته می‌شوند.

این رویکرد به مالک وب‌سایت اجازه می‌دهد تا نیازهای بارگیری صفحه را تأمین کند در حالی که با معیار CLS توازن بیافریند. این کار کاری آسان نیست و معمولاً نیاز به یک توسعه‌دهنده وب حرفه‌ای دارد.

از آنجا که CSS و JavaScript را نیز استفاده نکردیم ، می توانیم یک ممیزی کد عمومی JavaScript را نیز صادر کنیم تا ببینیم آیا JavaScript می تواند هوشمندانه تر مستقر شود.

بیایید به فرصت ها و تشخیص ها برگردیم:

حالا می‌خواهیم بر روی تشخیص‌ها تمرکز کنیم. گوگل با افت کیفیت اتصالات 4G ضعیف، این بررسی‌ها را با اختیار کمتری انجام می‌دهد، به طوری که مواردی مانند کار اصلی رشته اصلی به نظر می‌رسند که بسیار طولانی است (۱۷ ثانیه).

این کار به طور انگشت‌نگر انجام می‌شود تا کاربرانی با پهنای باند کم و/یا دستگاه‌های کند که در سراسر جهان رایج هستند، راضی شوند.

به طور معمول، بسیاری از وظایف مربوط به ارائه و اجرای اسکریپت‌های یک صفحه وب (JavaScript) از طریق موضوع اصلی پردازش مرورگر وب مشتری (که یک موضوع پردازش واحد است) منتقل می‌شوند. این باعث می‌شود که بارگیری صفحه به شدت محدود شود.

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

بنابراین، ارسال سریع بارهای جاوا اسکریپت به کاربر شما معادل است با شلیکندن یک آتش‌سوزی در یک دیوار آجری با شکاف یک سانتی‌متر.

اگرچه کار خوبی است که این ارائه می‌شود، اما همه چیز به این راحتی حل نمی‌شود!

Google به مرورها بیشتر به ما تحمیل می‌کند که مسئولیت پاسخگویی به سرعت مشتری را به عهده بگیریم. می‌پسندید یا نپسندید، وضعیت همین گونه است (بنابراین بهتر است با آن آشنا شویم).

ممکن است از ناامیدی بگویید: "چرا باید چنین باشد؟! مرورگرهای وب سال‌هاست که به چندین موضوع پردازش دسترسی دارند، حتی مرورگرهای تلفن همراه هم گیر کرده‌اند. آیا واقعاً نیاز به این پیچیدگی وجود دارد؟"

در واقعیت، بله، برخی از اسکریپت‌ها قبل از اجرای خود به دیگر اسکریپت‌ها وابسته هستند.

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

بنابراین، دلیل خوبی وجود دارد که اجرای توالی‌ای اسکریپت به عنوان رفتار پیش‌فرض برای مرورگرهای وب مدرن تعیین شده است. ما واژه "پیش‌فرض" را به شدت تأکید می‌کنیم. چرا؟

این به دلیل وجود گزینه‌های دیگر است. یکی از آنها جلوگیری از اجرای هر اسکریپت توسط مرورگر کاربر با پردازش آن‌ها به نیابت از کاربر است. این به عنوان اجرای سمت سرور (SSR) شناخته می‌شود.

این یک ابزار قدرتمند برای باز کردن گره‌های اجرای جاوا اسکریپت در سمت کاربر است . اما چالش های زیادی دارد

سرور شما باید تمام درخواست‌های اسکریپت (از تمام کاربران) را سریعتر از میانگین مرورگر کاربران خود پردازش کند. این مسئله بسیار مهم است.

اگر از این گزینه خوشتان نمی‌آید، خب، بیایید در مورد موازی‌سازی جاوا اسکریپت صحبت کنیم. ایده اصلی این است که از کارگران وب (Web Workers) استفاده کنیم تا تعیین کنند کدام اسکریپت‌ها باید به چه ترتیبی در مقابل کاربر بارگیری شوند، به طوری که ممکن است به صورت موازی بارگیری شوند.

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

با این حال، انجام این کار بسیار دشوار است و به عملکرد توسعه‌دهنده وب حرفه‌ای نیاز دارد

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

در این مثال، این نکته واقعاً جالب است:

بلافاصله می‌توانید مشاهده کنید که در حالی که موضوع اصلی به مدت ۱۷ ثانیه اشغال شده است، ۱۲ ثانیه از آن به اجرای جاوا اسکریپت اختصاص داده شده است.

این نشان می‌دهد که احتمالاً ۱۲ ثانیه از کل ۱۷ ثانیه اجرای موضوع اصلی به اجرای جاوا اسکریپت اختصاص دارد. ما می‌دانیم که تمام جاوا اسکریپت‌ها به طور پیش‌فرض از طریق موضوع اصلی پردازش می‌شوند. این نیز نشان می‌دهد که تمام آن ۱۲ ثانیه اجرای جاوا اسکریپت احتمالاً از زمان اشغال موضوع اصلی بیرون می‌آید.

این یک بینش مهم است، زیرا به ما می‌گوید که بیشترین زمان پردازش اصلی به اجرای جاوا اسکریپت اختصاص دارد. با توجه به تعداد اسکریپت‌هایی که به آن ارجاع داده شده، باور کردن این موضوع دشوار نیست.

آغاز کردن مبارزه با Chrome Dev Tools

حالا وقت آن است که به جزئیات فنی بپردازید و تنظیمات پیش‌فرض را رها کنید.

ابتدا Chrome را باز کنید و یک پروفایل مهمان را ایجاد کنید تا مطمئن شوید هیچ پلاگین یا افزونه‌ای فعال نیست که ممکن است نتایج ما را تحت تأثیر قرار دهد.

مهم است که این اقدامات را از پروفایل مهمان تمیز انجام دهید تا تنظیمات اصلی مرورگر را تغییر ندهید.

سایتی را که می خواهید تجزیه و تحلیل کنید بارگیری کنید. مثلا ما در اینجا همان سایت TechCrunch را انتخاب می کنیم .

کوکی ها را در صورت لزوم بپذیرید. پس از بارگیری صفحه ، Chrome Devtools را باز کنید (روی یک صفحه راست کلیک کرده و بازرسی را انتخاب کنید).

به بخش "Performance" بروید و سپس به قسمت "Screenshots" بروید.

با فشار دادن دکمه بازنشانی (reload) صفحه را بارگذاری کنید تا ضبط بارگیری صفحه انجام شود. سپس یک گزارش تولید خواهد شد:

در اینجا نیاز است که عمیق نفس بکشیم و تلاش کنیم که نگران نشویم.

در بالا، در جعبه به رنگ سبز، یک پنل نمایش داده شده است که درخواست‌ها در طول زمان را نشان می‌دهد.

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

منطقه‌ای که به طور دستی انتخاب کرده‌ام، قسمتی است که با یک جعبه آبی نیمه‌شفاف پوشانده شده است.

در این مورد، من تقریباً دامنه زمانی و رویدادها بین ۳۲ میلی‌ثانیه و ۲.۹۷ ثانیه را انتخاب کرده‌ام. بیایید تمرکز خود را بر روی داخل موضوع اصلی متمرکز کنیم:

آیا به این فکر می‌کردید که قبل‌تر، ما در مورد این صحبت می‌کردم که بیشتر وظایف رندرینگ و اجرای جاوا اسکریپت از طریق گلوگاه موضوع اصلی انجام می‌شوند؟

خوب، حالا نگاهی به داخل آن موضوع اصلی در طول زمان می‌اندازیم. و بله، به رنگ زرد، می‌توانید وظایف زیادی از نوع اسکریپت را مشاهده کنید.

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

اگرچه این یک تصویر قدرتمند است، اما در بخش خلاصه، یک تصویر قدرتمندتر را خواهید یافت:

این تمام داده‌های جزئی را که به بخش‌های موضوعی ساده تقسیم شده است (به عنوان مثال، اجرای اسکریپت، بارگیری، رندرینگ) با استفاده از نمایی به شکل دونات خلاصه می‌شود.

همانطور که می‌بینید، اجرای اسکریپت (script execution) بیشترین بخش از بارگیری صفحه را تشکیل می‌دهد. بنابراین، حدسی که در پیوند داده‌های میدانی و آزمایشگاهی گوگل به مشکلات اجرای جاوا اسکریپت در موضوع اصلی اشاره کرد و به محدودیت‌های اجرایی آن اشاره کرد، به نظر معقولی بوده است.

در سال ۲۰۲۳، این یکی از مسائلی است که بسیاری از آن روبرو می‌شوند، با کمترین راه‌حل‌های آماده و ساده. ایجاد مسیرهای مهم اجرای جاوا اسکریپت پیچیده است. بررسی کد جاوا اسکریپت نیاز به تخصص دارد، و از طرف دیگر، مسائل مرتبط با موازی‌سازی جاوا اسکریپت یا SSR نیز آنقدر ساده نیست.

حالا بیایید و به درخت تماس‌ها نگاه کنیم:

درخت تماس اغلب از پایین به بالا مفیدتر است.

داده ها مشابه است ، اما Call Tree وظایف موضوعی را به بخش های مفید مانند ارزیابی اسکریپت (اجرای اسکریپت) گروه بندی می کند.

سپس می توانید روی یک گروه کلیک کنید ، آن را گسترش دهید و اسکریپت ها را ببینید و چه مدت طول کشید تا بارگیری شود. ۱۱ ٪ از زمان بارگیری PUBADS_IMPL.JSM در حالی که ۶ ٪ از زمان بارگیری Opus.js. گرفته شده است.

ما نمی دانیم که این ماژول ها چیست (و ممکن است شما هم ندانید) ، اما این جایی است که سفر بهینه سازی اغلب آغاز می شود.

اکنون می توانیم یک قدم به عقب برداریم:

• این اسکریپت ها را گوگل کنید و ببینید که آیا آنها بخشی از کتابخانه های شخص ثالث هستند ، چه کاری انجام می دهند و تأثیر آن چیست.
• در مورد چگونگی استقرار هوشمندانه تر این موارد با توسعه دهنده سایت خود مشورت کنید.
• مشکل را به منابع فردی محدود کرده و به دنبال گزینه های دیگر باشید.
• با کسری عملکرد مقابله کنید (یا از طرف دیگر ، برای منابع/پهنای باند بیشتر ، یک محیط میزبانی قوی - اگر واقعاً مورد نیاز است) مبارزه کنید.

ابزارهای دیگر برای اندازه گیری و بهینه سازی برای Core Web Vitals

اگر توانستید تا اینجا با ما باشید، تبریک می‌گویم. در تحلیل سرعت صفحه از Core Web Vitals، ما تنها از منابع زیر استفاده کردیم:

۱. PageSpeed Insights
2. Chrome DevTools (برگه عملکرد)

البته، ابزارهای دیگری نیز موجود هستند که ممکن است به شما در این زمینه کمک کنند:

GTMetrix: به ویژه برای نمودار waterfall خود (که برای دسترسی به آن به یک حساب رایگان نیاز دارد) بسیار مفید است. می‌توانید یاد بگیرید که چگونه این نمودار را بخوانید. فراموش نکنید که GTMetrix به طور پیش‌فرض بدون محدودیت اجرا می‌شود و نتایج خیلی مطلوبی ارائه می‌دهد. حتماً آن را به اتصال LTE تنظیم کنید.

Google Search Console: اگر این ابزار را راه‌اندازی کرده و وب‌سایت خود را تأیید کنید، می‌توانید بسیاری از داده‌های عملکرد و کاربری در طول زمان را مشاهده کنید، از جمله معیارهای Core Web Vitals بر روی صفحات متعدد (جمع‌آوری شده).

Screaming Frog SEO Spider: این ابزار را می‌توان به واسطه‌ی صفحه‌ی page speed API متصل کرد تا اجازه دهد تا به صورت گروهی معیارهای Core Web Vitals را برای صفحات متعددی (Pass یا Fail) دریافت کنید. اگر از صفحه‌ی page speed API رایگان استفاده می‌کنید، باید به طریق منصفانه و بدون اسفنج‌زنی از آن استفاده کنید.

در گذشته، بهبود امتیازات سرعت صفحه شما به سادگی با فشرده‌سازی و بارگذاری تصاویری انجام می‌شد. اما در زمان حال؟ این یک مبارزه پیچیده برای Core Web Vitals است.

آماده باشید که به طور کامل درگیر شوید. هر چیز کمتر از این با شکست مواجه می‌شود.