JavaScript Part 3: Wie stellt ein Browser Websites für uns dar?

Das erwartet euch in diesem Artikel

  • Wie stellen Browser HTML dar?
  • Was macht das CSS?
  • Wo kann das JavaScript Probleme bereiten?

Nachdem wir im letzten Beitrag angeschnitten haben, wie sich Suchmaschinen das Web erschließen und erste Fallen gezeigt haben, in die man mit JavaScript tappen kann, legen wir heute eine kleine Theoriestunde ein.

Suchmaschinen, allen voran Google, versuchen stets nachzuvollziehen, wie ein echter Nutzer eine Website „erlebt”. Um dies zu erreichen, werden die Seiten für die interne Verarbeitung mittlerweile gerendert, also genau so dargestellt, wie wir als Menschen sie im Browser sehen würden.

Dass das Thema Rendering aktuell und wichtig ist zeigen auch wiederholt Aussagen von Google-Mitarbeitern:

Zeit, sich einmal mit der Frage zu befassen: Wie stellt ein Browser Websites für uns dar?
Ihr werdet überrascht sein, wieviel Arbeit ein moderner Browser verrichten muss.

HTML

Der Browser fordert das Dokument an, das er anzeigen soll. Entweder, weil Ihr die URL des Dokumentes eingegeben habt, oder weil ihr auf ein Suchergebnis geklickt habt.

Der Browser sagt zum Sever „gib mir bitte das Dokument ‘artikel.html’.”

Und der Server antwortet im besten Fall mit einem positiven Bescheid auf den Antrag des Browsers und schickt das angeforderte Dokument gleich mit.

Der Browser muss dieses Dokument dann lesen, verarbeiten, in eine für euch brauchbare Version übersetzen und diese dann darstellen. Das sieht dann in etwa so aus:

Screenshot: GrowthUp in HTML

Abb. 1: Der Browser stellt das HTML Dokument dar.

Grafik: Prozess HTML

Abb. 2: Der Prozess stark vereinfacht.

HTML + CSS

Diese Ansicht ist aber wenig schön und kaum individuell. Cascading Style Sheets (CSS) übernehmen die Gestaltung des HTML-Dokumentes. Sie sind weitestgehend für das Aussehen moderner Websites verantwortlich. CSS geben dem Browser Regeln vor, nach denen er Elemente anordnet (Layout) und sie darstellt (Form, Farbe, Größe). Seit CSS3 sind sogar umfassende Animationen und Effekte möglich.

Um diese Regeln anwenden zu können, müssen zwei grundlegende Bedingungen erfüllt sein:

  1. Der Browser muss die Regeln kennen.
  2. Der Browser muss die Elemente kennen, auf die er die Regeln anwenden soll.

Das klingt trivial, stellt uns jedoch noch vor Herausforderungen.

Wir senden dem Browser neben unserer HTML Datei noch eine CSS-Datei. Aus dieser kann er die Regeln herauslesen, die er braucht, um die Seite ansprechend und schön darzustellen.

Das bedeutet, der Browser muss nun zwei Anfragen an unseren Webserver senden. Ja, es gibt auch die Möglichkeit das CSS direkt im HTML unterzubringen. Wir halten uns der Einfachheit halber erst einmal an die goldene Regel Form und Inhalt voneinander zu trennen.

Und der Server antwortet wieder mit einem positiven Bescheid auf den Antrag des Browsers und schickt die Dokumente zurück.

Der Browser muss dieses Dokument dann lese, verarbeiten, in eine für euch brauchbare Version übersetzen. Dann muss er die Regeln aus dem CSS lesen, verarbeiten, die zugehörigen Elemente im HTML-Dokument ausfindig machen und diese dann entsprechend gestalten. (Bereits hier können wir beeinflussen, wie schnell der Browser die Darstellungsregeln anwenden kann – dazu vielleicht mehr in einem gesonderten Artikel.)

Das Ergebnis sieht dann in etwa so aus:

Screenshot: GrowthUp mit CSS

Abb 3: Die HTML-Seite mit angewendeten CSS-Regeln – schick.

Grafik: Prozess mit CSS

Abb. 4: Der Prozess jetzt, immer noch stark vereinfacht.

Experten-Einschub

Wenn man sich mit Webentwicklern unterhält, mag der Prozess oben etwas zu einfach sein.

Was der Browser im Schritt „Verarbeitung” tut ist kurz gefasst folgendes:

  • Er parst (also liest) das Dokument
  • Er erstellt das Document Object Model (DOM)
  • Er erstellt das CSS Object Model (CSSOM – für die Darstellung)
  • Er erstellt aus dem DOM einen Render-Tree (der alle sichtbaren Elemente enthält)
  • Er berechnet das Layout der Elemente aus dem Render-Tree (Layouting)
  • Er zeichnet die Elemente aus dem Render-Tree in ein Fenster (Painting)
Grafik: Prozess ausführlicher

