Startpagina » Coding » Hoe de website te versnellen met de tag

    Hoe de website te versnellen met de tag

    "voorziende"browsers zijn de toekomst van internet surfen op topsnelheid, ons middelen brengen die we willen nog voordat we weten dat we ze willen hebben. De browsers van vandaag al maken sommige voorspellingen zo nu en dan om het ophalen en weergeven van documenten te versnellen. Om dit naar de volgende stap te brengen, kijken we naar niemand anders dan webontwikkelaars.

    Ontwikkelaars hebben een best goed idee van hoe hun websites worden genavigeerd, en welke middelen worden het vaakst aangevraagd en dus kunnen ze bepaalde toekomstige bewerkingen voorspellen die browsers voor sites zouden moeten doen. Het enige dat nu nodig is, is dat ontwikkelaars een manier vinden om dit te doen relais deze voorspellingen naar browsers en ze goed gebruiken. Dit is waar sommige speciale "HTML-links" binnenkomen.

    Een opfrissing van HTTP-verzoeken

    Voordat we deze links bekijken, is het tijd om ons geheugen op te frissen over hoe een typische HTTP-aangevraagde bewerking voor het ophalen van bestanden plaatsvindt. Laten we zeggen dat iemand met de naam Joe een website wil bezoeken.

    Dit is wat er hierna gebeurt:

    1. Joe typt het menselijk herleidbare adres van de website in de adresbalk van een browser en drukt op "Enter".
    2. Zodra het dit adres heeft ontvangen, vraagt ​​de browser een DNS-server (complimenten van ISP) voor het IP-adres van het adres dat door Joe is opgegeven.
    3. De DNS-server verplicht.
    4. Nu de browser het IP-adres kent, verzendt het een bericht (in TCP-dialect) naar de server van de website om om een ​​verbinding te vragen.
    5. Als de server springlevend is, stuurt deze een antwoord waarin de aanvraag van de browser wordt bevestigd en de browser antwoordt en bevestigt het bericht van de server. (Notitie: Ja, dit is een extreem verwaterde versie van een TCP-handshake tussen een client en een server.)
    6. Wanneer de handdrukken voorbij zijn, wordt een verbinding tot stand gebracht tussen de twee.
    7. Nu verandert de browser de dialectstijl in HTTP en vraagt ​​de server naar de website.
    8. De server, die de homepage van de website kent, komt precies dat terug, die door de browser wordt ontvangen en wordt getoond aan Joe die heel geduldig wacht voor de computer.

    Een typisch HTTP-verzoek gaat door allemaal dat (en meer) om een ​​document op te halen via internet. Dus als een van deze processen kan zo mogelijk worden gestart met jumpstart, we kunnen verminderen van de tijd die we hebben om te wachten op de levering van de middelen die we willen.

    HTML-linkrelaties

    W3C specificeert 4 HTML-linkrelaties (rel voor relatie) genoemd dns-prefetch, preconnect, prefetch, en prerender. Samen worden ze (door W3C) de "HulpbronnenNu, we zullen zien wat ze kunnen doen en waar ze kunnen worden gebruikt.

    1. DNS Prefetch

    In DNS prefetch, de domeinnaam resolutie (ook bekend als het krijgen van het overeenkomende IP-adres van de DNS-server) is van tevoren gedaan.

    Laten we zeggen dat er een referentiepagina op een website staat met veel verwijzingslinks naar zijn zustersite. Wanneer een gebruiker de referentiepagina bezoekt, is er een grote kans dat de gebruiker naar de zustersite zal navigeren. Dus, een vroege DNS-lookup want de zustersite kan de tijd die nodig is om de site te openen verminderen (waardoor de gebruikerservaring verbetert).

    Deze vertragingsreductie via DNS-prefetching kan gedaan worden door deze code toe te voegen aan de referentiepagina.

     

    Wanneer een browser deze code verwerkt in de referentiepagina, voegt het de DNS-lookup van de zustersite toe aan zijn taakwachtrijen en wanneer het vrij is van andere taken met hoge prioriteit in de wachtrij, start het de DNS-resolutie van de zustersite.

    Dus wanneer een gebruiker uiteindelijk op een van de koppelingen klikt die hem naar de zustersite brengt, is de DNS-resolutie van die site mogelijk al voltooid en kan de browser meteen beginnen met het tot stand brengen van de client-server TCP-verbinding met de zustersite. server, waardoor die pagina sneller laadt.

    Deze functie is beschikbaar in vrijwel alle moderne browsers behalve Safari vanaf maart 2016.

    2. Preconnect

    Preconnect is een stap verder dan DNS prefetch, het brengt een verbinding tot stand met de server waarnaar later in de toekomst een verzoek kan worden verzonden.

    W3C somt een ideale use-case op voor preconnect: redirects. Ontwikkelaars gebruiken omleidingen om een ​​aantal redenen.

    In dit geval is het volgende verzoek van een browser (omgeleide site) 100% voorspelbaar, en kan vooraf zijn verbonden met, naar de latentie van de navigatie verminderen.

    Stel je voor dat er een tussenliggende sitepagina is die omleidt naar "xyzsite", zal de volgende HTML-link ervoor zorgen dat de browser een preconnect maakt met de xyzsite-server, wanneer deze die intermediaire pagina bereikt.

     

    Vanaf maart 2016 is dit beschikbaar in Chrome, Opera en Firefox.

    3. Prefetchen

    Met prefetch, voor een bron, de browser begint met de implementatie van de DNS-resolutie van de domeinnaam van de resource, dan voert een TCP-verbinding uit met de server van de bron, maakt het HTTP-verzoek en tot slot haalt de vooraf opgehaalde bron op en slaat deze op in de browsercache.

    Als u zeker weet welke bronnen later nodig zijn, is dat de resource die vooraf moet worden opgehaald; daarin ligt de vangst. Prefetching vereist giswerk, en als u verkeerd raadt, zou u zelfs kunnen vertragen in plaats van uw site te versnellen.

    Voor online boeken, galerijen of portfolio's, als de gebruiker hoogstwaarschijnlijk naar de volgende pagina bladert, prefetching de bronnen zoals afbeeldingen, kan dingen aanzienlijk versnellen. Hier is de code om dat te doen.

     

    Prefetch wordt ondersteund in Chrome, Firefox en Opera.

    4. Prerender

    Alleen voor HTML-pagina's kan prerendering worden gedaan. Een HTML-pagina met voorvertoning is offline weergegeven, en wordt op het scherm geverfd wanneer het daadwerkelijk door de gebruiker nodig is. rendering kost een hoger rekenwerk en geheugenresource; plus, om een ​​pagina weer te geven, heeft de browser mogelijk extra bronnen nodig (zoals afbeeldingen die aan de pagina zijn toegevoegd) die ertoe zullen leiden meer consequente verzoeken per browser.

    Zo, prerender moet zijn voorzichtig gebruikt, en niet te veel gebruikt. Als u de volgende code toevoegt, wordt vooraf de pagina 'Over' weergegeven.

     

    Prerender is vanaf maart 2016 al beschikbaar in Chrome, IE en Opera.

    Een paar dingen om op te letten

    (1) Geen van de hierboven genoemde resourcetips garandeert de uitvoering en voltooiing van de verschillende fasen van het verzoek waarvoor het is gemaakt, omdat wanneer de browser al bezig is met het verwerken van de aanvragen die nodig zijn voor de bewerkingen van de huidige pagina waar de gebruiker zich bevindt, deze optimalisaties uitvoeren kan de huidige taken van de gebruiker hinderen.

    Dus alles is in de wachtrij geplaatst en uitgevoerd wanneer de browser zich daar vrij genoeg voor voelt.

    Deze resourcehints hoeven niet noodzakelijk op de pagina aanwezig te zijn voordat de pagina wordt geladen. Ze kunnen zijn later toegevoegd door JavaScript, en de resource-hints zullen hun werk zoals gewoonlijk doen.

    (2) W3C specificeert a HTML-linkattribuut riep hint kans, pr (met waarde 0 tot 1) voor deze resourcehints, die kunnen worden gebruikt om de waarschijnlijkheid te geven van verzoeken die in de toekomst worden gedaan. Ik heb dit kenmerk nog niet door een browser geïmplementeerd. Als voorbeeld geeft de volgende code aan dat er een 80% kans xyzsite zal worden gevraagd in de toekomst en 30% voor de ongeveer pagina.

     

    We kunnen ook het optionele kenmerk crossorigin toevoegen aan de resourcewenken om de browser op de hoogte te stellen van de CORS-referentie van het gekoppelde verzoek.