من المؤكد أنه يمكن إجراء هذا التغيير (عرض HTML لجميع المستخدمين المجهولين)، لكنه سيؤثر بشكل كبير على قابلية الاستخدام للمستخدمين المجهولين. نعم، سيشاهدون المحتوى بشكل أسرع، لكن عددًا هائلاً من الميزات التي تعمل للمستخدمين المجهولين لن تعمل بعد ذلك، بالإضافة إلى أن الموقع لن يبدو “كما ينبغي” للمستخدمين المجهولين.
ربما يمكننا جعل هذا الإعداد نوعًا من إعدادات الموقع لتتمكن من تجربته، لكن أشياء مثل “التحميل اللانهائي” ستتوقف عن العمل للمستخدمين المجهولين، وهناك تكاليف عالية جدًا هنا. كما أننا سنحتاج إلى استثمار بعض الجهود الهندسية على الأقل لتوفير مسار /login بتجاوز حتى يتمكن الأشخاص من التسجيل أو تسجيل الدخول فعليًا.
هل من الممكن ربما تقديم عرض HTML كـ الصفحة الأولى التي يراها المستخدمون المجهولون عند الدخول، ثم توفير جميع الميزات إذا استمروا في التصفح؟ يبدو أن هذا حل جيد (مع أنني لا أعرف ما إذا كان مقبولاً لمحركات البحث، رغم ذلك)
يبدو ذلك غير مثالي حقًا. هل توجد طريقة لتقديم النسخة الثابتة ثم “إثراؤها” بالأجزاء الديناميكية؟ هذا ربما يتطلب إعادة هيكلة كبيرة للنظام، لذا قد لا يكون خيارًا متاحًا حاليًا. بشكل رئيسي، نواجه 49 ألف خطأ في LCP على موقعنا بدءًا من شهر مايو، وفي نفس الوقت تضرر حركة البحث. متوسط درجة LCP لدينا الحالي هو 5.3 ثانية. أبحث عن أفكار لكيفية خفض هذا الرقم.
ربما بإضافة أو إزالة بعض الإضافات؟ زيادة أو تقليل عدد الفئات؟ وضع الأصول الثابتة على شبكة CDN؟ حاولنا تشغيل Cloudflare في الشتاء الماضي دون نجاح، لكن يمكننا المحاولة مرة أخرى. لا أعرف بنية Discourse جيدًا، لذا أنا أبحث عن إرشادات.
هذا بالضبط ما وجدناه، فنحن نجرب إزالة كل الإضافات وحتى الإعلانات (حاليًا مواقعنا لا تحتوي على إعلانات، وصور محسنة… إلخ)، وقد تمكنا من خفض LCP، لكنه بالكاد وصل إلى المنطقة الصفراء؛ لم يعد خطأً بل تحذيرًا يؤثر على موقعنا، وقد لاحظنا زيادة طفيفة منذ ذلك الحين، لكننا نحتاج إلى مزيد من الوقت لتأكيد ذلك…
بصراحة، أنا مغرر جدًا بفكرة البدء في إنشاء نسخة مفتوحة المصدر من Discourse باستخدام Nuxt+Vue.js، أو غلاف يعمل فوقه، حيث يبدو هذا الخيار هو المعقول الوحيد في الوقت الحالي!
نعم، لا توجد طريقة لتقليل وقت التحميل الأولي هذا دون بعض الهندسة الكبيرة، لأنك تقوم بتنزيل تطبيق Discourse بالكامل.
ما يزيد الطين بلة هو أن أداء JavaScript على أجهزة Android بشكل عام أسوأ منه على أجهزة iPhone… ومن الواضح أن Google تحسب فقط أجهزة Android في مقاييسها “الواقعية” للهواتف المحمولة. أما على منصة Meta، فإن حسابات iOS تمثل حوالي 40% من حركة المرور على الأجهزة المحمولة.
كل ما يمكنني قوله هنا هو أننا على علم ببطء FCP و LCP ولدينا خطط طويلة الأجل لتحسينهما.
على وجه التحديد، يقوم @eviltrout بترقيتنا إلى Ember CLI. بمجرد الانتهاء من ذلك، يمكننا البدء في التفكير في تقسيم الكود وتجربته، بالإضافة إلى حيل أخرى.
لا توجد حيل سهلة هنا؛ فنحن نستخدم شبكة توصيل محتوى (CDN)، ونحن حريصون للغاية على كيفية تحميل الأشياء. لقد قضينا ساعات لا تحصى في التحسين هنا، ولكن في الأساس، نستخدم JavaScript لعرض صفحاتنا، وتستغرق عملية تسليم JavaScript وتحليله وتشغيله وقتًا في التحميل الأول.
نعتذر عن إحياء هذا الموضوع القديم مرة أخرى، لكننا جمعنا المزيد من البيانات بعد إجراء بعض الاختبارات خلال الشهرين الماضيين…
إذن، إليك الموقعان اللذان قمنا باختبارهما سابقًا: الأول تم نقله من Discourse (EmberJs) إلى واجهة أمامية مخصصة مبنية باستخدام Vue مع Nuxt.
أما الثاني فهو Discourse، بعد إزالة الإعلانات والخطوط المخصصة وكل ما يمكن إزالته لجعله خفيفًا قدر الإمكان (وهو ما نجح في تخفيض أخطاء LCP من مستوى الخطأ إلى مستوى التحذير).
1. منتدى Discourse (تم إزالة الخطوط المخصصة والإعلانات والإضافات… إلخ)
كما ترون، في شهر مايو بعد التحديث، فقدنا 50% من ترتيب الكلمات المفتاحية. وفي أكتوبر بدأنا التغييرات، مما ساعد في تحقيق ارتفاع مؤقت قصير، ثم انخفض مرة أخرى! وكأن هناك مقاومة (وبعبارة أخرى، عقوبة من Google).
كما ترون في الصورة أعلاه، ساعدت التغييرات التي قمت بها (إزالة كل الإضافات) في نقل الروابط من فئة “روابط ضعيفة” إلى فئة “روابط تحتاج إلى تحسين”، لكن حتى ذلك لم يساعد!
2. واجهة أمامية مخصصة بـ Vue/Nuxt مع خلفية Discourse
في هذا الموقع، كما لاحظنا منذ أكثر من شهر، عاد النمو ليصل إلى مستوياته السابقة قبل 4 مايو.
الخاتمة:
نعم، تهتم Google بـ LCP!
نأمل أن يأخذ فريق Discourse الأمر بجدية أكبر الآن، وربما يكون الانتقال بعيدًا عن Ember يستحق العناء. وقد اضطررت إلى القيام بذلك بنفسي في مشروع كبير؛ نعم، كان الانتقال مكلفًا للغاية، لكنه كان يستحق كل ذلك.
لا تزال ترقية Ember CLI جارية وتتقدم، ولكن إذا كنت تنتظر منا الانتقال بعيدًا عن Ember تمامًا، فقد ترغب في النظر في منصة أخرى والتحقق من وضعنا بشأن LCP بعد عام.
حسنًا، لست متأكدًا مما إذا كان ترقية Discourse إلى Ember CLI يستحق العناء، لكن لا أحد يعلم؛ فقد مررنا بتجربة مماثلة في مشروع آخر واضطررنا إلى التخلي عنه بالكامل. فترقية إلى Ember CLI تتطلب جهدًا يقارب تقريبًا الجهد المطلوب للترقية إلى Vue أو أي إطار عمل آخر.
بغض النظر، كان بحثي يهدف فقط إلى تسليط الضوء على المشكلة والوصول إلى استنتاج، ففي الأيام الأولى، كان الجميع يكادون ينكرون أن LCP له أي علاقة بالتصنيف.
نحن على الأرجح قد أتممنا حوالي 90% من هذا العمل، الذي كان مدرجًا في خطتنا طويلة الأجل على أي حال، لأنه يجلب قدرًا هائلاً من راحة المطورين ويحافظ على تحديثنا مع Ember. يمكن لـ @eviltrout تقديم المشورة بالتفاصيل الدقيقة لأنه المسؤول عن هذا الجهد.
نعم، لكن هذا لا يعني أن كل موقع سيعمد الآن إلى التبديل إلى عرض HTML ثابت حتى يتمكنوا من الهيمنة على الويب بقدراتهم السحرية في تحسين محركات البحث (SEO) وسرعة تحميل الصفحة. اتضح أن المحتوى الفعلي الموجود في الصفحة مهم أيضًا للترتيب؛)
يمكنك الاطلاع على تاريخ Google AMP لترى كيف يمكن أن تؤدي هذه الزيادة المبالغ فيها في التركيز على مقياس واحد إلى قدر كبير من الصعوبات وعمل هندسي مضلل.
حسنًا، هذا بالضبط ما أحاول دحضه في منشوري. لدى جوجل بالفعل كمية هائلة من المحتوى الجيد النوعية، لذا إذا كان عليهم اتخاذ قرار بناءً على رضا المستخدمين، فأعتقد أن LCP هو الحد الأدنى الذي سيعتمدون عليه في تقييمهم. بعد كل شيء، حذرت جوجل من ذلك قبل أشهر من التحديث.
بصراحة، لدي خبرة واسعة مع Ember CLI وهي بنفس سوء الماضي. بالإضافة إلى ذلك، لا أعتقد أن جهد الترقية يستحق العناء. لكننا سنرى كيف تسير الأمور، وآمل أن يكون لدى @eviltrout أي تعليق حول ما إذا لاحظوا أي تحسينات في السرعة.
للأسف، من بحثي أعلاه! في الواقع، تركز جوجل كثيرًا على تجربة المستخدم و LCP. لقد جربنا كل شيء آخر. وكما ترون من الموقع الثاني، لم نفعل شيئًا سوى إزالة خطأ LCP، مما وضعنا على المسار الصحيح لاستعادة جميع ترتيباتنا (في الواقع، حتى الآن، لقد فعلنا ذلك بالفعل).
بدأنا باستخدام Ember CLI في شركتنا الناشئة، وكان أحد الأسباب أننا لاحظنا استخدامه في Discourse (مما لفت انتباهنا). قمنا باختباره، وكان من السهل البدء به والعمل معه، لكنه كان ثقيلاً جداً (بغض النظر عن الأسباب الأخرى).
أدخل Ember CLI تحديثاً حديثاً يتطلب إعادة كتابة أي تطبيق تم إنشاؤه بالإصدارات السابقة لـ 3، وهو ما دفعنا إلى التخلص منه تماماً.
نعم، يدعم Ember CLI التحميل الكسول، لكنه غير فعال على الإطلاق (على الأقل خلال الاختبارات التي قمنا بها)، ومعظم المكتبات المتاحة المخصصة لـ Ember CLI إما قديمة أو مليئة بالأخطاء لدرجة أننا اضطررنا إلى كتابة معظم الأشياء بأنفسنا، أو استنساخ مستودعات قديمة وصيانتها بأنفسنا.
سواء كان ذلك مع Ember CLI أم لا، فإن وقت التصيير سيء دائماً (وهو ما لن يساعد في مشكلة LCP التي نناقشها هنا).
إلى جانب ذلك، فإن طريقة عمل Ember تجعل من السهل في النهاية الحصول على تطبيق ثقيل.
أتمنى لو كان لا يزال لدي تحليلات البيانات القديمة التي كنا نجريها قبل اتخاذ قرار تغيير المنصة. لقد أتممنا للتو الهجرة من Ember إلى Vue قبل بضعة أشهر، ولا يمكنني أن أكون أكثر سعادة بأداء تطبيقاتنا وسرعة التطوير.
ملاحظة: لم أتحسن بعد فرصة للتحقق من مستودع Discourse، لكن الترقية إلى Ember CLI قد تسبب المزيد من المتاعب، حيث ستضطر إلى الترقية مرة أخرى إلى Ember Octane (الذي لم يكن مستقراً بعد) ويستخدم صيغة مختلفة تماماً… إلخ. يمكن القول إنه فوضى، وبصراحة. لست متأكداً مما إذا كانت الحجج التي استُخدمت سابقاً لاختيار Ember لا تزال قابلة للتطبيق في الوقت الحالي @Jeff.
ماذا يعني “الأخذ بجدية”؟ حرق نظامنا البيئي بالكامل والبدء من الصفر؟
مشروع Discourse في نمو، ونحن مدركون تمامًا لهذه المشكلة وننظر في إجراءات للتخفيف منها مثل Fastboot، وتقسيم الكود بشكل أكثر عدوانية، وما إلى ذلك. كل هذا معلق حتى نقوم بترقية Ember CLI.
أنا مهتم برؤية واجهة المستخدم البديلة هذه. هل يمكنك إرسال رابط لي عبر الرسائل الخاصة؟ من حيث المبدأ، إن إنشاء واجهة تعتمد فقط على HTML وغير قابلة للتخصيص أمر تافه؛ نحن نوفر عرضًا يعتمد فقط على HTML، ويمكنك رؤية أن LCP على samsaffron.com ممتاز، وهذا ببساطة إضافة لـ Discourse تقوم بتصيير HTML.
بشكل عام، أوافقك الرأي فيما يتعلق بـ LCP وتحسين محركات البحث من جوجل، وأقدر تحليلك ورؤيتك بعمق.
هل يمكنك شرح سبب أن جوجل، رغم استخدامها لـ LCP إلى الحد الذي تروج له، فإن موضوعين كتبتهما على منتدى Discourse الخاص بنا، والذي يعاني من LCP ضعيف جدًا حسب تقييم جوجل، يحتلان المرتبتين الأولى والثانية من بين 3,580,000 إدخال؟
يبدو لي أنه إذا كانت مشكلة LCP في تطبيق الصفحة الواحدة (SPA) الخاص بـ Discourse خطيرة كما تدعي، وأنا لست هنا للجدال بأي حال، بل أنا فضولي فقط بناءً على خبرتك؛ فلماذا يستطيع موقع بطيء مثل موقعنا، الذي لا يستخدم أي شبكة توصيل محتوى (CDN) ويعاني من LCP ضعيف جدًا، أن يحتل المراكز الأولى في موضوعين نُشرا قبل 11 و13 يومًا فقط، حيث يحتل هذان الموضوعان المرتبتين الأولى والثانية من بين ما يقرب من 3.5 مليون منشور آخر؟
أنا حقًا فضولي لمعرفة كيف، إذا كان لـ LCP من جوجل تأثير كبير كما تعرضه، فإن موقعنا الذي يعاني من أداء ضعيف في LCP يحقق نتائج ممتازة في صفحات نتائج محركات البحث (SERP).
وفقًا لمثالك، تبدو الإجابة واضحة جدًا: لقد بحثت عن مصطلحات محددة جدًا حيث لا يوجد منافس حقيقي بأداء LCP أفضل. أن تكون “الأفضل” أمر سهل عندما تكون الوحيد. وكما ورد في المنشورات أعلاه، لا يزال المحتوى هو العامل الأهم، ولكن عندما يتوفر الكثير من المحتوى لبحثك، تصبح العوامل الأخرى مهمة. بل قد تثبت نقطة ضده بدلاً من العكس.
أعلم أن هذا قد ذُكر بالفعل أعلاه، ولكن ألا يمكن إنشاء نسخة ثابتة وسريعة من المنتدى بصيغة HTML فقط، واستخدامها لتقديمها لمحركات البحث؟ (مع منعهم من زحف المنتدى الفعلي حيث يتصفح الأعضاء وينشرون).
تذكر أن هناك إضافة لتوليد عرض ثابت؟ هل هذه الإضافة متاحة للجميع للاستخدام؟
يبدو لي مبالغًا فيه بعض الشيء الضغط على فريق Discourse لإجراء تغييرات كبيرة على نظامهم البيئي بناءً على تحليلات ورسوم بيانية من عدد قليل جدًا من الأشخاص الذين يدّعون أن LCP يؤثر على تحسين محركات البحث (SEO) حاليًا، بينما تؤكد Google أن هذه الإشارة غير نشطة بعد.
هل إشارة LCP نشطة أم لا؟
تقول Google إن LCP لا يُستخدم بعد كإشارة لتحسين محركات البحث.
فقط لأعلمكم، أنا لست من معجبي EmberJS بالتأكيد وأوافق على أن LCP مهم. أنا أسعى فقط إلى الحقائق المبنية على البراهين والأدلة القاطعة.
نقطةُي الوحيدة هي أنه عند قراءتي لهذا الموضوع، يبدو أن البعض يضغط بشدة على فريق Discourse لإجراء تغييرات هيكلية كبيرة بناءً على شيء لا يُستخدم بعد كإشارة لتحسين محركات البحث، وفقًا لشركة Google وخبراء تحسين محركات البحث الآخرين.
هل تقولون إن Google غير صادقة مع الجمهور؟
معلومة سريعة، من غير المرجح جدًا أن تخدع Google، وهي شركة مساهمة عامة، الجمهور. فهذا سيعرّض Google لمسؤولية مالية هائلة محتملة.
مقبول تمامًا. أنا نفسي لا أعرف الكثير عن LCP. أقر بذلك. كنت أعتمد فقط على ما يُقال في هذا الموضوع، وأنت محق، لا أعرف ما إذا كان دقيقًا على الإطلاق (باستثناء الأدلة المقدمة هنا). لذا، يرجى قراءة منشوري، “كما لو أن مسألة LCP صحيحة”.
استنتاجك (والذي أعتقد أنه أن Google لا تستخدم LCP لتحديد ترتيب نتائج البحث) قد يكون صحيحًا، لكنك لا تصل إليه بالطريقة التي شرعت بها.
إنه مصطلح بحث فريد جدًا لدرجة أن Google اقترحت تصحيحات لتهجئته. لا يوجد الكثير للاختيار منه.
ستحتاج إلى إجراء العديد من عمليات البحث لاستخلاص أي استنتاج. إذا بحثت عن “+discourse +gon”، فلن يظهر موقعك على الإطلاق، والنتيجة الأولى هي The Discourse Encouragement Fund
أيضًا، أعتقد أن Google تُخصّص نتائج البحث. فالموقع الذي تزوره غالبًا ما يظهر في المقدمة بالنسبة لك، لكنه قد لا يظهر كذلك للآخرين. بالنسبة لي، النتيجة الأولى هي Plugin - Discourse Meta. أنا أستخدم عادةً محرك DuckDuckGo، لذا ربما هذه النتيجة غير مخصّصة على الإطلاق.
لا شيء من هذا يقول أو يثبت أي شيء حول LCP. كان هذا موضوعًا مثيرًا للاهتمام، وأنا أتطلع إلى استمراره. شخصيًا، أنا راضٍ عن سرعة عمل Discourse.
