Willkommen beim Wegerl.at 'Lesemodus'!
Entspanntes Lesen und spannende Artikel warten auf dich.
Entdecke unsere besten Beiträge und genieße den Lesemodus.
.htaccess

.htaccess Datei! – das mit Browser-Caching und Gzip usw.

SVG-Bild, GDJ
Info echo
OpenClipart-Vectors-katze-1

Ist der Classic-Editor schon zu kennen? –
"Advanced Editor Tools – ist so klasse!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-2

Anklickt Classic-Editor mit Advanced Editor Tools
"Advanced Editor Tools – ist das ausgezeichnete!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-3

Klassischen Editor anwenden! – und …
"Advanced Editor Tools – ist so sehr gut !"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-7

… die Welt gehört dem, der sie genießt.
"Advanced Editor Tools – und tut sehr gut!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-4

Advanced Editor Tools aktive Installationen: 2+ Millionen
"Advanced Editor Tools – ist so fabelhaft!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-5

Ansprechend! – so gehts hier zur Lancierung
"Advanced Editor Tools – ist de luxe!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-6

… und NEU! – Classic Widgets
"Classic Widgets – sind so grandiose!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Info echo
OpenClipart-Vectors-katze-8a

Werkraum ist Werkraum und Frontend ist Frontend
Katzen SVG OpenClipart-Vectors; Ticker von Ditty News Ticker
"Advanced Editor Tools – ist so fein!"
Anklickt! – Advanced Editor Tools; und NEU! – Classic Widgets

Die .htaccess ist zur Serverkonfiguration, mit der die Gzip-Komprimierung auch das Browser-Caching definiert wird – eine leistungsstarke Technik, um die Ladezeit einer Webseite zu verbessern. Erfahre, wie eine Website mit wenigen Schritten optimiert werden kann. Durch die gezielte Festlegung der Gzip-Komprimierung und Browser-Cache-Richtlinien können wiederkehrende Besucher von bereits geladenen Ressourcen profitieren, was zu einer schnelleren Ladezeit führt. Im Anschluss machen wir noch einen Blick auf die technischen Feinheiten der .htaccess

htaccess für sich

"ht" steht für "Hypertext", und "access" wird wie "Ac·cess" /ˈɛksɛs/ ausgesprochen, was den Netzzugang in der EDV betrifft. Unter Netzzugang versteht man die Möglichkeit, auf Daten zuzugreifen, die in einem Speicher abgelegt sind.

Die .htaccess-Datei ist eine leistungsstarke Konfigurationsdatei, die auf Webservern, insbesondere auf Apache-Servern, verwendet wird. Ihr Name steht für "Hypertext Access", und sie ermöglicht die Feinabstimmung der Servereinstellungen auf Verzeichnis- oder Dateiebene. Oft wird sie mit einem vorangestellten Punkt geschrieben (.htaccess), um sie als versteckte Datei zu kennzeichnen.

Diese Konfigurationsdatei arbeitet mit einer speziellen Syntax, bekannt als Directives, die es Administratoren ermöglicht, serverseitige Einstellungen für bestimmte Verzeichnisse oder Anwendungen anzupassen. Im Wesentlichen fungiert die .htaccess als eine Art Verkehrsregler für den Server, der den Ablauf von Anfragen und den Zugriff auf Ressourcen steuert.

Es ist zu betonen, dass Änderungen in der .htaccess-Datei in Echtzeit wirksam werden, ohne dass ein Neustart des Servers erforderlich ist. Dies macht sie zu einem flexiblen Werkzeug für die schnelle Anpassung von Serverkonfigurationen.

WordPress: .htaccess im Allgemeinen

Die Position der .htaccess-Datei in einem WordPress-System bestimmt, für welche Bereiche der Installation ihre Regeln gelten. Es können mehrere .htaccess-Dateien vorhanden sein, die spezifische Regeln für verschiedene Ordner und Unterordner setzen. Die Datei in einem Unterordner setzt dabei spezifischere Regeln durch, während die Haupt-.htaccess-Datei allgemeine Regeln für die gesamte Website steuert. Diese Struktur ermöglicht präzise Anpassungen und Sicherheitsregeln auf verschiedenen Ebenen der WordPress-Website.

