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

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

دنیا از چشم ربات‌ها و مرورگرهای دیگر

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

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

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

سفر در زمان با تب Network و نمودار واترفال

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

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

اینجا متریک‌های حیاتی تجربه کاربری خودشان را نشان می‌دهند:

  • اسپید ایندکس (Speed Index): میانگین زمان دیده شدن المان‌ها در صفحه است. اگر یک المان بزرگ دیر لود شود، روی این شاخص تأثیر منفی می‌گذارد.
  • ال‌سی‌پی (LCP): بزرگ‌ترین المانی که کاربر در نگاه اول می‌بیند (می‌تواند یک بلوک متنی بزرگ یا یک تصویر باشد).

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

جادوی HTTP/2 و تکه‌تکه کردن فایل‌ها

در گذشته رسم بر این بود که تمام فایل‌های استایل (CSS) سایت را در یک فایل بزرگ تجمیع می‌کردند تا تعداد درخواست‌ها سمت سرور کم شود. اما با آمدن پروتکل HTTP/2 بازی کاملاً عوض شد.

پروتکل HTTP/2 این قابلیت را دارد که درخواست‌ها را به‌صورت همزمان (Concurrent) پردازش کند. این فرایند شبیه کار نرم‌افزارهای مدیریت دانلود مثل IDM است. وقتی می‌خواهید یک فایل حجیم را دانلود کنید، نرم‌افزار آن را به چند تکه تبدیل می‌کند تا از حداکثر پهنای باند استفاده کند.

در تحلیل تکنیکال، وقتی می‌بینیم یک فایل CSS مثلاً ۸۰ کیلوبایت حجم دارد و لود آن زمان‌بر شده است، کافیست آن را به دو فایل ۴۰ کیلوبایتی تقسیم کنیم. با توجه به قابلیت HTTP/2، مرورگر این دو فایل را همزمان دانلود می‌کند و سرعت بارگذاری صفحه به‌شکل چشم‌گیری بهبود پیدا می‌کند. همچنین یک کارشناس سئو حرفه‌ای، فایل‌های استایل هر بخش را جدا می‌کند. مثلاً اگر کدهای CSS مربوط به بخش نظرات در یک صفحه خاص استفاده نشده‌اند، اصلاً دلیلی ندارد در آن صفحه بارگذاری شوند.

معمای CSSهای استفاده نشده (Unused CSS)

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

اما آیا باید سریعاً کدهای قرمز رنگ را پاک کنیم؟ مطلقاً نه! کدی که در صفحه اصلی شما قرمز است و استفاده نشده، ممکن است دقیقاً همان کدی باشد که ظاهر صفحه مقالات یا محصولات شما را می‌سازد. حتی افزونه‌های معروفی مثل راکت (WP Rocket) هم که سعی می‌کنند این کدهای اضافی را به‌صورت خودکار حذف کنند، معمولاً با خطا مواجه می‌شوند. آن‌ها صفحه را توسط یک ربات بررسی می‌کنند و ممکن است کدهای مربوط به یک پاپ‌آپ یا منوی کشویی را به عنوان «کد اضافه» حذف کنند و ظاهر سایت را کاملاً به هم بریزند.

راهکار اصولی‌تر چیست؟ به جای درگیری با حذف کدهای استفاده نشده، باید روی کدهای حیاتی (Critical CSS) تمرکز کنیم. یعنی بررسی کنیم برای ساختن همان نمایی که کاربر در نگاه اول در موبایل می‌بیند (مثل هدر، رنگ‌ها و منوی بالا)، به چه کدهایی نیاز داریم. همان حجم کم از کد را به‌صورت مستقیم (Inline) درون تگ Head قرار دهیم و لود بقیه فایل‌های CSS را به بعد از لود شدن کامل صفحه موکول کنیم (Defer). این کار تأثیر فوق‌العاده‌ای روی تجربه کاربری می‌گذارد.

نبرد جاوا اسکریپت و بودجه خزش گوگل

روند بررسی صفحات توسط گوگل چند مرحله جذاب دارد: ۱. خزش (Crawl): ربات وضعیت صفحه را می‌سنجد (آیا ارور ۴۰۴ است؟ ریدایرکت شده؟ تگ نو ایندکس دارد؟). ۲. ایندکس اولیه (Index): گوگل صفحه را بدون اجرای کدهای جاوا اسکریپت و صرفاً به‌صورت متنی می‌خواند. ۳. رندرینگ (Rendering): در نهایت، گوگل با استفاده از یک مرورگر، کدهای جاوا اسکریپت را اجرا می‌کند تا صفحه را دقیقاً مثل یک کاربر واقعی ببیند.

رندر کردن صفحات برای سرورهای گوگل به‌شدت پرهزینه و زمان‌بر است. اگر سایت شما صرفاً با تکنولوژی‌های فرانت‌اند (مثل ریکت یا انگولار) ساخته شده باشد و تمام محتوا با جاوا اسکریپت لود شود (CSR)، ممکن است گوگل در ایندکس اولیه هیچ متنی نبیند. سپس باید روزها منتظر بمانید تا گوگل فرصت کند صفحه شما را رندر کند و محتوای اصلی را متوجه شود.

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

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