Werbung

Der Classic-Editor: Vertraut und zuverlässig –
Ihr bewährter Begleiter.

Viele Nutzer schätzen die vertraute Umgebung des Classic-Editors, die eine einfache und schnelle Bearbeitung ermöglicht.

---

Werbung

Mit dem Advanced Editor Tools auf das nächste Level –
Mehr Funktionen, mehr Möglichkeiten.

Der Advanced Editor erweitert den Funktionsumfang des Classic-Editors und ermöglicht es, Inhalte noch effektiver zu bearbeiten.

---

Werbung

Einfach und intuitiv –
Der Classic-Editor für alle.

Der Classic-Editor zeichnet sich durch Stabilität und Zuverlässigkeit aus, was für professionellen Anwender von Bedeutung ist.

---

Werbung

Mehr schaffen in weniger Zeit –
Der Advanced Editor für kreative Köpfe.

Mit dem Advanced Editor können Designer und
Content Creatoren kreative Ideen umsetzten.

---

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 https://www.apache.org/

"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.

• Webserver/htaccess (selfhtml)

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:

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.

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. 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.
3. ETag (Entity Tag): Ein eindeutiger Identifier für eine bestimmte Version einer Ressource. Wenn sich die Ressource ändert, ändert sich auch der ETag.
4. 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.
5. 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.
   • Das Header append Vary "User-Agent" wird am Ende hinzugefügt, damit es nach den ExpiresByType-Direktiven kommt, die die Ablaufdaten für die verschiedenen Dateitypen festlegen. Das Header wird als Teil des Apache-Moduls mod_expires verwendet, das die Funktionalität bietet, die Ablaufdaten für zwischengespeicherte Dateien festzulegen.

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.

Dirktive public

Die Direktive public in Cache-Control gibt an, dass die Ressource von jedem Cache (einschließlich Proxy-Caches) gespeichert werden kann. Selbst wenn FileETag MTime Size verwendet wird, um folgend den ETag basierend auf der Dateiänderungszeit (MTime) und der Dateigröße (Size) zu generieren, kann ein Proxy-Cache immer noch von der public-Direktive profitieren.

Dies liegt daran, dass FileETag MTime Size lediglich die Erstellung des ETag-Headers beeinflusst, während Cache-Control: public die Proxy-Caches anweist, die Ressource zu speichern und sie anderen Benutzern zur Verfügung zu stellen. Dies ist besonders nützlich in Umgebungen, in denen eine Vielzahl von Benutzern oder Clients dieselben Ressourcen abrufen und der Einsatz von Proxy-Caches die Netzwerklast reduzieren kann.

Daher ergänzen sich FileETag MTime Size und Cache-Control: public gut und können zusammen verwendet werden, um die Leistung und Effizienz des Cachings zu verbessern.

Direktive private

Die Cache-Control-Direktive private gibt an, dass die Ressource nur vom Browser des Endbenutzers zwischengespeichert werden sollte und nicht von Zwischenspeichern auf dem Weg, wie beispielsweise Proxy-Servern oder CDN (Content Delivery Networks).

Wenn eine Ressource als private gekennzeichnet ist, bedeutet dies, dass der Browser die Ressource zwischenspeichern kann, um die Ladezeit zu verbessern und die Netzwerkbandbreite zu sparen. Dies ist besonders nützlich für Ressourcen, die spezifisch für den Benutzer sind und nicht für andere Benutzer oder öffentliche Zwischenspeicher geeignet sind.

Ein typisches Szenario für die Verwendung von private ist, wenn eine Ressource personalisierte Daten oder vertrauliche Informationen enthält, die nur für den jeweiligen Benutzer bestimmt sind. Indem die Ressource als private gekennzeichnet wird, wird sichergestellt, dass diese Daten nicht von anderen Benutzern oder Zwischenspeichern im Netzwerk zwischengespeichert werden.

In der Konfiguration des Browser-Caching auf einem Apache-Webserver könnten Sie die private-Direktive wie folgt verwenden:

Header set Cache-Control "private, max-age=3600"

Direktive no-cache und max-age