Normalerweise enthält die Haupt-.htaccess-Datei im Stammverzeichnis der WordPress-Installation allgemeine Regeln, die für die gesamte Website gelten. Zusätzliche .htaccess-Dateien in Unterordnern oder für spezifische Zwecke können dann Regeln enthalten, die bestimmte Verzeichnisse oder Anwendungsfälle betreffen.


Um die .htaccess-Datei zu bearbeiten, navigiere über FTP zu deinem Webhosting-Server. Die .htaccess-Datei befindet sich normalerweise im Stammverzeichnis deiner Website. Wenn du die Datei nicht sehen kannst, vergewissere dich, dass dein FTP-Programm so konfiguriert ist, dass es versteckte Dateien anzeigt.

Sobald du die .htaccess-Datei gefunden hast, kannst du sie mit einem Texteditor öffnen und die gewünschten Anpassungen vornehmen.

.htaccess-Datei und
die Reihenfolge der Regeln

Der übliche Vorgang besteht darin, die .htaccess-Codes vor dem Abschnitt # BEGIN WordPress einzufügen. Dadurch werden die Serverkonfigurationen vor den WordPress-spezifischen Regeln angewendet.

Beispiel der Reihenfolge von Regeln in der .htaccess-Datei:

Serverkonfiguration: Reihenfolge der Regeln
# Schütze die .htaccess-Datei
# 7G-Firewall
# Image Hotlinking verbieten
# BEGIN WPSuperCache
# Browser Caching aktivieren ↓?
# Gzip-Komprimierung aktivieren ↑?
# Weiterleitungsregel
# Begin WordPress
  • Schütze die .htaccess-Datei: Sicherstellung, dass die .htaccess-Datei vor unerwünschten Änderungen geschützt ist.
  • 7G-Firewall: Verweis auf eine spezifische Regel oder Konfiguration im .htaccess-File.
  • Image Hotlinking verbieten: Verhindern, dass andere Websites Bilder direkt von der Website verlinken.
  • BEGIN WPSuperCache: Das steht im Zusammenhang der Regeln mit Plug-in WP Super Cache, falls die Option 'Experte' aktiviert wurde. (Wir konnten dazu keinen positiven Effekt erzielen.)
  • Browser Caching aktivieren. – mit Vorbehalt. Ermöglichen, dass der Browser Teile die Website zwischenspeichert, um die Ladegeschwindigkeit zu erhöhen.
  • Gzip-Komprimierung aktivieren: Aktivierung der Gzip-Komprimierung zur Reduzierung der Dateigröße und Verbesserung der Ladezeit.
  • Weiterleitungsregel: Regel für spezifische Weiterleitungen auf der Website.
  • Begin WordPress: Eintrag, um WordPress-spezifische Regeln oder Konfigurationen zu beginnen.

Graue Theorie, Browser-Caching vs. Gzip-Komprimierung: Das Browser-Caching und die Gzip-Komprimierung sind unterschiedliche Prozesse:

  • Das Browser-Caching legt fest, wie lange Ressourcen im Browser zwischengespeichert werden sollen.
  • Die Gzip-Komprimierung komprimiert Ressourcen, um die Übertragungszeit zu verkürzen, bevor sie zum Browser gesendet werden.

Die Reihenfolge in der .htaccess-Datei beeinflusst die Ausführungsreihenfolge dieser Prozesse. Wenn das Browser-Caching vor der Gzip-Komprimierung kommt, bedeutet dies, dass die Ressourcen zuerst zwischengespeichert und dann komprimiert werden.

Die ideale Reihenfolge zwischen Gzip-Komprimierung und Browser-Caching kann variieren und hängt von verschiedenen Faktoren ab, einschließlich der Art der Ressourcen, der Art der Website und der Serverkonfiguration. Es gibt jedoch einige Überlegungen, die bei der Entscheidung helfen können:

  1. Gzip-Komprimierung vor Browser-Caching: Wenn die Ressourcen zuerst mit Gzip komprimiert werden, bevor sie im Browser zwischengespeichert werden, verringert sich die Dateigröße der Ressourcen. Dies kann die Ladezeit der Website beim ersten Abruf dieser Ressourcen verbessern, da sie bereits komprimiert sind. Der Nachteil könnte sein, dass die komprimierten Ressourcen länger im Browsercache verbleiben, ohne dass sie erneut komprimiert werden, wenn sich ihre Inhalte ändern.
  2. Browser-Caching vor Gzip-Komprimierung: Hier werden Ressourcen zuerst im Browser zwischengespeichert, bevor sie komprimiert werden. Dadurch könnten die Ressourcen möglicherweise öfter komprimiert und aktualisiert werden, wenn sich ihre Inhalte ändern. Der Nachteil könnte sein, dass sie beim ersten Abruf nicht komprimiert sind, was zu einer etwas längeren Ladezeit führen könnte.

