Fordelene ved at bruge et CDN til dit WordPress-sted

At have en CDN-service, der fungerer sammen med dit WordPress-drevne websted, er en meget god ting, hvis dit websted besøges i hele verden. Især hvis dit websted er tungt med aktiver, og når jeg mener aktiver, mener jeg alle disse irriterende javascript, CSS og billedfiler.


Disse aktiver på dit websted er blandt de første emner, der har brug for et CDN. Hvis dit websted er en lille blog, betyder det sandsynligvis ikke noget, da nedskæringen i indlæsningstid vil være ubetydelig, men hvad med de store?

Til dette eksperiment vil jeg oprette en CDN77.com konto for mit tech / videospilsite er det et meget dyre websteds ”aktivt klogt” med en størrelse på ikke mindre end 2,4 MB og mere end 95 anmodninger. I form af lægfolk er det en tung byrde for browseren og serveren at indlæse. At være et magasin med mange nyheder, er der ingen måde at gøre dette bedre på. Serveren er allerede en high-end en, og at skulle skære ned på indholdet er bestemt en no-go.

Der er masser af sider som disse på Internettet. Jeg hører stadig stemmer om, hvor ubrugelig en CDN er for nogen form for side (stor eller lille), og jeg kan bare ikke undgå at undre mig over de slags kommentarer.

I denne artikel i dag skal jeg undersøge, hvorfor CDN’er er vigtige og spørgsmål (meget). Du kan med tal og beviser se, hvorfor du har et CDN betyder meget, især hvis du har kunder langt væk fra det sted, hvor din server er placeret. At skulle indlæse et websted med få aktiver er en ting, men mellemstore til store websteder vil få stor fordel, og jeg vil vise dig, hvorfor …

Benchmark med og uden CDN

Med henblik på dette eksperiment vil jeg bruge Pingdom værktøjer. Af alle de gratis værktøjer, du kan finde på til at teste webstedets faktiske hastighed og belastningstid, er Pingdom-værktøjer et af de bedste (og mest præcise også). Pingdom-målinger inkluderer ventetider for aktiver, der kan være eksterne og vigtigst af alt asynkrone. Indlæsningstid for en slutbruger er derfor lidt kortere. Først vil vi indlæse webstedet lige fra serveren uden nogen CDN overhovedet. Tag højde for, at serveren allerede er hurtig nok, en Xeon, der kører på 3,3 GHz på Nginx med FastCGI-cache, er ingen lille bedrift, og den skal indlæses ret hurtigt på egen hånd.

Uden CDN77 fra San Jose, Californien

På billedet kan du se, at den samlede belastningstid er ca. 2,64 sekunder, til dette eksperiment har jeg brugt San Jose-serveren i Californien, USA, da min server er placeret i North Carolina, USA, bør belastningstiden være lav nok. På højre skærm kan du se alle ressourcer (aktiver), der indlæses med deres faktiske tidspunkter.

Uden CDN77 fra Stockholm, Sverige

Som du kan se, så snart anmodningen kommer fra et langt væk sted, begynder tingene at gå ned … Hjemmesiden sænkede sin score til 86, og nu er belastningstiden omkring 5.20s, dette er hvad der sker, når mere end 95 anmodninger har at rejse over hele kloden. Tag højde for lysets hastighed, og alle disse irriterende filer øger kun den samlede belastningstid, der er bare ingen vej rundt.

Med CDN77 fra San Jose, Californien

Lad os nu aktivere CDN77, så det begynder at hente alle aktiver automatisk og se, hvad der sker …

Nu er dette den første ulempe ved at bruge et CDN. Hvis det tolkes forkert, kan det føre til en forkert opfattelse af, at CDN ikke fungerer. Første gang webstedet indlæses, skal CDN-service hente aktiverne fra originalserveren og indlæse dem fra det nærmeste sted, hvor det blev anmodet om. Du kan tydeligt se, at belastningstiden faktisk er steget til 6.36s, og på det rigtige billede kan du se hvorfor. På den X-Cache-svarhoved er svaret.  CDN-tjenesten svarede med en “GÅ GLIP AF” hvilket tydeligt indikerer, at aktivet ikke tidligere var cachelagret og skulle indlæses “på farten”, det er dette, der gør CDN-løsningen langsommere, men kun ved første belastning. Da aktivet skal foretage en rundtur fra CDN-tjenesten tilbage til originalserveren og derefter tilbage til det interne netværk og væk til den nærmeste server på det sted, der blev anmodet om. Rundturen er ikke så langsom når alt kommer til alt, men X-Cache-parameteren vil helt klart hjælpe dig med at identificere, hvornår den cache eller ikke. Nu er Pingdom Tools cool eller ej?

