حكايات تحذيرية وكيفية تفاديها

لقد قرأت مؤخرًا مقال Ziemek Bucko الرائع ، Rendering Queue: Google تحتاج إلى 9X وقتًا أكبر للزحف إلى JS أكثر من HTML ، على مدونة Onely.

وصف Bucko اختبارًا أجروه أظهر تأخيرات كبيرة من قِبل Googlebot في تتبع الروابط في الصفحات المعتمدة على JavaScript مقارنة بالروابط الموجودة في نص HTML العادي.

في حين أنه ليس من الجيد الاعتماد على اختبار واحد فقط مثل هذا ، فإن تجربتهم تتوافق مع تجربتي. لقد رأيت ودعمت العديد من مواقع الويب التي تعتمد كثيرًا على JavaScript (JS) لتعمل بشكل صحيح. أتوقع أنني لست وحدي في هذا الصدد.

تجربتي هي أن محتوى JavaScript فقط يمكن أن يستغرق وقتًا أطول للفهرسة مقارنةً بـ HTML العادي.

أتذكر عدة حالات من تلقي مكالمات هاتفية ورسائل بريد إلكتروني من عملاء محبطين يسألون لماذا لا تظهر أشياءهم في نتائج البحث.

في جميع الحالات باستثناء واحدة ، بدا أن التحدي يرجع إلى أن الصفحات مبنية على منصة JS فقط أو معظمها من JS.

قبل أن نذهب إلى أبعد من ذلك ، أود أن أوضح أن هذه ليست “قطعة ناجحة” في JavaScript. JS هي أداة قيمة.

ومع ذلك ، مثل أي أداة ، من الأفضل استخدامها للمهام التي لا تستطيع الأدوات الأخرى القيام بها. أنا لست ضد شبيبة. أنا ضد استخدامه حيث لا معنى له.

ولكن هناك أسباب أخرى للنظر فيها بحكمة باستخدام JS بدلاً من الاعتماد عليها في كل شيء.

إليكم بعض الحكايات من تجربتي لتوضيح بعضها.

1. نص؟ أي نص ؟!

تمت إعادة إطلاق أحد المواقع التي دعمتها بتصميم جديد تمامًا على نظام أساسي يعتمد بشدة على JavaScript.

في غضون أسبوع من بدء تشغيل الموقع الجديد ، انخفضت حركة البحث العضوي إلى ما يقرب من الصفر ، مما تسبب في حالة من الذعر مفهوم بين العملاء.

كشف تحقيق سريع أنه بالإضافة إلى كون الموقع أبطأ إلى حد كبير (انظر الحكايات التالية) ، أظهر اختبار الصفحة المباشرة من Google أن الصفحات فارغة.

أجرى فريقي تقييمًا وتوقع أن الأمر سيستغرق بعض الوقت من Google لعرض الصفحات. بعد أسبوعين إلى ثلاثة أسابيع ، اتضح أن شيئًا آخر كان يحدث.

التقيت بالمطور الرئيسي للموقع لحل ما كان يحدث. كجزء من محادثتنا ، شاركوا شاشتهم لتظهر لي ما كان يحدث في النهاية الخلفية.

هذا عندما “آها!” ضرب لحظة. بينما كان المطور يتخطى التعليمات البرمجية سطرًا سطرًا في وحدة التحكم الخاصة به ، لاحظت أن نص كل صفحة يتم تحميله خارج منفذ العرض باستخدام سطر من CSS ولكن تم سحبه إلى الإطار المرئي بواسطة بعض JS.

كان القصد من ذلك تقديم تأثير متحرك ممتع حيث “ينزلق” محتوى النص إلى العرض. ومع ذلك ، نظرًا لبطء عرض الصفحة في المتصفح ، كان النص معروضًا بالفعل عندما تم عرض محتوى الصفحة أخيرًا.

لم يكن تأثير الانزلاق الفعلي مرئيًا للمستخدمين. اعتقدت أن Google لا يمكنها التقاط تأثير الشريحة ولم ترى المحتوى.

بمجرد إزالة هذا التأثير وإعادة الزحف إلى الموقع ، بدأت أرقام الزيارات في التعافي.

2. إنها فقط بطيئة للغاية

قد تكون هذه عدة حكايات ، لكنني سألخص عدة حكايات في واحدة. تعد منصات JS مثل AngularJS و React رائعة لتطوير التطبيقات بسرعة ، بما في ذلك مواقع الويب.

