Fordelene ved å bruke et CDN for ditt WordPress-nettsted

Å ha en CDN-tjeneste som fungerer ved siden av ditt WordPress-drevne nettsted, er veldig bra hvis nettstedet ditt blir besøkt over hele verden. Spesielt hvis nettstedet ditt er tungt på eiendeler, og når jeg mener eiendeler, mener jeg alle de irriterende javascript-, CSS- og bildefilene.


Disse eiendelene på nettstedet ditt er blant de første emnene som trenger CDN. Hvis nettstedet ditt er en liten blogg, spiller det sannsynligvis ingen rolle siden kuttingen av lastetid vil være ubetydelig, men hva med de store?

For dette eksperimentet vil jeg sette opp en CDN77.com regnskap for nettstedet mitt for teknologi / videospill er det et veldig kostbart nettsted “eiendomsmessig” med en størrelse på ikke mindre enn 2,4 MB og mer enn 95 forespørsler. Når det gjelder lekfolk, er det en tung belastning for nettleseren og serveren å laste. Å være et magasin med mange nyheter, er det ingen måte å gjøre dette bedre på. Serveren er allerede en high-end en, og å måtte kutte på innhold er definitivt en no-go.

Det er mange nettsteder som disse på internett. Jeg hører stadig stemmer om hvor ubrukelig en CDN er for alle slags nettsteder (store eller små), og jeg kan bare ikke la være å undre meg over slike kommentarer.

I denne artikkelen i dag skal jeg undersøke hvorfor CDN-er er viktige og viktige ting (veldig mye). Du vil se, med tall og bevis, hvorfor du har et CDN betyr mye, spesielt hvis du har kunder langt borte fra det stedet serveren din befinner seg. Å måtte laste inn et nettsted med få eiendeler er en ting, men mellomstore til store nettsteder vil ha stor fordel, og jeg vil vise deg hvorfor …

Benchmark med og uten CDN

For dette forsøket skal jeg bruke Pingdom verktøy. Av alle gratis verktøyene du kan komme på for å teste nettstedets faktiske hastighet og lastetid, er Pingdom Tools et av de beste (og mest nøyaktige også). Pingdom-målinger inkluderer ventetider for eiendeler som kan være eksterne og viktigst asynkrone. Lastetiden for en sluttbruker er derfor litt kortere. Først skal vi laste inn nettstedet rett fra serveren, uten noe CDN overhodet. Ta i betraktning at serveren allerede er rask nok, en Xeon som kjører på 3,3 GHz på Nginx med FastCGI-cache er ingen liten bragd og den skal laste ganske raskt på egen hånd.

Uten CDN77 fra San Jose, California

På bildet kan du se at den totale lastetiden er omtrent 2,64 sekunder, for dette eksperimentet har jeg brukt San Jose-serveren i California, USA, siden serveren min ligger i North Carolina, USA, bør lastetiden være lav nok. På høyre skjermbilde kan du se alle ressursene (eiendelene) lastes med de faktiske tidene.

Uten CDN77 fra Stockholm, Sverige

Som du kan se, så snart forespørselen kommer fra et langt sted, begynner ting å gå ned … Nettstedet senket resultatet til 86 og nå er lastetiden rundt 5.20 sek. Dette er hva som skjer når mer enn 95 forespørsler har å reise over hele kloden. Ta hensyn til lysets hastighet, og alle de irriterende filene vil bare øke den totale lastetiden, det er bare ingen vei rundt det.

Med CDN77 fra San Jose, California

La oss nå aktivere CDN77 slik at det begynner å hente ut alle eiendelene automatisk og se hva som skjer …

Nå er dette den første ulempen med å bruke et CDN. Hvis det tolkes feil, kan det føre til en feil oppfatning om at CDN ikke fungerer. Første gang nettstedet lastes inn, må CDN-tjenesten hente eiendelene fra opprinnelsesserveren og laste dem fra det nærmeste stedet der det ble anmodet. Du kan tydelig se lastetiden faktisk har økt til 6.36s, og på høyre bilde kan du se hvorfor. På X-Cache-svaroverskrift er svaret.  CDN-tjenesten svarte med a “GÅ GLIPP AV” noe som tydelig indikerer at eiendelen ikke tidligere var hurtigbufret og måtte lastes “på fly”, det er dette som gjør CDN-løsningen tregere, men bare ved første belastning. Siden eiendelen må gjøre en rundtur fra CDN-tjenesten tilbake til opprinnelsesserveren og deretter tilbake til det interne nettverket og bort til den nærmeste serveren på stedet som ble anmodet. Rundturen er tross alt ikke så treg, men X-Cache-parameteren vil tydelig hjelpe deg med å identifisere når den blir bufret eller ikke. Nå er Pingdom Tools kult eller ikke?

