Er din hjemmeside også for langsom?

WP Rocket – sådan optimerer du hastigheden

WP Rocket er et hastighedsplugin til wordpress, som er nemt at bruge og opsætte. Det er ikke ligesom alle andre hastighedsplugins til wordpress hvor man enten kan alt for meget, eller kun har muligheden for meget få ting, eller endnu værre, slet ikke kan bruge alle funktioner fordi det er for svært. Det skal dog siges, jeg som hastighedsekspert, kun bruger dette plugin når jeg har foretaget den reelle hastighedsoptimering. Det er kun lige for at sætte prikken over i’et.

Herunder vil jeg prøve at guide dig gennem hver eneste funktion og mulighed der er med WP Rocket, sådan at du er i stand til at opsætte pluginet helt selv, og uden at du reelt behøver at bruge en hastighedsekspert til netop dette plugin.

Hvad er WP Rocket?

Vi har været inde på det, men WP Rocket er et betalingsplugin til wordpress, som man bruger til at hastighedsoptimere hjemmesiden yderligere. Den har funktioner som fx,

  • html cache separat for mobil og computer, og for indloggede brugere
  • minificering af html, js og css
  • sammenlægning af css, js og google fonts
  • Above the fold optimering af css
  • deferred load af javascript
  • lazyload af billeder, baggrundsbilleder og iframes
  • Oprydning af emoji, embed scripts og database
  • integration med CDN, Varnish, Cloudflare og Securi
  • Heartbeat styring
  • Egen hosting af google analytics og facebook pixel
  • Woocommerce understøttelse

Det bedste af det hele, du skal i de fleste tilfælde bare hakke af og gemme. Det er ret sjældent du skal gøre andet end det. Men følg guiden herunder, for selvfølgelig kan ting jo gå galt, og du får her info om de fejl som typisk kan ske.

Hvilke problemer kan der opstå?

Som ved alle andre hastighedsplugins, kan der opstå hvad som helst. I de fleste tilfælde er det typisk designfejl eller javascriptfejl. Det er ret sjældent at WP Rocket decideret lægger et site ned eller gør sitet ubrugeligt. Det kan selvfølgelig ske, og derfor er det også godt hvis du som hjemmesideejer selv lærer at opsætte dette plugin, for ingen kender dit site bedre end du selv gør. og læser du denne guide, så er jeg sikker på at du vil være i stand til både at opsættedet og rette eventuelle fejl der kunne opstå.

Hvor bør du starte din optimering?

Hvis jeg skal svare som hastighedsekspert, er svaret altid at plugins som dette, ikke er svaret på alle dine hastighedsproblemer. Men det er en nødvendighed for at få et super hurtigt wordpress site. Det er derfor et ret godt supplement til alt det andet du faktisk også bør gøre, eller få en som mig til at gøre.

Jeg kan ikke komme ind på alt det du bør gøre, men i stedet understrege at ingen hjemmesider kan nøjes med brugen af dette plugin. Man kan komme rigtig langt, men ikke langt nok – Fx skal du se på at rette fejlene som blandt andet WP Rocket prøver at rette op på og lave temaet bedre, eller se på om de plugins du bruger nu også bruges, eller helt se på om temaet er alt for stort osv. Jeg har skrevet mange indlæg her på bloggen om netop alt det.

Hvorfor fortæller du det?

Ja det er faktisk et godt spørgsmål når nu det overvejende er hastighedsoptimering jeg laver.

Men faktum er bare at det at opsætte et plugin som dette, er en så lille del af den reelle optimering, at du lige så godt kan lære at gøre det. eller i hvert fald ved at det er muligt for dig at gøre.

Men hvad er der så tilbage til dig?

