Lesetipp - Erfolgreiche Websites sind schnelle Websites

[Matthias Apsel]

Hallo alle,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Bis demnächst
Matthias

[pl]

Hallo alle,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Was heißt denn 'erfolgreich'? Außer daß dieser Begriff einmalig in der Überschrift verwendet wurde, wird der nirgendwo erklärt. MfG

[pl]

Hallo alle,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Was heißt denn 'erfolgreich'? Außer daß dieser Begriff einmalig in der Überschrift verwendet wurde, wird der nirgendwo erklärt. MfG

PS: Nun gut, die Zahl der Seitenbesuche hängt unmittelbar mit den Ladezeiten zusammen. Das ist eine Erfahrung die ich gemacht habe, geb ich gerne weiter 😉

[marctrix]

Hej Matthias,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Danke für den Hinweis. Der Titel ist aber definitiv nicht richtig. Jedenfalls wäre demnach die zwei Dutzend Megabyte schwere Apple-Seite nicht erfolgreich.

Angesichsts der ständig wachsenden durchschnittlichen Seitengrößen klingt mir das eher nach einem (sehr sympathischen!) Kampf gegen Windmühlen…

Marc

[1unitedpower]

Hej Matthias,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Danke für den Hinweis. Der Titel ist aber definitiv nicht richtig. Jedenfalls wäre demnach die zwei Dutzend Megabyte schwere Apple-Seite nicht erfolgreich.

Dieser Umkehrschluss steckt doch gar nicht im Titel und kann auch nicht daraus gefolgert werden.

Angesichsts der ständig wachsenden durchschnittlichen Seitengrößen klingt mir das eher nach einem (sehr sympathischen!) Kampf gegen Windmühlen…

Datenvolumen und Performance sind zwei unterschiedliche paar Schuhe. Für die Performance ist es wichtig, dass die relevanten Daten für den ersten "meaningful Paint" möglichst früh übertragen werden - der sogenannte kritische Pfad. D.h. aber nicht, dass das Übertragungsvolumen insgesamt gering sein muss. Es macht u.U. sogar Sinn Ressourcen vorzuladen, die später wahrscheinlich gebraucht werden. Dadurch erhöht sich das Datenvolumen aber eben auch die wahrgenommene Performance der Seite und sogar die Robustheit gegenüber instabilen Internetverbindungen. Als Nachteil fallen beim Endnutzer dafür ggf. Kosten an, wenn dieser einen Volumentarif hat. Es gibt leider keinen idealen Mix aus Performance, Robustheit und Kosten - es ist eine Abwägungssache.

[marctrix]

Hej 1unitedpower,

molily startet mit diesem Artikel eine kleine Artikelreihe bei den webkrauts http://webkrauts.de/artikel/2018/erfolgreiche-websites-sind-schnelle-websites

Danke für den Hinweis. Der Titel ist aber definitiv nicht richtig. Jedenfalls wäre demnach die zwei Dutzend Megabyte schwere Apple-Seite nicht erfolgreich.

Dieser Umkehrschluss steckt doch gar nicht im Titel und kann auch nicht daraus gefolgert werden.

Wo siehst du da eine Umkehrung?

Erfolgreiche Webseiten sind schnelle Webseiten.

Das stimmt so nicht. Erfolgreiche Webseiten sind nicht immer schnelle Webseiten. Der Erfolg einer Webseite hängt von mehreren Faktoren ab. Ein kritischer Faktor ist der Inhalt. Bin ich bereit zu warten? Manchmal ja, manchmal nein.

Heute war ich auf einer Webseite, die ewig die Meldung gezeigt hat, ich müsse dreißig Sekunden warten und wenn sich bis dahin nichts getan hat, muss ich die Seite neu laden. Habe ich das getan? Ja, weil die Webseite einen Service angeboten hat, den ich nur da bekommen konnte. Hat mir das gefallen? Überhaupt nicht. Habe ich trotzdem gemacht, wofür ich gekommen bin? Ja. Also hat die Webseite ihren Zweck erfüllt und ist erfolgreich. In dem Fall hat sie einen neuen Kunden mit dem Anbieter der Seite zusammen gebracht. Weil andere Faktoren als Geschwindigkeit ausschlaggebend waren.

Angesichsts der ständig wachsenden durchschnittlichen Seitengrößen klingt mir das eher nach einem (sehr sympathischen!) Kampf gegen Windmühlen…

Datenvolumen und Performance sind zwei unterschiedliche paar Schuhe. Für die Performance ist es wichtig, dass die relevanten Daten für den ersten "meaningful Paint" möglichst früh übertragen werden - der sogenannte kritische Pfad.

