WordPress eksponenten – hvordan håndtere treg WordPress

  1. Hvorfor er min WordPress så treg?
  2. Hvorfor hjelper ikke cache-innstikkene på hastigheten?
  3. WordPress er ikke like treg på andre servere, det må være noe galt med serveren!

Hvis du har problemer med en treg WordPress, eller kjenner igjen utsagnene over, så er du ikke den første, og garantert ikke den siste personen som føler at WordPress ikke helt svarer til forventingene til hastighet. Det er en grunn til dette, og den blir heretter kalt «WordPress eksponenten» (WP):

Websidens treghet = WPWP

Dette betyr i all enkelhet: Jo større WordPress, jo tregere vil nettsiden bli.

«Stor WP»?

Definisjonen av en «Stor WP» har ingenting med mengden innlegg eller trafikk. En webside med 1 million innlegg, 1 million bilder og millioner med besøkende trenger ikke å ha en «stor WP». Alle disse utfordringene løses med et godt serveroppsett, god caching og et godt tema.

Størrelsen på din WP øker med mengden jobb serveren må gjøre hver gang WordPress skal lastes inn, og dette er en av de største svakhetene til WordPress: Serverloaden blir raskt veldig høy.

Typiske kilder til større WP inkluderer bl.a. følgende:

  • Legge til et ekstra innstikk
  • Bruk av et teknisk dårlig tema
  • Bruk av et teknisk dårlig innstikk

Det krever litt forklaring for å forstå hvorfor dette øker størrelsen på serverloaden. Man må få et innblikk i hvordan WordPress fungerer.

Å lagre en ny tittel

Tenk deg at du sitter i kontrollpanelet til din WordPress og redigerer ditt siste innlegg (nyhet, side, hva som helst.. ). Du oppdager en skrivefeil i tittelen, justerer kjapt dette og trykker på den store fine blå «Oppdater»-knappen. Nå har du gjort din del av jobben, WordPress tar over for å fullføre det du har påbegynt: endre tittelen på ditt innlegg. Det burde være en enkel sak å bytte et par bokstaver  i dagens moderne samfunn, ikke sant?

Det som burde skje nå:

  1. Det sendes data til serveren som inneholder bl.a. din nye titteltekst og noen andre nyttige informasjoner.
  2. En databasekopling opprettes.
  3. Sikkerheten først, din innlogging og annet blir verifisert (Er du en bruker som har tilgang til å endre tittelen på denne websiden i denne situasjonen?)
  4. Teksten på tittelen endres i databasen
  5. Man sendes tilbake til redigeringen av innlegget hvor man får se om det fungerte eller ikke.

woho-1024x538
Suksess!

Det WordPress -faktisk- gjør nå:

Denne listen er litt omfattende, men legg spesielt merke til #8, #9 and #10. Det er nødvendig å forklare dette for å forstå treg WordPress:

  1. Data sendes til serveren og inneholder bl.a. din nye titteltekst og noen andre nyttige informasjoner.
  2. WordPress forbereder basiskonfigurasjonen sin fra bunnen av og oppretter en databasekopling.
  3. WordPress laster inn alle sine filer: Kjernefilene, og alt det andre den trenger for å fungere.
  4. Deretter laster den inn alle de store (!) funksjonsfilene, klassefilene (f.eks. brukerhåndtering, wpdb, rest API… ), starter en timer, og sjekker om den er blitt installert.
  5. …forsøker å normalisere verdier på tvers av mange plattformer (WordPress kan kjøres på mange typer systemer)…
  6. …Planlegger en rekke hendelser (actions/filters) som skal filtrere, rense, normalisere, forberede og laste inn flere ting senere (har ikke begynt å se på dine innsendte data – enda!).
  7. .. begynner å laste inn innebyggede innstikk og widgets. Din bruker verifiseres på et eller annet tidspunkt.
  8. Innstikk lastes (som betyr at hvert eneste innstikk lastes fullt inn og KJØRES)
  9. Temaet functions.php fil lastest (full lasting og KJØRES)
  10. WordPress begynner å kjøre sine viktigste planlagte hendelser (actions/filters), slik som after_setup_theme, init, og wp_loaded
  11. ???
  12. Innstikket er nå lagret – profit (?)
  13. Man sendes tilbake

