افسانه های احتیاطی و نحوه اجتناب از آنها


من اخیرا مقاله جذاب زیمک بوکو را خواندم، صف رندر: گوگل به 9 برابر بیشتر از HTML برای خزیدن JS به زمان نیاز دارد، در وبلاگ Onely.

Bucko آزمایشی را که انجام دادند توضیح داد که نشان می‌دهد تاخیرهای قابل توجهی توسط Googlebot برای دنبال کردن پیوندها در صفحات وابسته به جاوا اسکریپت در مقایسه با پیوندهای موجود در HTML متن ساده وجود دارد.

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

تجربه من این است که محتوای فقط جاوا اسکریپت در مقایسه با HTML ساده ممکن است بیشتر طول بکشد تا فهرست شود.

چندین مورد از تماس‌های تلفنی و ایمیل‌های مشتریان ناامید را به یاد می‌آورم که می‌پرسیدند چرا مطالبشان در نتایج جستجو نشان داده نمی‌شود.

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

قبل از اینکه به ادامه مطلب برویم، می‌خواهم توضیح دهم که این یک «تکه ضربه‌ای» در جاوا اسکریپت نیست. JS ابزار ارزشمندی است.

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

اما دلایل دیگری نیز وجود دارد که باید در نظر گرفت عاقلانه استفاده از JS به جای تکیه بر آن برای همه چیز.

در اینجا چند داستان از تجربه من برای نشان دادن برخی از آنها آورده شده است.

1. متن؟ چه متنی؟!

سایتی که من از آن پشتیبانی می‌کردم با طراحی کاملاً جدید بر روی پلتفرمی که به شدت به جاوا اسکریپت متکی بود، دوباره راه‌اندازی شد.

در عرض یک هفته از راه اندازی سایت جدید، ترافیک جستجوی ارگانیک به صفر رسید و باعث وحشت قابل درک در بین مشتریان شد.

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

تیم من یک ارزیابی انجام داد و حدس زد که Google برای ارائه صفحات زمان می برد. با این حال، بعد از 2-3 هفته دیگر، مشخص بود که چیز دیگری در حال وقوع است.

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

آن وقت است که “آها!” ضربه لحظه ای زمانی که توسعه‌دهنده کد را خط به خط در کنسول خود مرور می‌کرد، متوجه شدم که متن هر صفحه در خارج از ویوپورت با استفاده از یک خط CSS بارگذاری می‌شود، اما توسط برخی JS به فریم قابل مشاهده کشیده می‌شود.

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

جلوه واقعی اسلاید برای کاربران قابل مشاهده نبود. حدس می‌زدم Google نمی‌تواند اثر اسلاید را دریافت کند و محتوا را نمی‌بیند.

پس از حذف آن اثر و خزیدن مجدد سایت، اعداد ترافیک شروع به بازیابی کردند.

2. خیلی کند است

این می تواند چندین داستان باشد، اما من چندین داستان را در یک خلاصه می کنم. پلتفرم های JS مانند AngularJS و React برای برنامه هایی که به سرعت در حال توسعه هستند، از جمله وب سایت ها، فوق العاده هستند.

آنها برای سایت هایی که به محتوای پویا نیاز دارند مناسب هستند. این چالش زمانی پیش می‌آید که وب‌سایت‌ها محتوای ثابت زیادی دارند که به صورت پویا هدایت می‌شوند.

چندین صفحه در یک وب سایت که من ارزیابی کردم در ابزار PageSpeed ​​Insights (PSI) گوگل امتیاز بسیار پایینی کسب کردند.

همانطور که با استفاده از گزارش Coverage در ابزارهای برنامه‌نویس کروم در آن صفحات جستجو کردم، متوجه شدم که 90٪ از جاوا اسکریپت دانلود شده استفاده نشده است و بیش از 1 مگابایت کد را شامل می‌شود.

وقتی این مورد را از سمت Core Web Vitals بررسی می‌کنید، تقریباً 8 ثانیه زمان مسدود شدن را به خود اختصاص می‌دهد زیرا همه کدها باید دانلود و در مرورگر اجرا شوند.

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

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

متأسفانه، در تجربه من، سئو اغلب به دلیل عدم تمایل به تغییر چیزها پس از راه اندازی آنها را از دست می دهد.

3. این کندترین سایت تاریخ است!

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

من سه حدس در مورد ترافیک و تبدیل آن سایت به شما می دهم و دو مورد اول به حساب نمی آیند!


دریافت خبرنامه جستجوی روزانه بازاریابان به آن تکیه می کنند.


گاهی اوقات، این چیزی بیش از جاوا اسکریپت است

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

در دو مقاله قبلی کمی در مورد آنها نوشتم:

به عنوان مثال، در داستان دوم من، سایت های درگیر نیز تمایل به CSS بیش از حد داشتند که در بیشتر صفحات استفاده نمی شد.

بنابراین، سئو در این شرایط چه کاری باید انجام دهد؟

راه حل مشکلاتی مانند این شامل همکاری نزدیک بین SEO، توسعه، و مشتری یا سایر تیم های تجاری است.

ایجاد ائتلاف می تواند ظریف باشد و شامل دادن و گرفتن باشد. به عنوان یک متخصص سئو، باید مشخص کنید که در کجا می توان مصالحه کرد و نمی توان آن ها را انجام داد و بر اساس آن حرکت کرد.