Schon klar, das erklärt molily ja auch sehr schön — ist aber Common Sense leider, denn

D.h. aber nicht, dass das Übertragungsvolumen insgesamt gering sein muss. Es macht u.U. sogar Sinn Ressourcen vorzuladen, die später wahrscheinlich gebraucht werden.

Für den Anbieter einer Website, vielleicht auch noch für den Besucher, der gerade einen schnellen Anschluss ohne Volumenbegrenzung nutzt.

Aber oft ist es eine Verschwendung von Energie und bürdet dem Besucher, Netzbetreibern und unbeteiligten Lasten und Kosten auf in Form von vermeidbarer Umweltverschmutzung, Energiverschwendung, langsameren Netzen (selbst für die, die auf anderen Seiten unterwegs sind) — nur dem Seitenbetreiber selber kostet das oft nichts. Eine absolut widerliche Rücksichtslosigkeit!

Dadurch erhöht sich das Datenvolumen aber eben auch die wahrgenommene Performance der Seite und sogar die Robustheit gegenüber instabilen Internetverbindungen.

Man kann auch wenige Daten vorladen. Lazy Load setzt doch keine Mindestmengen voraus.

Als Nachteil fallen beim Endnutzer dafür ggf. Kosten an, wenn dieser einen Volumentarif hat. Es gibt leider keinen idealen Mix aus Performance, Robustheit und Kosten - es ist eine Abwägungssache.

Hmm - das verstehe ich nicht. Wenig Daten, die nicht wehtun vorgeladen zu werden (möglichst nur Texte) scheinen mir robuster und performanter zu übertragen, als große Mengen, die schon auf den Verdacht hin übertragen werden, dass sie zum großen Teil nötig werden könnten.

Mir ist schon klar, man kann da an vielen Schrauben drehen und Nutzer mit z.B. langsamen Verbindungen schonen, vielleicht in der Annahme, diese sind mit einem teuren Volumentarif unterwegs. Aber ich bin kein Freund von Annahmen. Vielleicht lebt jemand auf dem Land und geht zur Hauptzeit wie all seine Nachbarn ins Netz. Dass die Daten nur tröpfeln, weiß er und hat dafür womöglich eine Strategie entwickelt. Was er vielleicht nicht möchte ist, ungefragt schlechtere Bilder als vorher im Büro in der Stadt angezeigt zu bekommen. Hier sollte man dem Nutzer mehr Mitsprache erlauben.

Auf jeder popeligen Hausfrauen-Seite werde ich mit Cookie-Hinweisen genervt. Aber ob ich 10 MByte Daten runterladen will, während ich die Öffnungszeiten eines Ladens in Erfahrung bringen will, fragt mich niemand.

Ich glaube nutzerbedürfnisse zu berücksichtigen kann ein Erfolgsfaktor sein. Unter anderem spielt Performance dann eine viel geringere Rolle. Wer sich bewusst für hochauflösende Bilder entscheidet, weiß auch, dass er ggfs. länger warten muss und wofür. Was nicht bedeutet, dass der Seitenbetreiber nicht trotzdem für ein gefühlt flottes Nutzererlebnis sorgen sollte.

Nutzerzentriertes Design eben.

Marc

[1unitedpower]

Wo siehst du da eine Umkehrung?

Da hab ich Blödsinn erzählt das fällt mir jetzt auch auf - mein Gehirn hat die Implikation im Titel verdreht.

D.h. aber nicht, dass das Übertragungsvolumen insgesamt gering sein muss. Es macht u.U. sogar Sinn Ressourcen vorzuladen, die später wahrscheinlich gebraucht werden.

Für den Anbieter einer Website, vielleicht auch noch für den Besucher, der gerade einen schnellen Anschluss ohne Volumenbegrenzung nutzt.

Aber oft ist es eine Verschwendung von Energie und bürdet dem Besucher, Netzbetreibern und unbeteiligten Lasten und Kosten auf in Form von vermeidbarer Umweltverschmutzung, Energiverschwendung, langsameren Netzen (selbst für die, die auf anderen Seiten unterwegs sind) — nur dem Seitenbetreiber selber kostet das oft nichts. Eine absolut widerliche Rücksichtslosigkeit!

Dem Gesagten möchte ich gar nicht widersprichen. Energieeffizienz, Umweltschonung und geringe Übertragungsvolumen sind genauso gute Optimierungsziele wie Performance und Robustheit, allerdings stehen sie auch oft in Konflikt zueinander. Lazy-Loading zum Beispiel verringert das Datenvolumen und schont die Batterie, aber dadurch treffen Ressourcen eben auch prinzipbedingt später beim Nutzer ein als vorgelande Ressourcen - jenachdem um was sich dabei handelt, hat das einen Einfluss auf die wahrgenommene Performance. Optimistisches Prefetching ist da robuster und performanter, aber eben auch kostspieliger in punkto Batterielaufzeit und Datenvolumen. Die Vorteile von Lazy-Loading sind die Nachteile von Prefetching und umgekehrt.

