تأثیر سرعت سایت بر نرخ تبدیل و رتبه گوگل

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

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

Core Web Vitals چه چیزی را می‌سنجند

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

LCP (بزرگ‌ترین محتوای قابل‌دیدن) مدت زمانی را می‌سنجد که طول می‌کشد تا بزرگ‌ترین عنصر صفحه، معمولاً تصویر اصلی یا یک تیتر بزرگ، ظاهر شود. این معیار به سؤالی جواب می‌دهد که بازدیدکننده بی‌صدا از خودش می‌پرسد: آیا این صفحه واقعاً بارگذاری شد؟ گوگل LCP برابر ۲٫۵ ثانیه یا کمتر را خوب می‌داند.

INP (پاسخ‌گویی به تعامل) می‌سنجد صفحه با چه سرعتی به لمس، کلیک یا تایپ کاربر واکنش نشان می‌دهد. صفحه ممکن است کامل به نظر برسد ولی چون جاوااسکریپت مشغول است، «قفل‌شده» حس شود. INP برابر ۲۰۰ میلی‌ثانیه یا کمتر خوب محسوب می‌شود.

CLS (جابه‌جایی چیدمان) حرکت‌های غیرمنتظره‌ی صفحه هنگام بارگذاری را می‌سنجد، مثل دکمه‌ای که درست لحظه‌ای که می‌خواهید لمسش کنید پایین می‌پرد. CLS برابر ۰٫۱ یا کمتر خوب است.

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

چرا سرعت یک معیار کسب‌وکاری است، نه فقط سئو

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

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

قبل از بهینه‌سازی اندازه بگیرید

حدس زدن سریع‌ترین راه هدر دادن انرژی است. دو نوع داده وجود دارد و به هر دو نیاز دارید.

داده‌ی میدانی از کاربران واقعی می‌آید. Google Search Console گزارشی برای Core Web Vitals دارد که آدرس‌های شما را بر اساس وضعیت گروه‌بندی می‌کند و PageSpeed Insights هم وقتی بازدید کافی وجود داشته باشد، داده‌ی میدانی یک صفحه یا کل دامنه را نشان می‌دهد. این همان داده‌ای است که گوگل می‌بیند.

داده‌ی آزمایشگاهی از یک آزمون شبیه‌سازی‌شده می‌آید، مثل Lighthouse در ابزار توسعه‌دهنده‌ی Chrome یا بخش آزمایشگاهی PageSpeed Insights. تکرارپذیر است و می‌گوید چرا چیزی کند است، پس برای اشکال‌یابی عالی است، ولی فقط تقریبی از شرایط واقعی است.

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

چطور LCP را بهتر کنیم

بزرگ‌ترین عنصر معمولاً یک تصویر یا یک تیتر است و چهار دلیل رایج برای دیر ظاهر شدنش وجود دارد.

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

دوم، تصاویر سنگین. از قالب‌های مدرن مثل WebP استفاده کنید، اندازه‌ی تصویر را با ابعادی که واقعاً نمایش داده می‌شود تنظیم کنید و فشرده‌شان کنید. تصویر اصلی بالای صفحه را lazy-load نکنید، چون عمداً آن را دیر می‌کند؛ بارگذاری تنبل برای محتوای پایین صفحه است.

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

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

چطور INP را بهتر کنیم

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

چطور CLS را بهتر کنیم

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

هاست و کدهای شخص ثالث را فراموش نکنید

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

سرعت را به یک عادت تبدیل کنید

سرعت یک پروژه‌ی یک‌باره نیست. سایت‌ها با اضافه شدن تصویر، اسکریپت و قابلیت جدید کم‌کم کند می‌شوند و یک بازطراحی یا یک افزونه‌ی تازه می‌تواند حاصل ماه‌ها کار را در یک روز از بین ببرد. بعد از هر تغییر مهم، صفحه‌های کلیدی را دوباره بسنجید، گزارش Search Console را هر ماه ببینید و افت جدید را مثل هر باگ دیگری جدی بگیرید. ساختن سایت روی فریم‌ورکی که به‌صورت پیش‌فرض تصویر، تقسیم کد و فونت را بهینه می‌کند این کار را خیلی ساده‌تر می‌کند؛ یکی از دلایلی که اغلب Next.js برای سایت کسب‌وکاری پیشنهاد می‌دهیم.

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