Med CDN77, andre kjøring

La oss se hva som skjer på andre løp …

Den lever! Nå snakker vi. Du kan se at lastetiden reduserte til 2,48 sekunder, som nå er raskere enn den opprinnelige referanseindeksen uten CDN. Også på høyre bilde kan du nå se “TRUFFET” vises i svarhodet, og signaliserer nettleseren at forespørselen er bufret, og at den er levert fra nærmeste server til det stedet uten å måtte gjøre flere tur-retur.

Hva med utsiden av USA

I forrige eksempel så vi at når vi bruker nettstedet utenfor USA og utenfor landet der nettstedet ligger, begynte ting å bli stygt, la oss se hva som skjer med CDN aktivert.

Den første belastningen til venstre ga oss en tid som mer eller mindre lik den opprinnelige referanseporteføljen, om ikke bedre. Dette er uten at den faktiske forespørselen blir bufret. Nå kan du med riktig bilde se forbedringen, og den er ikke liten. Vi har nå gått fra 5.20s uten CDN til et enormt 2.34s å laste inn hele nettstedet, dette en forbedring av mer enn 2X siden nå er bare de grunnleggende PHP-filene lastet fra opprinnelsesserveren, mens alle resten av eiendelene lastes lokalt fra Stockholm-serveren på CDN77 !

Vil du ha et bevis? Sikkert. Her er det:

cdn77-datasentre

La oss gå til det ekstreme …

Uten CDN77 fra Melbourne, Australia

test03-01

Det er så vondt å laste siden fra Australia uten CDN, og nettstedet mitt har nå blitt den tregeste av gjengen, noe som gir en score på 77 og en C, oh well..

Med CDN77 fra Melbourne, Australia

test03-02

Med CDN77 aktivert er hastighetsøkningen imponerende og nesten 2X forskjell. Poengsummen er selvfølgelig tilbake til A, for å bevise at CDN faktisk fungerer, som det skal være.

La oss sette alt dette i perspektiv, skal vi?benchmark-sammenligning

Denne grafen snakker nesten for seg selv om hvordan CDN faktisk forbedrer ytelsen relatert til hvor nettstedet ligger. Hvis leserne / kundene dine får tilgang til nettstedet i samme land / sted der serveren din befinner seg, hvorfor be om et CDN ikke? Det vil ikke gjøre ting bedre. I beste fall vil det bare hjelpe serveren din med ressursene, og den vil redusere CPU-tiden det gjelder, men det vil ikke forbedre lastetiden.  Men så snart en av leserne dine prøver å få tilgang til nettstedet utenfor landet der serveren din er, går ytelsesforbedringen til 2X, veldig enkelt. Det er ingen som benekter, du kan gå foran og gjøre alle disse testene selv. CDN betyr mye hvis nettstedet ditt leses fra hele verden, og det vil også lette båndbreddekravene på serveren din.

Konklusjon

Å ha et CDN på det internasjonale nettstedet ditt er en nødvendighet. Det være seg en teknisk blogg, et digitalt magasin eller et produktnettsted. Hvis du bryr deg om ytelse, og kundene / leserne dine er lokalisert over hele verden, CDN vil faktisk øke hastigheten på WordPress-nettstedet ditt mye. Også, jo flere eiendeler nettstedet ditt laster inn fra de forskjellige stedene, desto større blir forbedringen. Å ha en CDN er ikke en seng med roser situasjon. Å administrere tjenesten på riktig måte er avgjørende for ytelsen. Husk at den første forespørselen alltid vil være tregere, det er veldig viktig å ha CDN-cachen på nettstedet riktig.

I den neste artikkelen vil vi undersøke hvordan du konfigurerer CDN77 service med WordPress, hvordan du konfigurerer beliggenhetene og tar mest mulig ut av det slik at du kan oppleve de samme fordelene som i denne artikkelen. Følg med!

Gratis CDN-tjenester

Ikke glem å sjekke innlegget vårt om de beste gratis CDN-tjenestene der ute. Noen av disse er 100% gratis opp til et bestemt punkt, mens andre er gratis i en prøveperiode. Selv om CDN77 er et godt alternativ, ønsker vi deg å sjekke ut disse andre gode tjenestene, slik at du kan velge den som passer best for deg.

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