Langsom Wordpress - min hjemmeside er langsom?

Hvorfor bliver din hjemmeside langsom, og hvorfor bliver en wordpress hjemmeside det?

Rigtig mange døjer med en langsom WordPress hjemmeside, og dette er der flere årsager til. Selvom WordPress kan virke langsomt, er det ikke fordi WordPress i sig selv er langsomt. Sagt på en anden måde, så er WordPress løsningen i udgangspunktet ikke langsomt, den reelle fejl ligger derfor et andet sted. Dermed ikke sagt at der ikke er plads til hastighedsforbedringer i wordpress.

langsom wordpress

Hvorfor bliver wordpress langsom?

Der er mange årsager til at wordpress bliver langsom. I dette indlæg beskriver jeg nogle af de årsager, som blandt andet dækker over det rette temavalg, oprydning i databasen, plugins og meget andet.

Hvorfor er temavalg noget nær det vigtigste?

Temavalg er noget nær det vigtigste fordi det valg du tager her, er hele fundamentet i den måde som din hjemmeside arbejder og ser ud. her tænker jeg ikke kun på visuelt, men også kodemæssigt. Læs yderligere om dette i et dedikeret indlæg om det rette temavalg her.

Hvad kan jeg gøre for at min hjemmeside bliver hurtigere?

At gøre sin hjemmeside hurtigere er alpha omega når du skal konkurrere på søgemaskiner som Google. Men det du kan gøre er at lærer hvordan. Det kan du blandt andet læse i ovenstående indlæg, eller på siden om hastighedsoptimering

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 problem

Ja der er et generelt problem, og det er at de fleste wordpress udviklere, inklusiv dem der udvikler wordpress, ikke tester deres løsninger på små servere, som de fleste jo køber sig til når de skal have en hjemmeside. Og yderligere har de ikke rigtig tænkt sig om hvad angår databasestruktur, inkludering af css og JS filer og mange andre småting, som tilsammen gør at systemerne køre dårligt efter noget tid, og man bliver som WordPress udvikler nødt til enten at programmere nogle elementer om, eller flytte til en større server, hvilket de fleste vælger da det er nemmest. Men det betyder jo ikke at det er godt at gøre da man jo bare flytter på en langsom wordpress hjemmeside.

Hvor tænker WordPress sig ikke om

Et eksempel er at WordPress gemmer på en helt del ”Revisions” altså 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.

Ja du læste rigtigt, det er rigtig mange ting de gemmer i samme tabel, og som du kan se nedenfor, har de ikke tænkt sig helt om der, dette er hvad der gemmes:

  • 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, og er der selvom de ikke er indsat i nogen indlæg.

For at skitserer det lidt, 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 kun have været 6 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.

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 50 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 at database læsninger bliver langsomme, serveren belastes og ja man får en langsommere wordpress hjemmeside

Kan man gøre noget ved det?

Ja man kan godt gøre noget ved lidt af problemerne i ovenstående:

  • å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 , 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.

Afslutning

Læser du ovenstående som WordPress Udvikler, skal du tænke over hvordan du bygger plugins, temaer og funktioner til WordPress. Det er nemlig ikke helt så nemt som det måske kan virke, hvis det altså skal laves ordentligt. Ting du bør have med i dine tanker er, hastighed, og at det du laver skal fungerer godt på små servere og mange brugere. Keep it Simple. Der er nemlig stort set ikke noget du ikke kan lave som samtidig også fungerer godt på små servere, der er selvfølgelig undtagelser, men der er langt imellem dem.

Det betyder ikke at du er en af dem der ikke tænker sig om, men problemet er jo med så mange andre Open Source løsninger, at der er mange udviklere som gerne vil levere et plugin, et tema eller en anden funktion til omverdenen. Både for at få navn ud, men glem ikke at de også gerne vil tjene penge. Og det vil til hver en tid være sådan at disse udviklere er på vidt forskellige stadier hvad angår viden, men samtidig også vidt forskellige mangler de prøver at afdække. Fælles er dog typisk, at de kun tænker hvordan når jeg målet, frem for at tænke hvordan når jeg målet på den bedste måde.

Er du WordPress ejer og har en langsom WordPress hjemmeside, så prøv at gøre ovenstående først. Og gå derefter temaer og plugins igennem for at se om de har fejl, for det har de typisk. Kan du stadig ikke få din wordpress hjemmeside hurtigere, så læs her om hastighedsoptimering.

kim tetzlaff

Om forfatteren

Se mere Kim Tetzlaff

Jeg har siden 1995 arbejdet med og haft stor fokus på Teknisk SEO og hastighed på hjemmesider. Jeg er programmør, nørd og stolt af det. Jeg bygger hjemmesider, hastighedsoptimere, ser på det SEO tekniske og det er mere end 25 års erfaring der ligger bag – Du er i gode hænder når jeg laver noget for dig 🙂

Skriv en kommentar

Kategorier og tags på dette indlæg

, , , , ,

Måske du også vil læse disse indlæg

Ja, jeg har også skrevet andre indlæg som måske kunne have din interesse