Die beste Vorgehensweise kann durch Tests ermittelt werden. Es gibt keine allgemeingültige Lösung, da die optimale Reihenfolge von vielen Faktoren abhängt und von Website zu Website unterschiedlich sein kann.

Browser-Caching

Die Verwaltung des Browser-Caches in der .htaccess-Konfiguration kann eine anspruchsvolle Aufgabe sein, da verschiedene Browser unterschiedliche Verhaltensweisen aufweisen. Der Browser-Cache spielt eine Rolle bei der Verbesserung der Website-Performance, da er Ressourcen lokal speichert und dadurch Ladezeiten reduziert. Jedoch kann die strikte Kontrolle über den Browser-Cache nicht garantiert werden, da Browser wie Chrome und Firefox ihre eigenen Algorithmen verwenden, um zu entscheiden, welche Ressourcen im Cache gehalten werden. Während die .htaccess einige Kontrolle ermöglicht, ist es wichtig zu verstehen, dass die genaue Steuerung des Browser-Caches nicht immer so vorhersehbar ist, wie es wünschenswert wäre. Es ist ratsam, die Balance zu finden, indem man bestimmte Ressourcen mit geeigneten Cache-Header-Direktiven* ausstattet, um die Leistung zu verbessern, aber dabei auch die potenziellen Probleme und die Variationen im Browser-Verhalten zu berücksichtigen.

Der Browsercache ist etwas, was man nicht unbedingt immer so wie gewünscht behandeln lassen kann.

Quelle: Host-Support bplaced

Verschiedene Browser können unterschiedliche Caching-Algorithmen verwenden. Oft kann es vorkommen, dass selbst wenn bestimmte Cache-Header-Direktiven in der .htaccess-Datei festgelegt wurden oder auf Serverebene konfiguriert sind, der Browser dennoch einige Entscheidungen eigenständig trifft.

Caching auf Anwendungsebene: Manchmal implementieren Hosting-Plattformen oder Content-Management-Systeme (wie WordPress) automatisches Caching auf Anwendungsebene.

*Was sind Cache-Header-Direktiven?

Cache-Header-Direktiven sind Anweisungen, die in den HTTP-Headern einer Serverantwort enthalten sind und den Browsern und Zwischenspeicher-Systemen mitteilen, wie sie Ressourcen speichern und abrufen sollen. Diese Direktiven spielen eine entscheidende Rolle bei der Steuerung des Caching-Verhaltens und der Performance von Webseiten. Hier sind einige häufig verwendete Cache-Header-Direktiven:

  1. Cache-Control: Diese Direktive bietet eine breite Kontrolle über den Caching-Mechanismus. Einige häufige Werte sind:
    • public: Ressource kann von jedem gecacht werden.
    • private: Ressource sollte nur vom Browser gecacht werden, nicht von Zwischenspeichern auf dem Weg.
    • no-cache: Browser muss die Ressource validieren, bevor sie sie verwendet.
    • max-age: Legt fest, wie lange eine Ressource im Cache gültig ist, z. B. max-age=3600 für eine Stunde.
  2. Expires: Gibt ein konkretes Ablaufdatum und eine Uhrzeit an, bis zu der die Ressource gültig ist. Es wird häufig mit der max-age-Option in Cache-Control kombiniert.
  3. Last-Modified: Zeigt den Zeitpunkt der letzten Änderung der Ressource an. Wird verwendet, um zu überprüfen, ob die lokale Kopie im Cache mit der Server-Version übereinstimmt.
  4. ETag (Entity Tag): Ein eindeutiger Identifier für eine bestimmte Version einer Ressource. Wenn sich die Ressource ändert, ändert sich auch der ETag.
  5. If-None-Match: Wird vom Browser verwendet, um mit dem Server zu kommunizieren und zu prüfen, ob die Ressource seit dem letzten Abruf unverändert geblieben ist, basierend auf dem ETag.
  6. Vary: Definiert, unter welchen Bedingungen die zwischengespeicherten Kopien als gültig angesehen werden können. Zum Beispiel kann Vary: User-Agent bedeuten, dass verschiedene Versionen der Ressource für verschiedene Browser zwischengespeichert werden sollen.