إنها مناسبة تمامًا للمواقع التي تحتاج إلى محتوى ديناميكي. يأتي التحدي عندما تحتوي مواقع الويب على الكثير من المحتوى الثابت الذي يتم دفعه ديناميكيًا.

سجلت عدة صفحات على أحد مواقع الويب التي قمت بتقييمها نقاطًا منخفضة جدًا في أداة PageSpeed ​​Insights (PSI) من Google.

أثناء بحثي في ​​الأمر باستخدام تقرير التغطية في أدوات مطوري Chrome عبر تلك الصفحات ، وجدت أن 90٪ من جافا سكريبت الذي تم تنزيله لم يتم استخدامه ، وهو ما يمثل أكثر من 1 ميغابايت من التعليمات البرمجية.

عندما تقوم بفحص هذا من جانب Core Web Vitals ، فإن ذلك يمثل ما يقرب من 8 ثوانٍ من وقت الحظر حيث يجب تنزيل جميع التعليمات البرمجية وتشغيلها في المتصفح.

وبالحديث إلى فريق التطوير ، أشاروا إلى أنهم إذا قاموا بتحميل كل جافا سكريبت و CSS التي ستكون مطلوبة على الموقع ، فستجعل زيارات الصفحة اللاحقة أسرع بكثير للزوار لأن الشفرة ستكون في ذاكرة التخزين المؤقت للمتصفح .

بينما وافق المطور السابق في داخلي على هذا المفهوم ، لم يستطع مُحسِّن محركات البحث بداخلي قبول كيف كان من المحتمل أن يؤدي تصور Google السلبي الواضح لتجربة مستخدم الموقع إلى تدهور حركة المرور من البحث العضوي.

لسوء الحظ ، من واقع خبرتي ، غالبًا ما تفقد مُحسّنات محرّكات البحث عدم الرغبة في تغيير الأشياء بمجرد إطلاقها.

3. هذا هو أبطأ موقع على الإطلاق!

على غرار الحكاية السابقة ، يأتي موقع قمت بمراجعته مؤخرًا وسجل صفرًا على PSI من Google. حتى ذلك الوقت ، لم أرَ صفرًا من قبل. الكثير من الثنائي والثلاثي وواحد ، لكن ليس صفرًا أبدًا.

سأعطيك ثلاثة تخمينات حول ما حدث لحركة المرور والتحويلات في هذا الموقع ، وأول اثنين لا يحتسبان!

---

---

في بعض الأحيان ، يكون الأمر أكثر من مجرد JavaScript

لكي نكون منصفين ، يمكن أن يؤدي استخدام CSS الزائد والصور الأكبر بكثير مما هو مطلوب وخلفيات الفيديو التي يتم تشغيلها تلقائيًا إلى إبطاء أوقات التنزيل والتسبب في حدوث مشكلات في الفهرسة.

لقد كتبت قليلاً عن هؤلاء في مقالتين سابقتين:

على سبيل المثال ، في قصتي الثانية ، تميل المواقع المعنية أيضًا إلى وجود CSS مفرط لم يتم استخدامه في معظم الصفحات.

seo-to-do-in-these-situations”>إذن ، ما الذي يجب أن يفعله مُحسِّن محركات البحث في هذه المواقف؟

تتضمن حلول مثل هذه المشكلات تعاونًا وثيقًا بين مُحسنات محركات البحث والتطوير والعملاء أو فرق العمل الأخرى.

قد يكون بناء الائتلاف أمرًا حساسًا ويتضمن العطاء والأخذ. بصفتك ممارسًا لكبار المسئولين الاقتصاديين ، يجب أن تعمل على تحديد الأماكن التي يمكن ولا يمكن فيها إجراء التنازلات والتحرك وفقًا لذلك.

نبدأ من البداية

من الأفضل إنشاء مُحسّنات محرّكات البحث في موقع ويب من البداية. بمجرد إطلاق الموقع ، يصبح تغييره أو تحديثه لتلبية متطلبات تحسين محركات البحث (seo) أكثر تعقيدًا وتكلفة.

اعمل على المشاركة في عملية تطوير موقع الويب في البداية عندما يتم تحديد المتطلبات والمواصفات وأهداف العمل.