Dadurch erhöht sich das Datenvolumen aber eben auch die wahrgenommene Performance der Seite und sogar die Robustheit gegenüber instabilen Internetverbindungen.

Man kann auch wenige Daten vorladen. Lazy Load setzt doch keine Mindestmengen voraus.

Als Nachteil fallen beim Endnutzer dafür ggf. Kosten an, wenn dieser einen Volumentarif hat. Es gibt leider keinen idealen Mix aus Performance, Robustheit und Kosten - es ist eine Abwägungssache.

Hmm - das verstehe ich nicht. Wenig Daten, die nicht wehtun vorgeladen zu werden (möglichst nur Texte) scheinen mir robuster und performanter zu übertragen, als große Mengen, die schon auf den Verdacht hin übertragen werden, dass sie zum großen Teil nötig werden könnten.

Denk an das klassische Zug-Beispiel: Nutzer fährt mit dem RE von Aachen nach Essen, sozusagen eine Pilgerfahrt, die einmal an jedem Funkloch in NRW Halt macht. In einer Minute hat der Nutzer noch 3G, in der nächsten hat er gar keinen Empfang mehr, dann für 10 Sekunden Edge bevor der Emfpang abermals verschwindet. Eine robuste Strategie versucht in den Zeitfenstern, in denen Emfpang besteht, möglichst viele relevante Daten zu laden. Das heißt natürlich zuerst die unmittelbar gebrauchten Daten und im Anschluss die mittelbar gebrauchten Daten. Es geht nicht darum dem Nutzer den gesamten peripheren Inhalt der Seite unterzuschieben, sondern gezielt seine nächsten Interaktionen vorauszudenken und zu ermöglichen. Prognosen sind natürlich grundsätzlich problematisch, besonders wenn sie die Zukunft betreffen.

Mir ist schon klar, man kann da an vielen Schrauben drehen und Nutzer mit z.B. langsamen Verbindungen schonen, vielleicht in der Annahme, diese sind mit einem teuren Volumentarif unterwegs. Aber ich bin kein Freund von Annahmen. Vielleicht lebt jemand auf dem Land und geht zur Hauptzeit wie all seine Nachbarn ins Netz. Dass die Daten nur tröpfeln, weiß er und hat dafür womöglich eine Strategie entwickelt. Was er vielleicht nicht möchte ist, ungefragt schlechtere Bilder als vorher im Büro in der Stadt angezeigt zu bekommen. Hier sollte man dem Nutzer mehr Mitsprache erlauben.

Auf jeder popeligen Hausfrauen-Seite werde ich mit Cookie-Hinweisen genervt. Aber ob ich 10 MByte Daten runterladen will, während ich die Öffnungszeiten eines Ladens in Erfahrung bringen will, fragt mich niemand.

Ich glaube nutzerbedürfnisse zu berücksichtigen kann ein Erfolgsfaktor sein. Unter anderem spielt Performance dann eine viel geringere Rolle. Wer sich bewusst für hochauflösende Bilder entscheidet, weiß auch, dass er ggfs. länger warten muss und wofür. Was nicht bedeutet, dass der Seitenbetreiber nicht trotzdem für ein gefühlt flottes Nutzererlebnis sorgen sollte.

Nutzerzentriertes Design eben.

Full ACK. Auch deshalb halte ich es für nötig die Tradeoffs bei der Optimierung verschiedener Nutzerbedürfnisse ins Bewusstsein der Entwickler zu rufen.

[marctrix]

Hej 1unitedpower,

Wo siehst du da eine Umkehrung?

Da hab ich Blödsinn erzählt das fällt mir jetzt auch auf - mein Gehirn hat die Implikation im Titel verdreht.

Ich habe aber auch dreimal hin und her „gerechnet“, ob man den Titel nicht auch anders verstehen könnte. Noch ein Grund, warum der problematisch ist.

Aber das schmälert ja den Artikel selber gar nicht und vielleicht bringt er auch mehr Leute dazu, den Artikel zu lesen. Dennoch mag ich so etwas nicht.

Gleichwohl ist mir bewusst, dass so etwas (Spiegel, Focus, Huff und wie sie alle heißen machen das auch) offenbar nötig ist, um die Aufmerksamkeit der Besucher zu erlangen.