Abb. 5: Der Darstellungsprozess – immer noch vereinfacht aber etwas genauer

HTML + CSS + JS

Jetzt kommt JavaScript ins Spiel.

Wir möchten unseren Besuchern noch ein paar Usability-Gimmicks präsentieren. Wir wollen auch messen, wie viele Besucher unsere Webseite hat. Und wir müssen ein paar rechtliche Vorschriften einhalte.

Für all diese Zwecke nutzen wir JavaScript. Und hier wird es verrückt.

Die Idee hinter JavaScript war und ist folgende: Der Browser führt kleine Programme aus, welche die Elemente, die er für uns darstellt, beeinflussen. So färbt er zum Beispiel ein Eingabefeld rot, wenn die Eingabe nicht der Erwartung entspricht. Oder er schreibt die aktuelle Uhrzeit in einen dafür vorgesehenen Bereich.

Damit der Browser das tun kann, müssen wieder eine Reihe von Voraussetzungen erfüllt sein:

  1. Er muss das HTML Dokument kennen
  2. Er muss die CSS Regeln kennen, um die Elemente korrekt darzustellen
  3. Er muss das Programm (Skript) kennen, das er ausführen muss
  4. Er muss weiterhin wissen, auf welches Element sich das Programm auswirkt
  5. Er muss unter Umständen die Darstellung der Elemente aus 1. und 2.wieder anpassen

Für uns sieht das Ergebnis im ersten Moment nicht anders aus:

Screenshot: GrowthUp mit Java

Abb. 6: Die HTML-Seite mit angewendeten CSS-Regeln und JavaScript.

Der Prozess dahinter verkompliziert sich jedoch ein wenig. Da der Browser sein Ziel möglichst schnell erreichen möchte, arbeitet er verschiedene Schritte parallel ab. So kann er zum Beispiel bereits anfangen, das HTML darzustellen, sobald er alle CSS Regeln kennt.

Wird ein JavaScript geladen, hält er den Prozess jedoch an. Der Browser weiß nicht, ob er eines der Elemente, die er darstellen möchte, verändern muss und wartet daher darauf, das Skript auszuführen.

Grafik: Prozess mit Java

Abb. 7: Der vollständige (stark reduzierte) Prozess mit HTML, CSS und JS.

An allen mit * markierten Stellen kann etwas schief gehen. Im letzten Artikel haben wir bereits Beispiele gesehen, wie etwas schief gehen kann. Beim HTML ist er noch extrem tolerant, beim CSS kann es unschön werden, aber beim JS wird’s hakelig.

Experten-Einschub

JavaScript hat in der Regel die Aufgabe, die Objekte im DOM oder im CSSOM zu manipulieren. Daher wird der gesamte Darstellungsprozess gestoppt, sobald ein JavaScript ins Spiel kommt.

JavaScript blockiert das DOM (sofern wir nicht explizit dafür sorgen, dass sie dies nicht tun).

JavaScript kann erst ausgeführt werden, wenn das CSSOM fertig erstellt wurde.

Grafik: Der ganze Prozess

Abb 8: Der vollständige (stark reduzierte) Prozess mit HTML, CSS und JS.

Erste Learnings

Hier bieten sich die ersten Stolpersteine für unsere JavaScript Website.

Da wir unsere Seite gut optimieren möchten ,müssen wir dafür sorgen, dass sie schnell erstellt werden kann.

Warum? Ganz einfach, unsere Besucher wollen nicht ewig warten, bis die Seite fertig geladen ist. Das weiß auch Google. Und Google wartet auch nicht ewig, bis unsere Seite fertig geladen ist, wenn es sie crawlt.

Die ersten Maßnahmen, um unsere Seite etwas SEO-sicherer zu gestalten, sind daher:

  1. Wir rufen JavaScript möglichst spät auf, um die Erstellung des CSSOM abzuwarten. Das bedeutet auch, dass CSS-Dateien immervor JavaScript referenziert werden.
  2. Wir laden so wenige JavaScript-Dateien wie möglich, da jeder Ladevorgang alle weiteren Arbeitsschritte blockiert. Das bedeutet zum Beispiel, dass wir nicht auf jeder Seite alle gleichen Skripte laden.
  3. Wir lassen JavaScript, das für die initiale Darstellung der Website nicht notwendig ist, erst laden, wenn das Dokument fertig erstellt wurde. Das bedeutet auch, dass wir essenzielle Inhalte nicht über JavaScript, sondern als HTML-Inhalte bereitstellen.

Diese Punkte rücken gerade in den aktuellen Diskussionen um JavaScript und SEO oft in den Hintergrund. Frameworks, Libaries und SSR sind jedoch nachgelagerte Punkte, wenn die oben genannten bereits beachtet werden.


