کابوس رندرینگ و ایندکسینگ جاوا اسکریپت: داستان‌های عبرت‌آموز و راه‌های نجات
نتایج یه آزمایش در مورد رندر و ایندکس شدن جاوا اسکریپت، بعضی از چالش‌های کار با محتوای وابسته به JS رو حسابی پررنگ کرده.
اخیراً مقاله جالب زیمک باکو (Ziemek Bucko) رو تو وبلاگ Onely می‌خوندم با عنوان «صف رندرینگ: گوگل برای کراول کردن JS به ۹ برابر زمان بیشتری نسبت به HTML نیاز دارد».
باکو تو این مقاله، آزمایشی رو توضیح داده بود که نشون می‌داد گوگل‌بات برای دنبال کردن لینک‌ها تو صفحاتی که به جاوا اسکریپت متکی هستن، در مقایسه با لینک‌های HTML ساده، با تاخیر قابل توجهی روبرو می‌شه.
با اینکه شاید درست نباشه فقط به یه آزمایش مثل این تکیه کنیم، اما تجربه اون‌ها با تجربه خودم کاملاً جور در میاد. منم تا حالا وب‌سایت‌های زیادی رو دیدم و پشتیبانی کردم که برای عملکرد درست، بیش از حد به جاوا اسکریپت (JS) وابسته بودن. فکر می‌کنم تو این زمینه تنها هم نیستم.
تجربه من میگه محتوایی که فقط با جاوا اسکریپت ساخته شده، ممکنه در مقایسه با HTML ساده، زمان بیشتری برای ایندکس شدن نیاز داشته باشه.
چندین مورد رو یادمه که تلفن‌ها و ایمیل‌های مشتری‌های کلافه رو جواب می‌دادم که می‌پرسیدن چرا مطالبشون تو نتایج جستجو دیده نمی‌شه.
تقریباً تو همه موارد، چالش اصلی این بود که صفحات روی یه پلتفرم کاملاً یا عمدتاً مبتنی بر جاوا اسکریپت ساخته شده بودن.
قبل از اینکه ادامه بدیم، می‌خوام شفاف‌سازی کنم که این مطلب قرار نیست جاوا اسکریپت رو بکوبه! JS یه ابزار خیلی ارزشمنده.
اما مثل هر ابزار دیگه‌ای، بهتره برای کارهایی ازش استفاده بشه که ابزارهای دیگه از پسش برنمیان. من مخالف JS نیستم، مخالف استفاده از اون در جاهای نامناسبم.
اما دلایل دیگه‌ای هم وجود داره که باید تو استفاده از JS محتاط باشیم و برای هر کاری بهش تکیه نکنیم.
اینجا چندتا داستان از تجربه‌های خودم براتون تعریف می‌کنم تا بعضی از این دلایل رو بهتر درک کنید.
۱. متن؟ کدوم متن؟!
یکی از سایت‌هایی که پشتیبانی می‌کردم، با یه طراحی کاملاً جدید روی پلتفرمی که شدیداً به جاوا اسکریپت وابسته بود، دوباره راه‌اندازی شد.
کمتر از یک هفته بعد از بالا اومدن سایت جدید، ترافیک ارگانیک تقریباً به صفر رسید و طبیعتاً باعث وحشت کارفرما شد.
یه بررسی سریع نشون داد که علاوه بر کندی قابل توجه سایت (که تو داستان‌های بعدی بهش می‌رسیم)، تست صفحه زنده گوگل (Live Page Test) هم صفحات رو خالی نشون می‌داد.
تیم ما یه ارزیابی انجام داد و به این نتیجه رسید که احتمالاً مدتی طول می‌کشه تا گوگل صفحات رو رندر کنه. اما بعد از ۲-۳ هفته دیگه، مشخص شد که یه مشکل دیگه‌ای این وسطه.
با برنامه‌نویس اصلی سایت یه جلسه گذاشتم تا ببینیم مشکل از کجاست. وسط صحبت‌هامون، صفحه‌ش رو به اشتراک گذاشت تا بهم نشون بده تو بک‌اند چه خبره.
همونجا بود که یهو لامپ بالای سرم روشن شد! همینطور که برنامه‌نویس داشت کدها رو خط به خط تو کنسولش بررسی می‌کرد، متوجه شدم که متن هر صفحه با یه خط کد CSS خارج از دید کاربر (viewport) لود می‌شه و بعد با یه کد JS به داخل کادر قابل مشاهده کشیده می‌شه.
هدف از این کار، ایجاد یه افکت انیمیشنی جالب بود که محتوای متنی «سُر بخوره» و وارد صفحه بشه. اما چون صفحه تو مرورگر خیلی کند رندر می‌شد، وقتی محتوا بالاخره نمایش داده می‌شد، متن از قبل تو جای خودش قرار گرفته بود.
در واقع، خود افکت «سُر خوردن» برای کاربرا اصلاً قابل مشاهده نبود. حدس زدم که گوگل هم نمی‌تونه این افکت رو تشخیص بده و در نتیجه محتوا رو نمی‌بینه.
به محض اینکه اون افکت حذف شد و سایت دوباره کراول شد، آمار ترافیک شروع به بهبود کرد.
۲. واقعاً خیلی کنده!
این مورد می‌تونست چندتا داستان مجزا باشه، اما سعی می‌کنم چندتاش رو تو یه داستان خلاصه کنم. پلتفرم‌های JS مثل AngularJS و React برای توسعه سریع اپلیکیشن‌ها، از جمله وب‌سایت‌ها، فوق‌العاده‌ان.
این فریم‌ورک‌ها برای سایت‌هایی که به محتوای داینامیک نیاز دارن، خیلی مناسبن. چالش از جایی شروع می‌شه که وب‌سایت‌ها کلی محتوای استاتیک دارن که به صورت داینامیک مدیریت می‌شه.
چندین صفحه تو یکی از وب‌سایت‌هایی که بررسی می‌کردم، امتیاز خیلی پایینی تو ابزار PageSpeed Insights (PSI) گوگل گرفته بودن.
وقتی با استفاده از گزارش Coverage تو ابزار توسعه‌دهندگان کروم (Chrome’s Developer Tools) عمیق‌تر شدم، فهمیدم که ۹۰ درصد از جاوا اسکریپت دانلود شده، اصلاً استفاده نمی‌شه؛ یعنی بیش از ۱ مگابایت کد اضافه!
اگه از زاویه Core Web Vitals به این قضیه نگاه کنیم، این حجم از کد، نزدیک به ۸ ثانیه زمان مسدودسازی (blocking time) ایجاد می‌کرد، چون همه این کدها باید دانلود و تو مرورگر اجرا می‌شدن.
وقتی با تیم توسعه صحبت کردم، منطقشون این بود که اگه همه جاوا اسکریپت و CSS مورد نیاز سایت رو از همون اول بارگذاری کنن، بازدیدهای بعدی کاربر از صفحات دیگه خیلی سریع‌تر می‌شه، چون کدها تو کش مرورگر ذخیره شدن.
با اینکه اون برنامه‌نویس درون من با این منطق موافق بود، اما اون سئوکار درون من نمی‌تونست این واقعیت رو قبول کنه که نگاه منفی گوگل به تجربه کاربری سایت، احتمالاً ترافیک ارگانیک رو نابود می‌کنه.
متاسفانه، تجربه به من ثابت کرده که وقتی پای تغییر دادن چیزی که قبلاً لانچ شده وسط میاد، سئو معمولاً بازنده میدونه.
۳. این کندترین سایتیه که تا حالا دیدم!
شبیه داستان قبلی، اخیراً سایتی رو بررسی کردم که تو ابزار PSI گوگل امتیاز صفر گرفته بود. تا اون موقع، من هیچوقت امتیاز صفر ندیده بودم. کلی امتیاز دو، سه و یکی دوتا یک دیده بودم، اما صفر هرگز!
حالا سه بار حدس بزنید چه بلایی سر ترافیک و نرخ تبدیل اون سایت اومده بود… دوتا حدس اولتون هم حساب نیست!
گاهی وقتا، مشکل فقط جاوا اسکریپت نیست
انصافاً باید بگیم که CSS اضافی، عکس‌هایی که خیلی بزرگ‌تر از حد نیازه و پس‌زمینه‌های ویدیویی با پخش خودکار هم می‌تونن سرعت دانلود رو کم کنن و باعث مشکلات ایندکس بشن.
مثلاً تو داستان دومی که تعریف کردم، سایت‌های درگیر، معمولاً کلی CSS اضافی هم داشتن که تو اکثر صفحات استفاده نمی‌شد.
خب، یه سئوکار تو این شرایط باید چیکار کنه؟
راه‌حل مشکلاتی از این دست، همکاری نزدیک بین تیم سئو، تیم توسعه و کارفرما یا بقیه تیم‌های بیزینسیه.
ایجاد یه ائتلاف می‌تونه کار ظریفی باشه و نیاز به بده‌بستان داره. به عنوان یه متخصص سئو، باید مشخص کنید کجاها می‌شه کوتاه اومد و کجاها نه، و بر اساس اون حرکت کنید.
از همون اول شروع کنید
بهترین کار اینه که سئو از همون اول تو فرایند ساخت وب‌سایت لحاظ بشه. وقتی یه سایت لانچ می‌شه، تغییر یا آپدیت کردنش برای مطابقت با نیازمندی‌های سئو خیلی پیچیده‌تر و پرهزینه‌تره.
سعی کنید از همون ابتدای فرایند توسعه وب‌سایت، یعنی زمانی که نیازمندی‌ها، مشخصات فنی و اهداف بیزینسی تعیین می‌شن، خودتون رو درگیر کنید.
تلاش کنید که ربات‌های موتور جستجو رو به عنوان «داستان کاربر» (user stories) تو مراحل اولیه پروژه جا بندازید تا تیم‌ها با ویژگی‌های خاص اون‌ها آشنا بشن و کمک کنن محتوا سریع‌تر و بهینه‌تر کراول و ایندکس بشه.
معلم باشید
بخشی از این فرایند، آموزشه. تیم‌های برنامه‌نویسی اغلب باید در مورد اهمیت سئو آگاه بشن، پس این شما هستید که باید بهشون بگید.
غرورتون رو کنار بذارید و سعی کنید مسائل رو از دیدگاه تیم‌های دیگه ببینید.
بهشون کمک کنید تا اهمیت اجرای بهترین شیوه‌های سئو رو یاد بگیرن، در حالی که شما هم نیازهای اون‌ها رو درک می‌کنید و به یه تعادل خوب بین این دو می‌رسید.
گاهی وقتا برگزاری یه جلسه آموزشی تو ساعت ناهار و آوردن غذا می‌تونه خیلی مفید باشه. غذا خوردن موقع بحث کردن، دیوارها رو از بین می‌بره – و خب، به عنوان یه رشوه کوچیک هم بد نیست! بعضی از سازنده‌ترین بحث‌هایی که با تیم‌های برنامه‌نویسی داشتم، سر چند تیکه پیتزا بوده.
برای سایت‌های موجود، خلاقیت به خرج بدید
اگه یه سایت از قبل لانچ شده، باید خلاقیت بیشتری به خرج بدید.
خیلی وقتا، تیم‌های توسعه سراغ پروژه‌های دیگه‌ای رفتن و ممکنه وقت نداشته باشن برگردن و چیزهایی رو «درست» کنن که طبق نیازمندی‌های اولیه، درست کار می‌کنن.
این احتمال هم وجود داره که کارفرما یا صاحبان کسب‌وکار نخوان پول بیشتری برای یه پروژه وب‌سایت دیگه سرمایه‌گذاری کنن. این موضوع به خصوص وقتی صادقه که وب‌سایت مورد نظر به تازگی لانچ شده باشه.
یکی از راه‌حل‌های ممکن، رندر سمت سرور (Server-Side Rendering) هست. این کار، پردازش رو از سمت کاربر (client-side) برمی‌داره و می‌تونه سرعت رو به طور قابل توجهی افزایش بده.
یه مدل دیگه از این روش، ترکیب رندر سمت سرور با کش کردن محتوای HTML ساده‌ست. این می‌تونه یه راه‌حل موثر برای محتوای استاتیک یا نیمه‌استاتیک باشه. این کار همچنین بار اضافی روی سرور رو خیلی کم می‌کنه، چون صفحات فقط وقتی که تغییری ایجاد می‌شه یا طبق یه برنامه منظم رندر می‌شن، نه هر بار که محتوا درخواست می‌شه.
گزینه‌های دیگه‌ای که می‌تونن کمک کنن اما ممکنه چالش‌های سرعت رو به طور کامل حل نکنن، کوچک‌سازی (minification) و فشرده‌سازی (compression) هستن.
کوچک‌سازی فضاهای خالی بین کاراکترها رو حذف می‌کنه و فایل‌ها رو کوچیک‌تر می‌کنه. فشرده‌سازی GZIP هم می‌تونه برای فایل‌های JS و CSS دانلود شده استفاده بشه.
کوچک‌سازی و فشرده‌سازی، چالش‌های مربوط به زمان مسدودسازی رو حل نمی‌کنن. اما حداقل زمان لازم برای دانلود خود فایل‌ها رو کاهش می‌دن.
ایندکس جاوا اسکریپت توسط گوگل: قضیه چیه؟
تا مدت‌ها، من معتقد بودم که حداقل بخشی از دلیل کندی گوگل تو ایندکس کردن محتوای JS، هزینه بالاتر پردازش اونه.
این باور بر اساس توصیف‌هایی که شنیده بودم، منطقی به نظر می‌رسید:
- یه مرحله اول که تمام متن ساده رو جمع می‌کنه.
- و یه مرحله دوم که برای دریافت، پردازش و رندر کردن JS لازمه.
من حدس می‌زدم که مرحله دوم به پهنای باند و زمان پردازش بیشتری نیاز داره.
این سوال رو از جان مولر گوگل تو توییتر پرسیدم که آیا این فرض درسته یا نه، و اون جواب جالبی داد.
از دید اون، صفحات JS هزینه چندان زیادی ندارن. چیزی که از نظر گوگل پرهزینه‌ست، کراول کردن دوباره صفحاتیه که هیچوقت آپدیت نمی‌شن.
در نهایت، مهم‌ترین فاکتور برای اون‌ها، مرتبط بودن و مفید بودن محتواست.
پاسخی بگذارید