Der er faktisk mange ting. Det jeg blandt andet ser på i min optimering er at optimere css, js, billeder, video, eksterne elementer, tema, plugins, fonte etc. fx er det ofte nødvendigt at optimere på hvornår plugins loader sine js og css filer. det er nemlig sådan at et plugin typisk loader globalt på alle sider, men kun bruges på en eller to sider. Det er også ret ofte sådan at der er en del css og js kode som slet ikke bruges, og derfor skaber en del overhead. Yderligere er det også ret ofte sådan at der er funktioner i et tema, som er overflødige og slet ikke bliver brugt.

Alt sammen er med til at gøre hjemmesiden langsom både set med serverbriller og browserbriller.

Men lad os starte guiden til opsætning af WP Rocket

HTML Cache

Cache – HTML Cache

HTML cache er ret vigtigt for dette plugin, det er nemlig en af de grunde til at man installerer dette plugin, for at benytte sig af html cache. Der er flere muligheder i WP Rocket for dette, fælles er dog at det er HTML cache vi snakker om, altså det at lave reelle html filer som serveres til brugeren i stedet for at gå hele møllen med WordPress, PHP og database igennem. Det betyder at sitet og serveren bliver aflastet en helt del og kan håndterer langt flere besøgende på en gang. Det er nemlig tit det at brugerne skal igennem hele møllen der gør at et site går ned eller at TTFB bliver alt for høj.

HTML caching er aktivt allerede når du aktiverer WP Rocket, men du skal tage stilling til følgende:

  • om mobile enheder også skal have en cachet udgave af sitet
    Det er ikke ret tit jeg møder sites i disse mobile tider der ikke skal have denne aktiveret, den er som standard aktiveret, og bør også være sådan for 99,9%
  • om den mobile cache skal være forskellig fra standard cachen
    Det er ikke ret tit denne skal være aktiv, da de fleste bygger eller opsætter responsive hjemmesider. Det er typisk kun hvis det mobile site er et helt andet design der bruges, eller hvis der sker ting som er lavet på serversiden, fx hvis funktionen wp_is_mobile() bruges til at vise og skjule indhold.
  • om brugere der er logget ind også skal serveres en cachet udgave.
    Dette gør man på sider hvor brugeren har mulighed for at oprette en bruger og logge ind efterfølgende. Det kan fx være på medlemssites eller webshops hvor dette er en mulighed. Standard cachen vises nemlig ikke i forskellige situationer, herunder også når brugeren er logget ind.
  • Hvor lang tid skal cachen virke?
    Standard indstillingen er fin for de fleste, men har du et site som ikke har så mange dynamiske elementer eller har du et site som netop har mange dynamiske elementer, så skal du enten forhøje eller nedsætte dette tal. Typisk siger jeg 1-2 timer ved højt dynamiske sites, eller 10-uendeligt (0) ved sites der ikke er så dynamiske.

Hvornår får brugeren ikke en cachet udgave?

Brugeren får typisk ikke en cachet udgave af siden ved kurven og checkud når vi snakker webshops, de er højt dynamiske og ikke mindst unikke, og skal derfor ikke caches. Dette sørger WP Rocket selv for ikke sker. Dernæst hvis der er en GET query i urlen (fx ?test=test) så vises der heller ikke en cachet udgave. Dette kan man dog ændre under Avancerede regler, mere om det senere.

Hvilke fejl kan du opleve når html cache er aktivt?

Der er reelt ikke mange fejl du kan opleve her, men oplagt er det at sider som ikke skal caches, alligevel caches. Her tænker jeg ikke på de sider jeg før nævnte, men hvis du fx har indbyggede funktioner på sider som ikke tåler at blive cachet. En anden oplagt en er at cachen for en eller flere sider er for lang, og brugere derfor ikke ser opdateringer så hurtigt som du vil. Her skal du tænke på at WP Rocket selv opdaterer cachen i ny og næ, også når du fx gemmer indlæg, eller anden data. Og man kan opsætte via programmering at den skal gøre det i specifikke tilfælde og på specifikke sider. men det kræver noget mere. Alternativt, skal du bare nedsætte den tid cachen gemmes i.

