ارتباط سرعت سایت و معیارهای کسب و کار

از تست A/B برای ارزیابی تاثیر سرعت سایت بر معیارهای کسب و کار خود استفاده کنید.

Bart Jarochowski

Martin Schierle

Dikla Cohen

در چند سال اخیر به خوبی ثابت شده است که عملکرد سرعت سایت بخش مهمی از تجربه کاربر است و بهبود آن به معیارهای مختلف تجاری مانند نرخ تبدیل و نرخ پرش کمک می کند. مقالات و مطالعات موردی متعددی برای حمایت از این موضوع منتشر شده است، از جمله نحوه عملکرد وب‌سایت Cloudflare بر نرخ تبدیل تأثیر می‌گذارد ، Deloitte's Milliseconds میلیون‌ها میلیون‌ها را می‌سازد ، و خرید برای سرعت در eBay.com .

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

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

این مقاله راهنمایی‌های سطح بالایی را در مورد نحوه استفاده از تست A/B برای ارزیابی تأثیر سرعت سایت بر معیارهای تجاری ارائه می‌کند، بنابراین تصمیم‌گیری مؤثرتری را در مورد این موضوع ممکن می‌سازد.

مرحله 1: یک صفحه را برای تست A/B انتخاب کنید

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

• تست A/B فقط باید روی دستگاه های کاربران موبایل اجرا شود. در سطح جهانی، سایت های شریکی که ما به آنها کمک می کنیم، به طور متوسط ​​بیش از 50٪ (و در حال رشد!) ترافیک خود را از طریق تلفن همراه می بینند، اما این میزان می تواند به طور قابل توجهی بر اساس منطقه و عمودی افزایش یابد. دستگاه‌های تلفن همراه به دلیل محدودیت‌های پردازش و حافظه و شبکه‌های پایدارتر نسبت به وب‌سایت‌های کندتر حساس‌تر هستند. همچنین، الگوهای استفاده در حال حرکت به این معنی است که انتظارات برای سرعت بالاتر است.

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

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

• صفحه انتخاب شده باید ترافیک کافی داشته باشد تا قبل از گرفتن نتیجه آماری قابل توجهی نیازی به صبر طولانی نداشته باشید.

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

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

با استفاده از موارد فوق به عنوان راهنما، باید کمی واضح تر مشخص شود که چه صفحاتی کاندیدای خوبی برای آزمون شما هستند. صفحات فرود تبلیغاتی نیز انتخاب خوبی هستند، زیرا به احتمال زیاد معیارهای تجاری داخلی، تست A/B و تجزیه و تحلیل در اختیار شماست. اگر هنوز مطمئن نیستید، در اینجا چند ایده برای هر عمودی وجود دارد:

• وب سایت های محتوا: بخش ها، مقالات
• ویترین ها: صفحات دسته بندی، صفحات محصول
• پخش کننده رسانه: صفحات کشف/جستجوی ویدئو، صفحه پخش ویدئو
• خدمات و کشف (مسافرت، اتومبیل های کرایه ای، ثبت نام خدمات و غیره): صفحه ورود به فرم اولیه

مرحله 2: اندازه گیری عملکرد

دو روش کلی برای اندازه گیری معیارها وجود دارد: در آزمایشگاه و در میدان . ما شخصاً تشخیص داده‌ایم که معیارهای اندازه‌گیری در این زمینه (همچنین به عنوان نظارت بر کاربر واقعی (RUM) شناخته می‌شود) مفیدتر است زیرا تجربه کاربران واقعی را منعکس می‌کند. نمونه‌هایی از کتابخانه‌ها و سرویس‌هایی که می‌توانند به شما در گزارش داده‌های RUM کمک کنند عبارتند از Perfume ، Firebase Performance Monitoring ، و رویدادهای Google Analytics .

معیارهای زیادی برای انتخاب وجود دارد زیرا هدف آنها ثبت جنبه های مختلف تجربه کاربر است. به یاد داشته باشید که هدف شما این است که در نهایت تعیین کنید که آیا یک همبستگی مستقیم بین معیارهای سرعت و کسب و کار شما وجود دارد، بنابراین ممکن است مفید باشد که چند معیار سرعت را دنبال کنید تا مشخص کنید کدام یک قوی‌ترین همبستگی را با موفقیت کسب و کار شما دارد. به طور کلی توصیه می کنیم با Core Web Vitals شروع کنید. کتابخانه web-vitals.js می تواند به شما کمک کند برخی از Core Web Vitals را در این زمینه اندازه گیری کنید، اگرچه توجه داشته باشید که پشتیبانی از مرورگر 100٪ نیست . فراتر از Core Web Vitals، سایر Web Vitals نیز ارزش بررسی دارند. همچنین می‌توانید معیارهای سفارشی مانند «زمان برای اولین کلیک آگهی» را تعریف کنید.