Med CDN77, anden løb

Lad os se hvad der sker på et andet løb …

Den lever! Nu taler vi. Du kan se, at belastningstiden faldt til 2,48 s, hvilket nu er hurtigere end det originale benchmark uden CDN. På det højre billede kan du også nu se ”HIT” vises i svarhovedet, signaliserer browseren, at anmodningen er cache, og den er leveret fra den nærmeste server til det sted uden at skulle foretage flere rundrejser.

Hvad med ydersiden af ​​USA

I det forrige eksempel så vi, at når vi bruger webstedet uden for USA og uden for det land, hvor webstedet er placeret, begyndte tingene at blive grimme, lad os se hvad der sker med CDN aktiveret.

Den første belastning til venstre gav os en tid, der mere eller mindre svarer til den originale benchmark, hvis ikke bedre. Dette er uden, at den faktiske anmodning er cachelagret. På det rigtige billede kan du tydeligt se forbedringen, og den er ikke en lille. Vi er nu gået fra 5.20s uden et CDN til et uhyre 2.34s at indlæse hele webstedet, dette er en forbedring af mere end 2X da nu kun de grundlæggende PHP-filer indlæses fra originalserveren, mens alle resten af ​​aktiverne indlæses lokalt fra Stockholm-serveren på CDN77 !

Vil du have et bevis? Det er sikkert. Her er det:

cdn77-datacentre

Lad os gå til det ekstreme …

Uden CDN77 fra Melbourne, Australien

test03-01

Indlæsning af webstedet fra Australien er bare så smertefuldt uden et CDN, og min hjemmeside er nu blevet til den langsomste af flokken, hvilket giver en score på 77 og en C, oh..

Med CDN77 fra Melbourne, Australien

test03-02

Med CDN77 aktiveret er hastighedsforøgelsen imponerende og næsten en 2X forskel. Scoringen er naturligvis igen, hvilket beviser, at CDN faktisk fungerer, som det burde være.

Lad os nu sætte alt dette i perspektiv, skal vi?benchmark-sammenligning

Denne graf taler næsten for sig selv om, hvordan CDN faktisk forbedrer ydeevnen relateret til, hvor webstedet er placeret. Hvis dine læsere / kunder får adgang til webstedet i det samme land / sted, hvor din server er placeret, hvorfor bede om et CDN ret? Det vil ikke gøre tingene bedre. I det bedste tilfælde hjælper det kun din server med ressourcerne, og det reducerer den involverede CPU-tid, men det forbedrer ikke belastningstiden.  Men så snart en af ​​dine læsere forsøger at få adgang til webstedet uden for det land, hvor din server er, går ydelsesforbedringen til 2X, meget let. Der er ikke noget at benægte, du kan gå videre og udføre alle disse test selv. CDN betyder meget, hvis dit websted læses fra hele verden, og det vil også lette båndbreddekravene på din server.

Konklusion

At have et CDN på dit internationale websted er et must. Det være sig en teknisk blog, et digitalt magasin eller et produktsted. Hvis du er interesseret i ydelse, og dine kunder / læsere er placeret rundt om i verden, CDN vil faktisk fremskynde dit WordPress-websted meget. Også, jo flere aktiver dit websted indlæser fra de forskellige placeringer, desto større er forbedringen. At have en CDN er dog ikke en seng med rosesituation. Håndtering af tjenesten korrekt er vigtigst for dens ydelse. Husk, at den første anmodning altid vil være langsommere, det er meget vigtigt at have CDN-cachen webstedet korrekt.

I den næste artikel undersøger vi, hvordan du korrekt konfigurerer CDN77 service med WordPress, hvordan du indstiller dens placeringer og drager mest muligt ud af det, så du kan opleve de samme fordele som i denne artikel. Bliv hængende!

Gratis CDN-tjenester

Glem ikke at tjekke vores indlæg om de bedste gratis CDN-tjenester derude. Nogle af disse er 100% gratis op til et bestemt punkt, mens andre er gratis i en prøveperiode. Mens CDN77 er en god mulighed, vil vi gerne have, at du tjekker ud af disse andre gode tjenester, så du kan vælge den, der bedst fungerer for dig.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map