Wieso sind Frames angeblich so schlecht?

[molily]

Hallo,

Ich find Frames + IFrames ideal um Bytes zu sparen.

Mit Frames sparst du nicht wirklich.

Das ist nett, aber - Verzeihung - ziemlich wertlos und widerlegt gar nichts. Niemand baut wegen 21 zu sparenden Byte ein Frameset ein mit der Begründung, es spare Traffic!

Ich bezweifle nicht einmal, das letztlich ein ähnlich eindeutiges Ergebnis herauskommen wird, aber man sollte eine solche Rechnung noch einmal mit einer realistischen Navigationsstruktur durchführen, bei der manche überhaupt an Frames als Alternative denken würden. Über 21 Byte regt sich nämlich niemand auf. Natürlich hängt es von der Größe der auszulagernden Daten ab, ob ein Frameset nennenswert Traffic einzusparen vermag.

Man denke z.B. an die dreiteilige Navigation mit zwei Ebenen auf http://www.bmfsfj.de/ - ich denke, die Seite ist ein gutes Beispiel, sie ist mit CSS gelöst. Das sind ca. 9,2 KB, die auf jeder Seite geladen werden. Natürlich ließe sich der Code optimieren, also nehmen wir großzügig 8 KB an. Wenn ich den Code zusammen mit dem Logo und dem völlig überladenen head in ein Dokument packe, ist dieses 11 KB groß. Ein einfaches Frameset, sagen wir mit einigen Metadaten, wäre etwa 2,4 KB groß. Also 13,4 KB, sagen wir großzügig 15 KB. Eine durchschnittliche Inhaltsseite würde um die geschätzten 8000 Byte entlastet, allerdings müssten wir vielleicht noch 300 bis 500 Byte für Maßnahmen veranschlagen, die die Nachteile von Frames ausgleichen (Zusatzlinks, Brotkrumenpfad, Nachlade-Maßnahmen, etc.).

Die Nutzlast der Startseite ohne Navigation, aber mit voluminösem head beträgt ca. 20 KB, auf einer Folgeseite habe ich stichprobenartig (Pressemitteilungen) 15 KB gemessen, was mir angemessen erscheint. Nehmen wir mal diese Werte und nehmen 700 Bytes für eine HTTP-Anfrage und die Kopfdaten der Antwort an.

1. Zugriff
   Frameset: 15 KB Frameset + 20 KB Nutzlast Startseite + 500 Byte Kompensation + 2,1 KB HTTP = 37,6 KB = Gesamt 37,6 KB
   Framelos: 20 KB Nutzlast Startseite + 8 KB Navigation + 700 Byte HTTP = 28,7 KB = Gesamt 28,7 KB
2. Zugriff
   Frameset: 15 KB Nutzlast Folgeseite + 500 Byte Kompensation + 700 Byte HTTP = 16,2 KB = Gesamt 53,8 KB
   Framelos: 15 KB Nutzlast Folgeseite + 8 KB Navigation + 700 Byte HTTP = 23,7 KB = Gesamt 52,4 KB
3. Zugriff
   Frameset: plus 16,2 KB = Gesamt 70 KB
   Framelos: plus 23,7 KB = Gesamt 76,1 KB
4. Zugriff
   Frameset: plus 16,2 KB = Gesamt 86,2 KB
   Framelos: plus 23,7 KB = Gesamt 99,8 KB
5. Zugriff
   Frameset: plus 16,2 KB = Gesamt 102,4 KB
   Framelos: plus 23,7 KB = Gesamt 123,4 KB
...

So gesehen amortisiert sich das Frameset schon beim dritten Zugriff, wenngleich die Ersparnis zunächst nicht nennenswert ist und wie gesagt insgesamt auch kein stichhaltiges Argument für den Frameset-Einsatz darstellt.
Habe ich etwas grundlegend übersehen oder mich verrechnet? Grafiken und Stylesheets bleiben außen vor (Inhalts- und Navigationsframe teilen sich dasselbe Stylesheet), die dürften mit Frames genauso geladen werden. Vielleicht hätte ich auch 1 KB für die Kompensierung von Frame-Nachteilen veranschlagen können.

Ich finde solche Untersuchungen ziemlich müßig. Sie verdecken nämlich das Problem und lenken von wirklich greifenden Maßnahmen zur Verringerung des Traffics ab. Das ist: eine sinnvolle, möglichst übersichtliche und immer zugängliche Navigation schaffen. Sinnvolle Orientierung anbieten. Eine hierarchische Hauptnavigation mit zwei Ebenen wie beim Bundesministerium ist schon nicht falsch. Hinzu kommen Suchfunktion, Schnell-Finder und eine zusätzliche thematische Navigation. Schließlich Meta-Links wie Startseite, Sitemap, Newsletter, Hilfe, Kontakt, Impressum, allgemeine Suchfunktion.

Das Bundesministerium scheint eine lange Navigation zu haben, die regulären Seiten sind dadurch tatsächlich überladen, aber wo ließe sich grundsätzlich einsparen? Die Site ist gar nicht so groß, es sind 17 Hauptrubriken, die allesamt sinnig erscheinen. Müssen sie aber auf jeder Unterseite auf einen Klick abrufbar sein? (Aufgeklappte Sekundärnavigationen usw. habe ich oben gar nicht mit eingerechnet, die lassen sich mit JavaScript im Navigationsframe realisieren.) Die Kritik von Frames-Benutzern an diesem Umstand ist vollkommen gerechtfertigt, bei framelosen Seiten kommt bei entsprechender Sitestruktur notwendigerweise eine riesige Navigation auf jeder Unterseite heraus. Also müsste man weg von der Selbstverständlichkeit, auf jeder Unterseite die komplette hierarchische Navigation zu wiederholen. Ich finde das schon seit langem schwachsinnig, die Debatte ist Jahre alt (zwei schöne Links dazu: </archiv/2002/5/t12885/#m71213>, </archiv/2003/12/t67816/>). Das Konzept von Frames bzw. Inner Frames (object) ist aus dieser Sicht gar nicht so verkehrt, sondern eigentlich sogar stimmig, weil man die wirklichen Inhaltsseiten und die Verzeichnis- bzw. Übersichtsseiten trennt. Was nicht daran ändert, dass der Hypertextknoten selbst Kontextbeziehungen aufweisen muss (das übliche Problem der fehlenden Navigation). Was nichts daran ändert, dass HTML-4-Frames sowie deren Implementierungen dem Hypertext-Gedanken aus anderen Gründen entgegenlaufen (es ging hier irgendwann auch einmal darum, wie ein sinnvolles Frames-Konzept aussehen würde, schließlich soll es einen Nachfolger geben, bei dem man alte Fehler vermeiden könnte).

Mathias