Aber als jemand, der Sprache mag, bin davon so dermaßen genervt, dass ich es manchmal sogar ausspreche. 😉

Unter Umständen stammt der Titel nicht einmal von Matthias (der wievielte eigentlich hier im Self-Raum?). So was bekommt man ja manchmal vorgegeben.

Eine absolut widerliche Rücksichtslosigkeit!

Um das noch mal klar zu sagen: das empfinde ich so. Andere mögen damit einverstanden sein. Aber mich stört es gewaltig, wenn man mir ungefragt mein Datenvolumen klaut. Dabei geht es mir gar nciht einmal immer so ums Geld. Wenn der Inhalt der Seite stimmt, bin ich auch bereit, dafür einen Obulus zu entrichten (wobei der ja nciht einmal beim Betreiber der Seite ankommt). Es geht mir eher darum, dass es total nervt ohne Datenvolumen da zu stehen, obwohl man weder Filme geschaut, noch ständig IP-Radio gehört hat. Es ist schon echt verwunderlich, welche Datenmassen inzwischen so durch die Leitung gehen.

Habe schon 6 GByte im Monat und muss trotzdem noch drauf achten, obwohl ich mobil nicht viel mehr mache als surfen und mailen.

Dem Gesagten möchte ich gar nicht widersprichen. Energieeffizienz, Umweltschonung und geringe Übertragungsvolumen sind genauso gute Optimierungsziele wie Performance und Robustheit, allerdings stehen sie auch oft in Konflikt zueinander.

Nicht in jedem Fall, wie gesagt kann man gerne Texte vorladen. Angesichts dessen, was Webseiten heute so im Schnitt verballern (2,5 MByte ist die letzte Zahl, die ich im Kopf habe), kommt es (mir) auf ein halbes oder auch zwei Kilobyte Text nicht an.

Optimistisches Prefetching ist da robuster und performanter, aber eben auch kostspieliger in punkto Batterielaufzeit und Datenvolumen.

Die Vorteile von Lazy-Loading sind die Nachteile von Prefetching und umgekehrt.

Schön auf den Punkt gebracht. Es hängt auch von der Webseite ab. Bei einer Bildergalerie macht es wenig Sinn, die vorhandenen Texte vorzuladen. Wegen denen kommt ja niemand auf die Seite.

Aber wie gesagt, ich fände es gut, wenn man als Nutzer eine Möglichkeit hätte, vielleicht durch eine Browser-Einstellung, die vom Seitenbetreiber ausgelesen und respektiert werden sollte, selber zu entscheiden, ob man die bestmögliche Qualität oder eine superschnelle Seite haben möchte. Derzeit habe ich nur die Möglichkeit zwischen Vollversion und einer Version ganbz ohne Bilder, die leider oft unverständlich ist, weil alt-Texte fehlen oder nur für Suchmaschinen optimiert sind.

Womit wir wieder beim Thema Rücksichtslosigkeit sind. Die meisten Seitenbetreiber denken zuallererst leider an sich. Nicht: wie mache ich meine Besucher glücklich? sondern: wie bekomme ich möglichst viele davon auf meine Seite und halte ich diese möglichst lange.

Dabei geht es auch ohne. W3Schools kann man sicher als erfolgreiche Seite nennen.

Mal abgesehen davon, wie man die Qualität der Inhalt bewertet: die Darstellung ist eher nüchtern. Aber man kommt an benötigte Infos schnell ran und wenn erst mal die dicken Brocken im Cache sind (JS und CSS, insgesamt knapp ein MByte — was sicher so auch nicht sein muss), sind die zu übertragenden Datenmengen im Bereich von 70 bis 120 KByte.

Die gerne auch vorladen! Aber nicht MByte-schwere Schmuck-Grafiken.

Dadurch erhöht sich das Datenvolumen aber eben auch die wahrgenommene Performance der Seite und sogar die Robustheit gegenüber instabilen Internetverbindungen.

Man kann auch wenige Daten vorladen. Lazy Load setzt doch keine Mindestmengen voraus.

Als Nachteil fallen beim Endnutzer dafür ggf. Kosten an, wenn dieser einen Volumentarif hat. Es gibt leider keinen idealen Mix aus Performance, Robustheit und Kosten - es ist eine Abwägungssache.

Hmm - das verstehe ich nicht. Wenig Daten, die nicht wehtun vorgeladen zu werden (möglichst nur Texte) scheinen mir robuster und performanter zu übertragen, als große Mengen, die schon auf den Verdacht hin übertragen werden, dass sie zum großen Teil nötig werden könnten.

Denk an das klassische Zug-Beispiel:

Schon klar. Aber das geht doch auch mit Seiten, die von Anfang an schlank sind!

Und wenn jemand riesige Schmuckgrafiken vorladen lässt, damit die robust vorgehalöten werden: Ausbaden müssen das auch alle, die keinen Zug fahren!

Wer Zug fährt hat seinserseits dank wget, httrack oder ähnlichem (Video, Hörbuch, eBook vor der Abfahrt runterladen) auch Möglichkeiten vorzubeugen.

Wieso den Nutzern und Betreibern und Nutzernvon oft (auch deswegen) lahmen öffentlichen WLAN-Angeboten unnötig Daten aufhalsen?

Klar, WLANs werden immer mehr und imme schneller, die mobilen Netze auch und die Kosten sinken langfristig. Aber ich mag einfach die Einstellung dahinter nicht.

Ist vielleicht auch eine sehr subjektive Sicht. Andere mögen damit weniger Probleme haben.

Marc

[Matthias Apsel]

Hallo marctrix,

Unter Umständen stammt der Titel nicht einmal von Matthias (der wievielte eigentlich hier im Self-Raum?).

Mathias. Der erste. Und leider nicht mehr aktiv.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Unter Umständen stammt der Titel nicht einmal von Matthias (der wievielte eigentlich hier im Self-Raum?).

Mathias. Der erste.

Nene. Da gabs noch Mathiase vor ihm 😀

Und leider nicht mehr aktiv.

Ja, leider.

LG,
CK

[marctrix]

Hej Matthias,

Unter Umständen stammt der Titel nicht einmal von Matthias (der wievielte eigentlich hier im Self-Raum?).

Mathias. Der erste. Und leider nicht mehr aktiv.

Ja, vermisse ihn auch. Mit einem „t“ also — ein feiner aber entscheidender Unterschied!

Marc

[Julius]

Hallo Marc,

Aber wie gesagt, ich fände es gut, wenn man als Nutzer eine Möglichkeit hätte, vielleicht durch eine Browser-Einstellung, die vom Seitenbetreiber ausgelesen und respektiert werden sollte, selber zu entscheiden, ob man die bestmögliche Qualität oder eine superschnelle Seite haben möchte.

Nette Idee, aber ich glaube, dass das letztlich wieder nur zum Tracken benutzt wird. Siehe Battery-API.

Wer Zug fährt hat seinserseits dank wget, httrack oder ähnlichem (Video, Hörbuch, eBook vor der Abfahrt runterladen) auch Möglichkeiten vorzubeugen.

Ich arbeite bei Zugfahrten gerne meine noch zu lesenden Seiten ab. Alles vorher über das heimische WLAN geladen und den Browser dann offen gelassen. Dummerweise macht einem das Lazyloading dann auf einigen Seiten schnell einen Strich durch die Rechnung (Zeit.de und die „mobil-Version“ von Wikipedia fallen mir spontan ein).

Gruß
Julius

[marctrix]

Hej Julius,

Ich arbeite bei Zugfahrten gerne meine noch zu lesenden Seiten ab. Alles vorher über das heimische WLAN geladen und den Browser dann offen gelassen. Dummerweise macht einem das Lazyloading dann auf einigen Seiten schnell einen Strich durch die Rechnung (Zeit.de und die „mobil-Version“ von Wikipedia fallen mir spontan ein).

Für iOS und macOS gibt es im Browser eine Leseliste, da kann man Seiten abspeichern, so dass man die jederzeit, auch ohne Netz lesennknn- vermutlich gibt es für andere Browser Plugins mit derselben Funktionalität?

Marc

[Rolf B]

Hallo Matthias,

Der beste Code kann trotzdem nicht erfolgreich sein…

http://www.commitstrip.com/en/2018/01/05/theres-a-problem-with-the-code/

Rolf

[Klawischnigg]

Hi there,

guter Artikel!

Aber das eigentliche Problem wird leider nicht einmal am Rande gestreift - die Verlängerung von Ladezeiten und -mengen durch die exzessive Verwendungung von überfrachteten CM-Systemen wie der WordPress-Pest und von unnötigen Javascript-Libraries. Das führt meist zu Content: 1-2%, Overhead 98-99%. Wenn man da ansetzen könnte, dann wäre der Artikel von Matthias wahrscheinlich gar nicht nötig...😉

[marctrix]

Hej Klawischnigg,

guter Artikel!

Aber das eigentliche Problem wird leider nicht einmal am Rande gestreift - die Verlängerung von Ladezeiten und -mengen durch die exzessive Verwendungung von überfrachteten CM-Systemen wie der WordPress-Pest und von unnötigen Javascript-Libraries. Das führt meist zu Content: 1-2%, Overhead 98-99%. Wenn man da ansetzen könnte, dann wäre der Artikel von Matthias wahrscheinlich gar nicht nötig...😉