Fil optimering

Fil optimering

Filoptimering er optimering af html, css, js og google fonts. Dette er vigtigt for hjemmesidens hastighed både at søge for at filer fylder mindre, men også hvis man loader mange filer kan reducerer antallet af js og css filer der hentes. Ja http2 kan klare at hente mange flere filer på en gang, men det er alligevel en god ide i de fleste tilfælde at reducerer antallet, især fordi mange sites benytter rigtig mange plugins som hver typisk har deres egen js og css fil.

Basis indstillinger

I de fleste tilfælde skal alle indstillinger her, være aktive. Det der dog kan ske er hvis der er lavet fejl i css, så kan man risikere at html minificering kan ødelægge designet. Det sker dog ikke ret tit. hvorfor jeg anbefaler at den er aktiv, og man så prøver at finde fejlen man har lavet i stedet for.

  • HTML minificering
    Dette sørger for at fjerne linjeskift, mellemrum og meget andet fra selve html koden. Det gør at første kald som alle brugere foretager bliver mindre. Vi snakker typisk ikke mange kb, men ret tit er det mellem 2-5kb man spare ved denne manøvre. Samtidig er det også hurtigere for browseren at renderer minificeret kode.
  • Sammenlæg Google fonte
    Ret tit oplever man at temaet henter google fonte, at plugins også gør og somme tider er dette mange kald til google for at hente de filer som fortæller hvilke skrifttyper der skal gøres klar til at hente. Denne reducerer antallet af kald til 1 kald. Det bedste er dog slet ikke at foretage kaldet, og i stedet indsætte den kode som hentes direkte i selve html koden.
    – Tip. Brug slet ikke Google fonte, men i stedet benyt dig af System fonte. Det gør jeg fx her på siden.
  • Fjern query fra statiske filer
    Query på css og js filer er ikke godt for browserens cache af de filer. Selvfølgelig er de blevet bedre til det, men generelt er det bedst ikke at have denne dynamik på statiske filer, hvorfor det er bedst at fjerne det. Det sørger denne for.

CSS filer

Her har du muligheden for at minificere, kombinere og optimere “above the fold” over folden CSS. Som minimum skal du minificere css filer. Det fjerner både kommentarer og det man kalder whitespace (mellemrum, tabs, linjeskift etc) fra CSS filerne. Det gør filerne mindre og ret tit sparer man ret mange KB bare ved denne manøvre. Det gør også at browsere og især mobile enheder henter disse filer hurtigere.

Dernæst kan du vælge at kombinerer css filer, altså at sammenlægge dem. Her skal du dog lige foretage nogle tests for at se om det giver et bedre resultat at sammenlægge dem, for ret tit skaber det en højere onloadtid, som jo er blandt andet den vi gerne vil have så lille som muligt.

Er der noget som går i stykker?

Så har du muligheden for at ekskluderer de css filer som ikke tåler sammenlægning eller minificering, via tekstboksen “Excluded CSS Files”.

Optimer CSS (Over folden)

Man gør dette for at optimere renderingstiden, altså den tid som browseren bruger på at vise brugeren design, indhold etc. Det er ikke det eneste som optimere renderingstiden, men den er med til det.

Det der sker er at den sender hver side til en ekstern kilde, eller det vil sige en side fra hver indholdstype til en ekstern kilde, som så sender det CSS tilbage som skal bruges over folden. Dette virker tit på mindre sider, men vær varsom med at bruge den på større sider, da siden tit kan gå i stykker visuelt. Og jeg oplever faktisk at designet i sit udgangspunkt lige starter ud med intet design for så at få designet koblet på. Dette indikerer at det eksterne værktøj endnu ikke er godt nok til at fange alt der skal bruges over folden.

