Slik aktiverer du nettleserbufring i WordPress

WordPress-tilbud


Nettstedets hastighet spiller en viktig rolle i å gi en optimal brukeropplevelse. (Merk: Hvis du er interessert i å lære hvordan du kan sjekke nettstedets hastighet, kan du se artikkelen vår om bruk av GTmetrix.) Et tregt nettsted kan forårsake forstyrrelse i salget, redusere konverteringer, og på lang sikt kan det få alvorlige konsekvenser både kundetilfredshet og det generelle antall besøkende.

Kort sagt: Hver liten ting du kan gjøre for å presse lastetidene ned vil telle. Nedenfor beskriver vi det nettleserbufring, inkludert hva det er, hva det betyr for WordPress, og hvordan du kan gjøre for å aktivere det på nettstedet ditt.

La oss komme i gang…

Hva er nettleserbufring?

Et nettsted består hovedsakelig av et antall filer som passer sammen for å lage en serie med nettsider. Noen av disse vil inneholde tekst (for eksempel hoveddelen av et blogginnlegg), noen vil inneholde stylinginformasjon for sideelementer (topptekst, bunntekst, sidefelt osv.), Noen vil være bilder, og så videre.

Når du nå besøker et nettsted, vil du sannsynligvis legge merke til mange vanlige elementer: Alle sidene er utformet på samme måte (de har alle lignende farger og designelementer), logoen er alltid den samme, rullegardinmenyene er alltid tilgjengelige, og lignende. Så hvis det er vanlige elementer, hvorfor laste ned dem alle hver gang noen laster inn en ny side? En mye bedre idé ville være å laste inn slike vanlige elementer en gang, lagre dem i nettleseren og deretter bare gjenbruk dem etter behov – for eksempel når noen går fra en side til en annen på nettstedet, eller når noen besøker siden på et senere tidspunkt.

Dette er essensen av nettleserbufring. I hovedsak ser nettleserbufring på hvilke filer du har definert som filer som ikke endres veldig ofte (mer om dette nedenfor) og laster dem ned til den besøkende nettleseren bare en gang. Når filene er lastet ned til nettleserbufferen, blir de ikke lastet ned igjen. Dette betyr at de, i stedet for å måtte lastes ned flere ganger, vil være klar til bruk på et øyeblikks varsel – og dermed redusere belastningen på nettstedets servere OG, enda viktigere, redusere tiden det tar å laste påfølgende sider betydelig.

Merk: Når en ny besøkende kommer til nettstedet ditt, vil hastigheten den første siden de besøker lastes faktisk være den samme om nettleserbufring er aktivert eller ikke, siden nettleseren ikke har besøkt nettstedet før, Det har muligens vært en mulighet til å lagre noen av nettstedets filer ennå. Fordelene med hurtigbufring av nettlesere vil derfor bare merkes når en besøkende laster mer enn en side og / eller besøker nettstedet ditt.

Hvordan utnytte nettleserbufring i WordPress

Det er ikke vanskelig å aktivere hurtigbufring av nettlesere, men fordi det krever redigering av en litt vanskelig nettstedfil (nettstedets .htaccess-fil, krever det litt foreløpig kunnskap).

Merk: Bufring av hurtigbufring er ikke spesifikk for WordPress, måten å aktivere den på er den samme uansett hvilket system du bruker.

Det er egentlig to måter å gjøre det på.

Superenkelig måte: Snakk med verten din

For å aktivere hurtigbufring av nettlesere, må du redigere – eller kanskje til og med lage – en fil som heter .htaccess-filen. Les mer. En skrivefeil i denne filen kan føre til at hele nettstedet ditt blir midlertidig utilgjengelig, hvis du er i tvil om hva du skal gjøre, kan det være best å gjøre det spør verten din å gjøre det for deg – bare for å være trygg. Hvis du bruker et flott vertsfirma og trenger en bedre vert?, Vil de nesten helt sikkert kunne konfigurere dette for deg i løpet av få minutter (hvis de ikke allerede har gjort det).

Redigere .htaccess-filen på egen hånd

.Htaccess-filen kan være et skummelt sted; det er et klassisk eksempel på “med stor kraft kommer stort ansvar”, slik at du kan få fart på nettstedet ditt, opprette omdirigeringer og gjøre fantastiske ting. All denne kraften kommer imidlertid til en pris – en feil i denne filen vil sannsynligvis føre til at hele nettstedet ditt går ned.

Å fikse det er et spørsmål om å angre det du har lagt til, men for en nybegynner kan det være en skremmende opplevelse. Jeg anbefaler på det sterkeste å eksperimentere på et teststed før du blir skitten med hendene dine med et viktig live-nettsted.

