مرحباً، أولاً وقبل كل شيء أود أن أقول إنني لست ممن يسعون وراء تحسين محركات البحث (SEO) أو أبذل قصارى جهدي لتلبية “متطلبات” جوجل أو تفضيلاتها حول كيف يجب أن يبدو موقعي ويعمل. ولكن يجدر العلم أن جوجل أرسلت لي للتو بريدًا إلكترونيًا حول حاجة موقعي إلى التحسن في مقياسهم الجديد “Core Web Vital” الذي سيبدأ قريبًا في التأثير بشكل كبير على تصنيفاتهم:
هذا هو التقرير على Discourse Meta، وهو أسوأ قليلاً من موقعي الخاص بالنسبة لمقياس INP (372 مللي ثانية مقابل 208 مللي ثانية):
بالنظر إلى أن Discourse هو في الأساس تطبيق ويب يعتمد على جافاسكريبت، أتخيل أنه لن يكون من السهل تحسين هذه المقاييس. ولكن مرة أخرى، يبدو أن جوجل تستند في تصنيفها إلى الإصدار الذي لا يستخدم جافاسكريبت والذي تراه برامج زحف الويب الخاصة بها على الرغم من ادعائها بمحاكاة هاتف Moto G Power…
مرحباً @rahim123 - إن تحسين INP هو أحد دوافع تبديل رسوم التنقل في صفحات Discourse من “دوار” لكامل الصفحة إلى شريط تمرير. لقد نشرنا هذا التغيير على Meta الأسبوع الماضي فقط، لذلك من المبكر جدًا ظهور التغيير في بيانات مسح مؤشرات أداء الويب الخاصة بجوجل.
لكن كن مطمئنًا، نحن نراقب البيانات وسننظر في إجراء تعديلات إضافية إذا لزم الأمر.
شكراً جزيلاً على الرد. يسعدني أن أسمع أنك على اطلاع بهذا الأمر.
لقد استخدمت أداة اختبار عناوين URL المباشرة من Google https://pagespeed.web.dev، لذلك ألا ينبغي تضمين ذلك بالفعل في التصنيف؟ وبما أن Google ترى الإصدار الذي لا يستخدم جافاسكريبت، لست متأكدًا من كيفية أخذها في الاعتبار الدوار مقابل شريط التمرير؟ ألا يتعلق INP بالتنقل من صفحة إلى أخرى داخل نفس الموقع؟ في هذه الحالة، لا أفهم حقًا كيف تقيس هذا المقياس لعنوان URL واحد. آسف لجهلي، أنا بعيد كل البعد عن الخبراء في هذه التفاصيل الدقيقة المتعلقة ببنية الصفحة وأحدث نزوات Google.
نعم، “رؤى سرعة الصفحة” وزاحف بحث Google يجلبان الإصدار الأساسي من HTML لـ Discourse. لذا للأسف هذه الأدوات عند الطلب ليست مفيدة جدًا لنا.
بالنسبة لتصنيف البحث، تستخدم Google بيانات العالم الحقيقي التي تم جمعها من مستخدمي Chrome على أجهزة الكمبيوتر المكتبية وأجهزة Android. إنهم يجعلون هذه البيانات متاحة للجمهور على Overview of CrUX | Chrome UX Report | Chrome for Developers. للأسف، هناك تأخير لمدة شهر إلى شهرين بين الجمع والنشر، وهذا هو السبب في أننا بحاجة إلى الانتظار لفترة قبل أن نتمكن من رؤية التأثير الحقيقي لهذا الشريط المنزلق الجديد للتحميل.
لمعرفة بيانات Google لموقعك الخاص (أو لـ Meta)، انتقل إلى هنا وأدخل النطاق: https://developer.chrome.com/docs/crux/dashboard/. بمجرد تحميل التقرير، يوجد علامة تبويب لـ INP على الجانب الأيسر. على حد علمي، تركز Google على بيانات “الجوال” لتصنيف البحث، لذا ستحتاج إلى استخدام عامل تصفية الجهاز للتعمق في ذلك.
على وجه الخصوص، يبدو أن الصفحات التي يتم الوصول إليها بشكل أساسي من قبل حسابات مجهولة قادمة من جوجل هي الأسوأ أداءً. قد يكون الأمر خاصًا بمنتدى الخاص بي ولكني اعتقدت أنه يستحق المشاركة.
ديفيد، يبدو أن هناك تحسنًا كبيرًا ملحوظًا، على الرغم من أنني معجب بالدوار القديم هل يمكنك تذكيري بالتغيير التقني رفيع المستوى في النهج هنا الذي يسهل هذا التحسن؟ هل تم توثيق ذلك في مكان ما؟
من المهم جدًا ملاحظة أن INP سيؤثر فقط على ترتيب الموقع في مارس 2024، لذا فإن التحسينات التي نعمل عليها اليوم لديها وقت للتكرار عليها قبل أن تبدأ في التأثير على جوجل.
بالنسبة لبيانات النطاق الخاص بك مثل meta.discourse.org، يوجد دائمًا تقرير حديث في وحدة تحكم بحث Google مخفي داخل “التجربة” – > “مقاييس الويب الأساسية” – > “الجوال (فتح التقرير)” وقم بالتمرير لأسفل إلى “مشكلة INP: أطول من 200 مللي ثانية (الجوال)”
تعديل: هذا يقع ضمن نطاق الاحتمالية المنخفضة/التأثير العالي. INP يأخذ في الاعتبار p75 فقط.
قد يتأثر INP بإجراءات ما بعد “الطهي” (= تحسين الميزات عبر JS عند التحميل) لنواة Matomo أو الإضافات التي تقوم ببعض المهام “الثقيلة” لـ JS والتي لديها “وقت حظر العرض” كبير.
خاصة عندما ينتقل المستخدم إلى موضوع آخر، يتم “طهي” حوالي 10-20 مشاركة دفعة واحدة.
هنا من الجيد دائمًا تقسيم المهام للمشاركات الفردية إلى setTimeouts() منفصلة للسماح للمتصفح بالرسم بين المهام الفردية وعدم الانتظار حتى انتهاء العملية بأكملها.
على سبيل المثال، شيء مثل هذا:
var initializeSliderSlickItem = function (item) {
/* قم بالتهيئة الفعلية هنا */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
تعديل: هذا يندرج ضمن نطاق الاحتمالية المنخفضة/التأثير العالي. INP يأخذ فقط p75 في الاعتبار.
… وبعد ذلك تبدأ عملية الطهي. إذا نقر المستخدم بعد ذلك على شيء ما أثناء تشغيل مهمة طهي Discourse، فإن Google تقيس INP كوقت حتى الطلاء التالي. قد يظهر الطلاء التالي في أقرب وقت عند انتهاء مهمة الطهي قيد التشغيل.
“حياة التفاعل. يحدث تأخير في الإدخال حتى تبدأ معالجات الأحداث في العمل، والتي قد تكون ناجمة عن عوامل مثل المهام الطويلة على الخيط الرئيسي [مثل “الطهي”]. ثم تعمل معالجات أحداث التفاعل، ويحدث تأخير قبل عرض الإطار التالي.”
تأخذ Google في الاعتبار أطول وقت حظر للطلاء لـ INP إذا كانت هناك أحداث متعددة تحظر “طوال دورة حياة الصفحة بأكملها”. دورة الحياة مثل:
يفتح الخيط “أ” لعنوان URL
يظهر المؤشر
طهي المشاركات في الخيط “أ”
النقرة 1: ينقر المستخدم على رابط إلى الخيط “ب”
يظهر المؤشر
تحميل الخيط “ب”
طهي المشاركات في الخيط “ب”
النقرة 2: ينقر المستخدم على رابط إلى الخيط “ج” أثناء طهي الخيط “ب”
ينتهي إجراء الطهي قيد التشغيل على الخيط “ب” (يُحتسب ضمن INP للنقرة 2)
هل يمكنك تذكيري بالتغيير التقني رفيع المستوى في النهج هنا الذي يسهل هذا التحسن؟ هل تم توثيق ذلك في مكان ما؟