مرحله 3: انواع عملکرد سرعت را ایجاد کنید

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

چند نکته را باید در نظر داشت:

1. از ایجاد هرگونه تغییر در UI یا UX خودداری کنید. گذشته از اینکه یک صفحه سریعتر از دیگری است، تغییرات باید برای کاربران نامرئی باشد.
2. اندازه گیری نیز یکی از جنبه های کلیدی این مرحله است. هنگام توسعه، ابزارهای آزمایش آزمایشگاهی مانند Lighthouse باید برای نشان دادن تأثیر تغییرات شما بر عملکرد استفاده شود. به خاطر داشته باشید که تغییرات در یک معیار اغلب می تواند بر دیگری تأثیر بگذارد. هنگامی که صفحات زنده شدند، برای ارزیابی دقیق تر به RUM بچسبید.

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

یک صفحه سریعتر ایجاد کنید

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

بهینه‌سازی‌های اضافی را می‌توان در زمان‌های بارگذاری سریع و چک لیست عملکرد Frontend پیدا کرد. همچنین می‌توانید از PageSpeed ​​Insights برای اجرای Lighthouse استفاده کنید، که فرصت‌هایی را برای بهبود عملکرد شناسایی می‌کند.

سرعت صفحه را کم کنید

این ممکن است ساده‌ترین راه برای ایجاد انواع مختلف باشد و می‌توان با افزودن یک اسکریپت ساده، کاهش سرعت پاسخ سرور، بارگیری تصاویر بزرگ‌تر و غیره به آن دست یافت. فایننشال تایمز هنگام آزمایش تأثیر عملکرد بر معیارهای کسب‌وکار خود، این گزینه را انتخاب کرد: سریع‌تر را ببینید. FT.com

افزایش سرعت بارگذاری صفحه

برای مواردی که صفحه آزمایشی (مثلاً یک صفحه جزئیات محصول) عمدتاً از یک صفحه دیگر (مثلاً صفحه اصلی) پیوند داده شده است، واکشی اولیه یا اجرای اولیه صفحه محصول مستقیماً از صفحه اصلی برای گروه آزمایشی، بارگیری بعدی را تسریع می کند. صفحه. توجه داشته باشید که در این حالت تقسیم تست A/B (مرحله 4) در صفحه اصلی انجام می شود. علاوه بر این، همه اینها ممکن است صفحه اول را کاهش دهد، بنابراین مطمئن شوید که آن را اندازه بگیرید و هنگام تجزیه و تحلیل نتایج آزمون آن را در نظر بگیرید (مرحله 5).

مرحله 4: یک تست A/B ایجاد کنید

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

اگر از ابزار تست A/B مانند Optimizely یا Optimize استفاده می‌کنید، اکیداً توصیه می‌کنیم که به جای تست سمت سرویس گیرنده، یک تست سمت سرور راه‌اندازی کنید، زیرا تست A/B سمت مشتری اغلب با پنهان کردن محتوای صفحه تا زمانی که آزمایش انجام شود کار می‌کند. بارگذاری شده است، که به این معنی است که خود آزمایش A/B معیارهایی را که می‌خواهید اندازه‌گیری کنید، تغییر می‌دهد. اگر فقط می‌توانید آزمایش سمت مشتری انجام دهید، آزمایش را در صفحه دیگری راه‌اندازی کنید و خروجی‌های پیوند را به صفحه آزمایشی خود تغییر دهید تا ترافیک را تقسیم کنید. به این ترتیب خود صفحه آزمایشی توسط تست سمت مشتری به پایین کشیده نمی شود.

مثال

نمونه ای از تغییرات عملکرد تست AB در صفحه جزئیات محصول (PDP) از طریق تست سمت سرور:

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

در اینجا نمونه ای از تنظیمات تست سمت سرویس گیرنده است که از صفحه قبلی (صفحه اصلی در نمودار زیر) برای اجرای آزمایشی جاوا اسکریپت استفاده می کند:

جاوا اسکریپت آزمایشی پیوند خروجی را دستکاری می کند تا به دو گروه آزمایشی کاربران پیوندهایی به دو نسخه PDP مورد نظر بدهد. راه‌اندازی و نگهداری از طریق ابزارهای رایج تست A/B مانند Optimizely یا Optimize آسان است و بر تست عملکرد تأثیری ندارد زیرا جاوا اسکریپت آزمایشی در صفحه دیگری اجرا می‌شود.

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

در صورتی که صفحه آزمایشی شما به عنوان صفحه فرود برای کمپین های تبلیغاتی استفاده می شود، استفاده از ابزارهای تست A/B داخلی شبکه تبلیغاتی شما، مانند تست تقسیم تبلیغات Facebook یا Google Ads Drafts & Experiments می تواند مفید باشد. اگر این یک گزینه نیست، می توانید از دو کمپین با تنظیمات یکسان استفاده کنید و صفحات فرود مختلف را به عنوان هدف تعیین کنید.