Die Direktive no-cache in der Cache-Control-Headerfeld bedeutet, dass der Browser die Ressource vor der Verwendung validieren muss, was bedeutet, dass er den Server bitten muss, zu überprüfen, ob die Ressource geändert wurde, bevor er sie aus dem Cache verwendet. Anders ausgedrückt, der Browser darf die Ressource im Cache speichern, aber er muss jedes Mal, wenn er sie abruft, den Server überprüfen, um sicherzustellen, dass er die aktuellste Version hat.

Die Verwendung von no-cache ist daher sinnvoll für Ressourcen, die sich häufig ändern und immer die aktuellste Version benötigen, wie z.B. dynamisch generierte Inhalte oder Inhalte, die auf Benutzeranforderungen basieren, Echtzeitdaten, Chat-Nachrichten, oder personalisierte Inhalte.

Für statische Ressourcen, die selten geändert werden und für die eine Zwischenspeicherung im Browser vorteilhaft ist, würde man normalerweise max-age verwenden, um anzugeben, wie lange die Ressource im Cache gültig ist.

In vielen Fällen wird empfohlen, sowohl no-cache als auch max-age zu verwenden, um sicherzustellen, dass der Browser die Ressource vor der Verwendung überprüft, aber dennoch eine maximale Cache-Dauer festlegt, um die Netzwerkbelastung zu reduzieren und die Ladezeiten zu verbessern.

# Cache-Control hinzufügen
    Header set Cache-Control "public, max-age=3600, no-cache"

Dies bietet eine gute Balance zwischen Aktualität und Effizienz des Cachings.

Insgesamt hängt die Wahl zwischen no-cache und einer festgelegten Cache-Dauer davon ab, welche Art von Inhalt du hast und wie wichtig es für dich ist, sicherzustellen, dass der Browser immer die aktuellste Version erhält.

Expires-Header vs.max-age?

Vergleich von Expires-Header und Cache-Control mit max-age.

Cache-Control mit max-age ist heutzutage eine bevorzugte Methode ist, um die Gültigkeitsdauer von Ressourcen im Browser-Cache anzugeben. max-age ist eine direktere und modernere Methode, um die Gültigkeitsdauer einer Ressource im Cache des Browsers anzugeben. Expires hingegen ist älter und funktioniert, indem ein spezifisches Ablaufdatum und eine Uhrzeit angegeben werden.

Browser-Caching aktivieren

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
    # Setzen Sie das Vary-Headerfeld
    Header append Vary "User-Agent"

    # Last-Modified und ETag aktivieren
    FileETag MTime Size
    Header unset ETag
    Header set Last-Modified "Tue, 1 Jan 2000 00:00:00 GMT"

    # If-None-Match verwenden
    RewriteEngine On
    RewriteCond %{HTTP:If-None-Match} !^$
    RewriteCond %{HTTP:If-None-Match} !^(.*)$ [NC]
    RewriteRule .* - [E=HTTP_IF_NONE_MATCH:1]

    # Cache-Control hinzufügen (1 Stunde in Sekunden)
    Header set Cache-Control "public, max-age=3600"

    # Pseudo Expires-Header zum Testen hinzufügen (setzt das Ablaufdatum auf eine Woche in der Zukunft)
    #Header set Expires "Thu, 31 Dec 2099 23:59:59 GMT"
</IfModule>
# END Browser Caching

1. ExpiresActive on: Aktiviert die Verwendung des Expires-Headers, um die Gültigkeitsdauer von zwischengespeicherten Ressourcen anzugeben.
2. Header append Vary "User-Agent": Fügt dem Vary-Headerfeld den Wert "User-Agent" hinzu, um sicherzustellen, dass verschiedene Versionen der Ressource für verschiedene Browser zwischengespeichert werden.
3. FileETag MTime Size: Aktiviert die Verwendung von Last-Modified und ETag für die Zwischenspeicherungskontrolle.
4. Header unset ETag: Deaktiviert den ETag-Header, um sicherzustellen, dass der Browser Last-Modified als Methode zur Überprüfung des Cache-Standards verwendet.
5. Header set Last-Modified "Tue, 1 Jan 2000 00:00:00 GMT": Setzt den Last-Modified-Header auf einen festen Wert, um sicherzustellen, dass Ressourcen immer als modifiziert angesehen werden.
6. Rewrite-Regeln für If-None-Match: Überprüft, ob der Browser bereits eine Kopie der Ressource zwischengespeichert hat und ob diese Kopie mit der aktuellen Version übereinstimmt. Wenn nicht, wird die Ressource erneut heruntergeladen.
7. Header set Cache-Control "public, max-age=3600": Setzt den Cache-Control-Header, um anzugeben, dass die Ressource öffentlich zwischengespeichert werden kann und für eine Stunde gültig ist.
8. (Auskommentiert) Header set Expires "Thu, 31 Dec 2099 23:59:59 GMT": Ein pseudoExpires-Header, der das Ablaufdatum auf eine Woche in der Zukunft setzt. Diese Zeile ist für Testzwecke auskommentiert und kann bei Bedarf aktiviert werden, um die Anforderungen einiger Testtools zu erfüllen.