Zwei Dinge:

1.) JavaScript und dessen falscher und übermäßiger Gebrauch wird durchaus angesprochen. Da bist du aufgefallen als Nichtleser 😉

2.) WP ist keine Pest, sondern ein Werkzeug. Genau wie react, jquery, etc. pp. Hier wie da gibt es denselben Grund für die unnötige datenschwemme: man kann sich beliebig viel Müll mit minimalem Aufwand dazuinstallieren.

Ich nutze selber wp und habe einige Sites gebaut, die mit weniger als 1 MByte auskommen. Wobei die meist inhaltlich relevanten großen headergrafiken davon mitunter die Hälfte ausmachen. Die kann ich nicht jedem Kunden ausreden. Will ich auch gar nicht.

Aber:

Was man mit seinem Werkzeug anfängt, liegt immer am Anwender. Mit einem Hammer kann man sowohl Sachen bauen, als auch kaputt machen.

Marc

[Klawischnigg]

Hi there,

Zwei Dinge:

1.) JavaScript und dessen falscher und übermäßiger Gebrauch wird durchaus angesprochen. Da bist du aufgefallen als Nichtleser 😉

Zugegeben. Ich hab diesen Part nur überflogen. Mir ist nur aufgefallen, daß er JQuery definitiv nicht erwähnt. Dabei dürfte das die meisteverwendete überflüssige Library überhaupt sein.

2.) WP ist keine Pest, sondern ein Werkzeug.

Na gut, dann halt ein Pest-Werkzeug.

Ich nutze selber wp und habe einige Sites gebaut, die mit weniger als 1 MByte auskommen.

Darauf kommt's ja nicht an sondern auf das Verhältnis von Inhalt zu Seitenbeschreibung. Und das ist vor allem bei kleinen Seiten so schlecht, daß man sich die Verwendung wirklich gut überlegen sollte. (Was keiner tut - erstens ist das den meisten wurscht, zweitens könnten viele, die WP verwenden, ohne WP überhaupt nichts zustandebringen (was ich Dir mitnichten unterstelle) und drittens haben viele Webworker Kunden, die zu blöd wären, mit einem anderen CMS ihre Inhalte zu pflegen)

Ich hab zu Testzwecken einmal eine relativ umfangreiche Seite mit Drupal7 und einmal "de lege artis" from the scratch gebaut - was soll ich sagen - der Unterschied im Umfang der zu übermittelnden Bytes war beinahe 10:1 bei identem Inhalt. (Vom Platzbedarf am Server einmal ganz zu schweigen, aber das ist ja heutzutage zum Glück eher kein Thema mehr - eher schon die Abhängigkeit von der Verwendung der verschiedenen PHP- und Datenbank-Versionen)

Was man mit seinem Werkzeug anfängt, liegt immer am Anwender. Mit einem Hammer kann man sowohl Sachen bauen, als auch kaputt machen.

Ja eh. Ich bin aber trotzdem der Meinung, "schlanke" Seiten für mobiles Design auf der einen und gängiges CMS wie Drupal, WP, typo3 etc. auf der anderen Seite schliessen sich definitiv gegenseitig aus, und daß das in dem Artikel von Molily nicht erwähnt wurde habe ich mir erlaubt zu monieren…

[Gunnar Bittersmann]

@@Klawischnigg

Na gut, dann halt ein Pest-Werkzeug.

😂

Ich bin aber schon der Meinung, dass es gut ist, dass jeder seine Inhalte ins Web bringen kann, ohne dafür HTML, CSS etc. lernen zu müssen. Das war ja schon der Grundgedanke von Tim Berners-Lee.

„Ich beabsichtigte niemals, daß der HTML-Quellcode (der Text mit den spitzen Klammern) für Benutzer sichtbar sein sollte. Ein Browser/Editor würde einem Benutzer einfach die Möglichkeit bieten, die Sprache einer Hypertextseite so zu betrachten oder zu bearbeiten wie bei einer Textverarbeitung.“
—Tim Berners-Lee in „Der Web-Report – Der Schöpfer des World Wide Webs über das grenzenlose Potential des Internets“, Econ, München, 1999, S. 72. Originaltitel: “Weaving the Web”

Ich hab zu Testzwecken einmal eine relativ umfangreiche Seite mit Drupal7 und einmal "de lege artis" from the scratch gebaut - was soll ich sagen - der Unterschied im Umfang der zu übermittelnden Bytes war beinahe 10:1 bei identem Inhalt.

