Verwenden von Wildcard-Domänen zum Bereitstellen von Bildern ohne HTTP-Blockierung

Verwenden von Wildcard-Domänen zum Bereitstellen von Bildern ohne HTTP-Blockierung

Ich habe gelesen, dass Browser manchmal blockieren, wenn sie auf mehrere Bilder vom selben Host warten, und ich versuche alles, was ich kann, um die Seitenladezeiten zu beschleunigen.

Eine Einschränkung: Ich muss Dateien über HTTPS bereitstellen.

Irgendwelche Meinungen darüber, ob dies machbar ist:

  1. Richten Sie ein Wildcard-Zertifikat für *.domain.com ein.
  2. Wenn ich ein Bild brauche, erzeuge ich eine Nummer basierend auf einem Hash Mod 5 des Dateinamens und hänge sie an eine „img“-Subdomäne an (z. B. img1.domain.com, img4.domain.com, img3.domain.com usw.); der Hash sorgt dafür, dass jeder Dateiname immer dieselbe Subdomäne verwendet, und daher sollte der Browser in der Lage sein, die Bilder zwischenzuspeichern
  3. Konfigurieren Sie einen dynamischen Virtualhost-Eintrag, um alle img#.-Subdomains auf /var/www/img zu verweisen.

Ich bin auf der Suche nach Feedback zu diesem Plan. Meine Bedenken sind:

  1. Bekomme ich Warnungen, wenn meine Seite https://-Links zu mehreren Subdomains enthält?
  2. Ist der dynamische Virtualhost-Eintrag, von dem ich spreche, überhaupt möglich?
  3. Wenn man bedenkt, wie viel Verarbeitungsaufwand das erfordert, stellt sich die Frage, ob es überhaupt einen Gesamtvorteil bringt? Ich verwende wahrscheinlich durchschnittlich ein halbes Dutzend Bilder pro Seite, wobei bei jedem Seiten-Update nur die Hälfte geändert wird.

Vielen Dank im Voraus für Ihr Feedback.

Antwort1

Ihr Schema ist möglich, wenn Sie einen Wildcard-DNS-Eintrag haben, der auf Ihren Webserver verweist und so konfiguriert ist, dass er auf allen möglichen Hosts antwortet, und wenn Sie ein Wildcard-SSL-Zertifikat haben. Ich sehe jedoch ein paar Probleme:

  1. Indem Sie jedes Bild auf einen anderen Hostnamen setzen, erhöhen Sie die Anzahl der DNS-Lookups, die zum Laden der Seite erforderlich sind.
  2. Indem Sie sie auf unterschiedliche Hostnamen setzen, verhindern Sie, dass der Browser eine bestehende TCP-Verbindung für mehrere Bilder wiederverwenden kann. Das Herstellen von TCP-Verbindungen ist „teuer“ und es muss jetzt für JEDES Bild eine Verbindung hergestellt werden, anstatt der wenigen, die hergestellt und wiederverwendet würden, wenn die Bilder unter demselben Hostnamen wären.

Im Allgemeinen gelten für Service-Bilder die folgenden bewährten Vorgehensweisen:

  1. Laden Sie Bilder von einem anderen Hostnamen als der Hauptdomäne, beschränken Sie sie jedoch auf einen oder zwei andere Hostnamen (aus den oben genannten Gründen).
  2. Stellen Sie sicher, dass auf diesen Hostnamen keine Cookies verwendet werden (so muss der Browser die Cookies nicht mehr zusammen mit der Anfrage senden).
  3. Stellen Sie sicher, dass für die über diese Hostnamen bereitgestellten Inhalte die Zwischenspeicherung aktiviert ist (gilt jedoch im Allgemeinen nicht für SSL).
  4. Kombinieren Sie Bilder und verwenden Sie, wenn möglich, CSS-Sprites.
  5. Viele andere, denen es gut gingdokumentiert anderswo.

Antwort2

  1. Nein, wenn alles SSL und ein gültiges Zertifikat ist, treten keine Probleme auf.
  2. Ja, zumindest in Apache ist es so trivial wie das Setzen einer einzelnen ZeileServerAlias *.domain.com
  3. Im aktuellen Zustand nicht wirklich.

Eine passendere Lösung:

Verwenden Sie einen leichtgewichtigen Server (z. B. lighttpd) unter einer anderen Domäne ohne geladene schwere Module (leichtgewichtige Prozesse) und verwenden Sie nur einen pro Server mit den entsprechenden Einstellungen. Oder noch besser: Verwenden Sie nginx als Server, da dies Folgendes bewirkt:

  1. Es sind keine anderen Domänen/Ports/Zertifikate erforderlich.
  2. nginx stellt den statischen Inhalt bereit und fungiert als Reverse-Proxy-Server für die „dynamischen“ Anfragen an Ihren ursprünglichen, leistungsstärkeren Server, der entweder lokal auf einem anderen Port/einer anderen IP-Adresse eines möglicherweise anderen Servers Ihrer Wahl läuft.
  3. Legen Sie in Nginx die entsprechenden Einstellungen fest (z. B. Keepalive, Worker usw.).
  4. hat kein Problem mit der Bereitstellung von HTTPS

verwandte Informationen