FF-AddOns

Kein Adblockplus? (<- Mein Hauptgrund für den FF)

'Open All in Tabs'

Früher hat Open All In Tabs die bisherigen Tabs zugemacht und dafür die neuen
Tabs aufgemacht. Im Firefox 3 ersetzt er das gerade aktive Tab, hängt die
restlichen an, und läßt die anderen alten Tabs so wie sie gerade sind.

Vielleicht liegt's ja auch an unserem HTML

Speziell beim Forum, Themen ab 1000 Beiträgen werden unlesbar lahm, dabei
scheiterts nur am gigantischen Overhead durch den Quelltext.

Euer Quelltext gehört mit zum Schlimmsten, was man im WWW heutzutage noch finden kann, bei Seiten dieser Größenordnung.

ch will gar nicht wissen, wie viel performanter GH sein könnte, wenn man das Layout gleichbehält, und nur den Quelltext optimiert (sauber neu schreibt), und ernsthaft mit Stylesheets arbeitet

Speziell beim Forum, Themen ab 1000 Beiträgen werden unlesbar lahm, dabei scheiterts nur am gigantischen Overhead durch den Quelltext.

Punkto Javascript hat sich der FF3 extrem verbssert, merkt man auf GH eher nicht. Wobei das als Pluspunkt zu sehen ist.

Grade auf GH würde es sich auch anbieten, das Link Prefetching vom FF zu
nutzen. Ich denke, den ersten Artikel einer Produktsuche könnte man immer
bereits im voraus laden, weil er ziemlich sicher angeklickt wird.

Ansichtssache, er gehört auf jeden Fall zum Kompaktesten und Schnellsten.

Was verstehst du unter "sauber"?

Da irrst du dich gewaltig, gerade die Lösung mit den Vorschaubildern hängt
stark von der JS-Implementierung (DOM-Manipulation) ab.

Ein Forum-Thread mit 1000 Postings ist kaum optimierbar. Zeig mir ein Forum,
das so etwas platzsparender mit Threading, ohne JS-Pflicht darstellt.

Das Feature scheint ziemlich kaputt zu sein... FF wirkt deutlich schneller mit
GH, wenn man es deaktiviert.

Wenn ich mir den Quelltext einiger Seiten durchsehe, sehe ich unzählige redundante Einträge, Byte für Byte wird da verschwendet, und muss bei jedem Request übertragen werden. Es ist nicht mehr zeitgemäß, Einrückungen durch unzählige  s zu erledigen, wenn ein simples CSS Attribut das ganze im Stylesheet regeln kann, welches nicht ständig angefordert werden muss.

Unter "sauber" verstehe ich keine Anbetung der W3 Standards, sondern eine optimale (im Sinne der Ladezeit, Renderzeit) Gestaltung des Quelltextes. Dazu gehört es auf jeden Fall nicht, Tabellen 5x und mehr zu verschachteln, das verursacht nur Traffic und Wartezeit beim Benutzer.

Aber wenn sämtliche Vorschaubilder geladen werden müssen, ist sowieso die Verbindung des Users der Flaschenhals, die paar Millisekunden beim Erzeugen der Bilder machen das Kraut nicht fett.

Kann ich nicht, weil ich keines kenne. Aber auch in dem Fall ist Fakt - der Quelltext ist voll von Zeilen und Spalten, die wiederum gespickt sind mit Class Attributen.

<p class="Posting"><img src="/images/blank.gif" align="left" 
alt="..................." width="290" height="1" vspace="1"/>
<img align="absmiddle" alt="" src="/ng/sibling.gif"/>&nbsp;<a 
href="t47708,235301.html#235301"> Re(19): Zweisprachige Ortstafeln, was 
haltet ihr davon???</a> 	( <a href="/userinfo.jsp?id=101">airboy</a> 
am 21.12.2001 01:53:04 )

Wenn man hier umstellen würde auf eine Kombination aus Tabellen / Layern (für antike Browser wie IE <=6), und den Rest per CSS lösen würde, hat man pro Post ein gewisses Einsparpotential, dass sich bei längeren Threads n-mal wiederholt.

