Responsive Webseiten-Vorlage

• Webhoster können Apache-Server unterschiedlich konfigurieren: das betrifft auch die Regeln, die in der Datei .htaccess gültig sind. Deshalb funktionieren die Regeln nicht immer und überall.
• Mit falschen .htaccess-Regeln kann man seine Website schnell lahmlegen. Darauf sollte man vorbereitet sein. Oft hilft nur Testen nach dem Ausschlußverfahren: nacheinander die Regeln (Regelblöcke) deaktivieren und wieder aktivieren, um den Übeltäter zu ermitteln. Anschließend beim Webhoster oder in einem Fachforum nachfragen.
• Wenn Sie absoluter Neuling auf diesem Gebiet sind und sich an das Thema nicht heranwagen, fragen Sie Ihren Webhoster, welche Regeln er Ihnen empfiehlt.
• Kommentare in der Datei .htaccess werden mit der Raute (Gartenzaun) # eingeleitet. Damit können Regeln auskommentiert (deaktiviert) werden.
• Zum Dateinamen: die Datei heißt .htaccess: die erste Stelle des Dateinamen ist ein Punkt.
• Falls Sie unter Windows keine Datei mit dem Namen .htaccess erstellen (speichern) können, haben Sie zwei Möglichkeiten: (a) Sie verwenden einen fähigen Quellcode-Editor wie die schon erwähnten Notepad++, SynWrite oder Cudatext: mit denen geht's. (b) Sie benennen die Datei .htaccess.txt, laden diese Datei .htaccess.txt auf Ihren Server hoch und ändern erst dort den Namen um in .htaccess.
• Als Fachforum empfehle ich Ihnen das Webserver- und .htaccess-Forum von Jörg Kruse. Dort erhalten Sie schnell kompetente Antworten.

Die eindeutige Erreichbarkeit (kanonische URL) ein und des gleichen Inhalts ist wichtig im Hinblick auf Suchmaschinen. Oft sind Seiten unter vier Adressen erreichbar, die Startseite sogar unter acht Adressen: mit https:// und mit http://, jeweils mit www. und ohne www. und dann noch jeweils mit /index.php und ohne /index.php. Wenn vom Webmaster nichts festgelegt ist, entscheiden Google™ und Co nach eigenem Gutdünken, wie sie Ihre Seiten verlinken.

Die mehrfache Erreichbarkeit sollte man also vermeiden und sich für genau eine Version entscheiden. Am Besten erledigt man das gleichzeitig mit dem Hochladen der Website auf den Server oder zeitnah danach. Die erforderlichen Weiterleitungen mit HTTP-Statuscode 301 kann man in der Datei .htaccess mit nur sechs Direktiven einrichten, wenn das Apache-Modul mod_rewrite verfügbar ist. Ob Sie sich für mit www. oder für ohne www. entscheiden, ist Geschmackssache. In meinem Vorschlag für Ihre .htaccess (siehe Datei /extras/.htaccess.txt im Download-Paket ab Version 1.2) verwende ich die kürzere Version ohne www.. Die bei mir enthaltenen Direktiven stammen aus Jörg Kruses Artikel Weiterleiten auf Standard-URL (vielen Dank an Jörg Kruse). Dort finden Sie auch die umgekehrte Lösung mit www..

Der Vollständigkeit halber weise ich darauf hin, daß manche Webhoster eine eigene technische Lösung für dieses Problem anbieten. Dann können Sie entscheiden, ob Sie die Webhoster-Lösung bevorzugen oder die .htaccess-Regel-Lösung.

Wenn ein Besucher eine nicht vorhandene Seite anfordert, zeigen die Webhoster meist eine Fehlermeldung an, ohne den Besucher darüber zu informieren, was er denn jetzt tun kann. Diese Standard-Fehlermeldung kann man durch eine individuelle Fehlerseite ersetzen, die (a) dem Layout der eigenen Website entspricht und (b) dem Besucher Möglichkeiten zeigt, wie es weitergeht.

Die Schnelligkeit, mit der Webseiten geladen werden, hängt auch davon ab, ob bei wiederkehrenden Besuchen oft benötigte Elemente (zB CSS-Dateien, Javascript-Dateien, Favicons, Kopfzeilen-Bilder) schon im Browser-Cache des Besuchers vorhanden sind. Die Cache-Dauer beim Besucher kann der Webmaster unterschiedlich je Mime Type (Media Type) über Regeln in seiner .htaccess-Datei festlegen, wenn auf dem Server das Apache-Modul mod_expires verfügbar ist. Seit einiger Zeit ist bei Google™ die Website-Geschwindigkeit eines der Ranking-Kriterien.

