Funktioniert das Link-Prefetching über Subdomains hinweg?

10

Ich habe versucht, so etwas zu verwenden, um eine Leistungssteigerung zu erzielen, wenn ich von einer einfachen Zielseite zu einer schwergewichtigen Einzelseiten-App klicke:

<link rel="prefetch" href="https://example.com" as="document" />
<link rel="prefetch" href="https://example.com/app.js" as="script" />
<link rel="prefetch" href="https://example.com/app.css" as="style" />

Es scheint keine merkliche Leistungssteigerung zu geben, wenn sich meine Zielseite in einer Subdomain befindet. Sagen Sie , https://subdomain.example.com.

Wenn ich auf einen Link klicken Besuch https://example.com, ich sehe immer noch eine lange Verzögerung in der Registerkarte Chrome Netzwerk wie app.jsund app.csssind geladen:

Vorabgerufene Ressourcen Zeit für das Herunterladen von Ressourcen mit Prefetching

Hier ist dieselbe Ressource mit deaktiviertem Prefetching:

Zeit für das Herunterladen von Ressourcen ohne Vorabruf

Insgesamt dauert es ungefähr genauso lange.

Fordern Sie Header für eines der Assets an, die mit dem Prefetch-Cache geladen wurden:

Allgemeines:

Request URL: https://example.com/css/app.bffe365a.css
Request Method: GET
Status Code: 200  (from prefetch cache)
Remote Address: 13.226.219.19:443
Referrer Policy: no-referrer-when-downgrade

Antwort:

accept-ranges: bytes
cache-control: max-age=31536000
content-encoding: gzip
content-length: 39682
content-type: text/css
date: Mon, 06 Jan 2020 21:42:53 GMT
etag: "d6f5135674904979a2dfa9dab1d2c440"
last-modified: Mon, 06 Jan 2020 20:46:46 GMT
server: AmazonS3
status: 200
via: 1.1 example.cloudfront.net (CloudFront)
x-amz-cf-id: dO3yiCoPErExrE2BLYbUJaVye32FIJXXxMdI4neDGzGX9a6gcCDumg==
x-amz-cf-pop: LAX50-C1
x-amz-id-2: 1O0LmihxpHIywEaMQWX7G3FDAzxtH9tZq1T/jeVLMzifFSJSIIJSS6+175H61kKdAq6iEbwfs2I=
x-amz-request-id: AF35C178092B65D4
x-cache: Hit from cloudfront

Anfrage:

DNT: 1
Referer: https://example.com/auth/join
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Meine Frage lautet: Wenn Chrome angibt, dass der Prefetch-Cache verwendet wird, warum gibt es dann eine erhebliche Downloadzeit für Inhalte?

Es scheint, dass Chrome verschiedene Arten von Caches hat: Prefetch-Cache, Festplatten-Cache und Speicher-Cache. Der Festplatten-Cache und der Speicher-Cache sind sehr schnell (Ladezeiten von 5 ms und 0 ms). Allerdings ist der Prefetch-Cache mit 300 ms Download-Zeiten manchmal ziemlich nutzlos. Kann ich eine technische Erklärung bekommen, warum dies passiert? Ist es ein Fehler mit Chrome? Ich bin auf Chrome 79.0.3945.117.

