Langsom WordPress – Min hjemmeside er langsom

Min hjemmeside er langsom?

Langsomme wordpress hjemmesider findes der mange af, og grunden er typisk alle de plugins man installerer, samt det tema man benytter sig af. De er alt for tit programmeret dårligt og med den eneste tanke at det skal være nemt at programmere og nemt for administrator at bruge. Og det er samtidig med at der ingen tanke er på om det de nu bygger, er ordentligt eller ikke. Inden jeg fordyber mig i den store verden af plugins og temaer, så skal det siges at der selvfølgelig altid plads til forbedringer i selve wordpress og den måde de tænker på.

Det generelle wordpress problem

Ja det er rigtigt, der er faktisk et generelt problem med wordpress hjemmesider. Både udviklere af plugins og temaer, men også de der udvikler wordpress tænker sig ikke helt om. Jeg er en af dem der har set mange open source CMS løsninger gennem tiden. WordPress hastighedsproblemer starter i at da wordpress i sin tid blev udviklet, var det kun til blogging, og ikke de store muligheder.

WordPress blev hurtigt stort hvad angår funktioner og muligheder, men databasestrukturen fulgte ikke rigtig med. Hvilket betyder at alle WordPress hjemmesider over tid, vil blive langsomme, medmindre man selv som udvikler og hjemmeside designer, tænker sig om og sikre at det ikke går for vidt. Her tænker jeg både på de som udvikler plugins og temaer, men også hjemmeside designer, webdesignere, hjemmesideejere mf. som kan implementere nogle regelsæt, som sikre at fx databasen forbliver så lille som muligt.

Databasestruktur problemet

Problemet med databasestrukturen gør, at tabellerne som både bruges til at gemme på data, og læse data fra, bliver ret store med tiden, hvis ikke man gør noget ved det. Lad os starte med de to tabeller som hedder

• wp_posts
  Her gemmes indhold, title, url og andre smådata om en given side, indlæg, attachment, produkt, ordre, revisioner, kladder og andre custom posttypes
• wp_postmeta
  Her gemmes alt det andet som ikke er i ovenstående, fx custom fields, og anden meta data som er tilknyttet den pågældende side, indlæg, attachment, produkt (fx priser og andre data fra produktet) og andre custom posttypes. Plugins som indsætter data på de enkelte sider, indsætter det også i denne tabel.

Lad os tage et eksempel, du har en hjemmeside, med 10 sider, 30 indlæg og 10 produkter og ca 5 ordre om ugen. Du har med stor sandsynlighed et billede på både sider, indlæg og produkter. Det betyder at du nu i wp_posts tabellen har minimum 105 rækker, Det er ikke meget. Men tænk lige over hvor mange gange du har gemt indlæg og sider, altså redigeret dem og gemt. det antal kunne godt være 3 gange højere, det er ikke unormalt. Med små sider, bliver det ikke et problem, men sådan som de fleste bruger wordpress, så skaber dette problemer med hastigheden.

WordPress gemmer på en helt del ”Revisions” altså gamle udgaver af sider og indlæg. Dette gør de i samme tabel som de indlæg, sider og attachments der er offentliggjort og ikke offentliggjort på hjemmesiden.

Mange data gemmes i samme tabel

• Sider (1 pr side)
  • Revisions (xxx pr side)
  • Autosave (1 pr side)
• Attachments
  • Revisions (xxx pr attachment)
  • Autosave (1 pr attachment)
• Indlæg
  • Revisions (xxx pr indlæg)
  • Autosave (1 pr indlæg)

Attachments er de mediefiler man har oploadet til serveren, det vil sige billeder, PDF, Word, videoer mf. som du har oploadet, dette gemmes i en tabel, hvilket ikke er unormalt, men de gemmes jo i samme tabel som alt andet, også selvom de ikke er indsat i nogen indlæg.

For at skitserer det lidt mere, sad jeg for ikke mange dage siden og skulle udvikle en hjemmeside i WordPress, og inden hjemmesiden var helt færdig med indhold mm. Altså klar til offentliggørelse, var der allerede kommet over 500 rækker i tabellen for indlæg, sider og attachments, og det var nu engang på en hjemmeside som kun havde 6 sider. Var det optimeret, ville der have været max 30 rækker i tabellen.

Det er dårligt fordi antallet af rækker jo vil blive betydeligt større med tiden, og reelt fylde tabellen op med skrammel efter min mening. Jo flere rækker der er, jo langsommere bliver det at finde frem til den rette data når en side efterspørges. Og det er rent faktisk også det der blandt andet er med til at gøre en wordpress hjemmeside langsom.

Man kan på sin vis sige, at revisions og autosave jo reelt ikke er til for den besøgende, men til for administrator, hvilket også kunne antyde at de to ting ikke bør blive blandet sammen som de i dag gør i WordPress. De burde faktisk, og ja WordPress Teamet må meget gerne lytte med, gøre det sådan at revisions, kladder og autosave er i en tabel, mens de offentliggjorte er i en anden tabel. Og yderligere bør attachments ikke være en del af den tabel, men være i deres helt egen tabel til medier. Det samme gælder selvfølgelig for metadata til de forskellige post types.

Denne metode er fx set i Drupal, opretter man en indholdstype, oprettes der også en tilhørende tabel til revisioner og udgivet indhold. Det fungerer virkelig hurtigt.

WordPress bliver endnu langsommere med custom felter (custom fields)

