De besøgende på dit websted hader at vente på, at siderne indlæses – på skrivebordet eller på mobile enheder. Sider, der er langsomme at indlæse, kan få dem til at skynde sig videre til en konkurrents websted. Du er også bekymret for den indvirkning, som webstedets ydeevne har på søgeresultaterne.

Hos Kinsta tager vi hastighed alvorligt, og vi forsøger altid at gøre vores kunders websteder hurtigere.

Tilføjelsen af Kinsta Edge Caching til vores Administreret WordPress Hosting-planer i december 2022 tilføjede nye værktøjer til at hjælpe kunderne med at få deres websider hurtigere til browsere.

Ved at måle tiden til første byte (TTFB) så vi en gennemsnitlig svartid på 207 millisekunder i alle tests med edge caching aktiveret, sammenlignet med 402,59 millisekunder uden edge caching. Det er et fald på næsten 49%. Men nogle af de virkelige websteder i vores test klarede sig meget bedre end det, idet TTFB-præstationer var næsten 80% hurtigere med edge caching. Vi vil grave dybere ned i disse tal nedenfor.

Lad os tage et kig på, hvordan dit WordPress-websted kan forbedre sin ydeevne, når mere af indholdet er “på edge”

Hvad er Edge Caching?

Mange af vores WordPress-hostingkunder drager allerede fordel af vores integration med Cloudflare og dets edge-ervere gennem Kinsta CDN. Dette content delivery network placerer et websteds statiske aktiver – som billeder, skrifttyper og filer, der indeholder CSS og JavaScript – på 260+ steder på Cloudflares netværk rundt om i verden. Det betyder, at disse aktiver er tilgængelige tættere på den fysiske placering af de besøgende på dit websted. Kortere transportstrækninger for disse aktiver resulterer i lavere netværkslatenstid.

Edge Caching af HTML-koden på WordPress-sider svarer meget til at administrere aktiverne i CDN’et. Forskellen er, at det er relativt enkelt at administrere en cache af filer som f.eks. billeder – som sjældent ændres – og at det er relativt enkelt. Det er vanskeligere at administrere indhold, der i første omgang genereres dynamisk af WordPress, cachelagres som statisk indhold og derefter genereres igen, hver gang indholdet redigeres.

Hvordan bliver indhold cachelagret på edge?

Edge-cacher udfyldes af forespørgsler om siderne på dit websted fra browsere. Hvis en side ikke allerede er cachelagret, sendes anmodningen til dit oprindelige WordPress-websted, hvor siden kan være i den lokale cache eller genereres igen af WordPress. Siden gemmes i edge-cachen på vejen tilbage til browseren. Fremtidige anmodninger på samme vej vil drage fordel af cachen, indtil den ryddes.

Det er også sådan, at mobilcaches fyldes op. Hvis anmodningen om en side kommer fra en mobilenhed, gemmes indholdet i en mobilcache. (Den mobile cache skelner ikke mellem f.eks. iOS- og Android-enheder. Anmodninger fra tablets grupperes sammen med desktopindhold.)

WordPress Local Cache og Edge Cache

Kinsta tilbyder en plugin-fri tilgang til lokal WordPress-caching på dit websted på din egen server. Kinsta’s take på Edge Caching opretholder denne enkelhed: de samme trin, du har taget for at rydde din lokale cache, vil nu også holde en edge cache synkroniseret.

Desuden indeholder MyKinsta-dashboardet funktionalitet til at rydde edge-cachen – og kun edge-cachen – direkte.

Noget nyt med Edge Caching er muligheden for at aktivere en cache til mobile enheder. Hvis dit websted genererer unik markup til mobile enheder, kan du cache denne HTML separat fra indhold til stationære enheder…

Er Kinsta Edge Caching det samme som Cloudflare’s APO?

Kinsta Edge Caching deler det samme kraftfulde netværk af edge-servere, der bruges af Cloudflares APO-tjeneste (Automatic Platform Optimization). APO er også designet til at levere edge caching til WordPress-websteder.

Her er, hvad der adskiller Kinsta Edge Caching fra andre:

  • Ingen ekstra gebyrer. (Edge Caching er gratis med alle Administreret WordPress Hosting-planer).
  • Intet behov for et plugin til cache-administration.
  • Problemfri integration med MyKinsta-dashboardet.
  • Én platform til at administrere CDN og Edge Caching.

Kinsta Edge Caching på prøve

Inden vi officielt frigav funktionen, inviterede vi nogle af vores kunder til at prøve en beta-version af den nye Edge Caching-tjeneste for at indsamle feedback. Vores beta-testeres virkelige websteder rundt om i verden var det perfekte miljø til at teste teknologien på hastighed.