html  link-prefetch 
— Maros
quelle
Prefetch wird verwendet, um zukünftige Navigationen zu beschleunigen. Eine kurze Erklärung finden Sie unter ( web.dev/link-prefetch )
— Mohammad Yaseer
Ja, Prefetch sollte zukünftige Navigationen beschleunigen. Warum hat es es dann in meinem Fall nicht beschleunigt? Siehe die Zeitdiagramme.
— Maros
Können Sie versuchen, den Inhalt der Subdomain auf einer anderen Domain zu platzieren und zu überprüfen, ob das Laden ebenfalls dieselbe Zeit in Anspruch nimmt? Sie scheinen gezeichnet zu haben, dass die Subdomain ein Problem sein könnte, ohne es zu zeigen, indem Sie zeigen, wie der Fall einer Nicht-Subdomain (dh einer anderen Domain) funktioniert. Wenn es sich bei der Subdomain um ein Problem handelt, besteht der nächste Schritt darin, zu untersuchen, ob eine Chrome-Konfigurationseinstellung zum Optimieren vorhanden ist, oder
— Martin
Oder werden in anderen Browsern mit ähnlichen Toolsets wie Firefox Inspector oder Opera dieselben Ladezeiten für Subdomain und / oder Indie-Domain angezeigt? Wenn das gleiche Timing-Problem bei anderen Browsern auftritt, die andere Engines verwenden (ich bin mir nicht sicher, welche dies tun und welche nicht mehr), kann es durchaus ein Fehler sein - ich kann davon ausgehen, dass es sich um einen Chrome-Fehler handelt wenn diese angegebenen Zeitwerte in anderen Browsern deutlich voneinander abweichen.
— Martin

Antworten:

0

Durch <link rel=prefetch>das Hinzufügen zu einer Webseite wird der Browser angewiesen, ganze Seiten oder einige der Ressourcen (wie Skripte oder CSS-Dateien) herunterzuladen, die der Benutzer möglicherweise in Zukunft benötigt. Dies kann Metriken wie First Contentful Paint und Time to Interactive verbessern und nachfolgende Navigationen häufig sofort laden.

Geben Sie hier die Bildbeschreibung ein

Der Prefetch-Hinweis verbraucht zusätzliche Bytes für Ressourcen, die nicht sofort benötigt werden. Daher muss diese Technik sorgfältig angewendet werden. Ressourcen nur vorab abrufen, wenn Sie sicher sind, dass Benutzer sie benötigen. Ziehen Sie in Betracht, nicht vorab abzurufen, wenn Benutzer langsame Verbindungen haben. Sie können dies mit der Netzwerkinformations-API erkennen.

Es gibt verschiedene Möglichkeiten, um zu bestimmen, welche Links vorab abgerufen werden sollen. Am einfachsten ist es, den ersten Link oder die ersten Links auf der aktuellen Seite vorab abzurufen. Es gibt auch Bibliotheken, die komplexere Ansätze verwenden, die später in diesem Beitrag erläutert werden: https://web.dev/link-prefetch/ .

— Mohammad Yaseer
quelle
Ich wollte eine Erklärung dafür bekommen, warum das Vorabrufen von Links die Dinge in meinem speziellen Fall nicht beschleunigt. Liegt es an Subdomains, Servicemitarbeitern oder etwas anderem? Wenn Sie sich meine Screenshots ansehen, können Sie sehen, dass der Browser den Inhalt trotz Vorabrufs erneut herunterlädt.
— Maros
0

Ich kann nur raten. Eine selbstbewusste Antwort kann wahrscheinlich nur von Ihnen durch Experimente gefunden werden. Es gibt zu viele Variablen, um sie zu berücksichtigen. Aber hier einige Ideen:

  1. prefetchist ein Hinweis für einen Browser. Der Browser kann dies aus beliebigen Gründen ignorieren. Darüber hinaus hat es die niedrigste Priorität.
  2. ZB für alle Fälle überprüfen Sie bitte Ihre Browsereinstellungen:
    Menu/Settings/Advanced/Privacy and security/Preload pages for faster browsing and searching
    (oder so ähnlich).
  3. Wenn Sie zufällig das mobile Internet nutzen, kann dies ebenfalls ein Problem sein.
    https://www.technipages.com/google-chrome-prefetch
  4. Wie schnell navigieren Sie von Ihrer Zielseite zur example.com?
  5. Überprüfen Sie Ihre Serverprotokolle, um festzustellen, ob jemals prefetchAnforderungen empfangen werden.

  6. Überprüfen Sie, ob Ihr Server als Antwort auf prefetchAnforderungen seltsame Header setzt . ZB Cache-Control: no-cache. Ja, ich sehe, dass Sie haben cache-control: max-age=31536000, also wäre es wirklich seltsam, wenn der Server unterschiedliche Header für dieselbe Anfrage senden würde ( na ja ... fast gleich , zumindest haben Sie nicht gesagt, dass dies der Fall ist, und zumindest können sie es einige Überschriften geben an, dass es sich um eine prefetchAnfrage handelt), aber es passieren seltsame Dinge.

  7. Sie sollten wahrscheinlich versuchen, ein crossoriginAttribut hinzuzufügen . Z.B

    <link rel="prefetch" href="https://example.com/app.css" as="style" crossorigin />

    Hier https://www.w3.org/TR/resource-hints/ finden Sie dieses Beispiel

    <link rel="preconnect" href="//example.com">