Det ville ellers være smart hvis den kunne gøre arbejdet 100% on the fly og hvor det så også 100% virkede. Men det kan den desvære ikke endnu. Men prøv den af, og test for at se om det virker for netop din side. En anden ting du lige skal være obs på her er at den endnu ikke tager højde for mobile enheder, altså den tager selvfølgelig det responsive design, men du kan risikerer at det lidt mangler for den mobile udgave. Især hvis designet til den mobile udgave er et helt andet end det til computer.

Når du har aktiveret den, så får du også muligheden for at indsætte noget CSS som er din udgave af Above the fold css, Dette slår dog KUN igennem hvis ikke WP Rocket kan generere den css selv.

Hvad er bedst?

Det er ikke svært at forestille sig de ting der kan gå galt når det sker on the fly, så derfor er det bedst at du selv sætter dig ned og optimere på netop dette. Det vil sige at du selv laver den kode som styre alt der skal vises over folden og du selv sørger for at filer loader asynkront. Du skal nok bruge en professionel til netop dette arbejde. Men det giver et bedre resultat i mange tilfælde.

javascript filer

Under optimering af javascript har du nogenlunde de samme muligheder som nævnt ovenfor. og de samme regler gælder også her. Der hvor der er en forskel er ved load af javascripts. Der har du muligheden for at loade javascripts defered som man kalder det. Det betyder at javascripts downloades, men læses først når DOM (Document Object Model) Også kaldet html koden, er læst. Det er også det samme som at de loades ikke blokerende.

Typisk vil man sætte hak i både Load javascript defered og safe mode for javascript. Men jeg vil anbefale dig at teste om du måske kan undlade at sætte hak i Safe mode. Da det nemlig også gør at selve jquery scriptet også loades defered og ikke blokerende. Men test det grundigt.

Medier

Media – Optimer billeder, iframes og video

Det er her man optimere de ting der har med billeder og medier at gøre. Og som en ekstra lille ting kan man også deaktiverer emojis, altså smilies etc.

Lazyload

Lazyload af billeder og iframes er en ret god feature. Det sørger for at loade billeder og iframes når brugeren reelt ser på dem. Altså de loades “on the fly” når brugeren scroller ned til et billede eller en iframe. Det vil sige det er bygget sådan at det er lige før brugeren rammer billedet at det hentes og loades. Det gør at siden i første omgang ikke skal hente mange billeder eller iframes.

Som noget nyt virker dette også på baggrundsbilleder. Dog ikke endnu baggrundsbilleder som loades via css filer. Det er kun inline baggrunde der loader via lazyload når dette er aktivt.

I langt de fleste tilfælde skal det være aktivt for både billeder og iframes, der kan dog være nogle tilfælde hvor lazyload ikke virker efter hensigten, og fx ikke viser billeder/iframes når brugeren scroller til det. I de tilfælde skal du ikke deaktivere, men i stedet gøre så netop de elementer der ikke vises, i stedet slet ikke er en del af lazyload. Dette er der mange løsninger på, den nemmeste er i mange tilfælde at fortælle WP rocket

Emoji

For de fleste vedkommende, skal denne hakkes af. Emojis er de Smilies som WordPress kan lave i indholdet på din hjemmeside. Men de fleste bruger dem faktisk ikke. Og ret tit er det sådan at selve browseren understøtter emojis hvilket betyder at du lige så godt kan bruge det som browseren allerede har indbygget.

Embeds

WordPress embeds er det at man kan nøjes med at skrive urlen på fx en youtube video, og så finder wordpress javascript som er lavet til formålet, den video som skal vises. Men i rigtig mange tilfælde bruger du slet ikke denne feature, da man i stedet indsætter en iframe kode fra youtube eller andre medier. Hvilket faktisk bare gør at man nu både loader en iframe og et stykke javascript som arbejder uden grund. Sæt hak her hvis du ikke bruger videoer på din hjemmeside eller hvis du bruger iframes embed metoden.

Preload

Preload

