Hallo, zuallererst möchte ich sagen, dass ich nicht hinter SEO her bin oder mich besonders bemühe, Googles Forderungen Präferenzen anzupassen, wie meine eigene Website aussehen und funktionieren soll. Aber es ist erwähnenswert, dass Google mir gerade eine E-Mail geschickt hat, in der es heißt, meine Website müsse ihre neue „Core Web Vital-Metrik“ verbessern, die bald sehr stark in ihre Rankings einfließen wird:
Hier ist der Bericht über Discourse Meta, der für INP etwas schlechter ist als meine eigene Website (372 ms vs. 208 ms):
Da Discourse im Grunde eine Javascript-Webanwendung ist, stelle ich mir vor, dass es nicht einfach sein wird, diese Metriken zu verbessern. Aber andererseits scheint Google sein Ranking auf der No-Javascript-Version zu basieren, die seine Webcrawler sehen, obwohl es behauptet, ein Moto G Power-Telefon zu emulieren…
…daher glaube ich nicht wirklich an oder kümmere mich zu sehr um das, was ihre Algorithmen und Rankings bestimmen. Aber es ist eine nützliche Information für Entwickler und Website-Administratoren, sich dessen bewusst zu sein.
Hallo @rahim123 - die Verbesserung von INP ist eine der Motivationen für den Wechsel der Seitennavigationsanimation von Discourse von einem vollständigen Seiten-„Spinner“ zu einem Schieberegler. Wir haben diese Änderung erst letzte Woche auf Meta bereitgestellt, daher ist es noch etwas zu früh, als dass die Änderung in den Web-Vitals-Umfragedaten von Google auftauchen würde.
Aber seien Sie versichert, dass wir die Daten im Auge behalten und weitere Anpassungen vornehmen werden, falls dies erforderlich ist.
Vielen Dank für die Antwort. Ich freue mich zu hören, dass Sie das im Griff haben.
Ich habe den Live-URL-Tester von Google https://pagespeed.web.dev verwendet, sollte das nicht bereits in das Ranking einbezogen werden? Und da Google die No-Javascript-Version sieht, bin ich mir nicht sicher, wie es den Spinner im Vergleich zum Schieberegler berücksichtigt? Muss INP nicht etwas mit der Navigation von einer Seite zur anderen innerhalb derselben Website zu tun haben? In diesem Fall verstehe ich nicht wirklich, wie es diese Metrik für eine einzelne URL misst. Entschuldigen Sie meine Unwissenheit, ich bin weit davon entfernt, ein Experte für diese Feinheiten der Seitenarchitektur und die neuesten Launen von Google zu sein.
Ja, ‘pagespeed insights’ und der Google-Suchcrawler rufen die Basic-HTML-Version von Discourse ab. Diese On-Demand-Tools sind daher leider nicht sehr hilfreich für uns.
Für das Suchranking verwendet Google reale Daten, die von Chrome-Nutzern auf Desktops und Android gesammelt wurden. Diese Daten stellen sie öffentlich unter Overview of CrUX | Chrome UX Report | Chrome for Developers zur Verfügung. Leider gibt es eine Verzögerung von 1-2 Monaten zwischen Sammlung und Veröffentlichung, weshalb wir eine Weile warten müssen, bevor wir die realen Auswirkungen dieses neuen Lade-Sliders sehen können.
Um die Google-Daten für Ihre eigene Website (oder für Meta) einzusehen, gehen Sie hierher und geben Sie die Domain ein: https://developer.chrome.com/docs/crux/dashboard/. Sobald Sie den Bericht geladen haben, gibt es auf der linken Seite einen Reiter für INP. Soweit ich mich erinnere, konzentriert sich Google für das Suchranking auf die ‘mobilen’ Daten, daher müssen Sie den Gerätefilter verwenden, um sich damit zu befassen.
Ziel ist es, mindestens 75 % ‘gut’ zu erreichen – das bedeutet, dass der P75 INP-Wert, den Google für das Suchranking verwendet, weniger als 200 ms beträgt.
Als Datenpunkt verwende ich ausschließlich die discourse-loading-slider-Theme-Komponente, seit meine Website live ist. Ich befinde mich immer noch in der Zone „Verbesserungsbedürftig“
Insbesondere scheinen die Seiten, auf die hauptsächlich anonyme Konten von Google zugreifen, am schlechtesten abzuschneiden. Könnte spezifisch für mein Forum sein, aber ich dachte, es wäre erwähnenswert.
David, es scheint eine riesige wahrgenommene Verbesserung zu sein, obwohl ich den alten Spinner mag. Können Sie mich an die technische Änderung des Ansatzes auf hoher Ebene erinnern, die diese Verbesserung ermöglicht? Wurde das irgendwo dokumentiert?
Ember reißt das gesamte DOM nieder und bereinigt Komponenten von der alten Route
Spinner wird auf dem Bildschirm gerendert
Sobald die Netzwerkanfrage gelöst ist, wird die neue Route im DOM gerendert
Mit dem Slider überspringen wir Schritt 2. Der Slider wird sofort gerendert, ohne auf den aufwendigen Abbauprozess warten zu müssen.
Ich sollte hier klarstellen: Die Hauptmotivation für uns, die Standardeinstellung zu ändern, ist die verbesserte Benutzererfahrung. Die Verbesserung der INP-Metrik ist ebenfalls nett, aber nicht der Hauptgrund für die Änderung.
Es ist sehr wichtig zu beachten, dass sich INP erst im März 2024 auf das Website-Ranking auswirken wird. Daher haben die Verbesserungen, an denen wir heute arbeiten, Zeit, iteriert zu werden, bevor sie Google beeinflussen.
Für Ihre eigenen Domaindaten wie meta.discourse.org gibt es immer einen aktuellen Bericht in der Google Search Console, versteckt unter ‘Erlebnis’ → ‘Core Web Vitals’ → ‘Mobil (Bericht öffnen)’ und scrollen Sie nach unten zu ‘INP-Problem: länger als 200ms (mobil)’
Bearbeiten: Dies fällt eher in die Kategorie geringe Wahrscheinlichkeit/hohe Auswirkung. INP berücksichtigt nur p75.
Der INP könnte durch die Post-?Cooking?-Prozeduren (= Feature-Verbesserung durch JS beim Laden) des Matomo-Kerns oder von Plugins beeinflusst werden, die einige ‘schwere’ JS-Aufgaben mit einer langen ‘Render Blocking Time’ ausführen.
Besonders wenn der Benutzer zu einem anderen Thread wechselt, werden etwa 10-20 Beiträge gleichzeitig “gekocht”.
Hier ist es immer gut, die Aufgaben für einzelne Beiträge in separate setTimeouts() aufzuteilen, damit der Browser zwischen den einzelnen Aufgaben malen kann und nicht auf den Abschluss des gesamten Prozesses warten muss.
Zum Beispiel so etwas:
var initializeSliderSlickItem = function (item) {
/* hier die eigentliche Initialisierung durchführen */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
Bearbeiten: Dies fällt eher in die Kategorie geringe Wahrscheinlichkeit/hohe Auswirkung. INP berücksichtigt nur p75.
… und danach beginnt das Kochen. Wenn der Benutzer dann etwas anklickt, während eine Discourse-Kochaufgabe läuft, misst Google INP als die Zeit bis zum nächsten Paint. Der nächste Paint kann frühestens nach Abschluss der laufenden Kochaufgabe erscheinen.
“Das Leben einer Interaktion. Eine Eingabeverzögerung tritt auf, bis die Ereignisbehandlungsroutinen zu laufen beginnen, was durch Faktoren wie lange Aufgaben auf dem Hauptthread [z. B. „Kochen“] verursacht werden kann. Anschließend werden die Ereignisbehandlungsroutinen der Interaktion ausgeführt, und es tritt eine Verzögerung auf, bevor der nächste Frame dargestellt wird.”
Google berücksichtigt die längste Paint-blockierende Zeit für INP, wenn es während des gesamten Lebenszyklus der Seite mehrere blockierende Ereignisse gibt. Lebenszyklus wie:
URL-Thread “A” wird geöffnet
Spinner wird angezeigt
Beiträge im Thread “A” werden gekocht
Klick 1: Benutzer klickt auf Link zu Thread “B”
Spinner wird angezeigt
Thread “B” wird geladen
Beiträge im Thread “B” werden gekocht
Klick 2: Benutzer klickt auf Link zu Thread “C”, während Thread “B” noch gekocht wird
Die laufende Kochaktion auf Thread “B” wird abgeschlossen (zählt in INP für Klick 2)
“INP wird berechnet, wenn der Benutzer die Seite verlässt, was zu einem einzigen Wert führt, der die allgemeine Reaktionsfähigkeit der Seite während des gesamten Lebenszyklus der Seite repräsentiert.”
Gut, dass die Verwendung des p75 der Metrik bedeutet, dass sich niemand wirklich Sorgen um das von Ihnen beschriebene Szenario machen muss, und es stellt eindeutig keine normalen Interaktionen mit Discourse dar.
mag. Können Sie mich an die technische Änderung des Ansatzes auf hoher Ebene erinnern, die diese Verbesserung ermöglicht? Wurde das irgendwo dokumentiert?