<link rel="preconnect" href="//cdn.example.com" crossorigin>

    ziemlich relevant für Ihren Fall, aber leider ohne Erklärung.

  8. In der Originalversion Ihrer Frage haben Sie Servicemitarbeiter erwähnt ... Wenn sie etwas herunterladen oder sogar selbst etwas manuell herunterladen, kann dies ebenfalls das Problem sein. Wegen der niedrigsten Priorität vonprefetch

    https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ#What_if_I.27m_downloading_something_in_the_background.3F_Will_link_prefetching_compete_for_bandwidth.3F

    Wenn Sie etwas mit Mozilla herunterladen, wird das Vorabrufen von Links verzögert, bis alle Hintergrunddownloads abgeschlossen sind

    Ich denke, dasselbe gilt für Chrome.

  9. Haben Sie versucht, Ihre Zielseite in die Stammdomäne zu verschieben? Wenn ja, und prefetchwie erwartet funktioniert, ist die Subdomain yes die Ursache des Problems. Und die GUI-Nachricht Status Code: 200 (from prefetch cache)ist wahrscheinlich nur eine Panne. Denn erst kürzlich haben sich einige Dinge im prefetchVerhalten von Chrome geändert . Und ich weiß noch nicht, ob sich die Dinge beruhigt haben. Grundsätzlich besteht ja eine gewisse Wahrscheinlichkeit, dass Sie prefetchnur aus derselben Herkunft stammen können.

    https://docs.google.com/document/d/1bKGDIePAuF6YXmmrwM33LeLvtuCsla3vTspsxsNp-f8/edit

— x00
quelle
Einige zufällige Notizen nach dem Lesen Ihrer Antwort: Ich navigiere sehr langsam von der Zielseite zu example.com, sodass alle Ressourcen genügend Zeit zum Laden haben. Ich habe die obigen Tests mit in Chrome deaktivierten Servicemitarbeitern durchgeführt. Ich denke, das Crossorigin-Attribut ist für etwas anderes. Ich habe es versucht und kein Glück. Im schlimmsten Fall werde ich die von Ihnen vorgeschlagenen Tests durchführen, indem ich die Zielseite in die Stammdomäne verschiebe. Ich hatte gehofft, eine Antwort hier würde mir die Arbeit ersparen.
— Maros
1
Hast du FF ausprobiert? Über den obigen MDN-Link: "Wird Mozilla Dokumente von einem anderen Host vorab abrufen? Ja. Es gibt keine Einschränkung für das Vorabrufen von Links mit demselben Ursprung. Die Beschränkung des Vorabrufs auf nur URLs vom selben Server bietet keine erhöhte Browsersicherheit." Diese Passage kann veraltet sein, aber immer noch. Es ist gut zu wissen, ob sie sich in ihrem Verhalten mit Chrome unterscheiden.
— x00
Ich habe es versucht, konnte aber keine Servicemitarbeiter deaktivieren, die anscheinend Vorrang vor dem Prefetch-Cache hatten. Ich kann es aber noch einmal versuchen.
— Maros
@ Maros, irgendwie besitzt du den Code nicht oder es gab ein technisches Problem?
— x00
-1

Sie sollten den folgenden Code hinzufügen, falls Sie sich in einer Subdomain befinden und Ressourcen von der Domain möchten

<link rel="preconnect" href="https://example.com">
— divyang4481
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.