كنت أستكشف نتائج بحث Google الخاصة بنا في وقت سابق من اليوم، ولاحظنا نحن أيضًا انخفاضًا كبيرًا في حركة المرور من نتائج البحث إلى مثيل discourse الخاص بنا (discourse.julialang.org) بعد 4 مايو (حوالي 30%). لم ألاحظ ذلك حتى الآن، لأن discourse يمثل حوالي نصف عدد مرات مشاهدة صفحاتنا فقط، بينما شهدت بقية موقعنا زيادة في حركة المرور نتيجة هذا التحديث، لذا كان التأثير الصافي سلبيًا قليلاً فقط. لكن يصبح الأمر واضحًا جدًا عند فصل discourse عن غير discourse على نفس النطاق. إنها تعود ببطء إلى الارتفاع، ولكن بنفس معدل نمو بقية الموقع. هل هناك أي إجراء يمكن اتخاذه بشأن مشكلة LCP؟ يبدو أن هذا مرشح جيد لما يتم معاقبته من قِبل Google (وأرى أيضًا عشرات الآلاف من شكاوى LCP في وحدة تحكم البحث الخاصة بنا). تشير مقاييس Google إلى أن LCP على الجوال يبلغ حوالي 3 ثوانٍ للعديد من صفحات discourse لدينا، وهو ما يبدو مرتفعًا جدًا. يبدو أن هذه مشكلة عالمية في discourse. على سبيل المثال، إذا قمت بتشغيل تقرير على هذا الموضوع نفسه، فستكون قيمة LCP هي 3.3 ثانية. للأسف، لست مطور ويب، لذا لا أملك أي اقتراحات ملموسة، لكنني آمل أن يتمكن شخص ما يعرف المزيد عن هذا الأمر من تقديم اقتراح. سيكون من الرائع حقًا استعادة تلك الـ 30% من حركة المرور 
.
إليك رسمنا البياني لظهورات البحث مع تنعيم أسبوعي، مقسّماً بين discourse وباقي النطاق (الذي أفترض أنه يحمل نفس تصنيف الثقة على مستوى النطاق). تحديث مايو واضح جداً. وبشكل متناقض، شهدنا طفرات حركة مرور غير مرتبطة في نفس الأسبوع لباقي الموقع، لكنني أقول إن السلوك العام يُظهر انخفاضاً ملحوظاً في ظهورات discourse وظهورات مستقرة إلى حد كبير (متجاهلين طفرات حركة المرور غير المرتبطة) لباقي الموقع.
هذا بالضبط ما كنت أشكو منه منذ أشهر، لكن المدراء لا يأخذونه على محمل الجد @Keno
بدأنا أيضًا في تجربة Vuejs لتقديم بعض محتوانا عبر Nuxt لتحسين أداء التصيير المسبق في Discourse، ويمكننا ملاحظة ذلك؛ فقد نُشرت التحديثات منذ أقل من شهر، وخلال آخر يومين أو ثلاثة أيام تضاعفت عدد مرات الظهور لدينا لتعود تمامًا إلى ما كانت عليه قبل تحديث مايو.
غير متأكد مما إذا كان هذا مجرد مصادفة أم لا، لكن ربما يكون له علاقة بـ LCP. سأواصل المراقبة لبضعة أسابيع أخرى قبل استخلاص أي استنتاجات.
بعد قراءة منشور المدونة هذا، يبدو النصيحة… عامة للغاية. يمكن تلخيصها بشكل أساسي في “أنشئ محتوى عالي الجودة”. لست متأكدًا حتى من التغييرات المحددة التي يمكننا إجراؤها على Discourse بناءً على منشور المدونة هذا؟ 
لا أعرف ما إذا كان الأمر يتعلق فقط بجودة المحتوى، فقد يكون له علاقة بوقت LCP المرتفع، والذي أعتقد أنه يمكن إصلاحه في Ember، لكنني لست متأكدًا حقًا، ما زلت أجرب حلولًا أخرى لأرى…
أعتقد أنك تركز بشكل مفرط قليلاً على مقياس واحد هنا. إنك تركز عليه أكثر مما تفعل جوجل.
لقد نشروا عن LCP في 28 مايو، وقد قالوا “سنقدم إشعارًا لمدة 6 أشهر قبل تنفيذ هذه التغييرات.”. ولم يتم تقديم هذا الإشعار حتى اليوم.
كما قلت، ليس لدي دليل، ولا أركز عليه. ما زلت أجرب أشياء أخرى وأرى ارتفاعًا في عدد مرات الظهور إلى ما كان عليه في البداية منذ أمس. سأتابع الأمر لأرى كيف يسير خلال الأسابيع القليلة القادمة.
نعم، لا نعرف ما إذا كان LCP هو المخطئ على الإطلاق، لكنه العنصر الوحيد الذي يلفت الانتباه في وحدة تحكم البحث، والذي يشير لنا إلى وجود حوالي 20 ألف خطأ لصفحات ذات LCP مرتفع. بغض النظر عن أي تأثير على تحسين محركات البحث (SEO)، يبدو أن تحسين وقت LCP هدف يستحق السعي إليه. بالطبع، هناك سؤال حول مدى دقة مقاييس جوجل في عكس الواقع، ولكن إذا كانت دقيقة، فإن وقت التحميل الأولي البالغ 5 ثوانٍ يعتبر طويلاً جداً، وبالتأكيد هناك طريقة للتحسين. خاصة في حالة المستخدم غير المسجل الذي يأتي من جوجل، يبدو أن تقديم صفحات مُعدة مسبقاً عبر شبكة توصيل المحتوى (CDN) قد يكون مفيداً للغاية.
إنه يشير إلى LCP، لكنني أعتقد أن المشكلة تكمن في FCP… لاحظ الأوقات المتطابقة
تحميل الصفحة الأولى في Discourse أبطأ من التحميلات اللاحقة لأنك تقوم بتحميل التطبيق وليس تلك الصفحة الأولى فقط، لذا أعتقد أن تقليل وقت التحميل الأولي للوصول إلى المستوى “الجيد” الذي تحدده جوجل (أقل من ثانية واحدة لـ FCP) على الأجهزة المحمولة هو أمر أسهل في القول منه في التنفيذ.
أعتقد أنكم تركزون كثيرًا على العوامل “الفنية” الصلبة. فما لا يخبركم به جوجل فعليًا هو أنهم يقيسون أيضًا “الأداء المُدرَك” للمواقع الإلكترونية.
قد يكون لدي Discourse إمكانات لتحسين “الأداء المُدرَك”، ويجب أن يكون كذلك.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
هناك العديد من الطرق للقيام بذلك، مثل التمهيد المسبق للهياكل العظمية (skeleton prerendering) قبل تحميل التطبيق بالكامل.
بشكل أساسي، أي شيء يظهر قبل اكتمال تحميل التطبيق يساعد في تحسين الأداء المُدرَك. حتى مجرد عرض الرأس (بدون محتوى، فقط اللون الصحيح) والخلفية مع مؤشر تحميل الصفحة قبل توفر التطبيق بالكامل سيساعد في عرض الصفحة الأولي. أي شيء يتم بناؤه على مراحل بحيث يعرف المستخدم… أن شيئًا ما يحدث حتى على الأجهزة البطيئة.
على سبيل المثال، بالنسبة لـ Meta، يمكن/يجب عرض شيء مثل هذا فورًا (يمكن القيام بذلك باستخدام CSS حرج بسيط) قبل توفر التطبيق بالكامل للمتصفح:
هناك مئات المقالات لتحسين الأداء المُدرَك لتطبيقات الويب الفردية. ربما يكون هناك شيء يستحق النظر فيه من قِبل @team؟
يمكن إنشاء صفحة “تحميل” كمكون في السمة، إذا رغبتَ، ربما تجرب ذلك وتُبلغنا عما إذا كان يُحدث أي فرق في موقعك؟
لا أعتقد أن النتيجة المرجوة ممكنة باستخدام مكون سمة بسيط. لهذا الغرض، أحتاج إلى وجود كتلة CSS مضمنة حرجة في الرأس، يتم وضعها قبل أي نصوص برمجية أو وسوم وصفية CSS أخرى. بالإضافة إلى ذلك، يتم عرض عنصر <body> فقط بعد تحميل التطبيق بالكامل. لا أرى كيف يمكن استخدام مكون سمة لتحقيق النتائج المرجوة، مثل وجود كتلة CSS حرجة في الرأس، وعرض بعض عناصر <div> على الأقل في الجسم قبل اكتمال تحميل التطبيق.
هناك حل يضيف عنصر التحميل بشكل طفيف في وقت أبكر…
هل تملك مصدرًا يؤكد تأثير الأداء المُدرَك على ترتيب البحث، أم أنك تقصد FCP/LCP؟ فـ FCP و LCP مفاهيم محددة ولها متطلبات تقنية رغم أنها مبنية على الإدراك. كما تجدر الإشارة إلى أن FCP ليست جزءًا من “إحصائيات الويب الأساسية” (Core Web Vitals) الخاصة بجوجل (بينما LCP جزء منها).
إليك المزيد من التفاصيل من https://web.dev/lcp/:
كما هو محدد حاليًا في واجهة برمجة تطبيقات Largest Contentful Paint، فإن أنواع العناصر التي تُؤخذ في الاعتبار لـ Largest Contentful Paint هي:
- عناصر
<img>- عناصر
<image>داخل عنصر<svg>- عناصر
<video>(يُستخدم صورة الغلاف)- عنصر يحتوي على صورة خلفية تم تحميلها عبر دالة
url()(على عكس تدرج CSS)- عناصر مستوى الكتلة تحتوي على عقد نصية أو عناصر نصية مضمنة أخرى كأبناء.
إذا أزال الصفحة عنصرًا من DOM، فلن يُؤخذ هذا العنصر في الاعتبار بعد ذلك. وبالمثل، إذا تغيرت مورد الصورة المرتبط بعنصر ما (مثل تغيير
img.srcعبر JavaScript)، فإن هذا العنصر سيتوقف عن الاعتباره حتى يتم تحميل الصورة الجديدة.
هذه المتطلبات تجعل الأمر صعبًا بعض الشيء، ربما يمكن أن يعمل عنصر تحميل يحتوي على صورة كبيرة أو نص إذا قمت بإخفائه بطريقة أخرى بدلاً من إزالته من DOM؟ يستخدم المؤشر أعلاه خاصية z-index لإخفاء نفسه، لذا ربما يمكن أن ينجح ذلك… لكن المؤشر نفسه لا يكفي لأنه ليس صورة أو نصًا (إنه CSS).
أتفق على أن وجود نوع من عناصر التحميل سيكون مفيدًا للمستخدمين على الشبكات البطيئة، لكن هناك متطلبات محددة يجب الالتزام بها من أجل جوجل (ولا نعرف ما إذا كان ذلك سيحل المشكلة التي ذكرها صاحب الموضوع الأصلي).
يتطلب ذلك إعادة كتابة شاملة لمنصة Discourse من القاعدة إلى القمة، لذا لا تتوقع حدوث ذلك قريبًا.
لقد راجعت هذا المكون، لكنني لا أعتقد أنه يُحدث فرقًا كبيرًا لأنه يُحمّل متأخرًا جدًا، أي عندما تكون معظم أجزاء التطبيق قد أُطلقت بالفعل. جوجل لا تكشف عن التفاصيل الدقيقة لما تأخذه في الاعتبار وغير ذلك. بالإضافة إلى المحتوى، فإن تجربة المستخدم (UX) الذاتية هي بالتأكيد شيء يقيسونه، حتى لو بشكل غير مباشر، مثل العودة إلى محرك بحثهم. التحميل الطويل (المُدرَك) = معدل ارتداد أعلى في أول ضربة. علاوة على ذلك، حتى لو لم يكن هذا ذا صلة بنسبة 200% بتحسين محركات البحث (SEO) وفقًا لما تعلنه جوجل رسميًا، فإنه لا يزال ذا صلة من منظور تجربة المستخدم وحركة المرور. لأن المستخدم سيعود إذا لم تكن الأداء المُدرَك في أول تحميل للصفحة جيدًا بما يكفي.
أفهم هذا تمامًا. ويجب أن أعترف أنني لا أفهم عملية عرض التطبيق بالكامل بعد.
في الواقع، إذا كنت ترغب في الفوز بناءً على هذه المقياس، فانتقل إلى موقع ثابت تم إنشاؤه مسبقًا، مثل مشروع Google AMP بأكمله.
لأنك ستخسر دائمًا أمام المواقع التي تحتوي على صفحات ثابتة.
أتحدث معي؟ لا لا، أنا سعيد جدًا بمنصة Discourse 
وتجربة المستخدم الجيدة لا تتعلق فقط بتحميل الصفحة الأولى، فربما نفقد بعضًا من الأداء في التحميل الأول، لكن بمجرد تحميل التطبيق، يبقى المستخدمون لفترة أطول ويعودون بشكل متكرر أكثر مقارنة بالصفحات الثابتة المملة. وأنا متأكد من أن جوجل تأخذ هذا في الاعتبار أيضًا.
علاوة على ذلك، منذ انتقالنا إلى Discourse، لم يشتكِ أي مستخدم من السرعة. كما أن حركة البحث لدينا في ازدياد مقارنة بصفحة Drupal فائقة التحسين التي كانت تتميز بوقت تحميل فوري للصفحة الأولى عبر التخزين المؤقت الكامل لـ HTML باستخدام Fastly و CSS الحرج.
@codinghorror يا أصدقاء، لقد أجريت بعض الاختبارات على النطاقين اللذين أملكهما،
تأثر كلاهما بتحديث 4 مايو:
دراسة الحالة الأولى: التركيز بالكامل على جودة المحتوى (كما اقترح العديد منكم أعلاه)
في الموقع الأول، ركزت على تحسين المحتوى، والكلمات المفتاحية، وإزالة أي روابط سيئة، والربط الداخلي، وإضافة محتوى جديد جيد يحمل الكثير من الإمكانات… وهكذا.
كما ترون أعلاه، ذهبت كل الجهود سدى. فحتى مع فهرسة المقالات الجديدة بشكل جيد، وإزالة المحتوى الضعيف، وتحسين المقالات القديمة، بالكاد يمكن ملاحظة أي تحسن على الإطلاق. الأمر أشبه بأن جوجل تفهرس الموقع بشكل جيد بما يكفي لاستقبال حركة مرور بسيطة، لكن ليس أكثر من ذلك!
دراسة الحالة الثانية: الانتقال إلى Vue+Nuxt (تحسين الهيكل قليلاً + سرعة LCP والتقديم)
أما في الموقع الثاني، فقد قمت فقط بنقل بعض الصفحات إلى تطبيق Vue+Nuxt مخصص لدينا يخدم نفس المحتوى مع تغييرات طفيفة أو معدومة في الهيكل عبر واجهة برمجة التطبيقات (API). لم يكن هناك أي جهود أخرى للتحسين (رغم أنه في هذه الحالة، فإن نقل المجتمع من نطاق community. إلى community.com وتقديم المحتوى على الموقع الرئيسي كان سيضر أكثر مما ينفع، وهو ما حدث فعلياً لفترة قصيرة).
لا أعرف ما يمكن استنتاجه مما سبق، وسأستمر في الاختبار والمراقبة. لكن بالتأكيد، تلك القفزة المفاجئة مثيرة للاهتمام. وبالمناسبة، لقد تحققت من الوضع قبل وبعد مايو، وبعد تلك القفزة الأخيرة، ولاحظت في جميع هذه الحالات أن العديد من المقالات فقدت عدد مرات الظهور (impressions)، وفجأة استعادت نفس المقالات تقريباً نفس الكمية من مرات الظهور. إذن، الأمر لا يتعلق بمقال أو صفحتين تأثرتا، بل بشيء ما يجعل جوجل يعاقب الموقع بأكمله، ثم يترك هذه العقوبة مفعلة على الموقع بالكامل بغض النظر عن الجهود المبذولة لتحسين جودة المحتوى.
أتمنى أن يكون ما سبق واضحاً، فلا تترددوا في إخباري إذا كانت لديكم أي أسئلة.
تحياتي!
إذا لم أكن مخطئًا، فإن Discourse يحاول تقديم نسخة ثابتة من صفحاته لمحركات البحث، أليس كذلك؟ هل من الممكن تقديم هذه النسخة الثابتة لجميع المستخدمين غير المسجلين؟ تشير عقوبات LCP هذه إلى أن Google ترى النسخة غير الثابتة من منتداك.
لقد بحثنا في هذا الأمر بشكل متقطع على مدار أشهر، بما في ذلك توظيف مستشارين خارجيين، وكل ذلك يعود إلى أن منتداك يتعرض لعقوبات شديدة من Google بسبب انتهاكات LCP بعد تحديث 4 مايو.