Du scheinst das Feature nicht zu kennen, denn ohne dein zutun tut der FF nämlich genau gar nichts - ohne entsprechende Tags "prefetched" der FF nix, und auch dann gibts gewisse Limits (64KB).

  ist nicht nur eine Einrückung, außerdem hat z.B. die Redaktion keinen
Zugriff auf die Stylesheets.

Viel kompakter geht es nicht, daher benötigen 1000e Postings auch kaum
Ladezeit (~30KB komprimiertes HTML).

Die Bilder werden i.d.R. gecacht, also liegst du falsch.

Da irrst du dich wieder, das Feature bremst den FF gewaltig ein, auch wenn es
von der Seite nicht genutzt wird. Ich habe mich davon überzeugt und es ist
tatsächlich so, die Langsamkeit des FF, die diesen Thread begründete, ist nach
dem Tipp, prefetching abzudrehen, nicht mehr vorhanden. Zumindest auf meinem
(zeitgemäßen) System und beim üblichen Browsen (mit oft 30+ offenen Fenstern).
Das war auch die Ursache für 1-2 Sekunden dauernde Hänger, die ich lange
gesucht habe (konnte mir auch nicht vorstellen, daß dieses Prefetching so mies
implementiert ist)...

Was hat denn der Quelltext mit eurer Redaktion zu tun? Normalerweise sollte es vordefinierte Stile geben und das wars, jemand der sich um die Inhalte kümmer braucht also keinen Zugriff auf Stylesheets. Oder anders rum - wäre ich Redakteur, wären technische Dinge wie der Quelltext das letzte, um das ich mich kümmern will.

Die Hälfte der Attribute und Klassen könnte man durch geschickte CSS Selektoren einsparen , und eine blank-Grafik bedarf keines weiteren Kommentars.

Tabellen sind da, um tabellarische Inhalte darzustellen. Für Produktauflistungen geschaffen, für Forenpostings missbraucht.

Das nehme ich dir beim besten Willen nicht ab. Ich habe das Prefetching aus Paranoia auf unterschiedlichen Rechnern aktiviert / deaktiviert, und stelle keine Unterschiede in der Performance auch. Auch wärst du scheinbar der erste, bei dem das der Fall wäre.

Übrigens: Prefetching ist bereits seit Firefox 1.x implementiert, und war über viele Versionen hinweg defaultmäßig aktiviert (so wie jetzt in 3.x), nur hat man es damals nicht wirklich bekannt gemacht. Du warst also möglicherweise schon ständig damit unterwegs. Und wie gesagt, ohne zutun des Seitenbetreibers hat Prefetching keine Auswirkungen.

Hänger beim Laden von Seiten stelle ich nur fest, wenn man mies geschriebene Plugins im Einsatz hat, die die Seite bei jedem Aufruf vollständig parsen. Z.b. wenn man eine unnötig lange AdBlock Filterliste hat, dann dauerts eben.

Zahlreiche  s stammen z.B. von der Redaktion - Artikelbeschreibungen,
Überschriften... In anderen Fällen ist es einfach eine kompakte Alternative zu
..., weil man nicht für jeden Furz einen style definieren will
(so kriegt man die "modernen" 20K stylesheets).

a) Falsch und b) du hast vermutlich keine Ahnung, wozu sie da ist - siehe
width-Angabe für einen Hinweis. Aber wenn Browser irgendwann verläßlich
Breitenangaben in CSS verarbeiten, kann man das ja durch eine Style-Definition
ersetzen, die "modern" ist und genausoviel Platz (eher mehr) braucht.

Oje, jetzt kommt eine philosophische Diskussion ... Manche Layouts lassen sich
nun mal nur mit Tabellen verläßlich lösen, weil Browser noch immer
größtenteils fehlerhafte / unterschiedliche CSS-Implementierungen haben (wobei
das in dem konkreten Fall andere Gründe hatte, aber es gibt wirklich keinen
ersthaften Grund, das zu ändern).