Insgesamt bieten diese Regeln eine solide Grundlage für das effektive Browser-Caching von Ressourcen auf deinem Apache-Webserver.

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>

Die vorgeschlagenen Gzip-Komprimierungsregeln sind modern und zeitgemäß. Sie verwenden das Apache-Modul mod_deflate, um Textdateien wie HTML, CSS, JavaScript, XML, JSON und TXT zu komprimieren, was die Übertragungsgröße reduziert und die Ladezeiten der Webseite verbessert.

Die Regeln sind auch flexibel und berücksichtigen verschiedene Browser. Zum Beispiel werden ältere Versionen von Mozilla und Internet Explorer spezifisch behandelt, um Probleme mit der Komprimierung zu vermeiden.

Insgesamt sind diese Regeln eine gute Praxis, um die Leistung deiner Website zu verbessern und sollten in den meisten modernen Webserver-Konfigurationen effektiv funktionieren.

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.

• Erfahre außerdem alles Wissenswerte über WP-Caching in unserem Artikel WP: Caching unter der Lupe.

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.

Wartungsmodus mit .htaccess steuern

Hierzu leiten wir zum Aritkel:

Wartungsmodus in WordPress mit .htaccess steuern

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 Hotlinking von Bildern stellt nicht immer ein großes Problem dar und viele seriöse Websites lassen es zu, dass ihre Bilder von anderen Websites eingebunden werden. Einige Websites betrachten es sogar als eine Möglichkeit, ihre Reichweite zu erhöhen und ihre Inhalte zu teilen.

Es ist jedoch auch wichtig anzumerken, dass Hotlinking in einigen Fällen zu einem Missbrauch der Ressourcen führen kann, insbesondere wenn eine beträchtliche Menge an Bandbreite für das Anzeigen von Bildern auf anderen Websites verwendet wird, ohne dass die entsprechende Website dafür angemessen anerkannt wird.

Die Entscheidung, Hotlinking zu verbieten, hängt von den individuellen Bedürfnissen und Prioritäten der Website-Betreiber ab. Einige möchten möglicherweise die Kontrolle über ihre Ressourcen behalten und sicherstellen, dass sie angemessen anerkannt werden, während andere dies möglicherweise nicht als problematisch erachten.

Insgesamt ist es wichtig, eine ausgewogene Herangehensweise zu wählen und die Vor- und Nachteile des Verbietens von Hotlinking sorgfältig abzuwägen, um sicherzustellen, dass die Entscheidung den Zielen und Bedürfnissen der jeweiligen Website entspricht.

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]

Obwohl Hotlinking technisch gesehen als Verweis auf deine Website angesehen werden kann, ist es nicht dasselbe wie ein traditioneller Backlink. In der Regel hat das keine positive Auswirkung auf das SEO-Ranking, da es normalerweise nicht von Suchmaschinen wie Google als qualitativ hochwertiger Verweis angesehen wird.

Siehe zum Beitrag Die Bedeutung von Backlinks für SEO und der Umgang mit Pingbacks. Dies könnte auch dabei helfen, Hotlinking-Verhalten zu erkennen und entsprechende Maßnahmen zu ergreifen, falls erforderlich. 😉

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.

Unsere Frage an den Host 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 Absicherung der Website im Beitrag Security! – NinjaFirewall WP.

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.

Aktualisiert im Jahr 2024 Oktober