At preloade altså forudloade html cachen, kan være en ret gode ide. Det der sker er at når der fx laves ændringer, gemmes kommentarer eller bare når cachen slettes, så sørger preload for at generere html cachen på ny. Dette kan være en fordel, da ingen brugere så rammer ind i en ucachet udgave af siden. Men du skal lige tænke over dette før du aktivere det.

  • Retter du tit på siden?
  • Kommer der mange kommentarer?
  • Laver du tit ændringer i designet?
  • Har du mange sider på din hjemmeside?

Hvis du kan svare ja til en af ovenstående. så vil jeg anbefale at du ikke aktivere preload. For som sagt det der sker er at sidernes html caches genereres på forhånd, det betyder at alle sider bliver besøgt en for en af WP rocket. Det betyder også at der i den tid skabes en belastning af serveren. Især hvis du har mange sider.

Hvad sker der når du ikke aktivere preload?

Jo der sker egentlig ikke andet end at cachen for en specifik side genereres når den første bruger besøger siden. hvilket også betyder at besøg nr 2 til den samme side, vil være på en cachet udgave. Så reelt er der en betydeligt mindre belastning af siden.

Har du en side som ikke bliver rettet så meget på, hvor den ikke får mange kommentarer og måske endda ikke ret mange sider, ja så kan det godt betale sig at lade siden preloade en cachet udgave.

Prefech DNS Requests

Denne er god at bruge når du loader eksterne filer. Altså filer fra andre domæner. Det gør at browseren på forhånd ved hvor de skal se efter de filer, fordi den allerede fra start kender domænet og ved hvor domænet peger hen. Så benyt dig af denne hvis du loader ting fra eksterne kilder. Det kan fx være fonte, det kan være javascripts og meget andet.

Man skriver et domæne pr linje, og skriver //domæne.dk uden http eller https.

Avanceret

Aldrig cache disse urls

Det hænder at der er url adresser som du ikke vil have cachet, det er her man indskriver dem. Det kan fx være højt dynamiske sider, sider hvor en action skal ske før noget indhold vises og andre tilfælde. Husk at woocommerce er understøttet af WP Rocket, hvorfor du ikke behøver at indsætte kurv og tjekud, ej heller bruger sider.

Men overvej om de sider du gerne vil undgå skal caches, er bygget på den bedste måde, når du er nød til at gøre så de ikke caches. Du kan også på hver side/indlæg når du redigere dem, fjerne hakket fra cache under WP Rocket indstillingerne for den side.

Du udfylder en pr linje, og du kan benytte (.*) til at matche

Aldrig cache cookies

WordPress og plugins kan bruge cookies, dog er det sjældent at du er nød til at fortælle at når en cookie er sat så skal siden ikke caches. Jeg har ikke selv oplevet det gennem mine mange år på bagen, hvorfor du heller ikke bør opleve det. Hvis du oplever det, kan du i stedet spørge dig selv, er det lavet korrekt, hvis en sat cookie, giver anledning til ikke at cache siden, eller ikke at servere en cachet udgave af siden til dine brugere.

Man udfylder bare cookiens ID/Navn, en pr linje.

Aldrig cache brugeragenter

Jeg kunne også have skrevet browsere, men WP rocket kalder det for brugeragenter. Men skriver du fx safari, så vil alle der besøger siden via safari ikke få en cachet udgave af siden. Dette har jeg heller ikke oplevet var nødvendigt. Men det kan jo være du har nogle eksempler på browsere hvor du hellere vil se en frisk udgave af siden, frem for en cachet udgave. Det kan også være hvis du sidder som udvikler og gerne vil se en frisk udgave hver gang du besøger siden via din browser.

også her er det en pr linje, og du kan benytte (.*) for at matche udefinerbare strenge.

Slet altid disse urls

Når du opdaterer sider og indlæg, er det ikke som standard alle urls der får slettet sin cachede udgave. Men her kan du definerer sider som du gerne vil have skal slettes når der opdateres.

Du skriver en url pr linje og du kan bruge (.*) til at matche strenge

