WP-motor med WP-rakettbuffer – Gjør det faktisk en forskjell? Er det verdt det?

WordPress-tilbud


Hvis du noen gang har prøvd å installere en cache-plugin mens du bruker WP Engine, vil du vite at WP Engine forbyr alle cache-plugins fordi de forstyrrer EverCache-systemet på servernivå..

Vel, alle hurtigbuffer-plugins bortsett fra en: WP-rakett. Faktisk er WP Rocket en del av WP Engines ‘Preferred Plugin Program’, og du står helt fritt til å bruke WP Rocket med WP Engine.

Det fikk oss til å lure på: Gjør det faktisk en forskjell å bruke WP Rocket med WP Engine? Det vil si at hvis du allerede betaler for WP Engine og alle ytelsesoptimaliseringene de implementerer på servernivå, er det fortsatt verdt å bruke WP Rocket for å øke hastigheten på nettstedet ditt ytterligere?

For å finne ut av det, satte jeg opp en testside på WP Engine og kjørte den gjennom noen tester for å sammenligne hvordan den fungerer med WP Rocket og uten, og jeg kommer til å dele disse dataene med deg.

Men før jeg kommer til det, la oss diskutere hva som faktisk skjer når du kobler sammen disse to …

Hva skjer når du bruker WP-rakett med WP-motor?

Som jeg nevnte ovenfor, inkluderer WP Engine caching på servernivå som standard via EverCache-systemet. Hvis du ikke er sikker på hva cache er, kan du sjekke dette innlegget, og du kan også lære mer om WP Engine i WP Engine-gjennomgangen vår.

WP-rakett ved WP Engine Solution Center

På produktsidene deres er WP Engine ganske vag med hva EverCache faktisk gjør (utover ‘caching statisk innhold på nettstedet’). Så for å få en mer detaljert forklaring, rakte jeg til supportteamet deres, som fortalte meg at det i utgangspunktet var en kombinasjon av:

  • Lakker hurtigbufring.
  • Bufret cache-lagring av objekter.

Dette systemet overlapper mange cache-plugins – inkludert WP Rockets sidebuffer-funksjonalitet – og det er grunnen til at WP Engine forbyr hurtigbufring-plugins fra plattformen deres.

Så, hvordan kan de samarbeide, da?

For å unngå konflikter, vil WP Rocket automatisk deaktivere sidebuffer-funksjonaliteten når du installerer den på et nettsted på WP Engine. Så, WP Rocket foretar ingen hurtigbufring når du bruker den med WP Engine, noe som betyr at du går glipp av et av WP Rockets største salgsargument.

Selv uten hurtigbufferfunksjonalitet tilbyr WP Rocket likevel en rekke andre ytelsesforbedringer som du kan dra nytte av, inkludert:

  • Minifisering og sammenkjøring – krymper og kombinerer HTML-, CSS- og JavaScript-filer uten å endre funksjonaliteten.
  • Lat lasting av bilder og videoer – venter på å laste bilder eller videoer under folden til brukeren begynner å rulle nedover på siden.
  • Utsett JavaScript – fremskynder de opplevde sidelastetidene ved å vente på å laste JavaScript til etter at siden er blitt gjengitt.
  • Kontroll av hjerteslag – lar deg begrense eller deaktivere WordPress Heartbeat API for å minske belastningen på serveren din.
  • Diverse finpusse – for eksempel å deaktivere emoji.

I tillegg renser WP Rocket automatisk WP Engine-hurtigbufferen når du tømmer hurtigbufferen i WP Rocket, som er en fin bonus når det gjelder bekvemmelighet.

Dette innlegget handler i bunn og grunn om å oppdage hvor mye disse ekstra ytelsestilpasningene kan bevege nålen på nettstedets ytelse.

Kjører noen tester: WP Engine og WP Rocket

For å finne ut hvor mye av forskjellen WP Rocket gjør på WP Engine, satte jeg opp en testside på WP Engine’s Startplan.

Dette testnettstedet bruker Avada-temaet og et komplett Avada-demoside, i tillegg til noen plug-in bak kulissene som Yoast SEO. I utgangspunktet prøvde jeg å tilnærme meg et ‘ekte’ WordPress-nettsted.

Deretter brukte jeg WebPageTest til å teste nettstedet:

  • uten WP Rocket (dvs. bare ved å bruke WP Engines innebygde ytelsesjusteringer)
  • med WP Rocket fullkonfigurert (jeg vil dele konfigurasjonsmetoden min etter testdataene).

