Kategorien
Apps HTML/CSS JavaScript & jQuery Responsive Design Webdesign

Progressive Web Apps: Mit HTML5 und JavaScript zur fast nativen App

Native Apps für Android- und iOS-Geräte haben in vielerlei Hinsicht große Vorteile gegenüber per HTML5 und JavaScript entwickelter Webanwendungen.

Kategorien
JavaScript & jQuery SEO & Online-Marketing

JavaScript und Suchmaschinen: Das solltest du beachten

Noch vor einigen Jahren war JavaScript mehr als umstritten. Nervige Werbe-Pop-ups führten dazu, dass die Programmiersprache oft ganz grundsätzlich blockiert wurde. Mittlerweile ist JavaScript aus dem modernen Webdesign nicht mehr wegzudenken. Vor allem im mobilen Internet spielt JavaScript eine wichtige Rolle – unter anderem zur Medienwiedergabe, aber auch für Geolocation und moderne Navigationen. Doch wie gut verträgt sich JavaScript mit Suchmaschinen? Was musst du beachten?

Suchmaschinen haben dazugelernt

Zunächst einmal sei gesagt, dass die Zeiten vorbei sind, in denen Suchmaschinen mit JavaScript gar nichts anfangen konnten. Waren per JavaScript geladene Inhalte früher unsichtbar für Suchmaschinen, haben die Suchmaschinen mittlerweile dazugelernt. Und wenn ich von Suchmaschinen spreche, ist natürlich vor allem Google gemeint. Denn der Suchriese ist nach wie vor das Maß aller Dinge.

So ist JavaScript keine grundsätzliche Hürde mehr für Google. Allerdings bedeutet dies nicht, dass du JavaScript völlig bedenkenlos einsetzen kannst. Da Google immer ein großes Geheimnis daraus macht, wie sein Suchalgorithmus funktioniert, sind folgende Tipps immer mit etwas Vorsicht zu genießen.

Inhalte per Load- statt User-Events laden

Oftmals werden Events eingesetzt, um per JavaScript Inhalte einer Website zu ändern. Hier gilt, dass Suchmaschinen in der Regel nur solche Inhalte berücksichtigen, die über Load-Events geladen werden.

Diese Ereignisse werden vom Browser gefeuert, sobald der DOM-Baum einer Seite geladen ist. Suchmaschinen wie Google lassen Load-Events beim Crawlen zu, sodass in der Regel der Seiteninhalt erst nach Ausführen der Load-Events indiziert wird.

User-Events werden jedoch nicht geladen. Das heißt, alle Veränderungen, die zum Beispiel über Click- oder Touch-Events ausgelöst werden, bleiben beim Indizieren unberücksichtigt.

Push-States und URLs

Damit Google eine Seite indizieren kann, muss diese immer zwingend über eine URL erreichbar sein. Daher können Click-Events auch nicht berücksichtigt werden, da diese immer einen vom Benutzer individuell herbeigeführten Inhalt darstellen.

Dank der Push-State-API von JavaScript ist es mittlerweile ja möglich, die URL einer Seite zu beeinflussen. So kannst du die komplette Navigation einer Seite per JavaScript realisieren, indem du per „pushState()“ die im Browser dargestellte URL änderst und gleichzeitig per JavaScript Inhalte lädst und ersetzt.

Da Google URLs, die ausschließlich per Push-State-API realisiert werden, nicht indizieren kann, muss jede per „pushState()“ erstellte URL immer auch eine „real existierende“ URL besitzen.

Dies ist übrigens nicht nur für Suchmaschinen interessant, sondern auch für soziale Netzwerke. Denn du kannst nur solche Seiten dort teilen, die über eine „echte“ URL verfügen. Denn auch Facebook und Twitter müssen Inhalte aus einer Seite extrahieren, was nur funktioniert, wenn die URL vorhanden ist.

Wichtig ist, dass du per „pushState()“ immer korrekte URLs erzeugt, die immer auch per JavaScript den richtigen Inhalt besitzen. Eine falsche Push-State-URL, die keine neuen Inhalte lädt, führt möglicherweise dazu, dass es du doppeltem Content kommt. Und das wiederum mögen Suchmaschinen ja auch nicht.

JavaScript nicht ausschließen
Es ist zwar selbstverständlich, sei aber dennoch erwähnt. Du musst natürlich dafür sorgen, dass JavaScript-Dateien für Suchmaschinen nicht ausgeschlossen sind. Werden über die „robots.txt“ JavaScript-Dateien grundsätzlich verboten, haben Suchmaschinen keine Möglichkeit, auf diese zuzugreifen.

Da JavaScript selbst ja keinerlei indizierbare Inhalte besitzt, wird es für Suchmaschinen gerne mal versteckt.

Progressive Enhancement