Die Verwendung dieser Direktiven ermöglicht eine fein abgestimmte Steuerung darüber, wie Browser und Zwischenspeicher Ressourcen zwischenspeichern und aktualisieren sollen, um die Ladezeiten zu optimieren und den Datenverkehr zu minimieren.

Browser-Caching aktivieren, mit Vorbehalt

… denn das wird viele eher nur verwirren, da in dieser Sphäre nicht wirklich immer das passiert, was eigentlich hat passieren sollen. Folgendes ergibt sich aus den Weiten des Webs, wo Ideen und Konzepte sich entfalten.

Der Browser-Caching-Code sollte vor dem Abschnitt # BEGIN WordPress und vor der hier folgenden # Gzip-Komprimierung in die .htaccess-Datei eingefügt werden.

# Browser Caching aktivieren
<IfModule mod_expires.c>
    ExpiresActive on
  # CSS
    ExpiresByType text/css                              "access plus 1 year"
  # JavaScript
    ExpiresByType application/javascript                "access plus 1 year"
    ExpiresByType application/x-javascript              "access plus 1 year"
  # Manifest files
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"
  # Media
    ExpiresByType audio/mpeg                            "access plus 1 year"
	ExpiresByType audio/mp3                             "access plus 1 year"
    ExpiresByType audio/ogg                             "access plus 1 year"
    ExpiresByType image/gif                             "access plus 1 year"
    ExpiresByType image/jpg                             "access plus 1 year"
    ExpiresByType image/jpeg                            "access plus 1 year"
    ExpiresByType image/png                             "access plus 1 year"
    ExpiresByType image/svg                             "access plus 1 year"
    ExpiresByType image/svg+xml                         "access plus 1 year"
    ExpiresByType video/mp4                             "access plus 1 year"
    ExpiresByType video/ogg                             "access plus 1 year"
    ExpiresByType video/webm                            "access plus 1 year"
    ExpiresByType image/x-icon                          "access plus 1 year"
    ExpiresByType application/pdf                       "access plus 1 year"
    ExpiresByType application/x-shockwave-flash         "access plus 1 year"
  # XML
    ExpiresByType text/xml                              "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"
  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 year"
    ExpiresByType application/font-woff2                "access plus 1 year"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 year"
    ExpiresByType application/x-font-ttf                "access plus 1 year"
    ExpiresByType font/opentype                         "access plus 1 year"
</IfModule>
# END Browser Caching
Anpassungen im Browser-Caching-Code

Der Code ist ziemlich umfassend und deckt eine Vielzahl von Dateitypen ab. Er legt fest, wie lange bestimmte Arten von Ressourcen im Browsercache gespeichert werden sollen. Wenn bestimmte Anpassungen vorzunehmen sind, könnte die Ablaufzeit (die Zeitspanne, für die die Dateien im Cache bleiben) geändert oder weitere Dateitypen hinzufügt oder wegzunehmen sein, je nachdem, welche Dateien der Website verwendet werden.

Zum Beispiel könnte application/x-shockwave-flash entfernt werden. Das ist der MIME-Typ für Flash-Dateien. Früher wurden Flash-Dateien für Animationen, Videos und interaktive Inhalte auf Websites verwendet. Heutzutage wird Flash aufgrund von Sicherheitsproblemen und der Entwicklung modernerer Webtechnologien nicht mehr so häufig eingesetzt.

Browser-Cache, mit Vorbehalt! – denn graue Theorie

Gzip

Gzip, kurz für GNU Zip, und bezieht sich auf ein Verfahren zur Reduzierung der Dateigröße, das Teil des GNU-Projekts ist. Das wird in der Regel auf Webservern verwendet, um Webinhalte wie HTML-, CSS- oder JavaScript-Dateien zu komprimieren. Durch die Anwendung von Gzip werden diese Dateien komprimiert, was bedeutet, dass sie weniger Speicherplatz bedürfen und somit schneller über das Internet übertragen werden können. Dies trägt  zur Verbesserung der Ladezeiten von Webseiten bei, da weniger Daten übertragen werden müssen, was letztendlich die Effizienz der Website fördert.

Shared-Webhosting-Services und Gzip

