Jeg bøvlede selv meget med en langsom WordPress hjemmeside. Meget er blevet prøvet, så her er min opsamling på hvordan du kan gøre WordPress hurtigere.
Det er først vigtigt at sige, at en af de største syndere i forhold til en langsomt WordPress hjemmeside, er det brugte tema. Du kan gøre mange ting i forhold til optimering og forskellige plugins, men hvis dit tema generelt er langsomt og/eller er meget afhængigt af javascript for bare at vise de mest simple ting, er der desværre lang vej til en hurtig hjemmeside. Mit tema er ikke det hurtigste, og der er ting som kunne optimeres fra forfatterens side. Men dette skal ikke stoppe os i at gøre det så godt som vi nu engang kan.
Der findes mange muligheder for at tilkøbe sig optimering af ens hjemmeside. Især ved optimering og levering af billeder er der mange muligheder for at betale for en færdig løsning. Jeg har i det følgende gjort en dyd ud af kun at finde gratis løsninger.
De vigtigste plugins
Med blot 2 plugins kan du komme UTROLIGT langt i forhold til at optimere din hjemmeside. Om ikke andet, så vil jeg på det kraftigste anbefale at du får installeret de to følgende plugins.
W3 Total Cache
Den første her er W3 Total Cahce, det nok vigtigste plugin. Pluginnet kan en masse, men de vigtigste funktioner er for mig at se de følgende:
Page Cache
Denne funktion er den nok vigtigste funktion i dette plugin. Det forsøger at lave alle dine sider om til statiske sider. Dette betyder at i stedet for at skulle spørge databasen om hvilket indhold der skal vises, og derefter begynde at “tegne” den enkelte side, gemmes en forud genereret side på serveren. Når en bruger så skal se en side på din hjemmeside, hentes denne forud-genererede side frem. Markant bedre end at hjemmesiden skal på arbejde for at genere siden forfra. Dette plugin alene kan spare oceaner af tid for dine brugere, og ressourcer på din server. Mindre arbejde til serveren = hurtigere svartider, samt at serveren kan håndtere flere samtidige brugere.
Browser Cache
Browser cache sørger for at din hjemmesides ressourcer gemmes lokalt i den enkelte brugers browser. Dette sikrer at dine brugere henter så lidt data fra serveren som muligt, og i stedet hele tiden tjekker browserens cahce for om data allerede er hentet og ligger lokalt.
Der er mange andre ting man kan sætte op i W3 Total Cache, men disse to funktioner er de to jeg har fundet altid virker, og har en stor indvirkning på hjemmesiden. Et dybere dyk i alle de indstillinger der er for W3 Total Cache, kan findes hos premium.wpmudev.org. Her går de virkeligt i dybden med de enkelte dele.
Autoptimize
Hjemmesider er bygget op af en masse henvisninger. Hvert billede kræver fx. et ny forespørgsel til serveren. En stor del af ventetiden på hjemmesiderne, er de mange forespørgsler til serveren, men det er ikke kun de tunge billeder der er problemet her. Hvis din hjemmeside gør brug af flere forskellige stylesheets og javascript filer, skal disse hentes hver for sig. Det tager tid. Auoptimize hjælper på dette problem. Den gennemløber din hjemmesider og finder henholdsvis alle javascript filerne og alle stylesheet (CSS) filerne. Når disse er fundet, samler den alle javascript filerne i én fil, komprimerer denne fil (minimize), og udstiller denne. Det samme sker for CSS filerne. I stedet for en masse refernecer, er der kun kun 2 små tilbage. Dette hjælper også en del på hastigheden.
W3 Total Cache er i princippet i stand til at komprimere (minimize) javascript og stylesheets. Men jeg har personligt ikke gode erfaringer W3 Total Cache her, og Autoptimize lade til (for mig) at virker bedre og generelt gøre et bedre job.
Optimering af billeder
Op imod 75% af de data bliver leveret fra hjemmesider verden over er billeder. Det er en meget stor del af din hjemmeside, så kan vi optimere hvor hurtigt billederne bliver leveret til brugerne, kan vi drastisk optimere på hastigheden af vores hjemmesider.
Gør billederne mindre
Det første step du kan gøre for at optimere leveringen af dine billeder, er at gøre dem mindre. Dette kan både gøres ved at ændre på størrelsen af billederne, så du ikke leverer et billede der er 1200px bredt hvis browseren bagefter gør billedet mindre så det kun fylder 600px. En halvering af bredden kan give dig et billede der kun fylder 25% af originalen.
Ud over at ændre på størrelsen af dine billeder kan du også ændre lidt på kvaliteten. Som det ses på billedet herunder kan der være mange KB data at hente ved blot at reducere størrelsen på et billede en smule.
Til at gøre mine billeder mindre bruger jeg EWWW Image Optimizer. Det er dejligt fleksibelt, relativt overskueligt, og har meget funktionalitet med sig. Dertil er deres Pixel Perfect komprimering virkeligt god til at fjerne data fra billederne uden at man rigtigt kan se det på det endelige resultat.
Konverter billederne
Nogle gange kan du også få en del ud af at skifte billedformat. Fx kunne du konvertere dine JPG/JPEG billeder over til PNG formatet. Dette giver rigtigt god mening hvis der er tale om fotografier eller lignende, men har du tekst på dine billeder vil jeg klart anbefale dig at holde dig til PNG.
Til dette plugin bruger jeg PNG to JPG. Jeg konverterer billederne enkeltvist, da det som tidligere nævnt ikke er i alle tilfælde du ville ønske at bruge JPG billeder.
WebP er et billedformat der er meget på vej frem, og har været det siden 2010. WebP billeder har vist sig at være i gennemsnit 25-35% mindre end JPG billeder, personligt har jeg set besparelser op imod 70% af den oprindelige billedstørrelse, uden at jeg har kunnet se forskel på de to billeder.
Når det omhandler generering af webp billeder, er EWWW Image Optimizer det bedste plugin jeg har fundet indtil videre.
Brug af WebP i praksis.
Desværre kan du ikke bare konvertere alle dine billeder over til WebP. Det er nemlig ikke alle browsers, der i skrivende stund (marts 2020) understøtter WebP. Apple enheder (og det døde Internet Explorer) understøtter endnu ikke WebP.
Herunder kan du se de browsers som i øjeblikket understøtter WebP
Caching & WebP
EWWW har indbygget en funktionalitet til at kunne levere det rigtige til de enkelte browsers. Desværre er denne funktionalitet baseret på at EWWW læser hvilken browser du besøger hjemmesiden med, og så leverer det billede du kan bruge. Dette virker dog ikke sammen med cache løsninger så som CloudFlare. Ikke med mindre at man betaler sig til funktionaliteten hos CloudFlare. Alternativt stiller EWWW noget javascript til rådighed som kan håndtere det. Men dette tilføjer blot mere data som skal indlæses af vores klienter, hvilket heller ikke er ønskværdigt.
Derfor bruger jeg WebP Express til at generere den nødvendige HTML så både Apple enheder og alle andre enheder får leveret et billede når de besøger min hjemmeside. WebP tilbyder nemlig muligheden for at kunne omskrive HTML’en så der i stedet for bare at være et <img> tag på hjemmesiden, nu kommer et <picture> tag som indeholder både WebP og JPG eller PNG billeder. Det tillader at HTML’en kan caches af CloudFlare, og lægger ansvaret over til browseren om at downloade det billede den kan forstå.
Det skal dog siges at EWWW har givet udtryk for at de arbejder på en lignende funktionalitet, og det kan ske vi derfor engang i fremtiden kan undvære WebP Express.
WebP Express indstillinger
Du kan se de indstilligner jeg har valgt til WebP Express her:
Vær opmærksom på at jeg har valgt ikke at refererer WebP billeder som ikke er genereret. Meningen med denne funktion er at man kan slå den til, sammen med live conversion, og så få genereret de WebP billeder man har brug for. Desværre har jeg oplevet at konverteringen nogle gange kan tage MEGET lang tid, og endda nogle gange gå helt i stå. Det ønsker jeg ikke at mine brugere skal opleve, så derfor konverterer jeg billederne på forhånd.
Dertil er det ikke altid fordelagtigt at konvertere til WebP, nogle gange bliver billederne større end hvis man leverede dem i JPG. Derfor sparer vi også noget data for brugerne ved kun at konvertere og vise de WebP billeder som rent faktisk er mindre end hvis vi havde leveret dem et JPG billede.
På denne måde kan vi levere de mindre WebP billeder til de browsers der understøtter det, og have en fallback til “normale” billeder til de browsers der ikke understøtter det nye format.
Læs mere
Hvis du vi dykke dybt i optimering af billeder på hjemmesider, og især dykke ned i den tekniske del, kan jeg klart anbefale e-bogen “Essential Image Optimization” af Addy Osmani. Det er en “lang” artikel, men den kan klart anbefales hvis du vil vide mere dybdegående information om emnet.
Generel optimering
Lazy loading
Lazy loading er et udtryk for at alle elementer på hjemmesiden ikke hentes på én gang, men derimod først når de rent faktisk skal bruges.
I dag bruger jeg Lazy Loader til at klare denne opgave. Tidligere brugte jeg BJ Lazy Load, som også er et rigtigt fint letvægts plugin. Desværre virker BJ Lazy Load dog ikke for AMP, og den kan heller ikke håndtere <picture> & det dertilhørende <source> tag, hvilket betyder at indlæsningen af webp billeder ikke kan gøres med Lazy Load.
Hvis dit site skal være AMP ready, kan du ikke bruge BJ Lazy Load. Til gengæld kan du bruge det lazy load der følger med Jetpack, hvilket er hvad jeg er skiftet over til de steder hvor AMP er vigtigt.
Progessiv Web App – PWA
Et andet plugin jeg har fundet, som jeg synes er en skam flere ikke kender til, er Super Progressive Web Apps. Min erfaring er dette plugin hjælper med at cache de besøgte sider på den enkelte bruger telefon. Sidder brugeren og navigerer rundt, og kommer forbi de samme sider igen, er disse sider allerede gemt lokalt på telefonen. Dét er en stor fordel, og giver en utroligt god brugeroplevelse. Pluginnet kan også komme op med en notifikation om at man kan tilføje hjemmesiden som et bogmærke på startskærmen. Gøres dette bliver der oprettet en Progressiv Web App (PWA), som er endnu bedre til at cache indholdet på telefonen.
Hvis du har en hjemmeside som ofte besøges af de samme brugere igen og igen, og især hvis disse brugere bruger de samme sider igen og igen, er dette plugin et must have i min bog.
Jetpack
Jetpack er et stort plugin. Det kan UTROLIGT meget!
I forhold til at gøre WordPress hurtigere, er der dog kun en enkelt funktionalitet jeg bruger; Site accelerator. Site accelerator består af to komponenter, et der håndterer billeder, og et der håndterer de statiske filer så som javascript & CSS som hyppigst bruges i WordPress regi.
Det at Jetpack tilbyder at hente alle dine billeder over til dem, og sørge for at de bliver leveret så hurtigt som muligt til brugeren, betyder at din hjemmesides server ikke skal stå for at finde og sende billederne til brugerne. Min erfaring er at dette gør en kæmpe forskel.
Jeg bruger ikke længere Jetpack til dette, da det viste sig at et korrekt konfigureret Cloudflare løste disse problematikker markant bedre end Jetpack, samtidig med at det resulterede i mindre Javascript til frontenden / brugere + potentielt bedre SEO da billede-URLs nu er fra mit eget domæne og ikke fra Jetpacks domæne.
Redirection & håndtering af 404 fejl
Noget der også kan gøre WordPress langsomt, er hvis dine brugere bliver videresendt / redirected fra side til side. Der kan være mange grunde til at dette sker, både tilsigtede og utilsigtede. Endvidere kan brugerne forsøge at tilgå ressourcer som ikke findes, sker dette vil de blive mødt af en 404 fejl. Dette kan være en viderestilling som ikke virker, og det kan være billeder som af den ene eller anden grund, ikke længere findes på hjemmesiden.
Et plugin jeg er blevet rigtigt glad for når jeg skal lede efter og håndtere disse fejl, er pluginnet Redirection. Herunder ser du et eksempel på et billede som jeg stadig linker til et sted, men som ikke længere findes i min uploads mappe på serveren.
Håndtering af disse redirects kan hjælpe med at gøre WordPress hurtigere, da browseren så ikke skal håndtere og vente på ressourcer som ikke findes.
Offsite cache – Cloudflare
Du har fået lavet en lokal cache på din server med W3, dine scripts og stylesheets er komprimeret og er samlet i én fil for hver type. Dine billeder har fået lazy load. Generelt har du gjort hvad du umiddelbart tænker du kan for at optimere din hjemmeside.
Men vent! Der er mere du kan gøre for at gøre WordPress hurtigere. Men nu begynder vi at bevæge os ind på den mere tekniske del af optimeringerne.
Når brugerne besøger din hjemmeside, er det dit webhotel som skal levere disse data. I langt de fleste tilfælde, er denne server langsom, fordi du (ligesom mig) har sparet på serveren til din hjemmeside. Derfor kunne det da være lækkert hvis vi kunne få en super hurtig webserver til at agere cache for vores hjemmeside. Og netop dette kan Cloudflare hjælpe os med. De er blandt andet kendt for at have verdens hurtigste DNS.
At få sat Cloudflare op som caching server er desværre så nemt som bare at downloade et plugin og trykke “aktiver”, her skal der lidt mere til da det er et mere teknisk setup. Vi skal nemlig have fortal dine besøgendes browser at den ikke skal lede efter din hjemmeside på din webserver, men i stedet skal lede efter den hos Cloudflare.
Hvor stor er effekten så af Cloudflare?
Heldigvis har Cloudflare selv lavet en guide til hvordan du får sat Cloudflare op for din hjemmeside, så jeg vil lade dem forklare den tekniske del, og i stedet vil jeg vise jer nogle før og efter billeder for min hjemmesides forside.
Læg især mærke til billederne under tallene. Her er det tydeligt at vi nu allerede fra starten har menuen, topbaren & overskriften af artiklen klar. Vi får også ret hurtigt vist et billede og den vigtigste tekst så brugeren kan komme igang med at læse indholdet.
På stationære & bærbare computere er resultatet et helt andet. Her er der snart ikke meget at komme efter længere.
Såfremt du ønsker at bruge Cloudflare kan det varmt anbefales at bruge Cloudflare pluginnet. Det kan sørge for at din off-location cache bliver purged hver gang du laver ændringer til dit layout. Dertil den har en fin handy knap til at sætte de mest normale indstillinger op for Cloudflare når man bruger WordPress.
Pagerules
Jeg kan på det varmeste anbefale at du får lavet de følgende “Page Rules” i Cloudflare. Formålet med disse regler er følgende:
- Undgå al caching på dine preview sider. Dette er de sider du får vist når du bruger forhåndsvisningen for dine indlæg.
- Fjernelse af hård cache (cache everything) på wp-admin delen af WordPress, men samtidig bibeholde caching af det statiske indhold du har i wp-content (fx dine billeder)
- “Cache everything” = hård cache / “fang alt” for resten af dit site. Alting bliver gemt her, også dynamisk indhold, hvilket også inkluderer søgeresultater på din side, widgets i din sidebar, og kommentarer. Dette er en ret stor hammer, og synes du den rammer for hårdt kan du med fordel ændre “Cache Everything” til “Standard”.
Ekstra: Mine egne funktioner
Her rammer vi den tekniske del. Følgende vil kræve at du kan håndtere at navigere rundt på en FTP server, og at du ved hvordan du håndterer at tilføje nye PHP funktioner til dit site.
Justeringer af billedkvalitet
Til EWWW har jeg tilføjet disse to overrides i wp-config.php. Disse to overrides sørger for at mine originale uploads holdes så originale som muligt. Derfor beholder jeg metadata / EXIF data på disse billeder, samt skipper billederne hvis der køres en lozzy optimering af billederne.
define( 'EWWW_IMAGE_OPTIMIZER_METADATA_SKIP_FULL', true ); define( 'EWWW_IMAGE_OPTIMIZER_LOSSY_SKIP_FULL', true );
Da jeg bruger EWWW til at optimere størrelsen på mine billeder, har jeg valgt at sætte WordPress’ komprimerings kvalitet på et højt niveau. Dette gøres ved at tilføje nedenstående linjer til functions.php. WordPress bruger som standard en kvalitet op 82, og det synes jeg personligt er synligt på de færdige billeder.
// Lock Image Quality add_filter( 'jpeg_quality', function($arg){return 90;} ); add_filter( 'wp_editor_set_quality', function($arg){return 90;} );
For store billeder på relaterede opslag
Hvis du bruger Jetpack og dennes “relaterede opslag” funktion, kan billederne godt være lidt for store i forhold til hvordan de vises på din hjemmeside, det var de i mit tilfælde. Jeg har lavet følgende script som kan bruges til at justere dette. Hvis du ved præcis hvor høje og brede du ønsker billederne, brug da med fordel nedenstående til at justere disse billeder til. Så hentes der ikke for store billeder ned til dine brugere.
// change thumbnail size function jetpackchange_image_size ( $thumbnail_size ) { $thumbnail_size['width'] = 240; $thumbnail_size['height'] = 137; return $thumbnail_size; } add_filter( 'jetpack_relatedposts_filter_thumbnail_size', 'jetpackchange_image_size' );
Brug den seneste version af jQuery
Rigtigt mange funktioner og plugins i WordPress bruger jQuery. WordPress kommer med jQuery forudinstalleret, men den version WordPress tilbyder er version 1.12.4. Denne version er langsommere end den nyeste version 3.4.1, og så er den også kendt for at indeholde sikkerhedshuller. JQuery version 3.4.1 har i øjeblikket ikke kendte sikkerhedshuller.
Vær dog opmærksom på at det ikke er alle temaer & plugins der fungerer med den seneste version af jQuery. De er alle skrevet med tanke på at WordPress som standard leverer version 1.12.4, så hvis de bruger funktionalitet specifik til denne version, vil din hjemmeside ikke fungere bagefter. Test scriptet andensteds først om muligt.
/* Replace the default WordPress jQuery script */ function squazz_modify_jquery() { wp_deregister_script('jquery'); if(wp_is_mobile()) { wp_enqueue_script('jquery', 'https://code.jquery.com/jquery-3.4.1.min.js', array(), null, true); } else { wp_enqueue_script('jquery', 'https://code.jquery.com/jquery-3.4.1.min.js', array(), null, true); } } add_action('wp_enqueue_scripts', 'squazz_modify_jquery');
Udskyd indlæsning af javascript
Google PageSpeed (Og Google Lighthouse) er ikke glade for at man indlæser javascript inden man skal bruge det. Og det er dine brugere heller ikke. Jo senere du indlæser tunge filer som jQuery, jo bedre.
Derfor har jeg ledt efter en måde hvorpå jeg kunne sikre mig at jQuery blev indlæst så sent som muligt. Nogle gange kan jeg nøjes med en defer (de fleste gange), men andre gange er man nødt til at indlæse data async så det kommer på siden lidt hurtigere. På stackoverflow fandt jeg en rigtig fin måde at udsætte loading af scripts. Samtidig fandt jeg også en måde hvorpå jeg kunne tilføje integrity og crossorigin tags til mit jQuery script, hvilket sikrer mig mod XSS (Cross Site Scripting).
// https://stackoverflow.com/questions/44827134/wordpress-script-with-integrity-and-crossorigin add_filter( 'script_loader_tag', 'add_attribs_to_scripts', 10, 3 ); function add_attribs_to_scripts( $tag, $handle, $src ) { // The handles of the enqueued scripts we want to defer $async_scripts = array( 'jquery-migrate', 'sharethis', ); $defer_scripts = array( 'contact-form-7', 'jquery-ui', 'jquery-form', 'wpdm-bootstrap', 'frontjs', 'jquery-choosen', 'fancybox', 'jquery-colorbox', 'search' ); $jquery = array( 'jquery' ); if ( in_array( $handle, $defer_scripts ) ) { return '<script src="' . $src . '" defer="defer" type="text/javascript"></script>' . "\n"; } if ( in_array( $handle, $async_scripts ) ) { return '<script src="' . $src . '" async="async" type="text/javascript"></script>' . "\n"; } if ( in_array( $handle, $jquery ) ) { return '<script src="' . $src . '" defer integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous" type="text/javascript"></script>' . "\n"; } return $tag; }
Kommentarer?
Hvad har du erfaringer med? Er der noget jeg har overset? Eller kender du et bedre alternativ til de plugins og løsninger jeg har valgt?
Hold dig endelig ikke tilbage, og fortæl mig om det i kommentarsporet.
Kom i kontakt med mig