Natürlich kann auch für die eigentlichen Seiteninhalte (Texte und Bilder) eine Cache-Dauer definiert werden. Ob das sinnvoll ist, hängt vom Thema der Seite ab: für schnell wechselnde Börsenkurse, Wettervorhersagen und Preisangaben eher nicht. In diesen Fällen sollten Sie also keine oder nur eine ganz kurze Cache-Dauer festlegen. Aber ein bebilderter Reisebericht, ein Artikel über Dinosaurier oder das Dienstleistungsangebot eines Therapeuten wird sich nicht stündlich ändern: dort kann auch für Seiteninhalte eine längere Cache-Zeit angegeben werden.

In meinem Vorschlag für Ihre .htaccess (siehe Datei .htaccess.txt) sind Cache-Regeln für alle Mime Types aufgeführt, die in der Webseiten-Vorlage vorkommen. Ich hoffe sehr, daß ich keinen übersehen habe, aber für die vergessenen Typen ist dann die Standard-Regel ExpiresDefault "access plus 2 days" zuständig.

Wenn Sie zusätzliche Elemente in Ihre Website aufnehmen (zB Video- oder Audio-Elemente), die in der Vorlage nicht vorkommen, können Sie deren Mime Types (Media Types) leicht ermitteln: Rufen Sie die Entwicklerwerkzeuge Ihres Browsers auf und klicken in der Netzwerk-Ansicht auf das betreffende Element: dann sehen Sie hinter Antwortheader -> Content-Type die Typangabe, die Sie in Ihrer neuen ExpiresByType-Regel eintragen müssen.

Und der Test? Ganz einfach: Vergleichen Sie mit den Browser-Entwicklerwerkzeugen, Reiter Netzwerk für das jeweilige Element unter Antwortheader die Angaben hinter Date: und Expires: (beschrieben für die Chromium-Entwicklerwerkzeuge unter Vivaldi).

Für die Website-Geschwindigkeit sind vor Allem die (möglichst geringe) Anzahl der benötigten Elemente und eine geringe Übertragungsgröße maßgebend. Die Übertragungsgröße (das Downloadvolumen) können Sie verringern, wenn Sie Elemente komprimiert an die Browser Ihrer Besucher ausliefern. Bevor Sie CSS- und Javascript-Dateien komprimieren, prüfen Sie zuerst, ob Ihr Webhoster das für Sie schon erledigt hat (zB über einen nginx-Proxyserver):

Wenn in der Netzwerk-Ansicht der Entwicklerwerkzeuge Ihres Browsers in den Reihen für regeln.css und scripte.js in der Spalte Größe zwei verschiedene Werte stehen, ist der Punkt schon erledigt: Der obere (kleinere) Wert gibt die komprimierte Größe, der untere (größere) Wert die Original-Größe des Elements an. Beachten Sie bitte: In den Chromium-Entwicklerwerkzeugen sehen Sie nur dann beide Werte, wenn Sie zuvor über das Zahnrad Netzwerkeinstellungen oben rechts die Option Große Anfragezeilen verwenden aktiviert haben. Diese Einstellung ist immer sinnvoll.

Wenn in der Spalte Größe je für CSS- und Javascript-Dateien zwei (annähernd) gleich große Werte stehen, wird nicht komprimiert. Dann sollten Sie in Ihrer .htaccess-Datei die Regeln in den beiden Blöcken Vorab-Komprimierung GZIP für css|js aktivieren (Block mod_headers und Block mod_rewrite). Was dann noch fehlt: Im Verzeichnis /y-code müssen zusätzlich die GZIP-komprimierten Versionen regeln.css.gz und scripte.js.gz abgelegt werden. Für die Komprimierung empfehle ich das (schon erwähnte) Programm 7-Zip.

Fremde Bilder werden oft geklaut und als die eigenen ausgegeben. Eine besonders fiese Masche vor etwa 20 Jahren war es aber, sich nicht nur an fremden Bildern zu bedienen, sondern diese fremden Bilder auch noch vom Original-Server des Urhebers einzubinden. Damals gab's noch keine traffic flatrates, ab einer bestimmten Freigrenze mußte das Download-Volumen beim Webhoster gesondert bezahlt werden. Durch das Bilder-Hotlinking wurden den Beklauten auch noch die vom Dieb verursachten Download-Kosten aufgebürdet (Traffic-Klau).

Dagegen konnte / kann man sich aber wehren: Mit ein paar .htaccess-Regeln wird veranlaßt, daß auf den Webseiten der Diebe anstelle des hotverlinkten Originalbildes ein hierfür erstelltes Ersatzbild angezeigt wird. Bis die Diebe das Ersatzbild bemerken, sind sie selbst bei den Besuchern ihrer Webseiten die Blamierten. Im Download-Paket ab Version 1.2 ist ein solches Hotlinking-Ersatzbild enthalten. Ich hoffe, es ist ausreichend häßlich ;-)