حاول الحصول على روبوتات محرك البحث كقصص للمستخدمين في وقت مبكر من العملية حتى تتمكن الفرق من فهم المراوغات الفريدة الخاصة بهم للمساعدة في فهرسة المحتوى بسرعة وكفاءة.

كن معلم

جزء من العملية هو التعليم. غالبًا ما تحتاج فرق المطورين إلى إعلامهم بأهمية تحسين محركات البحث ، لذلك عليك إخبارهم بذلك.

ضع نفسك جانبًا وحاول أن ترى الأشياء من منظور الفرق الأخرى.

ساعدهم على تعلم أهمية تنفيذ أفضل ممارسات تحسين محركات البحث مع فهم احتياجاتهم وإيجاد توازن جيد بينهم.

في بعض الأحيان يكون من المفيد عقد جلسة غداء وتعلم وإحضار بعض الطعام. تساعد مشاركة وجبة أثناء المناقشات في تحطيم الجدران – ولا تؤذي كشيء من الرشوة أيضًا.

بعض المناقشات الأكثر إنتاجية التي أجريتها مع فرق المطورين كانت حول بضع شرائح من البيتزا.

بالنسبة للمواقع الموجودة ، كن مبدعًا

يجب أن تكون أكثر إبداعًا إذا تم إطلاق الموقع بالفعل.

في كثير من الأحيان ، انتقلت فرق المطورين إلى مشاريع أخرى وقد لا يكون لديها الوقت للتراجع و “إصلاح” الأشياء التي تعمل وفقًا للمتطلبات التي تلقوها.

هناك أيضًا فرصة جيدة ألا يرغب العملاء أو أصحاب الأعمال في استثمار المزيد من الأموال في مشروع موقع ويب آخر. هذا صحيح بشكل خاص إذا تم إطلاق موقع الويب المعني مؤخرًا.

أحد الحلول الممكنة هو التقديم من جانب الخادم. يؤدي هذا إلى تفريغ العمل من جانب العميل ويمكن أن يؤدي إلى تسريع الأمور بشكل كبير.

يتمثل أحد أشكال ذلك في الجمع بين عرض جانب الخادم والتخزين المؤقت لمحتوى HTML للنص العادي. يمكن أن يكون هذا حلاً فعالاً للمحتوى الثابت أو شبه الثابت.

كما أنه يوفر الكثير من الحمل على جانب الخادم لأنه يتم عرض الصفحات فقط عند إجراء تغييرات أو وفقًا لجدول زمني منتظم بدلاً من كل مرة يتم طلب المحتوى فيها.

البدائل الأخرى التي يمكن أن تساعد ولكن قد لا تحل تمامًا تحديات السرعة هي التصغير والضغط.

يزيل التصغير المسافات الفارغة بين الأحرف ، مما يجعل الملفات أصغر. يمكن استخدام ضغط GZIP لتنزيل ملفات JS و CSS.

التصغير والضغط لا يحلان تحديات الوقت. لكنهم على الأقل يقللون من الوقت اللازم لسحب الملفات بأنفسهم.

Google-and-javascript-indexing-what-gives”>فهرسة جوجل وجافا سكريبت: ماذا يعطي؟

لفترة طويلة ، اعتقدت أن جزءًا على الأقل من سبب بطء Google في فهرسة محتوى JS هو التكلفة الأعلى لمعالجته.

بدا الأمر منطقيًا بناءً على الطريقة التي سمعت بها وصف هذا:

• استحوذ التمريرة الأولى على كل النص العادي.
• كانت هناك حاجة إلى تمريرة ثانية للاستيلاء على JS ومعالجته وتقديمه.

توقعت أن الخطوة الثانية ستتطلب مزيدًا من النطاق الترددي ووقت المعالجة.

سألت جون مولر من Google على Twitter إذا كان هذا افتراضًا عادلًا ، وأعطى إجابة مثيرة للاهتمام.

من وجهة نظره ، فإن صفحات JS ليست عامل تكلفة ضخم. ما هو مكلف في عيون Google هو الصفحات المتجاوبة التي لا يتم تحديثها أبدًا.

في النهاية ، كان العامل الأكثر أهمية بالنسبة لهم هو ملاءمة وفائدة المحتوى.

---

الآراء المعبر عنها في هذه المقالة هي آراء المؤلف الضيف وليست بالضرورة آراء محرك البحث. مؤلفو طاقم العمل مدرجون هنا.

---