Was sind eure Gedanken zu diesen Performance-Test-Websites? Ich habe gerade 3 Tests durchgeführt:
GTmetrix, PageSpeed und WebpageTest. Einige Varianten, natürlich, aber auch einige Ähnlichkeiten. Gestern hatte ich bei GTmetrix eine Note C, also ist ein B eine coole Verbesserung – ich bin mir aber nicht sicher, woher das kommt.
Soweit ich das beurteilen kann, scheinen die häufigsten Probleme meiner Website bei diesen 3 Tests die Ladezeiten mit Javascript und CSS zu sein. Liegt das JS überhaupt in meiner Kontrolle? GTmetrix listet die 2 URLs als ungenutztes JS auf, aber das sind doch Dinge, die in Discourse eingebaut sind?
PageSpeed listete irgendwie dasselbe mit dem Problem der render-blockierenden Ressourcen von JS/CSS auf. Die größten JS-Dateien, die die Website verlangsamen, sind:
So lala. Die ganze Sache hat mich zum Nachdenken gebracht, haha.
Das war auch mein Hauptgedanke, aber ich mag auch einige der Ergebnisse auf diesen Performance-Seiten nicht (was, ja, ich schätze, Host-Probleme sein könnten?).
Hmmm … das ist viel zusätzliche Komplexität für nicht viel.\n\nIch habe mehrere Jahre lang eine erfolgreiche Community betrieben, ohne ein CDN nutzen zu müssen.
Sollte kein hoher Traffic sein. Nur ein paar registrierte Benutzer. Habe die Seite erst vor etwa 12 Tagen erstellt. Scheint für einige zu Spitzenzeiten, in denen der Server gehostet wird, langsam zu sein, für andere aber in Ordnung. Die Server-/VPS-Spezifikationen sind:
CDN hilft ein wenig, wenn es ein großes globales Publikum gibt und/oder der VPS hinter einem Low-End-Server steckt. Und PHP-basierte Websites können eine etwas bessere Verbesserung erzielen, aber eine gute Caching-Richtlinie hilft mehr.
Die Natur von Discourse hat die Tendenz, solche Verbesserungen zunichte zu machen, oder, wenn man es so sagen möchte: Sie braucht solche Hilfen nicht.
Diese Metrikdienste haben viele Probleme und selten können diese „einfach so“ gelesen werden.
Ja, darüber bin ich ein wenig verwirrt. Im Grunde scheinen all die Punkte, die mir angerechnet werden, in Discourse eingebaut zu sein (lange JS-Ladezeiten/Blockierungen usw.) + vielleicht eine Kombination aus meinem Theme. Bedeutet das, dass eine Discourse-Website niemals eine gute Bewertung dafür erzielen wird, lol? Ich bezweifle das aber irgendwie. Insbesondere Foren.
Das bedeutet es. Man kann wenig helfen, indem man einige (unnötige) Funktionalitäten wegnimmt, hauptsächlich durch Plugins, aber… es gibt keine wirklichen Vorteile.
Die gute Nachricht ist, dass es überhaupt keine Rolle spielt. Und die Internetdienste und Geräte Ihrer Benutzer sind ein größeres Nadelöhr.
Wenn Sie zu viel Freizeit haben, können Sie dies und das und etwas anderes entwickeln, und alles, was Sie bekommen, ist vielleicht eine Sekunde hier und eine weitere von dort – und diese Ersparnisse sind nur durch Labortests messbar.
Lassen Sie das Team und die Plugin-/Theme-Entwickler ihre Arbeit machen. Das reicht.
Wenn Sie eine WordPress-, Drupal- usw. „echte“ Webplattform hätten, gäbe es eine Tonne anderer Tricks zu tun. Jetzt ist die Lösung grundlegend anders.
Und sicher – ich bin nur ein weiterer selbstgemachter Admin/Webmaster und werde korrigiert, wenn ich falsch liege. Aber das bin ich nicht
Es scheint, dass die Blockierungszeit immer das Hauptproblem ist (zumindest für mich, wenn ich diese ausführe). Müssen die Discourse-Entwickler es also besser optimieren oder? Ich frage wirklich, ich versuche nicht, etwas schlechtzumachen.
Das ist nicht das, was ein Mensch sieht. Noch einmal: Discourse ist eine Web-App, die zuerst notwendige Dateien verschiebt und danach ist alles (fast) nur JSON-Text. Dieser Test funktioniert irgendwie, wenn eine Website Seiten auf Serverebene generiert und lesbares HTML an den Client sendet. So wie es WordPress tut.
Und diese Zeit ist gar nicht schlecht.
Was Sie jetzt vorschlagen, ist, dass Discourse eine vollständige App sein sollte und nicht über Browser nutzbar ist, zum Beispiel.