Nochmal - wozu muss dies von einem Redakteur festgelegt werden? So viele designmäßig unterschiedliche Seiten hat GH nun wirklich nicht (öffentlich), als das man nicht für jede einzelne die Styles einmal definieren, und dann ohne diesen Overhead leben könnte. Ein "modernes" 20k Stylesheet ist um keinen deut mieser, als das positionieren von Inhalt durch Leerzeichen und Umbrüche, die immer geladen werden müssen.

Ja, ich habe keine Ahnung. Offensichtlich auch die anderen Autoren größerer Seiten nicht. Du tust hier, als müsse GH möglichst altmodisch aufgebaut sein, damit es mit jedem antiken Browser läuft - dabei gibt es seiten, die in der Hinsicht modern sind, UND sogar im uralt Browser mit deaktivierten Bildern / JS noch lesbar sind. Stichwort Barrierefreiheit.

Ein guter Frontend Entwickler hat die Eigenheiten der letzten Browsergenerationen im Kopf, und bügelt Fehler sofort aus, nachdem er in allen möglichen Konstellationen Tests durchgeführt hat. Dann gibts ebenen für den Uralt-IE ein alternatives Stylesheet, Opera, FF, Safari kommen auch mit einem gemeinsamen bestens zurecht, auch in älteren Versionen.

ad Prefetching - ich wiederhole mich - selbstständig lädt der Browser nichts voraus, sonst würden sich seit dem FF 3.0 Update Millionen User darüber beklagen, dass der Browser selbsttätig Bestellungen / Logouts / was auch immer ausführt, weil er einen Link aufruft, der mit Vorsicht zu genießen ist.

Es gibt gewiss Erweiterungen, die dir alle internen Aktionen vom FF anzeigen, darunter auch die selbstständigen Requests, das sollte Klarheit verschaffen. Wenn alles scheitert, werfen wir eben einen Blick in den Quelltext

Du verstehst es nicht ... Eine Seite besteht nicht nur aus Layout, sondern
auch aus Content.

Ein   ist kürzer als "class=bla" und kürzer als .

Beispiele von mir gibts keine, weil ich a) kein Frontend Entwickler bin, und b) nur firmenintern entwickle, wir sind keine Dienstleister.

Aber meine Kritik am Quelltext sehe ich als untermauert an.

Hier wird ganz klar mehr Zeit in das bestreiten von offensichtlichen Schwachstellen investiert, als die Behebung dieser in Anspruch nehmen würde. Das ist alles andere als pragmatisch.

Werfen wir einen Blick auf die Startseite - speziell die Linkpartner - hier
wird z.b. Bandbreite durch 6*3 nbsp's verbraten, obwohl sich mit einem
simplen, einzelnen CSS Selektor des Elternelements (P) ein padding für alle
enthaltenen Links definieren lassen würde. Ein class= für jeden einzelnen Link
wäre ebenso schwachsinnig.

Was dir ein eventueller Umbruch für Probleme macht, in einer Spalte mit fixer Breite, musst du erst mal erklären.

PS. ich kann mich vage daran erinnern, die LI-Variante aufgegeben zu haben,
nachdem jeder Browser das padding anders interpretierte. Vielleicht geht das
ja heutzutage besser.

LI:before {content: "» "}

Niemand klappt alles auf (bei threads mit 1000+ Postings),

Niemand klappt alles auf (bei threads mit 1000+ Postings), wie ein einziges
Posting dargestellt wird, ist daher ziemlich egal.

wie wärs mal mit "subthreads aufklappen" ...

[ OP ]
+- bla1
|  +- (27 weitere Postings)    
|
|--+-------------
|  | bla bla ... 
|  +-------------
|    +- bla
|    |  +- (19 weitere Postings)
|    +- bla
|
+- bla
+- bla2
|   +- (93 weitere Postings)
+- bla

Niemand klappt alles auf (bei threads mit 1000+ Postings),

Es ist erstaunlich, wie lahm FF 3.0 geworden ist, richtige Bloatware