Benytter du plugins, er der med stor sandsynlighed også brugt custom felter. Dermed ikke sagt at det er noget alle plugins gør, for det er ikke sandheden. Rigtig mange plugins benytter custom felter, udviklere benytter plugins som fx Advanced Custom Fields. Det er bestemt også et godt plugin, og reelt ikke et problem, hvis man ved hvad der sker bag kulissen med de custom felter.

Custom felter bag kulissen

Det er ret smart med custom felter i wordpress, men hvis du ikke tænker dig om, gør du faktisk mere skade end du lige tror og gør derfor wordpress langsommere. Et custom felt kan gemme sig flere steder i databasen. Det kommer lidt an på hvad der er tale om, hvad man tilknytter et custom felt til. fx gemmes custom felter der tilknyttes indlæg, sider og attachments, i tabellen “wp_postmeta”.

Du tænker sikkert, hvorfor er det et problem for wordpress hastigheden? Og jo, det er et problem fordi der rent faktisk gemmes en udgave pr revision og autosave, af det ene custom felt. Det vil reelt sige, har du fx bare 5 custom felter på et indlæg du har redigeret og gemt 10 gange. Så laves der reelt 55 rækker i tabellen som har med de 5 custom felter at gøre.

Bare prøv at skalere det op til hvor mange revisioner og indlæg du har liggende. Det er ikke unormalt at selv nye sider har op imod 1000 revisioner. Hvilket jo så vil give 5000 rækker bare på de 5 custom felter. Tager man gamle sider som har flere tusinde indlæg, og som ikke laver en oprydning i databasen i ny og næ. Vil man kunne opleve op imod 1.000.000 tabelrækker som bare ligger og flyder og rent faktisk ikke bliver brugt.

Alt sammen er med til at gøre det at læse og skrive til databasen bliver langsommere, serveren belastes og ja man får en langsommere hjemmeside

Kan man gøre noget ved en langsom hjemmeside?

Ja man kan godt gøre noget ved lidt af problemerne som kommer når vi har med langsomme hjemmesider at gøre, nedenfor er meget specifikt for wordpress:

• åben wp-config.php og skriv: define(‘WP_POST_REVISIONS’, false);
  det gør så der ikke bliver lavet revisions. Du kan også skrive et tal i stedet for false, det angiver hvor mange revisioner du vil gemme pr indlæg/side.
• Tag backup af databasen med fx UpdraftPlus WordPress Backup Plugin
• installer “WP-Sweep” eller ”wp optimize” og slet alt undtagen den der hedder Transients, samt optimer databasen. Det kan være nødvendigt også at slette orphaned postmeta endnu engang efter revisioner er slettet.
• Log ind i PHPMyAdmin, og slet alle ” _edit_lock ” og “_edit_last” fra wp_postmeta
• Yderligere, slet de Medier du har i mediebiblioteket som du ikke har vedhæftet eller indlejret på nogen sider eller indlæg, eller i andre elementer på wordpress hjemmesiden. Det kan være svært at få det rette overblik, især på store sider med mange billeder og filer i biblioteket. Men jo flere du sletter jo bedre er det.

Husk selvfølgelig altid at tage backup af databasen, før du gør ovenstående på et live site.

Problemer med WordPress Plugins og temaer

Rigtig mange plugins og temaer har det problem at de simpelthen ikke er testet ordentligt igennem, og udvikler har gået for lidt op i hvordan det de har lavet performer. Et eksempel kan være at der i utrolig mange temaer og plugins for den sags skyld, er stor mulighed for at justere forskellige parametre, det kan fx være farver, størrelser mm.

Disse rettelser gemmes i databasen, for så via en PHP fil blive skrevet ud som en fiktiv css fil. Det vil sige at i stedet for at det er en reel statisk css fil brugeren skal hente, er det en dynamisk php fil, som agerer en css fil, og som brugeren oven i købet skal hente på ny næsten hver gang de ser på en side. Og det er fordi PHP filer på de fleste servere ikke bliver cached i ret lang tid ude hos brugeren, typisk hvad der svare til et kvarter.

Hvorfor, tænker jeg, er det ikke lige at de har gjort det sådan at de bare skriver en css fil når administrator laver nogle ændringer i temaet/pluginet (hvilket typisk ikke sker ret tit), det er nogle få linjer kode mere der skal skrives, for at dette kan lade sig gøre, og det giver så meget bedre performance og loadtid at det slet ikke kan betale sig ikke at gøre. Det virker for mig vildt underligt at de ikke gør det der er bedst for dem selv og dem der skal benytte sig af temaet/pluginet, frem for det der er nemmest for dem selv.

Ovenstående er bare et eksempel ud af mange, og det sjove er at det er jo typisk er ret brugte plugins og temaer der ligger inde med lignende fejl.

Andre typiske fejl i plugins og temaer til wordpress

Vil ikke gå så meget i detaljer, men det typiske fejl er at der indbygges rigtig mange funktioner i plugins og temaer. Udelukkende for at ramme så mange brugsscenarier som muligt. Det er selvfølgelig også fint. Men rent faktisk er det bedre at installerer flere små plugins som dækker eksakt det man har brug for. Frem for at installerer færre store plugins som dækker langt mere end det man har brug for.

Ved god mange som prøver at kloge sig på hastighedsoptimering og siger: brug færre plugins, du har alt for mange plugins og meget andet som antyder at hvis man har over 15 plugins, så er det skylden til at din wordpress er langsom. Men det passer ganske simpelt ikke. En langsom wordpress hjemmeside kan ikke defineres ud fra antallet af plugins man har installeret. Det er defineret ud fra hvilke plugins man har installeret, og hvor meget man reelt har brug for funktionaliteten som er indbygget i dem.