برای تشخیص مشکلات و بهبود عملکرد وبسایت‌تان، باید بتوانید تا عملکرد وبسایت خود را در هر لحظه اندازه‌گیری کرده و گزارشی در خصوص عملکرد آن تهیه کنید. بدون کمک داده‌های میدانی، نمی‌توان با اطمینان گفت که وبسایت شما واقعاً به نتایج مطلوب دست پیدا می‌کند یا نه. بسیاری از ابزارهای تحلیل محبوب همانند RUM، از اندازه‌گیری شاخص‌های Web Vitals نیز پشتیبانی می‌کنند. اگر از ابزارهای تحلیلی RUM استفاده می‌کنید، می‌توانید با موفقیت آستانه توصیه شده برای Core Web Vitals را اندازه‌گیری کنید و با این کار از مشکلات بعدی جلوگیری نمایید.
آنچه در این مطلب می خوانید:
- شاخص‌ها و استانداردهای ابزار خود را شخصی‌سازی کنید
- مطمئن شوید که می‌توانید یک گزارش توزیع بدهید
- دیتا خود را در زمان درست ارسال کنید
- عملکرد وبسایت را در یک بازه زمانی مانیتور کنید
- تغییرات خود را در قالب ورژن قرار دهید
- از حالت اجرای آزمایشی استفاده کنید
- مطمئن شوید که آزمایش شما بر روی عملکرد وبسایت تأثیر نمی‌گذارد
اگر از ابزار تحلیلی که استفاده می‌کنید، از شاخص‌های Core Web Vitals پشتیبانی نمی‌کند، لزوماً نیازی نیست ابزار خود را تغییر دهید. بسیاری از ابزارهای تحلیلی قابلیت اضافه کردن استانداردها و شاخص‌های جدید را دارند. این یعنی می‌توانید روش اندازه‌گیری شاخص‌های Web Vitals را به ابزار خود اضافه کنید. به این طریق می‌توانید اندازه شاخص‌های Core Web vitals را بر روی داشبورد یا گزارش ابزار تحلیلی خود مشاهده نمایید.
برای اندازه‌گیری Core Web Vitals و همچنین اضافه کردن آن‌ها به‌صورت دستی به ابزار خود، باید از یک ابزار In-house یا Third-Party استفاده کنید. همانطور که در این مقاله هم گفته شده، معیارهای کور وب وایتال به جدیدترین معیارهای رتبه‌بندی موتورهای جست‌وجو اضافه شده و باید برای سئو سایت در سال 2021 به آن‌ها توجه ویژه داشت.
شاخص‌ها و استانداردهای ابزار خود را شخصی‌سازی کنید
همان طور که در بخش قبلی اشاره کردیم، بیشتر ابزارهای تحلیلی به شما اجازه می‌دهند تا شاخص‌ها و دیتاهای مختلف را به‌صورت شخصی‌سازی شده اندازه‌گیری کنید. اگر ابزار شما از شخصی‌سازی ابزارهای اندازه‌گیری پشتیبانی می‌کند، از طریق مکانیزم زیر می‌توانید شاخص‌های مدنظر را به ابزار خود اضافه نمایید.
- در بخش Admin ابزار خود، یک شاخص جدید تعریف کنید. البته این را در نظر داشته باشید که در همه ابزارها نیاز به تعریف یک شاخص جدید در بخش ادمین نیست.
- در کد جاوا اسکریپت فرانت – اند، مقادیر شاخص خود را محاسبه کنید.
- مقادیر شاخص خود را به analytics backend خود منتقل کنید. فقط مطمئن شوید که نام یا ID آن با نامی که در مرحله اول تعریف کردید یکسان باشد. البته تأکید می‌کنیم که اگر در مرحله اول این کار را انجام نداده باشید، نیازی به بررسی ID در این مرحله هم نیست.
برای آنکه مراحل 1 و 3 را درست انجام دهید، بهتر است بخش راهنمای ابزار تحلیلی خود را مطالعه کنید. در مرحله 2 باید از کتابخانه دیجیتال جاوا اسکریپت Web – Vitals برای محاسبه مقادیر هر شاخص Core Web Vitals استفاده نمایید. مثال زیر به شما نشان می‌دهد که چطور به سادگی می‌توانید این شاخص‌ها را در کدنویسی، پیدا کنید و آن‌ها را به ابزار تحلیلی خود انتقال دهید.
بیشتر بخوانید:
مطمئن شوید که می‌توانید یک گزارش توزیع بدهید
بعد از اینکه محاسبه مقادیر هر شاخص Core Web Vitals را به پایان رساندید و با کمک بخش شخصی‌سازی، آن را به ابزار تحلیلی خود انتقال دادید، در مرحله بعد باید یک داشبورد یا گزارش برای نشان‌دادن مقادیری که جمع‌آوری شده‌اند طراحی کنید. برای اینکه متوجه شوید آیا 75 درصد مقادیر اندازه‌گیری شده در کدام آستانه قرار دارند، نیاز به یک گزارش خواهید داشت.
اگر ابزار تحلیلی شما فاقد قابلیت ارائه گزارش به‌صورت پیش‌فرض باشد، شما می‌توانید به‌صورت دستی یک گزارش ترتیبی برای هر شاخص ایجاد کنید. زمانی که این گزارش ایجاد شد، باید به این شکل تعریف کنید که 75 درصد از مقادیر اندازه‌گیری شده و به دست آمده از هر شاخص در آستانه تعیین شده قرار بگیرند. این مسئله نباید ارتباطی به نوع کانکشن یا دیوایس کاربر داشته باشد. به زبان ساده‌تر اگر آستانه مطلوب و قابل قبول یک شاخص کمتر از 1000 میلی ثانیه باشد، 1250 میلی ثانیه نیز قابل قبول خواهد بود.
اگر ابزار تحلیلی‌تان به شما اجازه نمی‌دهد که از گزارش تفکیکی بر اساس هر شاخص به‌صورت پیش‌فرض استفاده کنید، شما می‌توانید به همان روش قبلی، از بخش شخصی‌سازی ابعاد مختلف استفاده نمایید. با قرار دادن یک بُعد جدید و تنظیمات منحصر‌به‌فرد برای هر شاخص، می‌توانید گزارش را بر اساس شاخص‌های مختلف به بخش‌های متفاوت تفکیک کنید. به این ترتیب هر بخش شامل مقادیر متفاوتی برای آن تنظیمات منحصر‌به‌فرد خواهد بود و دیگر گروه‌بندی در شاخص‌ها اتفاق نمی‌افتد.
راهنمایی
کتابخانه دیجیتال جاوا اسکریپ Web – vitals یک ID برای هر یک شاخص به شما ارائه می‌دهد. به این ترتیب می‌توانید یک سیستم توزیع برای اکثر ابزارهای تحلیلی ایجاد کنید. برای توضیح بیشتر می‌توانید راهنمای رابط شاخص را مطالعه کنید. همچنین برای بررسی web vitals می توانید از خدمات سئو در منتوریکس بهره مند شوید.
دیتا خود را در زمان درست ارسال کنید
برخی از شاخص‌های عملکرد وبسایت را فقط زمانی که بارگذاری صفحه به‌صورت کامل انجام شود می‌توان اندازه‌گیری کرد. این در حالی است که برخی دیگر از شاخص‌ها همانند CLS را در حین بارگذاری وبسایت باید اندازه‌گیری نمود. این مسئله می‌تواند مشکل‌ساز باشد. شاید تصور کنید می‌توانید از beforeunload و unload استفاده نمایید؛ اما این کدها قابل اطمینان نیستند. مخصوصاً اگر کاربر از موبایل استفاده کند، اصلاً نمی‌توان به این کدها اطمینان کرد. پس این کدها را برای حل مشکل توصیه نمی‌کنیم.
اگر شاخص شما در طول LifeSpan یا همان تمام مدت که کاربر بر روی وبسایت شما حضور دارد اندازه‌گیری می‌شود، باید در طول visibilitychange، هر زمان که Visibility به Hidden تغییر پیدا کرد، تمام مقادیر شاخص اندازه‌گیری شود. این بدان خاطر است که وقتی وضعیت صفحه شما به Hidden تغییر پیدا کند، به هیچ عنوان احتمال این وجود ندارد که اسکریپتی بتواند دوباره بر روی صفحه اجرا شود. این مسئله مخصوصاً زمانی که کاربر شما از موبایل استفاده می‌کند بیشتر نمود پیدا خواهد کرد. در حین استفاده از موبایل، کاربر می‌تواند بدون اینکه از کال – بک صفحات استفاده کند، مستقیم اپلیکیشن مرورگر خود را ببندد.
توجه داشته باشید که سیستم عامل‌های موبایل معمولاً هنگام تعویض تب‌ها، سوئیچ کردن اپلیکیشن‌ها و همچنین بستن خود اپلیکیشن مرورگر، از visibilitychange استفاده می‌کنند. همچنین زمانی که یک تب بسته می‌شود یا به یک صفحه جدید هدایت می‌شود نیز از visibilitychange استفاده می‌کنند. این باعث می‌شود که visibilitychange به‌مراتب از Unload یا حتی Beforunload قابل اطمینان‌تر باشد.
توجه
به یاد داشته باشید به‌خاطر برخی از باگ‌های نرم‌افزاری، گاهی امکان دارد که visibilitychange اجرا نشود. اگر شما به‌صورت دستی کتابخانه آنالیتیکس خود را ایجاد می‌کنید، باید حتماً باگ‌های نرم‌افزاری را نیز در نظر داشته باشید. البته لازم به ذکر است که کتابخانه دیجیتال جاوا اسکریپت Web – Vitals را نباید جزو این باگ‌ها در نظر بگیرید.
عملکرد وبسایت را در یک بازه زمانی مانیتور کنید
پس از اینکه تمامی مراحل فوق را انجام دادید و قادر به ارائه گزارش و نظارت بر شاخص‌های Core Web Vitals شدید، در مرحله بعد باید بررسی کنید تغییراتی که بر روی وبسایت خود انجام می‌دهید، در چه مدتی باعث تغییر عملکرد آن می‌شوند.
تغییرات خود را در قالب ورژن قرار دهید
روش‌های مختلفی برای تفسیر تغییرات وجود دارد. ساده‌ترین راه و غیرقابل اطمینان‌ترین روش برای بررسی تغییرات، بررسی لحظه‌ای آن است. این یعنی دقیقاً پس از اعمال تغییرات، انتظار داشته باشید که تمامی شاخص‌ها تغییر کنند. انگار که وبسایت خود را به دو بازه زمانی قدیم و جدید تقسیم کنید و انتظار داشته باشید شاخص شما پیش از تغییرات با شاخص‌های شما پس از تغییرات کاملاً تفاوت داشته باشند. حافظه کش HTTP، service worker یا لایه CDN از این تغییرات آنی جلوگیری می‌کنند.
روش بهتر این است که یک ورژن منحصر‌به‌فرد از هر یک از تغییراتی که ایجاد کرده‌اید بسازید. سپس این ورژن را با کمک ابزارهای تحلیلی مختلف بررسی نمایید. اکثر این ابزارها قابلیت تغییر ورژن دارند. اگر ابزار شما چنین قابلیتی ندارد، می‌توانید به‌صورت دستی در بخش شخصی‌سازی ابعاد، قابلیت اجرای ورژن‌های مختلف را به آن اضافه کنید.
از حالت اجرای آزمایشی استفاده کنید
شما می‌توانید برای تخمین بهتر تغییراتی که صورت دادید، از اجرای همزمان دو یا چند ورژن مختلف استفاده کنید. اگر ابزار تحلیلی شما از قابلیت اجرای آزمایش گروهی پشتیبانی می‌کند، از همین قابلیت استفاده کنید. در غیر این صورت شما می‌توانید از بخش شخصی‌سازی ابزار خود برای هر شاخص استفاده کنید تا از قابلیت اجرای آزمایشی همزمان چند ورژن در گزارش نهایی خود بهره‌مند شوید.
با کمک اجرای آزمایشی می‌توانید متوجه شوید که تغییرات انجام شده چه تاثیری بر روی عملکرد گروه‌های مختلف کاربران می‌گذارد. در این حین یک گروه را به‌عنوان گروه کنترل انتخاب می‌کنید تا بتوانید نتایج نهایی را با آن گروه مقایسه نمایید. – گروه کنترل گروهی است که هیچ تغییراتی بر روی آن اعمال نکرده‌اند. در نهایت زمانی که مطمئن شدید تغییرات بر روی عملکرد تمام گروه‌های کاربران موثر است، می‌توانید آن تغییرات را اعمال کنید.
توجه
گروه‌های آزمایشی را همیشه باید بر روی سرور ست کنید. به‌هیچ‌وجه از ابزارهای آزمایشی یا ابزارهای امتحانی A/B که در Client-side اجرا می‌شوند، استفاده نکنید. این ابزارها تا زمانی که گروه آزمایشی مشخص شود، باعث انسداد رندرینگ خواهد شد. انسداد رندرینگ نیز می‌تواند بر روی LCP تأثیر منفی بگذارد.
مطمئن شوید که آزمایش شما بر روی عملکرد وبسایت تأثیر نمی‌گذارد
زمانی که عملکرد را بر روی کاربر واقعی امتحان می‌کنید، بسیار مهم است که کد اندازه‌گیری عملکرد کاربر تأثیر منفی بر عملکرد صفحه شما نگذارد. اگر اینطور باشد، اندازه‌گیری عملکرد در اثر تغییراتی که اعمال کرده‌اید، فاقد اعتبار خواهد بود. وقتی خود کد اندازه‌گیری بر روی عملکرد وبسایت تأثیر منفی بگذارد، دیگر نمی‌توان تغییرات عملکردی که بر اثر دستکاری کدهای شما اعمال شده است را اندازه‌گیری کرد. همیشه حین اجرای کد آنالیتیکس RUM موارد زیر را در نظر بگیرید:
تحلیل خود را به تأخیر بیاندازید
کدهای آنالیتیکس شما باید به‌صورت غیرهمزمان و به شکلی که باعث انسداد نشوند اجرا شوند. در عین حال این کدها باید در آخرین مرحله، بارگذاری و اجرا شوند. اگر اجرای کد آنالیتیکس شما انسداد ایجاد کند، تأثیر مخرب و منفی بر روی LCP و نهایتاً عملکرد کلی وبسایت شما خواهد گذاشت. تمامی API ها به شکل غیرهمزمان شاخص‌های Core Web Vitals را اندازه‌گیری می‌کنند. این API ها با کمک فلگ Buffered، اجرای اسکریپت را به تأخیر می‌اندازند. به این ترتیب هیچ نیازی نیست که اجرای اسکریپت با عجله و سرعت بسیار انجام شود.
گاهی اوقات نمی‌توان کد را به تأخیر انداخت و باید کد را در همان ابتدا یا حین بارگذاری اجرا کرد. در چنین مواردی شما فقط کدی که باید همزمان یا سریع‌تر از کدهای دیگر اجرا شود را Inline کنید. برای این کار می‌توانید در متن کد خود برای کدی که باید زودتر اجرا شود از کد head استفاده نمایید و مابقی کدهای اندازه‌گیری را به تأخیر بیاندازید. توجه داشته باشید برای اندازه‌گیری یک شاخص پیش از اجرای تمام کد، لازم نیست که اندازه‌گیری تمامی شاخص‌ها به‌صورت همزمان انجام شود. پس فقط برای همان شاخصی که نیاز به اندازه‌گیری زودتر از اتمام بارگذاری دارد ازاستفاده نمایید.
تسک‌های طولانی مدت ایجاد نکنید
کدهای آنالیتیکس معمولاً در پاسخ کاربر به ورودی کاربر اجرا می‌شوند؛ اما اگر کد شما از اندازه‌گیری‌های DOM یا سایر API هایی که به شدت از منابع پردازنده استفاده می‌کنند، استفاده کند، خود کد آنالیتیکس شما باعث ایجاد پاسخ ورودی ضعیف و نامطلوب خواهد شد. به علاوه اینکه اگر فایل جاوا اسکریپت شما که شامل کد آنالیتیکس است، اندازه بزرگی داشته باشد، باعث می‌شود که حین اجرا، انسداد در thread اصلی به وجود بیاید و همین مسئله تأثیر منفی بر تأخیر اولین ورودی یا همان FID خواهد گذاشت.
از API های نان – بلوکینگ استفاده کنید
API هایی همانند sendBeacon و requestIdleCallback به شکلی خاص طراحی شده‌اند تا تسک‌های غیرضروری را به شکلی اجرا کنند که باعث بلاک شدن تسک‌های ضروری کاربر نشوند. این API ها ابزاری بسیار مفید و عالی برای کتابخانه آنالیتیکس RUM محسوب می‌شوند. به‌صورت کلی تمامی بیکان‌ها (beacons) در صورتی که قابل دسترس باشند، باید از طریق API sendBeacon ارسال شوند و تمام کدهای اندازه‌گیری پسیو آنالیتیکس باید در زمان بیکاری (Idle Period Tim) ارسال شوند.
نکته: شما می‌توانید از الگوی Idle-Until-Urgent استفاده کنید تا متوجه شوید چطور باید تا زمانی که نیاز به اجرای یک کد ضروری و اورژانسی نیست، زمان بیکاری را به حداکثر مقدار خود رساند.
بیش از حدی که نیاز دارید دیتاها را بررسی نکنید
هر مرورگر در معرض دیتاهای عملکرد بسیاری قرار دارد؛ اما این مسئله لزوماً باعث نمی‌شود تا شما هر داده‌ای را به سرور آنالیتیکس خودتان ارسال کنید. به‌عنوان مثال Recourse Timing API جزئیاتی درباره داده‌های زمانی هر منبعی که بر روی صفحه شما بارگذاری شده است را ارائه می‌دهد؛ اما تمامی این داده‌ها برای بهبود عملکرد بارگذاری بار وبسایت شما ضروری و مفید نیستند. به‌صورت مختصر باید گفت یک دیتا را فقط به‌خاطر اینکه وجود دارد نباید بررسی کنید. همیشه باید در نظر داشته باشید که برای بررسی یک دیتا باید از منابع مختلف استفاده کنید. پس باید در نظر بگیرید که آیا صرف این منابع برای بررسی یک دیتا ارزنده است یا نه؟
اگر مایلید در این زمینه بیشتر مطالعه کنید، پیشنهاد می‌کنیم مجموعه مقالات Core Web Vitals منتوریکس را ببینید و بخوانید. اگر برای کسب‌وکار خود به مشاوره دیجیتال مارکتینگ نیاز دارید، با منتوریکس تماس بگیرید.
این مطلب توسط اعضای تیم منتوریکس تهیه و گردآوری شده است.
انتشار مطالب فوق تنها با ذکر مرجع به همراه لینک وبسایت منتوریکس مجاز می‌باشد.
لطفا به حقوق هم احترام بگذاریم.