Jeg brukte WebPageTest fordi jeg ønsket en god måte å tallfeste WP Rockets late lasting, som WebPageTest’s Hastighetsindeks gjorde en god jobb med å fange. ‘Hastighetsindeksen’ er ‘den gjennomsnittlige tiden der synlige deler av siden vises’. I utgangspunktet hvor raskt innholdet over folden er synlig for folk, noe som bør fange opp effekten av lat lasting.

For å prøve å fjerne så mange variabler som mulig, kjørte jeg tre separate WebPageTest-tester på tre separate dager.

Hva mer er, jeg satte opp hver WebPageTest-test som skal kjøres fem separate tester seg selv og ta medianverdien. Så alt i alt var det 15 separate tester for hver konfigurasjon, noe som gjorde en god jobb med å eliminere en enkelt-testvariabilitet.

For referanse, var mitt WP Engine datacenter i South Carolina, og jeg brukte WebPageTests Dallas, TX-plassering og emulerte en 5 Mbps kabelforbindelse ved å bruke Chrome-nettleseren.

Her er dataene:

Dag 1:

konfigurasjon

Lastetid

Hastighetsindeks

Fulllastet

Ingenting

4.296 sekunder

4.400 sekunder

4.798 sekunder

WP-rakett

3.959 sekunder

4.312 sekunder

4,407 sekunder

Dag 2:

konfigurasjon

Lastetid

Hastighetsindeks

Fulllastet

Ingenting

3,932 sekunder

4.172 sekunder

4,403 sekunder

WP-rakett

3.819 sekunder

4.062 sekunder

4,377 sekunder

Dag 3:

konfigurasjon

Lastetid

Hastighetsindeks

Fulllastet

Ingenting

3,376 sekunder

3.699 sekunder

3.845 sekunder

WP-rakett

2.491 sekunder

2,919 sekunder

5,289 sekunder

Terminologi forklart

Her er definisjonene for de tre begrepene fra WebPageTest:

  • Lastetid – ‘tiden fra starten av den første navigasjonen til begynnelsen av vinduet last hendelse (onload)’.
  • Hastighetsindeks – ‘gjennomsnittlig tid der synlige deler av siden vises’.
  • Fulllastet – ‘tiden fra starten av den første navigasjonen til det var to sekunder uten nettverksaktivitet etter at dokumentet var fullført. Dette vil vanligvis omfatte all aktivitet som blir utløst av JavaScript etter at hovedsiden er lastet inn. ‘

Hvordan jeg konfigurerte WP-rakett for disse testene

Som referanse skrudde jeg ganske mye på WP Rocket. Jeg aktiverte …

  • minifisering og sammenkoble for HTML, CSS og JavaScript
  • optimaliser CSS og JavaScript levert for å eliminere render-blokkeringskode
  • lat lasting for bilder og video
  • Heartbeat API-kontroll (jeg deaktiverte APIen helt)
  • alle justeringer av misc-ytelse, for eksempel å deaktivere emoji.

Så gjør bruk av WP-rakett med WP-motor en forskjell?

Fra dataene ser det ut til at det fortsatt er en fordel å bruke WP Rocket selv på WP Engine. Med WP Rocket aktivert lastet nettstedet raskere på alle tre dagene jeg kjørte tester (og husk at hver test i seg selv var fem separate kjøringer).

Når du vurderer hva WP Rocket gjør, er det absolutt fornuftig.

Tilpasninger som filminifisering / sammenheng, lat lasting, optimalisering av levering og så videre, er alle gode råd for å få fart på WordPress-nettstedet ditt.

Trenger du WP Rocket for å gjøre disse optimaliseringene? Ikke nødvendigvis. Du kan bygge en gratis stabel med plugins med lignende funksjonalitet. For eksempel:

  • Automatisk optimalisering for minifisering og skriptoptimalisering.
  • Lazy Load for lat lasting (en gratis plugin fra WP Rocket-teamet).
  • Heartbeat Control for å begrense eller deaktivere Heartbeat API (en annen gratis plugin fra WP Rocket-teamet).
  • WP-Optimaliser for å rense databasen
  • Clearfy for misc ytelse justeringer.

Imidlertid tror jeg det er verdien i bekvemmeligheten og enkelheten ved å kunne gjøre alt dette fra én plugin (WP Rocket), noe som kan rettferdiggjøre $ 49-prislappen.

I tillegg er to andre fordeler med WP Rocket i forhold til gratisalternativene:

  • Premium support, i tilfelle du trenger hjelp med å konfigurere alle de tingene.
  • WP Rocket integreres med WP Engine’s Lakk-cache, som lar deg rense cachen din via WP Rocket (bare en fin liten bekvemmelighetsfunksjon).

Hvis det er verdt $ 49 for deg, kan du lære mer om hvordan WP Rocket fungerer i WP Rocket-gjennomgangen vår.

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