Bei "Shared-Webhosting-Services" teilen mehrere Websites denselben Server und die damit verbundenen Ressourcen. Das bedeutet, dass die Konfigurationsoptionen, die für die Servereinstellungen sind, begrenzter sein könnten, da der derselbe Server mit anderen Nutzern geteilt wird.

In diesem Kontext kann es sein, dass einige fortgeschrittenen Konfigurationsoptionen, die bei dedizierten Servern oder VPS-Hostingplänen verfügbar sind, auf einem Shared-Hosting-Service möglicherweise nicht verfügbar sind oder eingeschränkt sind. Das bedeutet, dass du möglicherweise nicht die gleiche Kontrolle über die Serverkonfiguration hast.

Diese Option ist jedoch in der Regel bei den meisten Shared-Hosting-Plänen verfügbar. Im Beispiel des Hosts 'bplaced' ist dies von Haus aus inkludiert, wodurch zusätzliche Regeln in der .htaccess als rudimentär beziehungsweise überflüssig erscheinen.

Gzip-Komprimierung aktivieren

Der Code zur Aktivierung der Gzip-Komprimierung in der .htaccess-Datei verbessert die Übertragungsgeschwindigkeit der Website. Beachte jedoch, dass bestimmte Hosting-Anbieter möglicherweise bereits Gzip aktiviert haben oder gewisse Einschränkungen bezüglich der Konfiguration aufweisen könnten.

Der richtige Vorgang besteht darin, die # Gzip-Komprimierung vor dem Abschnitt # BEGIN WordPress und im Regelfall nach dem # Browser-Caching einzufügen. Dadurch werden die Serverkonfigurationen vor den WordPress-spezifischen Regeln angewendet.

# Gzip-Komprimierung aktivieren
<IfModule mod_deflate.c>
  # Komprimierung für Textdateien, einschließlich HTML, CSS, JavaScript, XML, JSON und TXT
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/json
  
  # Optionale Komprimierung für andere Dateitypen
  AddOutputFilterByType DEFLATE application/rss+xml application/xml image/svg+xml

  # Caching für Komprimierung
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
Effektives Gzip:
Grundlagen und erweiterte Konfigurationen im Überblick

Andere Gzip-Konfigurationen beinhalten oft spezifische MIME-Typen oder Dateierweiterungen. Diese Erweiterungen können effektiv sein, um die Komprimierung auf bestimmte Dateitypen zu beschränken oder auszuschließen. Wenn die Website bestimmte Arten von Inhalten bevorzugt oder aus spezifischen Gründen auf bestimmte Dateiformate beschränkt ist, kann das Hinzufügen von MIME-Typen oder Dateierweiterungen in die Gzip-Konfiguration sinNvoll sein. Dies bietet eine präzisere Kontrolle darüber, welche Ressourcen komprimiert oder ausgeschlossen werden sollen.

Es ist jedoch wichtig, diese erweiterten Konfigurationen mit Bedacht einzusetzen, da sie regelmäßige Wartung erfordern und die Komplexität der .htaccess-Datei erhöhen können. Die Standard-Konfiguration für die Gzip-Komprimierung, wie sie mit dem hier vorgeschlagenen Gzip implementiert wird, ist in den meisten Fällen bestens geeignet, um die Ladezeiten durch die Komprimierung der meisten Textdateien und Ressourcen zu optimieren.

Benchmark-Tests

In Benchmark-Tests können unterschiedliche Ergebnisse erzielt werden, da manche Test-Anbieter die Gzip zwar berücksichtigen, jedoch möglicherweise nicht korrekt anzeigen, ob sie aktiviert ist, während andere dies zeigen. Zum Beispiel auch der Maßstab zu den HTTP-Anfragen: Ein Tester zeigt gelegentlich an, dass weniger Abfragen besser wären, obwohl nur etwa 30 Abfragen erforderlich sind. Daher sollte man den Testergebnissen mit einem kritischen Blick begegnen.

Persistenz des Gzip-Codings:
Temporäre Speicherung trotz Entfernung aus .htaccess?

Im Benchmark-Test ist sofort deutlich, dass der Gzip-Code hinzugefügt wurde. Jedoch können die guten Testergebnisse bestehen, selbst nachdem der Gzip-Code aus der .htaccess entfernt wurde. Dies könnte auf serverseitiges Caching zurückzuführen sein, das die vorherige Gzip-Konfiguration eine Weile speichert. Möglicherweise führt diese temporäre Speicherung dazu, dass die Änderungen nicht sofort sichtbar sind, selbst nachdem der Code entfernt wurde.