Ist das nicht eher ein Problem der Templates als ein Problem des CMS als solches?

Ja eh. Ich bin aber trotzdem der Meinung, "schlanke" Seiten für mobiles Design auf der einen und gängiges CMS wie Drupal, WP, typo3 etc. auf der anderen Seite schliessen sich definitiv gegenseitig aus

Wenn man die Templates vernünftig™ baut, würde ich das verneinen.

LLAP 🖖

[marctrix]

Hej Gunnar,

Ich hab zu Testzwecken einmal eine relativ umfangreiche Seite mit Drupal7 und einmal "de lege artis" from the scratch gebaut - was soll ich sagen - der Unterschied im Umfang der zu übermittelnden Bytes war beinahe 10:1 bei identem Inhalt.

Ist das nicht eher ein Problem der Templates als ein Problem des CMS als solches?

Ja eh. Ich bin aber trotzdem der Meinung, "schlanke" Seiten für mobiles Design auf der einen und gängiges CMS wie Drupal, WP, typo3 etc. auf der anderen Seite schliessen sich definitiv gegenseitig aus

Wenn man die Templates vernünftig™ baut, würde ich das verneinen.

Ein bisschen von beidem. Natürlich bringt beispielsweise jedes CMS-Template Klassen mit, von denen man viele ausDesigngründen gar nicht benötigt. Aber so kann halt nicht nur der Klicker zu akzeptablen Ergebnissen gelangen, sondern für den, der was damit anzufangen weiß, sind die Klassen die man braucht, meistens dabei. Auch die, die man nicht slebst benötigt, aber jemand anderes für ein anderes Layout. Oft sind die auch noch gut benannt, also logische Bezeichnungen an Stelle von presentational markup.

Das Mitliefern von Dingen, die nicht jeder benötigt, gilt auch für diverse andere Ressourcen. Sonst wäre die zielgruppe womöglich nur ein Anwender. 😉 Dennoch gibt es um Sparsamkeit bemühte Themes, die vielleicht auch noch auf Zugänglichkeit wert legen und deren Entwickler mindestens redlich engagiert waren - und solche in denen es nur darum geht mit möglichst vielen Effekte Prahlen zu können und das mit möglichst geringem Aufwand: also alles reinhauen, was Rang und Namen hat, jemand könnte es ja gebrauchen…

Das Theme Avada bringt von Haus gleich mal drei oder vier Slider mit (ind ie man Texte, Bilder und Filme(!) reiklicken kann), einen Pagebuilder, mehrere Social-Media-Lösungen, jquery, Bootstrap und, und, und usw.

Bestens geeignet also für jedes Urlaubsblog und sicher daher das meistverkaufte Theme…

Die Welt ist schlecht! 😉

Marc

[Julius]

Hallo Gunnar,

Ich hab zu Testzwecken einmal eine relativ umfangreiche Seite mit Drupal7 und einmal "de lege artis" from the scratch gebaut - was soll ich sagen - der Unterschied im Umfang der zu übermittelnden Bytes war beinahe 10:1 bei identem Inhalt.

Ist das nicht eher ein Problem der Templates als ein Problem des CMS als solches?

WordPress scheint mir von der Ideologie her eher aufs Oberflächliche ausgelegt zu sein als auf einfache, umfangreiche Konfigurierbarkeit (einfache Bedienbarkeit und Konfigurierbarkeit müssen sich nicht ausschließen) und Schlankheit. Ganz nach dem Motto „Eins von den drölfzig Caching-Plugins wird’s schon richten!“. Mir ist auch noch kein simples Theme untergekommen, dass sich aufs Wesentliche beschränkt und vom Code her nicht allzu kompliziert aufgebaut ist.

Trifft zwar nicht direkt die Performance, ist aber typisch für WordPress:
WordPress beispielsweise inkludiert selber von sich aus ein Script von einer Drittdomain (s.w.org), um in alten Browser Emojis anzeigen zu können. Nicht, dass ich die Funktionalität nicht grundsätzlich sinnvoll finden würde, ich möchte aber kontrollieren können, ob meine Seite Ressourcen Dritter einbinden soll. Als Sahnehäubchen wäre diese Funktion auch abschaltbar (da gäbe es auch noch einige andere, aber dafür muss man jeweils Plugins installieren). Dafür könnte man problemlos ein extra Menü „Erweiterte Konfiguration“ einführen und dort auch (externe) Webfonts deaktivieren (sauber entwickelte Themes sollten Fallbacks im Font-Stack haben).

Bei DokuWiki ist das in den Einstellungen möglich:

Gruß
Julius

[marctrix]

Hej Klawischnigg,