Cache disse query strenge

Som standard når der er query i urlen serveres der IKKE en cachet udgave for brugeren. Det betyder hvis du fx skriver domæne.dk/?tester=1 så vil det være den rå side du får. der er dog undtagelser hvor WP rocket som standard viser en cachet udgave:

  • utm_source
  • utm_campaign
  • utm_medium
  • utm_expid
  • fb_action_ids
  • fb_action_types
  • fb_source
  • fbclid
  • _ga
  • gclid
  • age-verified
  • ao_noptimize
  • usqp

Søgeresultatsider bliver heller ikke cachet, her skal der dog andre boller på suppen for at WP Rocket kan cachet netop det.

Indsæt denne kode i din functions.php fil:

add_filter( 'rocket_cache_search', '__return_true' );

Database

Database optimering

Her kan du optimere databasen, og de mest basale fejl som en standard wordpress laver. Det handler især om at fjerne gammel bras som bare ligger og fylder i databasen. Som standard er det sådan at WordPress laver revisioner hver gang du laver en lille rettelse på en side. Dette kan for nogle hjemmesider blive til mange tusinde revisioner. Har engang oplevet en hjemmeside med næsten 120.000 revisioner.

Hvorfor er revisioner farlige?

Det er de reelt heller ikke, de er jo godt for arbejdet man laver på siden, især hvis man laver en fejl og kommer til at gemme. Men det sker dog ret sjældent at man laver disse fejl, hvorfor det i min optik er meget bedre slet ikke at have dem. De er nemlig farlige for hastigheden, da revisioner ligger i samme tabel som alt andet indhold, så når en side skal vises, ja så skal der søges i databasen efter den rette side.

Samtidig kan denne side også have flere tilknyttede custom fields, og de lægger sig i en anden tabel, og ja disse bliver ikke som sådan revisioneret, men de tilknyttes revisionerne, hvorfor der der også kan være rigtig mange poster. Så min anbefaling for database optimeringerne er som følger:

Sæt hak i følgende muligheder:

  • Revisioner
  • Slettede indlæg
  • Spam kommentarer
  • Slettede kommentarer
  • Udløbne transienter
  • Optimer tabeller
  • Automatisk oprydning
    – 1 gang om dagen hvis du tit retter dagligt, ellers minimum månedligt

Husk at trykke “optimize” – OBS, hvis du oplever at posterne ikke slette lige med det samme, så er det fordi WP Rocket prøver at undgå at lægge serveren ned, derfor tager den det i bidder af ca 100 poster af gangen.

Derudover vil jeg anbefale at du nedsætter antallet af revisioner som wordpress gemmer på, som standard gemmer wordpress på ALLE revisioner. Det gør man ved at indsætte dette stykke kode i din wp-config fil som ligger i roden på din FTP.

define( 'WP_POST_REVISIONS', 1 );

CDN

CDN – Content delivery Network

Denne er primært tiltænkt de CDN’s som benytter fx CNAME (et underdomæne som peger på samme som roden). Det eneste man faktisk skal er at indskrive de forskellige CNAME man har oprettet, og så køre det faktisk af sig selv. WP rocket udskifter selv domænet på de statiske filer som fx billeder, css og javascript.

Men her er hvordan du gør og hvad du skal tænke over:

  • Har du kun en CNAME, skal du vælge All Files
  • Har du flere CNAMEs, kan det være en god ide at dele det op så billeder køre på den ene og css og javascripts køre på den anden.

Du kan optimalt set køre med 3 CNAMES, Men jeg vil ikke anbefale dette, medmindre der loades rigtig mange filer, og jeg mener rigtig mange. Brug i stedet en løsning som cloudflare, der er både muligheder for bedre sikkerhed og bedre hastighed. Og så køre det på hoveddomænet. Altså ikke et sub domæne eller et andet domæne til forlålet.

Heartbeat

WordPress heartbeat