Temporäre Beobachtung

Es wurde festgestellt, dass Gzip nicht funktionierte. Nach der Aktivierung des Plug-ins Query Monitor funktionierte es prompt und blieb auch nach der Deaktivierung des Query Monitor erhalten.

Mögliche Erklärung:

  • Die Aktivierung des Query Monitor könnte eine Art Cache oder Konfiguration auf Serverebene beeinflusst haben, was dazu führte, dass das Gzip-Modul ordnungsgemäß funktionierte.
  • Ein möglicher Grund könnte sein, dass das Query-Monitor-Plug-in einige Servereinstellungen temporär geändert hat und diese Änderungen auch nach der Deaktivierung des Plugins beibehalten wurden. – wie gesagt temporär.

Es ist nicht ungewöhnlich, dass solche Dinge in der Welt der Webentwicklung auftreten, und oft sind sie schwer vorhersehbar.

Quelle: ChatGPT

Es wäre ratsam, den Hosting-Anbieter zu kontaktieren, um genauere Informationen darüber zu erhalten, wie lange solche Caching-Mechanismen aktiv bleiben und wie sie sich auf Änderungen in der Serverkonfiguration auswirken können.


Technische Feinheiten der .htaccess

Die .htaccess-Datei spielt eine entscheidende Rolle in der Konfiguration von Apache-Servern, insbesondere für WordPress-Websites. Sie regelt nicht nur die URL-Struktur, sondern beeinflusst auch die Sicherheit und die Ladezeit der Webseite.

Es ist wichtig, die .htaccess-Datei so schlank wie möglich zu halten, um die Ladezeiten nicht unnötig zu erhöhen. In einigen Fällen kann es übertrieben sein, jedes einzelne Dateiformat explizit im Cache zu definieren. Manchmal ist es effizienter, die grundlegenden Dateiformate zu definieren und dann die allgemeinen Regeln für den Cache zu verwenden. Auf diese Weise wird das Laden der Seite optimiert, ohne die .htaccess-Datei mit zu vielen spezifischen Einträgen zu belasten.

Platzierung von Anpassungen: Die Reihenfolge und Platzierung von Codes in der .htaccess-Datei sind entscheidend für ihre Wirksamkeit. Allgemein sollten Regeln, Beispiels 'Image-Hotlinking' und andere spezifische Anpassungen, die auf die Anforderungen der Website zugeschnitten sind, normalerweise vor den und Gzip-Komprimierungs- und Browser-Cachingregeln platziert werden.

Image Hotlinking verbieten

'Image Hotlinking verbieten' bezieht sich auf eine Regel in der .htaccess-Datei, die verhindert, dass andere Websites direkt die Bilder und Grafiken von einer anderen Website einbinden. Das belastet Bandbreite und Serverressourcen der betreffenden Seite, ohne dass sie dafür die Erlaubnis haben oder die Seite angemessen creditieren. Durch das Blockieren des Hotlinkings können Serverressourcen geschützt und die Kontrolle darüber, wie deine Inhalte geteilt werden, bewahrt werden.

Beispiels 'Image Hotlinking verbieten' sind vor 'Browser-Cachingregeln' einzufügen:

# Image Hotlinking verbieten
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?deinedomain.at [NC]
RewriteRule \.(jpg|jpeg|png|gif|svg)$ [NC,R,L]

WP Super Cache

Das Plug-in WP Super Cache bietet unter "Erweitert" die Cache-Auslieferungsmethode 'Experte' an. Wenn diese Option ausgewählt wurde, müssen nach der Aktualisierung des Status die darunter befindlichen Regeln zur .htaccess hinzugefügt werden. Dies sollte idealerweise vor den Regeln von Gzip und Browsercaching geschehen. (Wir konnten dazu keinen positiven Effekt erzielen.)

Weiterleitungsregel

Hier wird die URL-Struktur für Weiterleitungen und Umleitungen festgelegt, um die Benutzerfreundlichkeit der Website zu verbessern und die SEO-Aspekte zu optimieren.

Eine Weiterleitungsregel in der .htaccess-Datei ist eine Anweisung, die den Server anweist, Anfragen von einer URL auf eine andere umzuleiten. Sie wird häufig verwendet, um Benutzer von einer alten URL auf eine neue umzuleiten, sei es aufgrund einer geänderten Seitenstruktur, einer Aktualisierung der Website oder aus anderen Gründen. Das ermöglicht es, den Traffic von einer URL auf eine andere umzuleiten, ohne dass Benutzer auf Fehlerseiten landen oder die SEO-Rankings beeinträchtigt werden.

