{"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":"Selbsthosting von Drittanbietern: 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 M\u00f6glichkeiten f\u00fcr das Self-Hosting oder das Proxieren von Drittressourcen an. Akamai erm\u00f6glicht es, spezifische Parameter<\/a><\/noindex> f\u00fcr selbst erstellte URLs festzulegen. Cloudflare verf\u00fcgt \u00fcber die Technologie Edge Workers. Fasterzine kann URLs auf Seiten umschreiben, sodass sie auf Drittressourcen auf der Hauptdomain der Website verweisen.<\/a><\/noindex> URLs auf den Seiten so gestalten, dass sie auf externe Ressourcen verweisen, die sich auf der Hauptdomain der Website befinden.<\/p>\n

\"Selbsthosting<\/a><\/noindex><\/p>\n

Wenn bekannt ist, dass die Drittservices, die in Ihrem Projekt verwendet werden, nicht allzu h\u00e4ufig ge\u00e4ndert werden, und dass der Auslieferungsprozess an Endkunden verbessert werden kann, denken Sie sicherlich \u00fcber das Proxieren solcher Services nach. Mit diesem Ansatz k\u00f6nnen Sie diese Ressourcen n\u00e4her an die Nutzer bringen und mehr Kontrolle \u00fcber ihr Caching auf der Clientseite erlangen. Dies sch\u00fctzt zudem die Nutzer vor Problemen, die durch den Ausfall eines Drittservices oder einer Verschlechterung seiner Leistung verursacht werden.
\n<\/a><\/noindex><\/p>\n

Gut: Leistungssteigerung<\/h2>\n

\nDie eigenst\u00e4ndige Bereitstellung externer Ressourcen verbessert die Leistung auf eine ganz offensichtliche Weise. Der Browser muss nicht unn\u00f6tig DNS-Anfragen stellen, keine TCP-Verbindungen aufbauen und kein TLS-Handshake auf einer externen Domain durchf\u00fchren. Wie sich die eigenst\u00e4ndige Bereitstellung externer Ressourcen auf die Leistung auswirkt, l\u00e4sst sich deutlich an den folgenden beiden Abbildungen erkennen.<\/p>\n

\"Selbsthosting
\nExterne Ressourcen werden aus externen Quellen geladen (entnommen hier herunter<\/a><\/noindex>)<\/i><\/p>\n

\"Selbsthosting
\nExterne Ressourcen werden dort gespeichert, wo auch die anderen Materialien der Website liegen (entnommen hier herunter<\/a><\/noindex>)<\/i><\/p>\n

Die Situation wird zus\u00e4tzlich verbessert, da der Browser die M\u00f6glichkeiten zur Multiplexierung und Priorisierung von Daten \u00fcber die bereits mit der Hauptdomain etablierte HTTP\/2-Verbindung nutzen kann.<\/p>\n

Wenn Sie keine externen Ressourcen hosten, k\u00f6nnen diese aufgrund der unterschiedlichen Domains nicht priorisiert werden. Dies f\u00fchrt dazu, dass sie um die Bandbreite des Kunden konkurrieren. Infolgedessen kann die Ladezeit f\u00fcr Seiteninhalte, die entscheidend f\u00fcr die Gestaltung der Seite sind, viel l\u00e4nger sein als bei optimalen Bedingungen. Hier<\/a><\/noindex> eine Pr\u00e4sentation \u00fcber die HTTP\/2-Priorisierung, in der dies ausf\u00fchrlich 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 hilfreich sein kann. Wenn jedoch zu viele solcher Links zu verschiedenen Domains vorhanden sind, kann dies tats\u00e4chlich die Verbindung zu einem kritischen Zeitpunkt \u00fcberlasten.<\/p>\n

Wenn Sie externe Ressourcen selbst hosten, k\u00f6nnen Sie kontrollieren, wie diese Ressourcen dem Kunden bereitgestellt werden. Insbesondere geht es um Folgendes:<\/p>\n