از ابتدا شروع کنید

بهتر است از همان ابتدا سئو را در یک وب سایت ایجاد کنید. هنگامی که یک سایت راه اندازی می شود، تغییر یا به روز رسانی آن برای برآوردن الزامات SEO بسیار پیچیده تر و گران تر است.

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

سعی کنید ربات‌های موتور جستجو را به عنوان داستان‌های کاربر در اوایل فرآیند دریافت کنید تا تیم‌ها بتوانند ویژگی‌های منحصر به فرد آن‌ها را درک کنند تا به فهرست‌بندی سریع و کارآمد محتوا کمک کنند.

معلم باش

بخشی از فرآیند آموزش است. تیم های توسعه دهنده اغلب باید از اهمیت سئو مطلع شوند، بنابراین باید به آنها بگویید.

نفس خود را کنار بگذارید و سعی کنید مسائل را از دیدگاه تیم های دیگر ببینید.

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

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

برخی از سازنده‌ترین بحث‌هایی که با تیم‌های توسعه‌دهنده داشته‌ام، درباره چند تکه پیتزا بوده است.

برای سایت های موجود، خلاق باشید

اگر سایتی از قبل راه اندازی شده باشد، باید خلاقیت بیشتری به خرج دهید.

غالباً، تیم‌های توسعه‌دهنده به پروژه‌های دیگر رفته‌اند و ممکن است وقت نداشته باشند که به عقب برگردند و چیزهایی را که مطابق با الزاماتی که دریافت کرده‌اند، «تعمیر» کنند.

همچنین این احتمال وجود دارد که مشتریان یا صاحبان مشاغل نخواهند پول بیشتری در پروژه وب سایت دیگری سرمایه گذاری کنند. این امر به ویژه در صورتی صادق است که وب سایت مورد نظر اخیراً راه اندازی شده باشد.

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

یک تغییر از این ترکیب رندر سمت سرور است که محتوای HTML متن ساده را در حافظه پنهان ذخیره می کند. این می تواند یک راه حل موثر برای محتوای استاتیک یا نیمه استاتیک باشد.

همچنین باعث صرفه جویی در هزینه های زیادی در سمت سرور می شود زیرا به جای هر بار درخواست محتوا، صفحات تنها در صورت ایجاد تغییرات یا در یک برنامه منظم ارائه می شوند.

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

کوچک‌سازی فضاهای خالی بین کاراکترها را حذف می‌کند و فایل‌ها را کوچک‌تر می‌کند. فشرده سازی GZIP را می توان برای فایل های JS و CSS دانلود شده استفاده کرد.

کوچک‌سازی و فشرده‌سازی چالش‌های زمان مسدود کردن را حل نمی‌کند. اما، حداقل آنها زمان مورد نیاز برای پایین کشیدن فایل ها را کاهش می دهند.

نمایه سازی گوگل و جاوا اسکریپت: چه چیزی می دهد؟

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

بر اساس روشی که من این توضیح را شنیده ام منطقی به نظر می رسید:

  • اولین پاس تمام متن ساده را گرفت.
  • برای گرفتن، پردازش و رندر کردن JS به پاس دوم نیاز بود.

من حدس زدم که مرحله دوم به پهنای باند و زمان پردازش بیشتری نیاز دارد.

من از جان مولر گوگل در توییتر پرسیدم که آیا این یک فرض منصفانه است و او پاسخ جالبی داد.

از آنچه می بیند، صفحات JS فاکتور هزینه زیادی نیستند. چیزی که از نظر گوگل گران است صفحاتی است که هرگز به روز نمی شوند.

در پایان مهمترین عامل برای آنها مرتبط بودن و مفید بودن محتوا بود.


نظرات بیان شده در این مقاله نظرات نویسنده مهمان است و لزوماً سرزمین موتور جستجو نیست. نویسندگان کارکنان در اینجا فهرست شده اند.


جدید در زمین موتورهای جستجو

درباره نویسنده

المر بوتین

المر بوتین معاون عملیات در WrightIMC، یک آژانس بازاریابی دیجیتال با خدمات کامل مستقر در دالاس. او پس از حرفه ای در ارتش ایالات متحده به عنوان مترجم و تحلیلگر اطلاعاتی، بیش از 25 سال در بازاریابی دیجیتال کار کرده است و همه چیز را از کدنویسی و بهینه سازی وب سایت ها گرفته تا مدیریت تلاش های مدیریت شهرت آنلاین به عنوان یک پیمانکار مستقل، مدیر وب سایت شرکتی و در تنظیمات آژانس انجام داده است. او دارای تجربه و تخصص گسترده ای است که برای مشاغل در هر اندازه کار می کند، از SMB ها گرفته تا شرکت های با اندازه 5 فورچون، از جمله Wilsonart، Banfield Pet Hospital، Corner Bakery Cafe، Ford Motor Company، Kroger، Mars Corporation، و Valvoline. بهینه سازی وب سایت ها با تمرکز بر تجارت الکترونیکی، اطلاعاتی، آموزشی و بین المللی.


منبع: https://searchengineland.com/javascript-rendering-and-indexing-cautionary-tales-and-how-to-avoid-them-390011