Ich habe heute Morgen unsere Google-Suchergebnisse genauer untersucht, und auch wir haben nach dem 4. Mai einen deutlichen Rückgang des Traffics von den Suchergebnissen zu unserer Discourse-Instanz (discourse.julialang.org) festgestellt (etwa 30 %). Mir ist das erst jetzt aufgefallen, da Discourse nur etwa die Hälfte unserer Seitenaufrufe ausmacht und der Rest unserer Website durch dieses Update einen Traffic-Anstieg verzeichnete, sodass der Gesamteffekt nur leicht negativ war. Allerdings wird es sehr deutlich, wenn man Discourse und Nicht-Discourse auf derselben Domain getrennt betrachtet. Der Traffic steigt langsam wieder an, aber mit derselben Wachstumsrate wie der Rest der Website. Gibt es etwas, das man gegen das LCP-Problem unternehmen könnte? Das scheint ein guter Kandidat dafür zu sein, was von Google bestraft wird (und ich sehe auch zehntausende LCP-Beschwerden in unserer Search Console). Die Google-Metriken melden für viele unserer Discourse-Seiten etwa 3 Sekunden mobile LCP, was ziemlich hoch erscheint. Das scheint ein universelles Discourse-Problem zu sein. Wenn ich beispielsweise einen Bericht zu diesem Thread selbst erstelle, erhalte ich 3,3 Sekunden für die LCP. Leider bin ich kein Webentwickler und habe daher keine konkreten Vorschläge, aber hoffentlich kann jemand, der sich besser damit auskennt, etwas empfehlen. Es wäre wirklich schön, diese 30 % des Traffics zurückzubekommen 
.
Hier ist unser Graph der Suchanzeigenimpressionen mit wöchentlicher Glättung, aufgeteilt zwischen Discourse und dem Rest der Domain (bei dem ich davon ausgehe, dass derselbe domainweite Vertrauenswert gilt). Das Update im Mai ist deutlich erkennbar. Ironischerweise gab es in derselben Woche für den Rest der Website einen nicht zusammenhängenden Traffic-Anstieg, aber ich würde sagen, dass das allgemeine Verhalten einen merklichen Rückgang der Discourse-Impressionen und überwiegend stabile Impressionen für den Rest der Website zeigt (wenn man den nicht zusammenhängenden Traffic-Anstieg ignoriert).
Genau das habe ich seit Monaten beklagt, aber die Admins nehmen es nicht ernst. @Keno
Wir haben auch begonnen, mit Vue.js zu experimentieren, um einige unserer Inhalte über Nuxt auszuliefern, um die Performance des Vorrenderns von Discourse zu verbessern. Und wir können dies sehen: Das Update wurde vor weniger als einem Monat veröffentlicht, und in den letzten 2–3 Tagen haben sich unsere Impressionen verdoppelt und liegen exakt wieder auf dem Niveau vor dem Mai-Update.
Ich bin mir nicht sicher, ob das ein Zufall ist oder nicht, aber es könnte etwas mit dem LCP zu tun haben. Ich werde es noch einige Wochen weiter beobachten, bevor ich irgendwelche Schlussfolgerungen ziehe.
Nachdem ich diesen Blogbeitrag gelesen habe, ist das… suuuuper allgemeine Ratschläge. Man kann es im Grunde zusammenfassen als „qualitativ hochwertige Inhalte haben“. Ich bin mir nicht einmal sicher, was wir konkret in Discourse basierend auf diesem Blogbeitrag ändern könnten? 
Ich bin mir nicht sicher, ob es nur um die Inhaltsqualität geht. Es könnte ernsthaft mit der hohen LCP-Zeit zusammenhängen, die ich vermute, in Ember behoben werden kann. Aber ich bin mir wirklich noch nicht sicher und experimentiere weiterhin mit anderen Lösungen, um zu sehen…
Ich finde, du konzentrierst dich ein wenig zu sehr auf diese eine Metrik. Mehr sogar als Google selbst.
Sie haben am 28. Mai über LCP veröffentlicht und gesagt: „Wir werden vor der Umsetzung dieser Änderungen eine Ankündigungsfrist von sechs Monaten einhalten.
Wie ich bereits sagte, habe ich keinen Beweis, und ich konzentriere mich auch nicht darauf. Ich experimentiere weiterhin mit anderen Dingen und beobachte einen Anstieg der Impressionen auf das Niveau von gestern. Ich werde es in den nächsten Wochen im Auge behalten, um zu sehen, wie es weitergeht.
Ja, ich weiß nicht, ob LCP überhaupt schuld ist, aber es ist das eine Ding, das in der Search Console sofort ins Auge fällt und für uns ~20.000 Fehler bei Seiten mit großem LCP meldet. Unabhängig von jeglichen SEO-Auswirkungen scheint die Verbesserung der LCP-Zeit ein lohnenswertes Ziel zu sein. Natürlich stellt sich die Frage, inwieweit Googles Metriken die Realität widerspiegeln, aber wenn sie es tun, dann sind 5 Sekunden Ladezeit bei der ersten Anfrage schon recht lang, und sicher gibt es einen Weg, es besser zu machen. Besonders für den Fall, dass man angemeldet ist und direkt von Google kommt, könnte das Ausliefern vorgerendrierter Seiten über das CDN sehr nützlich sein.
Es wird auf den LCP verwiesen, aber ich denke, das Problem liegt beim FCP … beachte die identischen Zeiten.
Der erste Ladevorgang bei Discourse ist langsamer als nachfolgende Ladevorgänge, da die gesamte App und nicht nur die erste Seite geladen wird. Daher ist es meiner Meinung nach eine (viel) leichter gesagt als getan Situation, die initiale Ladezeit zu reduzieren, um auf Mobilgeräten das von Google als „gut
Ich denke, ihr konzentriert euch zu sehr auf die „technischen
Eine „Lade“-Seite kann, falls gewünscht, über eine Theme-Komponente umgesetzt werden. Probieren Sie es doch einfach aus und berichten Sie uns, ob es einen Unterschied für Ihre Website macht.
Ich glaube nicht, dass das gewünschte Ergebnis mit einer einfachen Theme-Komponente erreichbar ist. Dafür benötige ich einen kritischen Inline-CSS-Block im Header, der vor allen anderen Skripten und CSS-Meta-Tags platziert wird. Außerdem wird das -Element erst gerendert, sobald die gesamte App geladen ist. Ich sehe nicht, wie eine Theme-Komponente genutzt werden könnte, um die gewünschten Ergebnisse zu erzielen – etwa einen kritischen CSS-Block im Header zu haben und mindestens einige
Es gibt dies hier, was den Ladebalken etwas früher einblendet…
Hast du eine Quelle zur wahrgenommenen Performance, die das Suchranking beeinflusst, oder meinst du FCP/LCP? FCP und LCP sind sehr spezifisch und haben technische Anforderungen, obwohl sie auf der Wahrnehmung basieren. Beachte zudem, dass FCP nicht zu Googles „Core Web Vitals
Das würde eine bottom-up-Neuschreibung von Discourse erfordern, also würde ich mir davon keine großen Hoffnungen machen.
Ich habe mir diese Komponente angesehen, aber ich glaube nicht, dass sie einen großen Unterschied macht, da sie viel zu spät geladen wird, also wenn die meisten Teile der App bereits hochgefahren sind. Google gibt nicht bekannt, was genau sie berücksichtigen und so weiter. Neben dem Inhalt ist sicherlich auch das subjektive Nutzererlebnis etwas, das sie messen, auch wenn indirekt, z. B. durch Rückkehr zur Suchmaschine. Lange (wahrgenommene) Ladezeiten führen zu einer höheren Absprungrate beim ersten Treffer. Außerdem ist dies, selbst wenn es nach offiziellen Angaben von Google nicht zu 200 % für SEO relevant ist, immer noch aus Sicht des Nutzererlebnisses und des Traffics relevant. Denn ein Nutzer wird abspringen, wenn die wahrgenommene Leistung beim ersten Laden der Seite nicht gut genug ist.
Ich verstehe das vollkommen. Und ich muss zugeben, dass ich den Renderprozess der App noch nicht vollständig verstehe.
Ehrlich gesagt: Wenn du bei dieser Metrik gewinnen willst, solltest du zu einer statisch vorab generierten Seite gehen, wie etwa beim gesamten Google AMP-Thema.
Denn du wirst immer gegen Seiten mit statischen Seiten verlieren.
Sprichst du mit mir? Nööö, ich bin super zufrieden mit Discourse 
Und gutes UX geht nicht nur um den ersten Seitenaufruf. Vielleicht verlierst du beim ersten Laden etwas, aber sobald die App geladen ist, bleiben Nutzer definitiv länger und kommen häufiger zurück als bei langweiligen statischen Seiten. Und ich bin mir sicher, dass Google das auch irgendwie berücksichtigt.
Außerdem hat sich seit dem Wechsel zu Discourse keiner der Nutzer über die Geschwindigkeit beschwert. Und unser Suchmaschinen-Traffic steigt im Vergleich zu unserer super optimierten Drupal-Seite mit Blitzstart beim ersten Seitenaufruf durch vollständiges HTML-Caching über Fastly und kritisches CSS.
@codinghorror Also Leute, ich habe ein paar Tests mit zwei meiner Domains durchgeführt.
Beide waren vom Update vom 4. Mai betroffen:
Fallstudie 1: Vollständige Fokussierung auf die Inhaltsqualität (wie von vielen oben vorgeschlagen)
Beim ersten Fall habe ich mich darauf konzentriert, die Inhalte zu verbessern, Keywords zu optimieren, schlechte Links zu entfernen, interne Verlinkungen aufzubauen und neue, vielversprechende Inhalte hinzuzufügen usw. usw.
Wie ihr oben sehen könnt, waren all diese Bemühungen umsonst. Obwohl die neuen Artikel gut indexiert wurden, der dünne Inhalt entfernt und ältere Artikel verbessert wurden, ist kaum eine Verbesserung zu erkennen. Es ist, als würde Google die Website nur so gut indexieren, dass sie etwas Traffic erhält, aber nicht mehr.
Fallstudie 2: Umzug auf Vue+Nuxt (ein wenig Strukturverbesserung + LCP und Rendering-Geschwindigkeit)
Bei der zweiten Website habe ich lediglich einige Seiten in unsere eigene benutzerdefinierte Vue+Nuxt-App verschoben, die denselben Inhalt über die API bereitstellt, wobei sich die Struktur kaum oder gar nicht geändert hat. Es wurden keine weiteren Maßnahmen zur Verbesserung ergriffen (obwohl es in diesem Fall tatsächlich schädlicher als nützlich gewesen wäre, die Community auf eine Community-Subdomain zu verlagern und den Inhalt auf der Hauptwebsite auszuliefern, was auch für einen kurzen Zeitraum der Fall war).
Ich bin mir nicht sicher, was man aus dem Vorstehenden schließen kann, aber ich werde weiter testen. Der plötzliche Anstieg ist jedoch interessant. Übrigens habe ich vor und nach dem Mai-Update sowie nach diesem jüngsten Anstieg geprüft und in allen Fällen festgestellt, dass viele Artikel ihre Impressionen verloren haben. Plötzlich haben fast genau dieselben Artikel wieder die gleiche Anzahl an Impressionen erhalten. Es waren also nicht ein oder zwei Artikel/Seiten betroffen, sondern etwas, das dazu führt, dass Google die gesamte Website bestraft und diese Strafe dann auf der gesamten Website belässt, unabhängig von den Bemühungen um die Qualitätsverbesserung der Inhalte.
Ich hoffe, das ergibt Sinn. Zögert nicht, Fragen zu stellen.
Cheers!
Wenn ich mich nicht irre, versucht Discourse, Suchmaschinen eine statische Version seiner Seiten auszuliefern, korrekt? Wäre es möglich, diese statische Version auch allen nicht angemeldeten Nutzern bereitzustellen? Diese LCP-Strafen deuten darauf hin, dass Google die nicht-statische Version unseres Forums sieht.
Wir beschäftigen uns seit Monaten immer wieder damit, einschließlich der Beauftragung externer Berater, und alles führt darauf zurück, dass unser Forum nach dem Update vom 4. Mai von Google wegen LCP-Verstößen stark bestraft wird.