Zwei Dinge:

1.) JavaScript und dessen falscher und übermäßiger Gebrauch wird durchaus angesprochen. Da bist du aufgefallen als Nichtleser 😉

Zugegeben. Ich hab diesen Part nur überflogen. Mir ist nur aufgefallen, daß er JQuery definitiv nicht erwähnt. Dabei dürfte das die meisteverwendete überflüssige Library überhaupt sein.

Ist die wirklich nicht drin? Einige werden namentlich genannt, andere nicht. Ist aber wurscht. Es ändert nichts dran, dass du prinzipiell natürlich recht hast!

Ich nutze selber wp und habe einige Sites gebaut, die mit weniger als 1 MByte auskommen.

Darauf kommt's ja nicht an sondern auf das Verhältnis von Inhalt zu Seitenbeschreibung.

Da hast du recht. Das Problem sind die Kosten für eine Individual-Entwicklung einerseits, der Pflegeaufwand andererseits. Was ich wirklich schade finde ist, dass schätzungsweise 80% meiner WP-Kunden so selten und wenig Inhalte ändern, dass Sie auf Dauer mit einer statischen Seite besser dran gewesen wären. Aber wenn ich am Anfang berate und die Vor- und Nachteile beider Konzepte erwähne (SEO, Performanz, Sicherheit, Wartungskosten - alles Punkte für statische Seiten) reduziert sich am Ende doch alles auf die Frage, welche 1. (!) Rechnung niedriger ist.

Und das ist vor allem bei kleinen Seiten so schlecht, daß man sich die Verwendung wirklich gut überlegen sollte.

Bei großen Seiten wäre das Verhäktnis nur dann besser, wenn sich Besucher tatsächlich mehr Seiten anschauen. Sonst ist es sogar noch schlechter, weil Styles und Sprites und was weiß ich geladen werden, die auf der oder den besuchten Seiten keine Verwendung finden…

Je "größer" eine Site, desto mehr unterschiedliche Seitentypen im der Regel.

Ich hab zu Testzwecken einmal eine relativ umfangreiche Seite mit Drupal7 und einmal "de lege artis" from the scratch gebaut - was soll ich sagen - der Unterschied im Umfang der zu übermittelnden Bytes war beinahe 10:1 bei identem Inhalt. (Vom Platzbedarf am Server einmal ganz zu schweigen, aber das ist ja heutzutage zum Glück eher kein Thema mehr - eher schon die Abhängigkeit von der Verwendung der verschiedenen PHP- und Datenbank-Versionen)

Ich hätte den UNterschied tatsächlich auf 1:25 geschätzt - kommt sicher auf das Angebot an. Wobei du hast ja eine Anwendung entwickelt. Sind statische HTML-Dokumente möglich und sinnvoll, ist man vermutlich bei 1:25 * pi / Daumen 😉

Was man mit seinem Werkzeug anfängt, liegt immer am Anwender. Mit einem Hammer kann man sowohl Sachen bauen, als auch kaputt machen.

Ja eh. Ich bin aber trotzdem der Meinung, "schlanke" Seiten für mobiles Design auf der einen und gängiges CMS wie Drupal, WP, typo3 etc. auf der anderen Seite schliessen sich definitiv gegenseitig aus, und daß das in dem Artikel von Molily nicht erwähnt wurde habe ich mir erlaubt zu monieren…

Ich finde es immer gut, wenn jemand für Effizient wirbt! Das wollte ich keinesfalls kritisieren!

Marc

[Mitler]

[...] wenn ich am Anfang berate und die Vor- und Nachteile beider Konzepte erwähne (SEO, Performanz, Sicherheit, Wartungskosten - alles Punkte für statische Seiten)

Inwiefern siehst Du bzgl. SEO statische Seiten im Vorteil?

[marctrix]

Hej Mitler,

Inwiefern siehst Du bzgl. SEO statische Seiten im Vorteil?

Hauptsächlich Geschwindigkeit.

Man ist aber auch etwas freier jeder Hinsicht und kann leichter Optimierungen für einzelne Seiten vornehmen. Geht in der Regel auch mit Systemen wie WP - dann sind aber wieder Plugins nötig, die das System weiter aufblähen. Man kann noch caches und allen möglichen Aufwand betreiben.

Gerade für Anfänger ist das aber schwierig und wenn man eh jemanden braucht, der die Seite pflegt, stellt sich wieder die Frage, wofür überhaupt ein cms - die meisten Webseiten werden selten geupdatet.

SEO ist insofern nur ein Teil dessen, was meiner Meinung nach statisch gut umsetzbar ist. Ein Puzzlestein von vielen.

Marc