Fra Googles datacenter, der er kendt som us-central1 i Council Bluffs, Iowa, undersøgte vores teams automatiserede værktøjer beta-testernes websteder og registrerede svartider for tre caching-scenarier:

  1. Når en side blev leveret fra cachen på en Cloudflare edge-server.
  2. Når en side ikke blev fundet på en Cloudflare edge-server og blev hentet fra oprindelsesserverens “lokale” cache.
  3. Når der slet ikke var nogen cachet side, og WordPress måtte starte PHP-scripts og affyre databaseforespørgsler for at opbygge siden dynamisk.

Det primære fokus var forskellen i svartider for lokale og edge caches.

Vi målte svartider på to måder:

  1. Tid til første byte – tidsrummet mellem en anmodning om en side og ankomsten af den første byte af data.
  2. Tid til at downloade en hel HTML-side.

Ved måling af TTFB fokuseres der på latenstiden i netværket mellem en webserver og en browser, da den stort set er uafhængig af den mængde data, der overføres for at færdiggøre en side. Timing af overførslen af en fuld side er en nyttig måling, der afspejler den virkelige opgave med at levere HTML til browsere.

Edge Caching i tal

Efter hundredvis af tests målrettet WordPress-websteder i datacentre rundt om i verden fandt vi, at Kinsta Edge Caching i gennemsnit reducerede den tid, der kræves for at levere hele sider til browsere, med mere end 50%.

Tag et kig:

Diagram, der viser forbedringer i TTFB og sideleveringshastighed takket være Edge Caching.
TTFB: 402,59 ms (lokal cache), 207 ms (edge). Fuld side: 490.99 ms (lokal cache), 223,98 ms (edge).

Baseret på vores test reducerede Edge Caching TTFB i gennemsnit med næsten 48,6%, og tiden til at overføre komplette sider faldt med næsten 54,4%

Over 80% forbedring over lange afstande

Selvom gennemsnittene af alle hastighedstestene var imponerende, kan denne visning skjule vigtige data – især for dem, der henvender sig til et globalt publikum.

Vores test viste nogle dramatiske forbedringer af ydeevnen, når Edge Caching indsnævrede afstanden mellem browsere og mere fjerntliggende origin-servere.

Edge Caching reducerede f.eks. TTFB med 83,6% og sideoverførselstiden med 85,6% mellem vores testlokation i Iowa og Googles asia-southeast1 -datacenter i Singapore:

Diagram, der viser Edge Caching-ydeevne for Jurong West-datacenter.
TTFB: 672,01 ms (lokal cache), 110,05 ms (Edge). Hele siden: 901.1 ms (lokal cache), 129,79 ms (edge).

Opretter forbindelse til WordPress-websteder i Sydney australia-southeast1 datacenter, faldt TTFB med næsten 73,6 %, og sideoverførselstider faldt med 77,3%.

Diagram der viser Edge Caching ydeevne for Sydney datacenter.
TTFB: 898,26 ms (lokal cache), 237,21 ms (edge). Hele siden: 1.130,48 ms (lokal cache), 256,95 ms (edge).

Vi så lignende tal ud fra australia-southeast2 -datacenteret i Melbourne. De WordPress-websteder hos Kinsta-kunder der oplevede Edge Caching trimme TTFB med gennemsnitligt 77,8% og sideoverførsel med næsten 82,7%:

Diagram, der viser Edge Caching-ydeevne for Melbourne datacenter.
TTFB: 607,37 ms (lokal cache), 134,63 ms (edge). Hele siden: 812.46 ms (lokal cache), 140,62 ms (edge).

Ved at oprette forbindelse til websteder, der er hostet i europe-north1 ‘s datacenter i Hamina, Finland, faldt TTFB med næsten 41,7%, og overførselstiden for sider faldt med mere end 56,3%.

Diagram, der viser Edge Caching-ydeevne for Haminas datacenter.
TTFB: 579,81 ms (lokal cache), 338,17 ms (edge). Hele siden: 822.21 ms (lokal cache), 358,89 ms (edge).

Ghislain, Belgien, i datacenteret europe-west1 faldt TTFB- og sideoverførselstiderne med 69%.

Diagram, der viser Edge Caching-ydeevne for Ghislain-datacentret.
TTFB: 464,64 ms (lokal cache), 143,13 ms (edge). Hele siden: 464.92 ms (lokal cache), 143,38 ms (edge).

Websteder, der blev testet i europe-west2 -datacenteret i London, UK, viste en TTFB-tab på 58% og en sideoverførselstid på 60,8%.

Diagram, der viser Edge Caching-ydeevne for Londons datacenter.
TTFB: 372,4 ms (lokal cache), 156,17 ms (edge). Hele siden: 458.18 ms (lokal cache), 179,34 ms (edge).