Trotz aller Möglichkeiten, die Google und andere Suchmaschinen dir geben, um per JavaScript erstellte Inhalte zu crawlen, ist die sicherste Methode immer noch das sogenannte „Progressive Enhancement“.

Dieses Prinzip verfolgt den Ansatz, dass Inhalte so aufzubereiten sind, dass sie immer unabhängig von Browser beziehungsweise Crawler verfügbar sind.

Konkret bedeutet dies, dass Texte, Bilder und andere Inhalte, die von einer Suchmaschine gefunden und durchsucht werden sollen, nach Möglichkeit ohne JavaScript auskommen sollen.

Dies bedeutet allerdings für den Webentwickler immer ein oft erheblichen Mehraufwand. Denn jede Seite muss im Grunde auch ohne JavaScript alle Inhalte bereitstellen. Je nach Art und Aufbereitung der Inhalte kommen möglicherweise auch Kompromisse in Frage, bei denen nur wichtige Inhalte auch ohne JavaScript bereitgestellt werden.

Hier musst du abwägen, welcher Aufwand für dein Projekt vertretbar ist.

Korrekte Semantik

Ob mit oder ohne JavaScript: In jedem Fall ist es wichtig, dass deine Inhalte semantisch korrekt ausgezeichnet sind. Auch Überschriften, die per JavaScript geladen werden, müssen mit den entsprechenden HTML-Elementen ausgezeichnet werden.

Denn hier gelten dieselben Regeln wie für normale Inhalte. Letztendlich ist für Google entscheidend, wie der HTML-Quelltext nach dem Ausführen von JavaScript aussieht. Da ist die Wahl der richtigen Elemente entscheidend.

Crawler-Ansicht testen

Entscheidest du dich dazu, Inhalte ausschließlich per JavaScript zu laden (also nicht nach dem „Progressive Enhancement“-Prinzip), solltest du testen, ob Suchmaschinen deine Inhalte tatsächlich korrekt und vollständig sehen und crawlen können.

So hilft dir zum Beispiel die „Search Console“ von Google. Unter „Crawling“ findest du die Funktion „Abruf wie durch Google“. Hier kannst du dir deine Website für Desktop- oder Mobilgeräte so darstellen lassen, wie Google sie tatsächlich crawlt.

Es gibt aber auch andere, meist kostenpflichtige Tools wie SEO.JS und prerender.io, die sich darauf spezialisiert haben, Websites dahingegend zu prüfen, ob JavaScript-Inhalt beim Crawlen korrekt und vollständig dargestellt werden. Bei komplexen Projekten mag das eine sinnvolle Ergänzung sein.

Kategorien
JavaScript & jQuery Programmierung Webdesign

Framework jQuery: die Vorteile und Nachteile

Frameworks wie jQuery gehören zu den bekanntesten und weit verbreitetsten Helfer, die auf Websites eingesetzt werden. Das Framework ermöglicht es, schnell und unkompliziert auf HTML-Elemente zuzugreifen und diese zu manipulieren oder per CSS zu gestalten. Ich selbst bin kein großer Freund von solchen Frameworks und versuche, sie – wo immer es geht – zu vermeiden. Das funktioniert nicht immer, ist aber häufig problemlos machbar.

jQuery und Co. und der große Ballast

Gerade jQuery hat sich in den letzten Jahren zu einer Art Schweizer Taschenmesser für JavaScript entwickelt. Das Frameworks bietet unzählige Methoden, Eigenschaften und Ereignisse, von denen die Meisten wohl nur ein Bruchteil benötigen.

Auch wenn jQuery in der aktuellen komprimierten Fassung auf gerade einmal 85 Kilobyte kommt, bliebe ein Großteil des Frameworks in meinen Projekten ungenutzt. Man kann es kleinlich nennen, dass mir 85 Kilobyte solch Kopfzerbrechen bereiten. Aber als Webentwickler ist mir ein schlanker Code, der nur das beinhaltet, was auch tatsächlich gebraucht wird, wichtig.

Jetzt ist jQuery mittlerweile zu einer Art Standard in der Webentwicklung geworden. Daher sind viele andere Frameworks mittlerweile als Plugins für jQuery entwickelt. Will ich diese nutzen, muss ich auch jQuery nutzen. Hier zeigt sich im besonderen Maße, was solche Frameworks für Nachteile mit sich bringen.

Denn letztlich benötige ich jQuery dann nur, um das Plugin nutzen zu können. Da sind mir 85 Kilobyte dann in der Tat zu viel.

Doppelt gemoppelt: Was jQuery kann, kann JavaScript oft auch

Mit der Einführung von HTML5 hat auch JavaScript einen großen Sprung gemacht. Viele Funktionen, die bislang nur per jQuery möglich waren, sind nun auch ebenso einfach als native JavaScript-Methoden vorhanden.

