{"id":54566,"date":"2019-12-29T00:00:00","date_gmt":"2019-12-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj"},"modified":"2020-02-18T14:02:35","modified_gmt":"2020-02-18T11:02:35","slug":"samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","title":{"rendered":"Selbstst\u00e4ndiges Hosting von Drittressourcen: gut, schlecht, b\u00f6se","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In den letzten Jahren bieten immer mehr Plattformen zur Optimierung von Frontend-Projekten die M\u00f6glichkeit, Ressourcen selbst zu hosten oder externe Ressourcen zu proxyen. Akamai erm\u00f6glicht es, spezifische Parameter<\/a><\/noindex> f\u00fcr selbst erstellte URLs festzulegen. Cloudflare hat die Technologie Edge Workers. Fasterzine kann URLs umschreiben,<\/a><\/noindex> sodass sie auf externe Ressourcen verweisen, die sich auf der Hauptdomain der Website befinden.<\/p>\n

\"Selbstst\u00e4ndiges<\/a><\/noindex><\/p>\n

Wenn bekannt ist, dass die externen Dienste, die in Ihrem Projekt verwendet werden, nicht allzu h\u00e4ufig ge\u00e4ndert werden, und der Prozess ihrer Bereitstellung f\u00fcr die Kunden verbessert werden kann, denken Sie sicherlich \u00fcber das Proxying solcher Dienste nach. Bei diesem Ansatz k\u00f6nnen Sie diese Ressourcen ``n\u00e4her'' zu den Benutzern bringen und eine umfassendere Kontrolle \u00fcber deren Caching auf der Client-Seite erlangen. Dies sch\u00fctzt zudem die Nutzer vor Problemen, die durch das ``Ausfallen'' eines externen Dienstes oder eine Verschlechterung seiner Leistungsf\u00e4higkeit verursacht werden k\u00f6nnten.
\n<\/a><\/noindex><\/p>\n

Gut: Leistungssteigerung<\/h2>\n

\nDas selbstst\u00e4ndige Hosting externer Ressourcen verbessert die Leistung auf recht offensichtliche Weise. Der Browser muss nicht erneut auf DNS zugreifen, muss keine TCP-Verbindung herstellen und kein TLS-Handshake auf einer externen Domain durchf\u00fchren. Wie sich das selbstst\u00e4ndige Hosting externer Ressourcen auf die Leistung auswirkt, kann man sehen, indem man die folgenden zwei Abbildungen vergleicht.<\/p>\n

\"Selbstst\u00e4ndiges
\nExterne Ressourcen werden aus externen Quellen geladen (genommen von hier<\/a><\/noindex>)<\/i><\/p>\n

\"Selbstst\u00e4ndiges
\nExterne Ressourcen werden dort gespeichert, wo auch die anderen Materialien der Website sind (genommen von hier<\/a><\/noindex>)<\/i><\/p>\n

Die Situation wird zus\u00e4tzlich verbessert, da der Browser die M\u00f6glichkeiten zur Multiplexierung und Priorisierung von HTTP\/2-Datenverbindungen nutzt, die bereits mit der Hauptdomain hergestellt wurden.<\/p>\n

Wenn Sie externe Ressourcen nicht selbst hosten, k\u00f6nnen diese nicht priorisiert werden, da sie von einer Domain geladen werden, die sich von der Hauptdomain unterscheidet. Dies wird dazu f\u00fchren, dass sie gegeneinander um die Bandbreite des Clients konkurrieren. Dies kann dazu f\u00fchren, dass die Ladezeiten von f\u00fcr die Seitenbildung kritischen Materialien wesentlich l\u00e4nger sind als in einem idealen Fall. Hier<\/a><\/noindex> eine Pr\u00e4sentation zur HTTP\/2-Priorisierung, in der all dies sehr gut erkl\u00e4rt wird.<\/p>\n

Es kann angenommen werden, dass die Verwendung von Attributen in Links zu externen Ressourcen preconnect<\/code> bei der L\u00f6sung des Problems helfen wird. Wenn es jedoch zu viele solcher Links zu unterschiedlichen Domains gibt, kann dies tats\u00e4chlich die Verbindung in einem entscheidenden Moment \u00fcberlasten.<\/p>\n

Wenn man externe Ressourcen selbst hostet, kann man kontrollieren, wie diese Ressourcen dem Client bereitgestellt werden. Konkret geht es um Folgendes:<\/p>\n