I europe-west3 -datacenteret i Frankfurt i Tyskland faldt TTFB med næsten 64%, og sideoverførselstiden faldt med 67,5%.

Diagram, der viser Edge Caching-ydeevne for Frankfurts datacenter.
TTFB: 409,27 ms (lokal cache), 147,42 ms (kant). Hele siden: 507.52 ms (lokal cache), 164,98 ms (edge).

Ved forbindelse til websteder, der er hostet i europe-west4 -datacenteret i Eemshaven i Holland, faldt TTFB med næsten 56%, og overførselstiden for sider faldt med 63,6%.

Diagram, der viser Edge Caching-ydeevne for Eemshaven datacenter.
TTFB: 394,49 ms (lokal cache), 173,76 ms (edge). Hele siden: 538.84 ms (lokal cache), 195,82 ms (edge).

Under test af websteder i northamerica-northeast1 -datacenteret i Montreal, Canada, faldt TTFB med lidt over 10%, og sideoverførselstiden faldt med lidt over 16,2%.

Diagram, der viser Edge Caching-ydeevne for Montreals datacenter.
TTFB: 325,3 ms (lokal cache), 292,28 ms (edge). Hele siden: 351.1 ms (lokal cache), 294,15 ms (edge).

I us-east5 -datacenteret i Columbus, Ohio, blev TTFB- og sideoverførselstiderne reduceret med næsten 59%.

Diagram, der viser Edge Caching-ydeevne for Columbus datacenter.
TTFB: 326,69 ms (lokal cache), 133,97 ms (edge). Hele siden: 341.15 ms (lokal cache), 140,5 ms (edge).

I datacenteret us-west4 i Las Vegas, Nevada, i USA faldt TTFB med lidt over 54,7%, og sideoverførselstiden faldt med næsten 57,3%.

Diagram, der viser Edge Caching-ydeevne for Las Vegas datacenter.
TTFB: 366,73 ms (lokal cache), 165,88 ms (edge). Hele siden: 413.39 ms (lokal cache), 176,63 ms (edge).

Men det er ikke kun Kinsta, der sætter Edge Caching på prøve.

Brian Jackson, medstifter af det digitale bureau forgemedia, timede TTFB og den komplette rendering af WordPress-sider i en browser efter Edge Caching. Han kiggede også på largest contentful paint (LCP), det punkt, hvor nok af en sides hovedindhold er blevet renderet til, at en bruger kan opfatte den som brugbar. Han offentliggjorde sine resultater på Twitter:

Skærmbillede af et tweet fra Brian Jackson.
Twitter/Brian Jackson. (Se på Twitter.)

Simon Harper fra SRH Design testede Kinsta Edge Caching ved at se på TTFB og LCP samt første contentful paint (FCP), som er den første fremvisning af ethvert indhold på en skærm, selv om det ikke er sidens primære indhold. Han rapporterede også via Twitter:

Skærmbillede af et tweet fra Simon Harper.
Twitter/Simon Harper. (Se på Twitter.)

Strukturen af websider og linkede aktiver som JavaScript, CSS og billeder kan påvirke FCP og LCP, men det hele begynder med leveringen af en sides HTML til en browser.

Kom godt i gang med Kinsta Edge Caching

Edge Caching er som standard aktiveret, når du opretter et WordPress-websted i MyKinsta-dashboardet. Det betyder, at du ikke behøver at løfte en finger for at drage fordel af Edge Caching-hastighedsforøgelsen.

Fra januar 2023 vil Kinsta automatisk aktivere Edge Caching på eksisterende websteder, der er kompatible med tjenesten. Hvis du vil have Edge Caching til at fungere på dit eksisterende websted med det samme, kan du aktivere det nu på følgende måde:

  • Vælg WordPress SItes i navigationen til venstre.
  • Vælg navnet på et websted, som du vil have Edge Caching aktiveret for.
  • Vælg Edge Caching.
  • Klik på knappen Enable Edge Caching (Aktiver Edge Caching).
Skærmbillede: Aktiverer Edge Caching i MyKinsta.
Aktivering af Edge Caching i MyKinsta-dashboardet: Du kan aktivere Edge Caching nu: Sådan aktiveres: Aktiver Edge Caching i MyKinsta-dashboardet.

Cache dit mobilindhold på edge

Hvis dit websted registrerer mobile browsere og genererer sider med markup, der er unik for disse enheder, kan du aktivere en mobil cache separat fra indholdet til desktopbrugere.

Aktiver mobil caching i MyKinsta på denne måde:

  • Vælg WordPress SItes i navigationen til venstre.
  • Vælg navnet på et websted, for hvilket Edge Caching er aktiveret.
  • Vælg Edge Caching.
  • Klik på knappen Enable Mobile Cache (Aktiver mobilcache)