<!DOCTYPE html>
<html>
  <head>
    <meta name=“viewport“ content=“width=device-width,initial-scale=1″>
    <script type=“text/javascript“ src=“suchbegriff-vorschlaege-produktsuche.js“ ></script>
    <script type=“text/javascript“ src=“footer-animation.js“ ></script>
    <script type=“text/javascript“ src=“foto-lightbox.js“ ></script>
    <script type=“text/javascript“ src=“weitere-skripte-nachladen.js“ ></script>
    <link href=“style.css“ rel=“stylesheet“>
    <title>Unsere kleine Webseite</title>
  </head>
  <body>
    <script type=“text/javascript“ src=“ueberschriften-erstellen.js“ ></script>

    <p>Diese Seite hat einige Probleme. Allerdings weiß keiner so genau, welche</p>

    <div><img src=“fragezeichen.jpg“ class=“ohne-lightbox“></div>

    <p>Was könnte es wohl sein?</p>

    <script type=“text/javascript“ src=“besuchererkennung.js“ ></script>
  </body>
</html>;

Listing: Quelltext einer kleinen Seite.

Schauen wir uns den Quelltext einer kleinen Website einmal an. Stellen wir uns die erste Frage: Werden die Inhalte in der korrekten Reihenfolge geladen?

Nein. ganze 4 Skripte werden vor dem CSS geladen. Sie blockieren den gesamten Darstellungsprozess, können dabei noch gar nicht ausgeführt werden.

Das Skript besuchererkennung.js ist sicher wichtig, kommt aber erst ganz am Ende, steht also erstmal nicht im Weg.

Zweite Frage: Brauche ich alle diese Skripte?

Nein. Zugegeben, das Beispiel wirkt ein wenig konstruiert – verdeutlicht aber, worum es geht. Wir brauchen nicht alle Skripte. Das einzige Bild, das wir verwenden, gehört der Klasse "ohne-Lightbox" an. Das Skript foto-lightbox.js kann demnach weggelassen werden, wir laden es umsonst. Die Skripte suchbegriff-vorschlaege-produktsuche.js und footer-animation.js sind gewiss nicht für die initiale Darstellung notwendig. Sie können geladen werden, wenn sie gebraucht werden. Das Skript weitere-skripte-nachladen.js ist ein potenzieller Pferdefuß. Nicht nur blockiert es den Darstellungsprozess, es lädt noch weitere Skripte nach. Hier muss zwingend geklärt werden, welche, warum, und ob wir darauf verzichten können.

Was wir jetzt tun:

  1. Wir laden Skripte erst nachdem CSS.
  2. Wir entfernen unnötige Skripte.
  3. Wir sorgen dafür, dass die Skripte, die zur initialen Darstellung gebraucht werden, nicht dem Rendern im Weg stehen.

Das sieht im Ergebnis dann wie folgt aus:


<!DOCTYPE html>
<html>
  <head>
    <meta name=“viewport“ content=“width=device-width,initial-scale=1″>

    <link href=“style.css“ rel=“stylesheet“>

    <script type=“text/javascript“ src=“weitere-skripte-nachladen.js“ defer ></script>

    <title>Unsere kleine Webseite</title>
  </head>
  <body>
    <h1>Sparsam sein mit JavaScript</h1>

    <p>Diese Seite hatte einige Probleme. Allerdings konnten wir die ersten identifizieren und beheben.</p>

    <div><img src=“dollarzeichen.jpg“ class=“ohne-lightbox“></div>

    <h2>Nach der Theorie kommt die Praxis</h2>

    <p>Demnächst zeigen Wir Euch, wie wir unsere Seite optimiert haben.</p>

    <script type=“text/javascript“ src=“besuchererkennung.js“ defer ></script>
    <script type=“text/javascript“ src=“footer-animation.js“ defer></script>
  </body>
</html>

Listing 2: Jetzt wird es schon besser.

Eine Anleitung, wie man diese und weitere Ansatzpunkte auf seiner Website identifiziert und dann genau darauf reagiert, ist bereits in Arbeit. Die Grundlagen sind jetzt zumindest geklärt.

Da fehlt doch noch was?

Richtig!

Das Skript ueberschriften-erstellen.js ähnelt dem, was bei vielen modernen JavaScript-Seiten passiert: wichtige Inhalte werden über Skripte erstellt und geladen. Die erste Devise sollte immer sein: vermeidet diesen Schritt. Je weiter ihr JavaScript aus dem obigen Prozess heraus haltet, desto besser. Den Hintergrund hierzu erklären wir in einem weiteren Beitrag.

Über den Autor

Sebastian Adler

Redakteur
Den Einstieg in die Online-Marketing-Welt fand ich 2011 bei Barketing im Offpage-Bereich. 2013 wechselte ich dann zu Searchmetrics in die SEO-Beratung, um dort den Kunden bei ihren SEO-Strategien mit Rat und Tat zur Seite zu stehen. Nach einem kurzen Ausflug ins Produktmanagement führte mich mein Weg im Sommer 2017 (zurück) zu LEAP/, wo ich nun wieder als SEO-Consultant tätig bin.
Kommentare