Eine Weiterleitungsregel sollte vor dem Abschnitt # BEGIN WordPress in der .htaccess-Datei platziert werden, also hier den Beispielen ist das nach der Gzip-Komprimierung.

# Weiterleitungsregel
RewriteEngine On
RewriteRule ^wordpress-absichern/$ /wordpress-security-ninjafirewall/ [R=301,L]

Das mit (301) ist eine permanente Weiterleitung.

Schütze die .htaccess-Datei

Die .htaccess-Datei kann auch genutzt werden, um die Sicherheit der Website zu erhöhen, indem der Zugriff auf bestimmte Dateien oder Verzeichnisse beschränkt wird. Hierbei können etwaige Angriffe oder unerwünschte Zugriffe auf sensible Daten verhindert werden.

Für zusätzliche Sicherheitsebenen können spezifische Codes den Zugriff auf die .htaccess-Datei beschränken. Zum Beispiel:

# Schütze die .htaccess-Datei
<Files .htaccess>
    Require all denied
</Files>

Am besten ganz oben, damit er zuerst greift. Dies verhindert unbefugten Zugriff auf die Datei. Ein ähnlicher Code, der die Datei mit 'Deny from all' absichert, kann die Bearbeitung über FTP erschweren:

# Schütze die .htaccess-Datei
<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>

Besonders im Shared-Hosting-Umfeld ist vor der Implementierung solcher Maßnahmen eine Abstimmung mit dem Hosting-Anbieter ratsam. Sicherheitsvorkehrungen können manchmal die Bearbeitungsmöglichkeiten beeinträchtigen.

7G-Firewall

Zusätzlich könnte die Verwendung der 7G-Firewall hilfreich sein und sollte daher als erste Maßnahme vor dem oben genannten Code platziert werden. Diese Firewall wird regelmäßig aktualisiert, daher ist es ratsam, sie gelegentlich zu überprüfen und zu aktualisieren.

Bei Shared-Webhosting-Services wäre es ratsam, nachzufragen, ob die Anwendung der 7G-Firewall in der .htaccess möglicherweise redundant ist, da die Sicherheitsmaßnahmen möglicherweise bereits einen vergleichbaren oder sogar besseren Schutz bieten.

Share Webhosting und 7G-Firewall

Die Sicherheit beim Shared Webhosting wird in der Regel durch das vorhandene Know-how im Bereich Managed Services gewährleistet. Frage bezüglich der 7G-Firewall – die Antwort:

Tatsächlich ist eine userseitige Firewall in der .htaccess nicht notwendig und kann in ungünstigen Fällen sogar hinderlich sein. Etwa, wenn sich zwei Heuristiken gegenseitig stören.

Grundsätzlich sind unsere Standards sehr hoch, unsere Anforderungen an Sicherheitsmechanismen noch höher.

Quelle: Host-Support bplaced

Da wir unsere Server selbstverständlich bereits umfassend abschirmen – nicht nur gegen konventionelle Cyberangriffe, sondern auch gegen Flood- und DDoS-Attacken, Hacking-Algorithmen und ähnliche Bedrohungen –, ist zusätzlicher Schutz auf Serverebene rudimentär oder sogar hinderlich.



Weiteres zur .htaccess? – dann siehe .htaccess – Einführung


Schlussworte: Das Feintuning zur Performance erfordert möglicherweise etwas Zeit, aber die Resultate können sich definitiv lohnen. Verwende diese Optimierungswerkzeuge mit Bedacht, und vergiss nicht, Sicherungskopien anzulegen, bevor du Änderungen an der .htaccess vornimmst.

Eine gut optimierte Website sorgt nicht nur für schnellere Ladezeiten, sondern kann auch dazu beitragen, dass deine Inhalte von Suchmaschinen besser bewertet werden.

Hoffentlich bieten die besprochenen Techniken eine solide Grundlage, um deine Website zu optimieren und ihre Leistung zu steigern. Für weitere Fragen oder Unterstützung stehen Communitys und Online-Ressourcen gerne zur Verfügung.

Der Beitrag wurde mit fachlicher Unterstützung erstellt.