Det første du trenger er en måte å få tilgang til serverens filer på. Den vanligste måten å gjøre dette på er via FTP (filoverføringsprotokoll – les mer. Filen kan være litt vanskelig å finne fordi den er en dotfile – en skjult fil på et Linux-basert system, hva er en dot-fil? – men mest FTP-redaktører har et alternativ “vis skjulte filer” som skal tillate deg å se disse filene. (Merk: Hvis du bruker en Mac, kan du lese artikkelen vår om hvordan du laster ned, redigerer og laster opp en htaccess-fil på nytt uten å måtte endre noen av datamaskinens innstillinger.)

.Htaccess-filen skal være i din viktigste WordPress-mappe – den samme mappen som inneholder wp-innhold, wp-inkluderer og wp-admin mapper. Hvis du ikke finner det, er det greit, det kan ikke eksistere – i så fall trenger du å lage det (noe som ikke er dekket her, er jeg redd). Når du har funnet (eller opprettet), vil du deretter legge til følgende kode ved å bruke en ren tekstredigerer, IKKE en tekstbehandler!

Utløper Aktiv på
ExpiresByType image / jpg "tilgang pluss 1 år"
ExpiresByType image / jpeg "tilgang pluss 1 år"
ExpiresByType image / gif "tilgang pluss 1 år"
ExpiresByType image / x-icon "tilgang pluss 1 år"
ExpiresByType image / png "tilgang pluss 1 år"
ExpiresByType text / css "tilgang pluss 1 måned"
ExpiresByType text / x-javascript "tilgang pluss 1 måned"
ExpiresByType-applikasjon / x-shockwave-flash "tilgang pluss 1 måned"
ExpiresDefault "tilgang pluss 2 dager"

Disse linjene forteller brukerens nettleser hvordan cache hver filtype skal bufres. Over har jeg satt jpg-, jpeg-, gif-, ikoner- og png-bilder til å bli bufret i et år (siden disse knapt endres), og CSS-, JavaScript- og Flash-filer som skal bufres hver måned (siden disse er mer tilbøyelige til å endre ). Jeg har også satt standardinnstillingen til to dager for filer som ikke er spesifisert ellers.

Deaktivering for utvikling

Ettersom disse filene vil bli bufret ganske lenge (uansett tid du har bestemt deg for å definere for hver filtype), kan utvikling være vanskelig, så jeg vil på det sterkeste anbefale å ikke bruke nettleserbufring for nettsteder som fremdeles er i aktiv utvikling. Du kan selvfølgelig gå til nettleserens innstillinger og tømme hurtigbufferen hver gang, men dette vil snart bli slitsomt (pluss at det ikke er like lett å tømme en annens cache – tips nedenfor).

Hvis du begynner å endre ting, vil du først endre cachen til noe mye kortere, for eksempel en eneste dag – i så fall vil brukerne se de nye ressursene når det har gått 24 timer.

En annen metodeutviklere bruker for å oppdatere hurtigbufrede filer er å legge til spørringsparametere til ressursene sine. Hvis du for eksempel laster script.js, når du har bufret, vil endringene du gjør der, bare lastes ned etter ett år (eller hvor lenge du har satt den til). For å komme seg rundt dette vil utviklere ofte legge versjonen av ressursen til URLen. Så i stedet for “http://mysite.com/scripts.js” blir URLen noe som “http://mysite.com/scripts.js?version=1.0”, og når skriptet endres igjen utvikleren igjen erstatter URL-en til ressursen, og gjør den til “http://mysite.com/scripts.js?version=1.1”, for eksempel.

Når det gjelder nettleseren, er dette teknisk sett en ny ressurs, så den blir lastet ned og hurtigbufret på nytt – i enda et år.

Kontroller arbeidet ditt

Det er flere måter å sjekke om nettstedshurtigbuffer er aktivert eller ikke, med en av de enkleste (og mest interessante) tingene ved å bruke et gratis verktøy for nettstedhastighetstesting kalt GTmetrix – noe vi allerede har dekket grundig i en tidligere artikkel: Hvordan bruke GTmetrix til å teste hastighet på et nettsted – effektivt

GTMetrix Browser Cache Test

Hvis nettstedet ditt scorer et ‘A’, er cache-nettleseren i orden, og du er helt klar for en fin fartshump!

Siste tanker

Nettleserbufring kan føre til betydelige hastighetsøkninger, og siden det egentlig bare betyr å kopiere og lime inn noen få kodelinjer (og ikke har noen ulemper overhodet – forutsatt at du ikke har tenkt å endre noen av de definerte filene før de er satt til utløper), og aktivering av det er nesten absolutt noe verdt å gjøre.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me