مرحله 5: آزمون A/B را تجزیه و تحلیل کنید

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

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

پلتفرم هایی مانند Optimizely یا Optimize نیز راه های آسانی را برای تفسیر نتایج و تعیین میزان تأثیر سرعت بر صفحات شما ارائه می دهند.

اگر از Google Analytics یا ابزاری مشابه استفاده می کنید، باید خودتان گزارش را جمع آوری کنید. خوشبختانه، Google Analytics ساخت گزارش های سفارشی را بسیار آسان می کند، بنابراین از اینجا باید شروع کنید. اگر داده‌های سرعت را با استفاده از یک بعد سفارشی به Google Analytics ارسال کرده‌اید، راهنمای گزارش‌دهی را بررسی کنید تا نحوه تنظیم آن‌ها و گنجاندن آنها در گزارش‌های سفارشی خود را بیاموزید. مطمئن شوید که گزارش شما تاریخ آزمایش را پوشش می دهد و برای نمایش هر دو نوع پیکربندی شده است. در این گزارش چه باید کرد؟

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

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

Looker Studio (سابق Data Studio) یا سایر ابزارهای تجسم داده، ادغام منابع داده های مختلف از جمله Google Analytics را آسان می کند. این امر انجام تجزیه و تحلیل را آسان می کند و همچنین داشبوردهایی ایجاد می کند که با بسیاری از سهامداران درگیر در اجرای یک وب سایت مدرن برای خرید بیشتر قابل اشتراک گذاری است. به عنوان مثال، گاردین یک سیستم هشدار خودکار ایجاد کرد که به تیم تحریریه هشدار می‌داد که محتوای اخیراً منتشر شده از اندازه صفحه یا آستانه سرعت آنها عبور کند و احتمالاً منجر به نارضایتی کاربران شود.

مرحله 6: نتیجه گیری کنید و در مورد مراحل بعدی تصمیم بگیرید

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

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

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

هشدارها

ممکن است دلایل مختلفی برای پیدا نکردن همبستگی قابل توجهی بین معیارهای سرعت سایت و معیارهای تجاری وجود داشته باشد:

• صفحه انتخاب شده تأثیر کافی بر معیارهای کسب و کار مورد بررسی شما ندارد. به عنوان مثال، اگر صفحه تسویه حساب بسیار غیر دوستانه یا کند باشد، ممکن است صفحه محصول سریعتر تأثیر زیادی بر نرخ تبدیل نداشته باشد. به معیارهای مرتبط تری مانند نرخ پرش، نرخ افزودن به سبد خرید یا هر معیار دیگری که مستقیماً به صفحه ای که در حال آزمایش آن هستید متصل است، توجه کنید.
• تفاوت سرعت بین دو نسخه به اندازه کافی قابل توجه نیست. این باید با توجه به معیارهای RUM که اندازه گیری می کنید ارزیابی شود.
• مکانیسم تست A/B ایراد دارد. ممکن است ترافیک به درستی توزیع نشده باشد یا تجزیه و تحلیل به درستی گزارش نشده باشد. به منظور رد این موضوع، آزمایش A/A را در نظر بگیرید که در آن نسخه یک صفحه را با استفاده از مکانیسم آزمایش یکسان آزمایش می‌کنید و مطمئن شوید که هنگام انجام این کار تفاوتی در نتایج وجود ندارد.
• سرعت سایت واقعاً بر معیارهای کسب و کار شما تأثیر نمی گذارد. این نادر است، اما می تواند در مواردی رخ دهد که بازار هدف شما نسبت به سرعت حساسیت کمتری دارد (مثلاً سایت بیشتر از طریق دستگاه های قدرتمند در یک شبکه قوی قابل دسترسی است) یا تقاضای کاربر بسیار زیاد است و انتخاب محدود است (مثلاً یک سرویس فروش بلیط که به طور انحصاری می فروشد. بلیط برای نمایش های پرتقاضا). توجه داشته باشید که این بدان معنا نیست که یک سایت سریعتر تجربه کاربر را بهبود نمی بخشد و در نتیجه بر شهرت برند تأثیر می گذارد .

نتیجه

در حالی که راه اندازی بهینه سازی سرعت در کل سایت وسوسه انگیز است، اما معمولاً در دراز مدت مفیدتر است که ابتدا درک کنید که داشتن یک وب سایت سریعتر برای کاربران و شرکت شما چه معنایی دارد. این تفاوت بین گفتن "ما FCP را 1.5 ثانیه بهبود دادیم" و "ما FCP را 1.5 ثانیه بهبود دادیم و نرخ تبدیل ما را 5٪ بهبود دادیم". این به شما امکان می دهد کارهای بیشتر را اولویت بندی کنید، از سهامداران مختلف خرید کنید و عملکرد سرعت سایت را به تلاشی در سطح شرکت تبدیل کنید .