Sådan fremskynder du webstedet med Tag

"forudse"browsere er fremtiden for top internet surfing, bringe os ressourcer, vi ønsker selv før vi ved, vi vil have dem. Dagens browsere allerede lave nogle forudsigelser nu og da for at fremskynde hentning og gengivelse af dokumenter. For at tage dette til næste trin ser vi ingen andre end webudviklere.

Udviklere har en ret god ide af hvordan deres websites navigeres, og hvilke ressourcer bliver ofte bedt om og dermed kan de forudsige nogle fremtidige operationer, som browsere skal gøre for websteder. Alt hvad der er brug for nu, er for udviklere at finde vej til relæ disse forudsigelser til browsere og sæt dem til god brug. Her kommer nogle specielle "HTML links" ind.

En opdatering på HTTP-anmodninger

Inden du tager et kig på disse links, er det tid til at opdatere vores hukommelse om, hvordan en typisk HTTP-anmodet filhentning sker. Lad os sige, at nogen, der hedder Joe, vil besøge et websted.

Her er hvad der sker næste gang:

1. Joe skriver webstedets menneskelige recallable adresse i en browsers adresselinje og trykker "Enter".
2. Når den har modtaget denne adresse, spørger browseren en DNS-server (komplimenter af internetudbyder) for IP-adressen til adressen fra Joe.
3. DNS-serveren forpligter.
4. Nu, hvor browseren kender IP-adressen, sender den en besked (i TCP dialekt) til hjemmesidens server og beder om en forbindelse.
5. Hvis serveren lever og godt, sender den et svar, der anerkender browserens anmodning, og browseren reagerer og anerkender serverens besked. (Bemærk: Ja, dette er en ekstremt udvandret version af et TCP-håndtryk mellem en klient og en server.)
6. Når håndtryk er forbi, etableres der en forbindelse mellem de to.
7. Nu ændrer browseren sin dialektstil til HTTP og beder serveren til hjemmesiden.
8. Serveren, der kender hjemmesiden på hjemmesiden, returnerer netop det, som er modtaget af browseren og vist til Joe, som venter meget tålmodigt foran computeren.

En typisk HTTP-anmodning går igennem alle at (og mere) at hente et dokument via internettet. Så hvis nogen af ​​disse processer kan hoppes i gang, når det er muligt, vi kan reducere den tid, vi skal vente på leveringen af ​​de ressourcer, vi ønsker.

HTML Link Relationer

W3C specificerer 4 HTML link relationer (rel for forhold) navngivet dns-prefetch, forhåndstilslutning, amtmand, og forhåndsgengive. Sammen kaldes de (ved W3C) "Resource Tips". Nu vil vi se hvad de kan gøre og hvor de kan bruges.

1. DNS Prefetch

I DNS prefetch, den domænenavn resolution (også ved at få den matchende IP-adresse fra DNS-serveren) er færdig på forhånd.

Lad os sige, at der er en referenceside på et websted med mange referencer til sit søsters websted. Når en bruger besøger referencesiden, er der en høj sandsynlighed at brugeren vil navigere til søstersiden. Så, en tidligt DNS opslag for søstersiden kan reducere den tid det tager at åbne webstedet (derved forbedre brugeroplevelsen).

Dette latens reduktion via DNS prefetching kan gøres ved at tilføje denne kode til referencesiden.

Når en browser behandler denne kode på referencens side, tilføjer den DNS-opsætningen af ​​søstersiden til dens opgavekøer, og når den er fri for andre højt prioriterede opgaver i køen, starter den DNS-opløsningen af ​​den søster side.

Så når en bruger endelig klikker på en af ​​de links, der fører dem til søstersiden, kan DNS-opløsningen af ​​dette websted allerede være afsluttet, og browseren kan med det samme starte etableringen af ​​TCP-serverens TCP-forbindelse med søstersiden server, hvilket gør den side hurtigere.

Denne funktion er tilgængelig i næsten alle moderne browsere bortset fra Safari fra marts 2016.

2. Forbind forbindelsen

Forbindelse er et skridt videre fra DNS prefetch, det etablerer en forbindelse til serveren, som der kan være en anmodning sendt senere i fremtiden.

W3C lister en ideel brugstilfælde til forudforbindelse: omdirigeringer. Udviklere bruger omdirigeringer af flere årsager.

I dette tilfælde er en browsers næste anmodning (omdirigeret websted) 100% forudsigelig, og kan være forudforbundne til, til reducere navigationslatens.

Forestil dig, at der er en mellemledningsside, der omdirigerer til "xyzsite", vil følgende HTML-link få browseren til at forbinde forbindelsen til xyzsite-serveren, når den kommer til den mellemliggende side.

Fra marts 2016 er denne tilgængelig i Chrome, Opera og Firefox.

3. Prefetch

Med amtmand, for en ressource, browseren begynder at implementere DNS-opløsningen af ​​ressourceens domænenavn, derefter udfører en TCP-forbindelse med ressourcens server, gør HTTP-anmodningen og endelig henter og gemmer den forudindrettede ressource i browserens cache.

Hvis du er sikker på hvilke ressourcer der skal bruges senere, er det den ressource, du skal forudfinde på forhånd. der ligger fangsten deri. Prefetching tager guesswork, og hvis du gætter fejlagtigt, kan du faktisk sænke i stedet for at fremskynde dit websted.

For onlinebøger, gallerier eller porteføljer, hvis brugeren mest sandsynligt vil gennemse til den næste side, skal du forudindlæse ressourcerne som f.eks. billeder, kan fremskynde tingene væsentligt. Her er koden til at gøre det.

Prefetch understøttes i Chrome, Firefox og Opera.

4. Prerender

Kun for HTML-sider kan prerendering ske. En prerendered HTML-side er gjort offline, og er malet til skærmen, når det faktisk er brug for af brugeren. rendering koster et højere beregningsarbejde og hukommelsesressource; plus, for at gøre en side, kan browseren have brug for ekstra ressourcer (som billeder tilføjet til siden), som vil føre til mere efterfølgende anmodninger ved browser.

Så, forhåndsgengive skal være bruges med forsigtighed, og ikke overbrugt. Tilføjelse af følgende kode vil prerender "Om" siden på forhånd.

Prerender er allerede tilgængelig i Chrome, IE og Opera fra marts 2016.

Et par ting at notere

(1) Ingen af ​​de ovennævnte ressourcehenvisninger garanterer udførelsen og afslutningen af ​​de forskellige stadier af anmodningen, den er lavet til, fordi når browseren allerede er optaget af behandlingen af ​​de anmodninger, der er nødvendige for operationerne på den aktuelle side, brugeren er i, udfører disse optimeringer kan forhindre brugerens aktuelle opgaver.

Så alt er i køen og henrettet, når browseren føles fri nok til at gøre det.

Disse ressourcehenvisninger behøver ikke nødvendigvis at være til stede på siden, selv før siden læses. De kan være tilføjet senere af JavaScript, og ressourcehenvisningerne vil gøre deres arbejde som normalt.

(2) W3C angiver a HTML link attribut hedder hint sandsynlighed, pR (med værdi 0 til 1) for disse ressourcestik, som kan bruges til at give sandsynligheden for anmodninger, som vil blive fremsat i fremtiden. Jeg har ikke set denne egenskab, der implementeres af en browser endnu. Som et eksempel siger følgende kode, at der er en 80% chance xyzsite vil blive anmodet om i fremtiden og 30% for den omkringliggende side.

Vi kan også tilføje den valgfrie crossoriginattribut til ressourcehenvisningerne for at informere browseren om den linkede forespørgsels CORS-legitimation.