Og dette er bare toppen av isfjellet.

tldr
«Ineffektivt»

Påstand: «WordPress har eksistert lenge, og lært seg hvordan man verifiserer alt på en ordentlig måte, selvfølgelig er det mye som skal skje, selv for en enkel justering!»
Sant, og WordPress gjør antagligvis mange gode filtreringer, normaliseringer og sikkerhets-relaterte ting. Størrelsen på denne koden er ikke problemet. Dette er ikke grunnlag for hvorfor din WP er stor, og WordPress treg.

Problem #8, første del av problemet

WordPress laster inn alle dine innstikk når du lagrer tittelen. Den laster alle dine innstikk hver gang noen besøker forsiden din (untatt når man har god caching), og hver gang noen klikker «rediger» på et innlegg. Faktisk lastes alle innstikk fullt ut og kjøres hver gang WordPress mottar en spørring.

Jo flere innstikk du har, jo mer kode skal lastes og kjøres fullt ut hver gang WordPress gjør noe, som inkluderer å vise en side, gjøre en ajax-spørring (admin-ajax.php), lagre et innlegg, alt og hva som helst!

Problem #9, enda en del av problemet

Temaet ditt lastes inn når du skal lagre en tittel. Akkurat som med innstikk, vil din temafil «functions.php» lastes fullt og kjøres på hver spørring i WordPress.

Hvorfor i huleste skal temaets filer lastes når man skal lagre en tittel i databasen? Den skal ikke vises i løpet av «lagre tittel»-spørringen, og temafiler er kun ment å skulle vise innhold!

WordPress-systemet bryr seg ikke om dette. Dette «problemkonseptet» er synlig over hele WordPress arkitekturen.

Problem #10, den siste delen av problemet

En påminnelse:
#10:

  1. WordPress begynner å kjøre sine viktigste planlagte hendelser (actions/filters), slik som after_setup_theme, init, og wp_loaded

I løpet av #8, og muligens i løpet av #9, vil alle innstikke laste inn sine filer og kjøres. Disse planlegger også hendelser som skal kjøres i løpet av «init», «wp_loaded»… Disse forbereder alle mulige slags filter og registrerer egendefinerte innleggstyper, legger til spesialfelter, tømmer mellomlagring, sender epost, kjører wp-cron.php osv.

Hvert eneste innstikk legger til mer arbeid for serveren når noe skal lastes, og i løpet av prosessen legges det til VELDIG MYE arbeid for serveren når planlagte hendelser begynner å kjøres.

Innstikk kan også kjøre sine egne hendelser, og til og med kjøre andre hendelser på nytt. De er svært kreative, og sparer ikke på datakreftene for å få sin jobb gjort.

Innstikk kan også legge til filter til andre hendelser, som betyr at hvert innstikk kan øke arbeidsmengden for andre innstikk.

Et faktisk eksempel

Tenk at du har 20 innstikk i din WordPress. Hvis en av disse innstikkene legger til 1 millisekund ekstra på lastetiden til hver av de andre 20 innstikkene, så betyr det totalt 20ms ekstra lastetid. Ingen problem

Men:
Hvis alle 20 innstikk legger til 1ms ekstra lastetid på alle de andre 20 innstikkene, så betyr det plutselig 400ms ekstra lastetid! Det er nesten et halvt sekund ekstra, og er ikke uvanlig. Dette er en vanlig kilde til treghet i din WordPress.

Så legger du til et ekstra innstikk som tilfeldigvis 1ms ekstra til alle innstikk, og nå har du totalt 441ms ekstra lastetid!

Hva om en av innstikkene tilfeldigvis mer enn 1ms til alle andre innstikk? Da øker tallet plutselig veldig fort.

Dette potensielle problemet er tilstede i hver eneste spørring i din WordPress, i alle situasjoner og alle steder, på alle WordPress installasjoner, uansett om din host påstår at «Våre WordPress er raskere».

needs-conclusion

Jeg trenger mine innstikk og mitt themeforest tema med fancy ting og..

Nei det gjør du ikke. Slutt å samle på innstikk, og skaff deg et ordentlig tema. Installer WP Fastest Cache og hold den aktiv. Med sunnfornuft kan din trege WordPress bli betydelig kjappere!