Das gilt zum Beispiel für das Hinzufügen und Entfernen von JavaScript-Klassen. Mit der „classList“-API kannst du dies ähnlich wie in jQuery realisieren.

Eine der wichtigsten Funktionen in jQuery ist die Möglichkeit, per „$()“ auf beliebige Elemente zuzugreifen – und zwar in Anlehnung an CSS-Selektoren. Selbst dieses Alleinstellungsmerkmal von jQuery ist mittlerweile mit der Methode „querySelector()“ in JavaScript aufgegriffen worden.

document.querySelector("ol li").classList.add("new");

Im Beispiel wird allen „<li>“-Elementen, die Kinder eines „<ol>“-Elementes sind, die Klasse „new“ zugewiesen. In jQuery ist ein entsprechender Aufruf kaum kürzer – vor allem aber nicht weniger kompliziert.

$("ol li").addClass("new");

In vielen Fällen benötige ich jQuery also gar nicht, sondern kann mit JavaScript auf ähnlich einfachem Wege arbeiten.

Performance vs. Einfachheit

jQuery und seine weniger bekannten Freunde machen es einem in vielen Fällen sehr viel einfacher, mit JavaScript zu arbeiten. Aber nicht immer ist der einfach Weg auch der Beste – gerade wenn es um die Performance geht.

Denn sowohl die jQuery-Methode „$()“ als auch die JavaScript-Methode „querySelector()“ schneiden in Sachen Performance schlechter ab als die Methoden „getElementsByTagName()“ oder „getElementsByID()“. Denn bei „$()“ und „querySelector()“ wird zunächst der komplette DOM-Baum eines Dokumentes nach entsprechenden zutreffenden Elementen durchsucht.

Die beiden Methoden „getElementsByTagName()“ oder „getElementsByID()“ kommen deutlich schneller ans Ziel. Natürlich sind die letztgenannten Methoden für Entwickler zuweilen mit mehr Aufwand verbunden. Auch hier mag der geringe Unterschied bei der Performance vernachlässigbar sein. Man sollte sich dessen jedoch bewusst sein.

Vorteil: einheitliche Browser-Kompatibilität

Jetzt will ich natürlich auch nicht so tun, als sei jQuery durch und durch überflüssig. Denn es hat ja seinen Grund, warum es immer noch sehr erfolgreich und beliebt ist. Ein Vorteil ist natürlich die einfache Anwendung.

Darüber hinaus haben solche Frameworks natürlich den Vorteil, dass sie eine breite Browser-Kompatibilität mit sich bringen. Während ich bei nativen Methoden immer schauen muss, welcher Browser ab welcher Version sie unterstützt, macht jQuery mir das einfacher.

Denn für jede jQuery-Version weiß ich, welche Browser und Versionen unterstützt werden. Gerade wer für ältere Versionen des Internet Explorers entwickelt, hat mit jQuery in der aktuellen Version die Sicherheit, dass dieser ab Version 9 unterstützt wird.

Und wer ältere Browser noch unterstützen möchte, kann auf ältere Versionen von jQuery zurückgreifen. Das erleichtert die Entwicklung von Websites, da man schon im Vorfeld weiß, welche Browser denn mit an Bord sind.

Frameworks fürs Spezielle

Jetzt bin ich also jemand, der – wenn immer es möglich und sinnvoll ist – auf Frameworks verzichtet. Möglich ist es eigentlich immer. Denn grundsätzlich kann man ja alles selbst in JavaScript programmieren. Nur sinnvoll ist es natürlich nicht immer.

Es gibt natürlich Situationen, in denen der Aufwand, eine komplexe JavaScript-Programmierung selbst zu entwickeln, in keiner Relation zum Ergebnis steht. Wer mit JavaScript zum Beispiel 3D-Animationen erstellen möchte, kann sich natürlich selbst sein eigenes 3D-Framework bauen.

Hier ist es hingegen mehr als sinnvoll, auf ein stabiles und möglichst leichtes Framework zurückzugreifen. In solchen Fällen ist es mir aber immer wichtig, dass dieses Framework nicht auf andere Frameworks wie jQuery aufbaut, sondern unabhängig verwendet werden kann.

Fazit

Natürlich ist die Frage, ob man auf Frameworks setzt oder nicht, durchaus eine ideologische. Denn der Gewinn an Schnelligkeit ist in vielen Fällen marginal. Aber man sollte als Entwickler nicht aus bloßer Bequemlichkeit auf jQuery und Co. zurückgreifen.

Denn natives JavaScript kann häufig all das, was jQuery kann, selbst auch abdecken. Gerade wer für zeitgemäße Browser entwickelt und die Abwärtskompatibilität eh in Grenzen hält, kommt gut ohne dieses Framework aus.