Skærmbillede: Aktiverer mobilcache i MyKinsta.
Aktivering af Edge Caching til mobile enheder: Aktivér Edge Caching for mobile enheder på følgende måde

Du behøver ikke at aktivere mobil caching, hvis dit webstedsdesign understøtter både desktop- og mobilbrowsere med den samme responsive HTML/CSS-markup.

Håndtering af dit cachede indhold

Kinsta Edge Caching er designet til at fungere problemfrit med de cache-styringsværktøjer, som de fleste af vores kunder allerede bruger på deres WordPress-websteder. Du kan også målrette indhold i edge cachen direkte i MyKinsta her:

  • Vælg WordPress SItes i navigationen til venstre.
  • Vælg navnet på et websted, for hvilket Edge Caching er aktiveret.
  • Vælg Edge Caching.
Skærmbillede: Rydning af caches i MyKinsta.
Rydning af kantcacher i MyKinsta-dashboardet.

Hvis du vil rydde alle siderne på dit websted fra den globale edge cache, skal du klikke på knappen Ryd cachen.

Hvis du kun skal rydde bestemte sider eller stier, skal du indsætte en mål-URL i feltet Ryd URL-cache og klikke på knappen Ryd URL-cache. Ryd cachen for alt indhold på en bestemt sti ved at markere indstillingen Ryd cache for alle undermapper under den angivne URL-adresse.

Fravalg af Edge Caching

Hvis du ved, at Edge Caching ikke passer til dit websted, kan du fravælge tjenesten, inden vi begynder at aktivere tjenesten for de fleste eksisterende websteder i januar 2023.

I MyKinsta:

  • Vælg WordPress SItes i venstre navigation.
  • Vælg navnet på dit WordPress-websted.
  • Vælg Edge Caching.
  • Aktiver vipsknappen “Jeg ønsker at fravælge…“.
Skærmbillede: Fravalg af Edge Caching i MyKinsta.
Du kan fravælge Edge Caching ved hjælp af dashboardet i MyKinsta.

Hvis Edge Caching allerede er aktiveret for et websted, finder du en knap til at deaktivere i øverste højre hjørne af siden:

Screenshot: Deaktivering af Edge Caching i MyKinsta.
Deaktivering af Edge Caching

Hurtige spørgsmål om Edge Caching

Du undrer dig måske over…

Er Edge Caching gratis på alle abonnementer?

Ja. Edge Caching er som standard aktiveret på alle live-websteder, der er oprettet i MyKinsta-dashboardet. Edge Caching er også tilgængelig på Scene-websites inden for Premium-konti.

Forbedrer Edge Caching ydeevnen for mobilversionen af mit websted?

Du kan aktivere en mobilspecifik cache for websteder, der genererer markup, der er skræddersyet til mobile enheder. Hvis dit webstedsdesign understøtter både desktop- og mobilbrowsere med den samme responsive HTML/CSS-markup, er det ikke nødvendigt med en mobilcache.

Skal jeg bruge WordPress-optimeringsplugins?

Nej. Kinsta’s Managed WordPress Hosting-platform tilbyder lokal caching, Edge Caching og et CDN, der er fintunet til at understøtte verdens mest populære CMS. Der kræves ingen WordPress-plugins fra tredjepart.

Kan jeg slå Edge Caching fra?

Ja. Du kan deaktivere Edge Caching på enhver type i MyKinsta-dashboardet. Hvis du ikke er sikker på, om dit websted er kompatibelt med Edge Caching, kan du kontakte Kinstas supportteam for at få råd.

Oversigt

Internettets løfte har altid været at forbinde folk rundt om i verden. Men det har vist sig, at den fysiske afstand mellem servere og besøgende har en reel indvirkning på den opfattede ydeevne af websteder. Edge Caching flytter indholdet tættere på webbrowsere og fremskynder det vigtige første skridt til hurtigere sideindlæsning.

Kinsta gør Edge Caching til en grundlæggende komponent i sin Administreret WordPress Hosting-tjeneste, som supplerer CDN- og netværkssikkerhedsfunktionerne, der følger med vores Cloudflare-integration.

I gennemsnit halverer Kinsta Edge Caching den tid, det tager at levere HTML af websider til de besøgende på dit websted, til det halve. For websteder med virkelig globale publikum kan hastighedsforøgelsen være dramatisk højere.

Edge Caching er tilgængelig for alle vores kunder uden ekstra omkostninger. Hvis du stadig leder efter en WordPress-host, der er bygget med sikkerhed, brugervenlighed og ydeevne i tankerne, har vi et hostingabonnement, der passer til dig.

Steve Bonisteel Kinsta

Steve Bonisteel is a Technical Editor at Kinsta who began his writing career as a print journalist, chasing ambulances and fire trucks. He has been covering Internet-related technology since the late 1990s.