Heartbeat er en indbygget javascript funktion der gentagende gange loader i baggrunden. Dette er typisk noget AJAX som i sidste ende kan belaste serveren. Det sker både i frontend og backend. I backend er det fx det der sørger for at der automatisk gemmes en kladde i ny og næ når man arbejder på en side.

Det kan være en god ide at deaktivere dette totalt for frontend, men der kan også være tilfælde hvor det er nødvendigt at den køre. Er det det, så sæt den i stedet til at være reduceret. I backend skal den bare sættes til at være reduceret, og det samme for post editor.

Husk altid at teste det.

Add-ons

WP Rocket Add-ons

Her finder du yderligere indstillinger og yderlige funktioner. De fedeste er nok Google analytics, Facebook Pixel og Cloudflare. Vil tage dem fra en ende af herunder.

Google tracking og Facebook Pixel

Begge disse gør det samme, de laver en lokal version i stedet for at scriptet skal hentes fra henholdsvis Google og Facebook. Dette er godt fordi det ret tit er sådan at netop de scripts kan være lang tid om at loade, og du kan styre browser cache noget bedre. Jeg aktiverer typisk disse når der er Google analytics og facebook pixel installeret direkte på sitet. Husk at undersøge det først, da begge disse også kan være loadet via Google Tag Manager.

Varnish

Denne gør egentlig bare det at den også sørger for at varnish er up to date, når der laves ændringer på siden. Så bruger du varnish, aktiver denne

Cloudflare

Aktiverer du denne, får du muligheden for at indskriver nogle oplysninger fra cloudflare, sådan at WP Rocket kan snakke sammen med cloudflare. Når den er aktiveret og opsat, behøver man derfor ikke logge ind på cloudflare for fx at slette cachen. hvilket man jo gør når man laver ændringer i temaet.

For at opsætte denne, skal du logge ind på cloudflare, og finde følgende:

  • API key
  • Din email som du bruger til cloudflare
  • Zone ID

Securi

Bruger du securi, kan WP Rocket også arbejde sammen med denne, og det WP Rocket gør er at sørge for at den cache Securi ligger inde med bliver slettet. Også denne skal opsærttes, det er dog bare en API key du skal have fat i og så er den kørende.

billedoptimering

Billedoptimering

Denne er egentlig bare en reklame for en udvidelse som WP Rocket står bag. Det er et billedoptimeringsplugin som de kalder for Imagify. Jeg har faktisk ikke prøvet det da jeg selv bruger Kraken.io til mine billedoptimeringer. Så hvis nogen har prøvet det, skriv gerne dine erfaringer med det til mig.

Værktøjer

Her har du mulighed for at eksporterer, importerer de indstillinger du har lavet i WP Rocket. Det betyder at opsætning på andre sites kan blive nemmere for dig. Der ud over har du også muligheden for at sætte pluginet tilbage til en tidligere version. Det er meget handy hvis der fx opdages en fejl med en opdatering. Så kan man altid gå tilbage til den forrige.

Fik du ikke hentet WP Rocket? så gør det her:

3 kommentarer til “WP Rocket – sådan optimerer du hastigheden”

  1. Hej Kim
    Bruger du stadig Kraken.io til billedoptimering, eller er du gået over til et andet plugin? Det ser nemlig ikke ud til at blive opdateret synderligt meget længere.

    Svar
    • Selve pluginet skal i sig selv jo heller ikke opdateres synderligt, da arbejdet på billederne foregår off site, på deres servere. Så al opdatering sker jo hes dem. Ja jeg bruger stadig kraken.io. Dog sammen med cloudflare så der on the fly skabes fx WebP formatet.

      Svar

Skriv en kommentar

Målet er kvalitet

Det er mit mål at levere kvalitetsløsninger med høj fokus på hastighed og teknisk seo. Uanset om der er tale om små eller store løsninger, vil fokus altid være på hastighed og teknisk seo.