Sådan Fremskynder Du Dit WordPress Site (Ultimativ Guide)

Vi har udgivet mange vejledninger gennem årene med måder at optimere og fremskynde WordPress på. Men nogle gange kan det være forvirrende at forsøge, at finde alt du behøver på ét sted. Så i dag vil vi dele alt, hvad vi ved om turboladning WordPress, med dig, over 15 års erfaring og hårde lektioner lært, alt sammen i en ultimativ vejledning. Uanset om du lige er begyndt at bruge WordPress eller er en erfaren udvikler, lover vi, at du finder noget nyttigt i dette guide!

Over 43.5% af internettet er nu drevet af WordPress. Mens dette er fantastisk, betyder det også, at der er tusindvis af forskellige temaer, plugins og teknologier, som alle skal sameksistere. For den daglige WordPress-bruger kan dette hurtigt blive til et mareridt, når deres websted begynder at flaskehalse, og de ved ikke hvorfor eller endda hvor de skal fejlfinde.

I vores tidligere guide om sidens hastighed gik vi over mange grundlæggende principper for ydeevne og hvordan det kan få stor indflydelse på succesen i din virksomhed. Men i dag dykker vi ind i de gældende trin, du kan tage lige nu for at se forbedringer på dine egne WordPress-websteder. Vi deler også nogle ressourcer, der har været uvurderlige for os.

WordPress Side-typer: Statisk Eller Dynamisk

Før vi dykker ind i optimeringerne, er det vigtigt først at forstå, at ikke alle WordPress-websteder er ens. Det er derfor, at mange brugere har problemer, da man ikke kan løse alle problemer på samme måde. Vi giver altid WordPress-websteder en klassifikation: statisk eller dynamisk. Så lad os først undersøge forskellene mellem disse to typer af websteder.

For Det Meste Statiske Steder

Statisk vil typisk omfatte websteder som blogs, små virksomheder, nyhedswebsteder, personlige medier, fotografering osv. Ved statisk mening mener vi, at dataene på disse WordPress-websteder ikke ændrer sig meget ofte (måske et par gange om dagen) . Selvom det meste af vores Kinsta-websted vil blive betragtet som en statisk hjemmeside.

Dette bliver utrolig vigtigt, da mange af forespørgsler kan serveres direkte fra cache på serveren ved lynhurtige hastigheder! Bare rolig; vi vil dykke ind i emnet for caching i længden længere nedenfor. Det betyder, at de vil have færre databasesamtaler, og ikke så mange ressourcer vil være nødvendige for at opnå google ydeevne.

Højt Dynamiske Websteder

På forsiden har vi meget dynamiske steder. Disse omfatter websteder som e-handel (WooCommerce eller Easy Digital Downloads), fællesskab, medlemskab, fora (bbPress eller BuddyPress) og læringsstyringssystemer (LMS). Ved dynamisk mener vi, at dataene på disse WordPress-websteder ændrer sig ofte (servertransaktioner finder sted hvert par minutter eller endog hvert sekund). Dette betyder, at ikke alle anmodninger til serveren kan serveres direkte fra cache og kræver yderligere serverressourcer og database forespørgsler.

Disse websteder har også typisk et stort antal samtidige besøgende og sessioner. På et informations- eller corporate WordPress-websted, der for det meste er statisk, kan en besøgende forblive i fem eller ti minutter, indtil de finder det, de har brug for (og dette er et højt antal, normalt er antallet af udfald meget højere). På dynamiske steder har du det modsatte. Besøgende kommer typisk til stedet for at engagere sig i noget eller nogen. Hvis de går gennem et online kursus, er det ikke usædvanligt, at de bliver i timevis.

Du kan se, hvor dette går hen. De samtidige besøgende i forbindelse med din WordPress-vært løber hurtigt op. For at gøre det værre har du et stort antal samtidige besøgende på toppen af et problem med “uhyggelig indhold”.

Vælg High Performance WordPress Hosting

En WordPress-vært er et firma, der lagrer alle dine websteds data. Du tilmelder dig en plan, og alle dine billeder, indhold, videoer osv. Ligger på en server, der sidder i værtens datacenter. WordPress-værten giver dig en nem måde at få adgang til dataene til, administrere den og rute den til dine besøgende. Ret simpelt ik? Nå, ikke helt.

Der er tre meget forskellige typer af WordPress værter, du møder på internettet. Lad os dykke ind i fordele og ulemper ved hver. Det er vigtigt, at du vælger den rigtige fra begyndelsen, ellers vil du simpelthen forårsage dig hovedpine og spildt tid på vejen.

1. Delt WordPress Hosting

Den første og mest populære type af WordPress hosting er det, vi kalder “shared hosting”. Disse omfatter de største værter i branchen som EIG-virksomheder som Bluehost og HostGator samt udbydere som Siteground, GoDaddy Media Temple, OVH, GreenGeeks, og InMotion Hosting. De bruger typisk cPanel, og den gennemsnitlige kunde betaler normalt mellem 3$ og 25$ om måneden.

Enhver der bruger denne type hosting, vil på et tidspunkt opleve langsommelighed, det er bare et spørgsmål om tid. Hvorfor? Fordi delte værter har tendens til at overbelaste deres servere, hvilket igen kan påvirke dit websteds ydeevne. Site suspensions eller se hyppige 500 fejl er almindelige ting, du oplever, da de skal sætte grænser for alt og konsolidere ressourcer for at overleve. Eller endnu værre, nedetid på hjemmesiden. Selv om du ikke ved det, sidder dit WordPress-websted sandsynligvis på samme server som 200 + andre mennesker. Eventuelle problemer, der dukker op med andre websteder, kan liste over til dit websted.

Ligegyldigt hvordan du laver matematikken, efter udgifter, genererer 3$ om måneden ingen indtægter for hostingfirmaet. Især når du tildeler support til det. Én support billet og de ser allerede rødt. Den måde, de tjener mange af deres penge på, er på opsving og skjulte gebyrer. Disse opsalg omfatter ting som migreringer, domæneregistreringer, SSL-certifikater osv. En anden fælles taktik er at give enorme tilmeldingsrabatter. Men når fornyelsen kommer, får du den rigtige regning.

De fleste af disse værter tilbyder hvad de kalder deres “ubegrænsede ressourcer” plan. Du har sikkert alle set dette. Nå, der er ikke sådan noget i den virkelige verden, som ubegrænsede ressourcer. Hvad værterne gør bag kulisserne er at tage gas på kunderne og opbruge en masse af ressourcerne. Dette til gengæld, ender med sureonde klienter, der forlader, hvilket gør plads til flere kunder, der ikke bruger mange ressourcer. I sidste ende har du en ond cirkel af hosting firmaet, der skubber billige planer og tilmelder kunder, som de håber ikke vil bruge mange ressourcer og vil købe upsells.

Kundeservice og support med delt hosting er næsten altid normalt på grund af det store antal websteder vs. supportrepræsentanter. Delt værter skal sprede sig meget tynde for selv at tjene penge, og det fører normalt til en ubehagelig oplevelse for kunden.

Sørg for at tjekke en dybdegående artikel fra vores økonomidirektør, om de chokerende sandheder om hvordan billig WordPress hosting virkelig virker.

2. DIY VPS WordPress Hosting

Den anden type af WordPress-hosting er DIY VPS eller “Gør det selv på en virtuel privat server.” Denne menneskemængde består typisk af bootstrap startups og brugere med lidt mere udvikling, serveradministration og WordPress-oplevelse. De er DIY crowd. Disse mennesker forsøger typisk stadig at spare penge, men de er også normalt involveret i præstation og realiserer sin betydning for succesen med deres forretning. Commons-opsætninger kan omfatte brug af en tredjeparts VPS-udbyder som Digital Ocean, Linode eller Vultr; sammen med et værktøj som ServerPilot at håndtere det lettere.

En lille VPS fra DigitalOcean starter med 5$ om måneden, og den populære plan på ServerPilot starter på 10$ om måneden. Så afhængigt af dit opsætning kan du se på en pris på mellem 5$ til 15$ eller mere om måneden. DIY-tilgangen kan reducere omkostningerne, men det betyder også, at du er ansvarlig, hvis noget går i stykker, og for at optimere din server til ydeevne.

DIY tilgangen kan være stor, men det kan også komme tilbage på dig, hvis du ikke er forsigtig. Gå ikke denne vej, hvis du ikke er teknisk kyndig eller bare fordi du vil kaste dig ud i det! Din tid er penge værd, og du bør bruge det på at dyrke din virksomhed.

3. Administreret WordPress Hosting

Den tredje type hosting er det, vi tilbyder hos Kinsta, og det er administreret WordPress hosting. Disse typer værter håndterer alle back-end serverrelaterede opgaver for dig, sammen med at yde support, når du har brug for det. De er typisk finjusteret til at arbejde sammen med WordPress og indeholder normalt funktioner som et klik med mellemlag og miljømæssige sikkerhedskopier. Deres support teams vil være mere vidende, når det kommer til at kende deres vej rundt om CMS, da de er fokuseret på en platform på daglig basis.

Hvis du vil spare tid, er administreret WordPress hosting den rigtige vej! 👍

Planer for Administreret WordPress hosting spænder typisk fra 25$ til 150$ om måneden eller mere afhængigt af størrelsen af dit websted og dine behov. Store virksomheder som jQuery, Intuit, Plesk, Dyn, Nginx, og endda The White House bruger alle WordPress til at være vært for deres hjemmeside. Nogle populære administrerede WordPress værter du sikkert er bekendt med, eller måske også i øjeblikket bruger inkluderer WP Engine, Flywheel, Pressable, Media Temple, Pressidium og Pagely.

Kinsta Tar’ En Anden Tilgang

Kinsta tager dog WordPress hosting til næste niveau. Vores hosting platform falder ikke ind i nogen af de traditionelle hosting kategorier. Hele vores infrastruktur er bygget på Google Cloud Platform og adskiller sig fra traditionel delt, VPS eller dedikeret infrastruktur, hvilket gør den til en af de hurtigste WordPress-hostingløsninger, der er tilgængelige.

Hvert WordPress-websted på vores platform kører i en isoleret softwarebeholder, der indeholder alle de nødvendige software ressourcer til at køre webstedet (Linux, Nginx, PHP, MySQL). Det betyder, at den software, der kører hvert websted, er helt privat og deles ikke lige mellem dine egne websteder.

Hver webstedscontainer kører på virtuelle maskiner i et af flere GC-datacentre og bruger Google Cloud Platforms premium tier-netværk til optimeret dataoverførsel med lav latens. Hver maskine har op til 96 CPU’er og hundreder af GB RAM. Hardware-ressourcer (RAM / CPU) allokeres automatisk til hver webstedscontainer af vores virtuelle maskiner efter behov.

I modsætning til andre værter, der bruger Google Cloud Platforms generelle virtuelle maskiner, stiller vi compute optimized C2 VM’er til rådighed for alle vores kunder i understøttede regioner. Google Clouds C2-maskiner indeholder den nyeste generation Intel Xeon skalerbare processorer, der er i stand til at opretholde 3,8 GHz turbomængder med hele kernen. C2-maskiner er populære til CPU-tunge anvendelsessager som videnskabelig modellering og maskinlæring, men de er også gode til WordPress-hosting med høj ydeevne. Under vores test fandt vi ud af, at migrering af et WordPress-site fra en generel VM til en C2 VM resulterede i en 2x stigning i ydelsen!

Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0

— Adam Lundeen (@adam_lundeen_) January 29, 2019

Hvert år Review Signall udgiver deres WordPress hosting præstations benchmarks, og vi er stolte over, at Kinsta har vist sig at være den bedste virksomhed på tværs af alle niveauer fem år i træk! Og ikke kun på en eller to af vores planer, men hver plan, fra Starter hele vejen op til Enterprise. 🤘

Vi har heller ikke support-reps på niveau 1 eller niveau 2. Hele vores supportteam består af WordPress-udviklere og Linux-hostingingeniører, hvoraf mange har styret deres egne servere, skabt temaer og plugins og bidraget tilbage til kernen. Dette sikrer, at du modtager ekspertrådgivning fra en person, der aktivt bruger og udvikler sig med WordPress.

Du kommer til at chatte med de samme support team medlemmer, der støtter vores Fortune 500 og enterprise klienter. Vi er så kræsen om kvaliteten af vores support team, at vi kun ansætter mindre end 1% af ansøgere, der ansøger. Du vil ikke finde bedre støtte andre steder!

For at lære mere om hvorfor du skal vælge Kinsta for administreret WordPress hosting, læs hvorfor os – hvordan Kinsta er anderledes. Men uanset hvem du vælger som din hostingudbyder, skal du altid kigge efter følgende serverfunktioner for at sikre, at dit websted kører hurtigst muligt.

PHP 7 Eller Højere for den Bedste Ydeevne

PHP er en open source, server-side scripting og programmeringssprog, der primært anvendes til webudvikling. Størstedelen af den centrale WordPress-software er skrevet i PHP sammen med dine plugins og temaer, hvilket gør PHP til et meget vigtigt sprog for WordPress-fællesskabet. Du bør sikre, at dine WordPress host tilbyder mindst PHP 7 eller højere.

Der er forskellige versioner af PHP, som din vært vil give dig på din server, med den nyere PHP 7.2 tilbyder enorme præstation forbedringer.

Faktisk, i vores seneste PHP benchmarks, hvis du sammenligner PHP 7.3 med PHP 5.6, kan den håndtere 3 gange så mange anmodninger (transaktioner) pr. sekund! PHP 7.3 er også i gennemsnit 9% hurtigere end PHP 7.2. Dette kan også påvirke responsen på dit WordPress admin-dashboard.

Hurtigere hastigheder plus forbedret sikkerhed, er hvorfor Kinsta altid tilbyder de nyeste versioner af PHP. Du kan ændre PHP-versioner med et enkelt klik.

Og pas på, at alle WordPress-værter tilbyder HHVM som et alternativ til PHP. HHVM er ikke længere en passende løsning til WordPress hosting.

Vælg en Vært Der Bruger Nginx

Bag kulisserne bruger hver WordPress-vært en webserver til at drive dine WordPress-websteder. De mest almindelige felg er Nginx og Apache.

Vi anbefaler stærkt at gå med en vært, der bruger Nginx på grund af dets rødder i præstationsoptimering under skalaen. Nginx overgår ofte andre populære webservere i benchmark-test, især i situationer med statisk indhold eller høj samtidige anmodninger. Derfor bruger Kinsta Nginx.

Nogle højt profilerede virksomheder, der bruger Nginx, omfatter Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple , Intel og mange flere. (kilde)

Ifølge W3Techs driver Apache 44,0% af alle hjemmesider, hvilket gør den til den mest udbredte mulighed. Men hvis du ser på den mest populære webserver blandt højtrafikwebsteder (top 10.000), har Nginx 41,9% af dem, mens Apache kun har 18,1%. Det bruges af nogle af de mest ressourceintensive websteder, der findes, herunder Netflix, NASA, og endda WordPress.com.

Læs mere i vores webserver showdown: Nginx vs Apache.

Dine Værts Netværk Betyder Noget

Når du vælger en WordPress-vært, tør du måske ikke engang at spørge eller undersøge, hvilket netværk de bruger, men det skal du. Netværket kan have en stor indvirkning på dit websteds ydeevne og endda hastigheden af dit WordPress dashboard. Mange værter vil undlade dette ud af deres markedsføring, da de vælger det billigste netværk for at reducere omkostningerne.

Her er et par spørgsmål, du burde spørge:

• Hvilke netværk overfører du data fra? Er størstedelen af det over offentlige internetudbydernetværk eller private infrastrukturer som Google eller Microsoft? Disse store udbydere har netværk, der er bygget og optimeret til lav latens og hastighed. De har selv deres egne internet kabler under havet!
• Er de netværk, du bruger overflødige? Hvad sker der, hvis et kabel ved et uheld skæres over? Dette sker oftere end du tror.

Tilbage i 2017 annoncerede Google deres standard tier netværk, hvilket er et langsommere netværk, men til en billigere pris. På Kinsta udnytter vi deres premium-niveau netværk for alle vores hosting planer. Selv om dette er en ekstra pris for os, sikrer det dig, at du får lynhurtige hastigheder.

Ifølge Google opnår premium-netværket forbedret netværksydelse ved at reducere rejsens varighed på det offentlige internet; pakker ankommer (og forlader) Googles netværk så tæt på brugeren som muligt og derefter rejser på rygraden, inden de kommer til VM. Standardniveauet leverer udgående trafik fra GCP til internettet via offentlige transit (ISP) netværk i stedet for Googles netværk.

At sige det på en anden måde, der kan være lettere at forstå:

• Premium-pakker bruger mere tid på Googles netværk, med mindre ustabilitet og performer dermed bedre (men koster mere).
• Standardpakker bruger mindre tid på Googles netværk, og mere tid på at spille karl smart på offentlige netværk og dermed udføre dårligere (men koste mindre).

Hvor meget påvirker dette? Nå, for data, der rejser på tværs af kontinenter, er deres premium tier netværk omkring 41% hurtigere i gennemsnit end standard tier netværk. For data, der rejser til et nærliggende område (samme kontinent), er premium-niveauet ca. 8% hurtigere. Mens netværk kun udgør en brøkdel af din samlede sideindlæsningstid, løber hver millisekund op!

Redundans er også nøglen, og derfor bruger Google mindst tre uafhængige stier (N + 2 redundans) mellem to steder på Google-netværket og hjælper med til at sikre, at trafikken fortsætter med at strømme mellem lokaliteterne selv i tilfælde af forstyrrelser.

Som du sikkert kan forstå nu, foregår meget bag kulisserne, når det kommer til netværk. Sørg for, at din WordPress-vært bruger en velrenommeret og ikke vælger de lavere niveauer for at reducere omkostningerne.

HTTP/2 er et Must-Have

HTTP/2 er en webprotokol udgivet i 2015, som blev designet til at fremskynde, hvordan websteder leveres. På grund af browsersupport kræver det HTTPS (SSL). Hvis din WordPress-vært ikke understøtter HTTP/2, skal du begynde at lede efter en ny udbyder. Med flytningen af hele nettet til HTTPS er dette ikke længere bare en god funktion at have; det er en nødvendighed.

Forbedringen i ydeevne med HTTP/2 skyldes en række forskellige årsager, såsom understøttelse af bedre multipleksering, parallelisme, HPACK-komprimering med Huffman-kodning, ALPN-udvidelsen og serverdæmpning. Der var en del TLS-overhead, når det drejede sig om at køre over HTTPS, men det er nu meget mindre takket være HTTP/2 og TLS 1.3. Kinsta understøtter TLS 1.3 på alle vores servere og vores Kinsta CDN.

En anden stor sejr med HTTP/2 er at med de fleste WordPress-websteder behøver du ikke længere at bekymre sig om concatenation (kombinere filer) eller domæne deling. Disse er nu forældede optimeringer.

Vælg en Server Nærmest Dine Besøgende

En af de allerførste ting, du bør gøre, når du er vært for dit WordPress-websted, er at bestemme, hvor størstedelen af dine besøgende eller kunder kommer fra. Hvorfor er dette vigtigt? Fordi den placering, hvor du er vært for dit websted, spiller en væsentlig faktor i bestemmelsen af din samlede netværkslatens og TTFB. Det påvirker også dine SFTP-hastigheder og WordPress admin dashboard responsiveness.

Netværksforsinkelse: Dette refererer til den tid og eller forsinkelse, der er involveret i transmissionen af data via et netværk. Med andre ord, hvor lang tid det tager for en pakke data at gå fra et punkt til et andet. I dag måles dette typisk i millisekunder; Det kan imidlertid være sekunder, afhængigt af netværket. Jo tættere på nul jo bedre.

Tjek vores dybtgående indlæg på netværkslatens.

TTFB: Dette står for tid til første byte. For at sige det, er det en måling af, hvor længe browseren skal vente, før den modtager sin første byte af data fra serveren. Jo længere tid det kræver at få disse data, jo længere tid det tager at vise din side. Igen jo tættere på nul jo bedre.

Se vores indgående post på TTFB.

Vi vil ikke KEDE dig med alle de tekniske detaljer i dette indlæg. Alt du behøver at vide er, at du vil have din netværkstid og TTFB så lav som muligt. En af de nemmeste måder at opnå dette på er at vælge en server, der er tættest på dine besøgende. Du kan bestemme den bedste placering ved at følge nedenstående tips.

Tip 1 – Kontroller Geografisk Placering af Dine besøgende i Google Analytics

En af de allerførste ting, du kan gøre, er at se på de geografiske placeringer af dine besøgende i Google Analytics. Du kan finde dette under “Målgruppe → Geo → Placering.”

I dette eksempel nedenfor kan du se, at over 90% af trafikken kommer fra USA. Så i de fleste tilfælde vil du placere dit WordPress-websted på en server i USA. Du kan også filtrere dataene endnu længere til byer. Dette er især vigtigt, hvis du er et lokalt firma. Men typisk vil vi anbefale en central beliggenhed som Iowa, USA.

Tip 2 – Tjek E-Handelsdata

Hvis du kører en e-handelsbutik, skal du også sørge for at kontrollere, hvor dine kunder kommer fra. Dette er selvfølgelig, hvordan du genererer indtægter, så det er dine vigtigste besøgende. Dette bør falde sammen med din trafik ovenfor; Dette er dog ikke altid tilfældet. Hvis du har e-handelsdataopsætning eller -mål i Google Analytics, kan du nemt overlejre disse oplysninger oven på geolocation-dataene for at træffe en mere informeret beslutning. Eller kontroller placeringsoplysninger, der er gemt i din e-handelsplatforms database.

Tip 3 – Lav en Hurtig Forsinkelsesprøve

Der er mange praktiske gratis værktøjer derude til at måle latens fra din nuværende placering til forskellige cloud-udbydere. Dette kan hjælpe dig med hurtigt at vurdere, hvilken region der kan være det bedste valg til dit websted.

• GCP Ping (måleforsinkelse til Google Cloud Platform-regioner, herunder Kinsta-servere)
• CloudPing.info (måle latens til Amazon Web Services regioner)
• Azure Latency Test (måleforsinkelse til azurregioner)

I dette eksempel nedenfor kan vi se, at Oregon, USA (us-west1) er den hurtigste fra, hvor vi er placeret. Men hvis du betjener kunder over hele USA, kan det være bedre at vælge Iowa, USA (us-central1) for at sikre lav ventetid for besøgende fra både vest og østkyst.

Her på Kinsta tilbyder vi 37 forskellige datacentre over hele kloden. Du kan nemt vælge et websted, der vil have både lav latenstid og lav TTFB! Dette hjælper også med at reducere net-besvær.

Yderligere Måder at Reducere Latens og TTFB

Ud over at vælge en tæt serverplacering, her er et par andre måder at reducere ventetid på.

• Implementér caching på dit WordPress-websted. I vores test reducerede caching vores TTFB med en kæmpe 90%!
• Udnyt et indholdsleveringsnetværk (CDN) til at betjene cachelagrede aktiver fra POP’er over hele kloden. Dette hjælper med at negatere netværkslatens for besøgende, som måske ikke er tæt på din værtsserver.
• Udnyt HTTP / 2-protokollen for at minimere antallet af runde ture takket være parallelisering. HTTP / 2 er aktiveret på alle Kinsta-servere.
• Reducer antallet af eksterne HTTP-anmodninger. Hver af disse kan have deres egen tilføjede latens baseret på deres serveres placering.
• DNS spiller en rolle i TTFB, så du bør bruge en premium DNS-udbyder med hurtige opslagstider.
• Brug prefetch og prerender til at udføre opgaver bag kulisserne, mens siden indlæses.

Bare rolig; Vi dækker alle ovennævnte anbefalinger nærmere nedenfor i dette indlæg.

SFTP-Hastighed og WordPress Admin Dashboard

Dine besøgende og kunder skal altid være din prioritet. Men et andet aspekt af ydeevne, som mange ikke taler om, er, hvordan nogle af disse beslutninger påvirker dit daglige arbejde. Den datacenterplacering, du vælger, har indflydelse på, hvor hurtigt dine SFTP-download- og uploadhastigheder (overførsel af filer med en FTP-klient) er, såvel som responsen af dit WordPress admin-dashboard.

Så mens du vil sikre dig og vælge en placering, der er bedst for dine besøgende, skal du også huske på, at det kan påvirke webstedets ledelse. Opgaver som at uploade filer til WordPress mediebiblioteket bliver hurtigere, når dit websted er hostet på et datacenter tættere på dig.

Vi hører konsekvent fra kunder hos Kinsta, at de er overraskede over, hvor meget hurtigere deres admin dashboard er hos os. Der er en lang række faktorer der påvirker dette, men at have 18 forskellige datacentre er en stor ting! Vælg et sted, der fungerer både for dine besøgende og for dig! Når alt kommer til alt, er du den der sandsynligvis vil bruge tusindvis af timer på din hjemmeside.

Premium DNS er Bedre End Gratis DNS

DNS, der er kort for Domain Name System, er en af de mest almindelige, men ikke-forståelige komponenter i weblandskabet. For at sige det, hjælper DNS direkte trafik på internettet ved at forbinde domænenavne med egentlige webservere. I det væsentlige tager det en menneskelig venlig anmodning – et domænenavn som kinsta.com – og oversætter den til en computervenlig server-IP-adresse – som 216.58.217.206.

Du kan finde både gratis DNS og premium DNS. Alle Kinsta-kunder får adgang til premium DNS via Amazon Route 53. Og generelt tror vi, at premium DNS er en nødvendighed i dagens verden.

En stor grund til at vælge premium DNS er hurtighed og pålidelighed. At kigge på DNS-registreringer og styre trafik tager tid, selvom det kun er et spørgsmål om millisekunder.

Typisk er den gratis DNS, du får fra dit domænenavnsregistrator, forholdsvis langsom, mens premium DNS ofte giver bedre ydeevne. For eksempel viste vi i vores tests, at den gratis NameCheap DNS var 33% langsommere end Amazon Route 53 Premium DNS. Derudover kan premium DNS tilbyde bedre sikkerhed og tilgængelighed, især når du er under et DDoS-angreb.

Du kan bruge et værktøj som SolveDNS hastighedstest til at kontrollere dine DNS opslagstidspunkter. DNSPerf giver også fremragende præstationsdata på alle de bedste DNS-udbydere.

For en god mellemting mellem den gratis DNS, som din domæneregistrator og premium DNS tilbyder, er Cloudflare DNS en gratis tjeneste, der stadig giver mange af fordelene ved premium DNS. Og de brænder hurtigt med under 20 ms gennemsnitlige responstider rundt om i verden (som set nedenfor).

Cloudflare-integration kommer med alle Kinsta-planer. Hvis du primært betjener besøgende i USA, er DNS Made Easy en anden fantastisk premium DNS-udbyder, du måske vil tjekke ud. De har ry for at levere noget af den bedste DNS-uptime i løbet af det sidste årti.

I de sidste 30 dage viser DNSPerf følgende oppetid fra disse udbydere:

• DNS Made Easy: 99,99% hvilket svarer til 4m 23,0s månedlig nedetid.
• Amazon Route 53: 99,88%, hvilket svarer til 52m 35,7s månedlig nedetid.
• Cloudflare: 99,85%, hvilket svarer til 1h 5m 44,6s månedlig nedetid.

Betyder nedetid så meget hos DNS-udbydere? Svaret på dette er virkelig et ja og et nej. DNS caches typisk med internetudbydere ved hjælp af tid til live værdi (TTL) på DNS-posten. Derfor, hvis en DNS-udbyder går ned i 10 minutter, vil du højst sandsynligt ikke lægge mærke til noget. Nedetid er vigtigt, men hvis udbyderen konsekvent har længere og hyppige udfald, eller hvis din internetudbyder og DNS-optegnelser begge bruger meget lave TTL-værdier.

Dine WordPress Temaer Betyder Noget

Alle elsker et helt nyt WordPress-tema, men pas på før du går ud og tager den, med alle de nye skinnende funktioner. For det første bør du tjekke vores artikel om forskellene, når det kommer til gratis vs betalte temaer. Med hensyn til ydeevne har hvert element du ser i et tema, en vis indflydelse på den samlede hastighed på dit websted. Og desværre, med tusindvis af temaer ude i naturen er der både gode og dårlige.

Så hvordan skal du vide, hvilken man skal vælge? Vi anbefaler at gå med en af følgende to muligheder:

• Et hurtigt letvægts WordPress-tema, der er bygget med kun de funktioner, du har brug for, intet mere.
• Et mere funktionsrige WordPress-tema, men du kan deaktivere funktioner der ikke er i brug.

Ting som Google Fonts, Font Awesome ikoner, sliders, gallerier, video og parallax scripts mv. Dette er blot nogle få af de mange ting, du bør kunne slukke, hvis du ikke bruger dem. Du vil ikke forsøge at finjustere disse manuelt efter det fakta. Og vi vil ikke vise dig 50 forskellige måder at strippe ting ud. I stedet skal du starte eller skifte til et WordPress-tema, der enten er let fra begyndelsen eller giver dig disse muligheder.

Nedenfor er et par WordPress temaer, som vi anbefaler, og at du ikke kan gå galt med! Stol på os, du vil takke os senere. 😉

Hvert tema nævnt nedenfor er fuldt kompatibel WooCommerce og Easy Digital Downloads, WPML, BuddyPress og bbPress. Vi kører et par hurtighedstest med hvert tema ved hjælp af følgende konfiguration:

• Hosted hos Kinsta, der kører WordPress 4.9.8
• PHP 7.3 og SSL (HTTPS)
• Kinsta CDN
• Imagify blev brugt til automatisk at komprimere billeder.

GeneratePress

GeneratePress er et hurtigt, letvægts (mindre end 1MB lukket), mobil responsivt WordPress tema bygget med hastighed, SEO og brugervenlighed i tankerne. Bygget af Tom Usborne, en udvikler fra Canada. Det er aktivt opdateret og godt understøttet. Selv et par Kinsta-team medlemmer bruger GeneratePress til deres projekter.

Der er både en gratis og premium version til rådighed. Hvis du kigger på WordPress-depotet, har den gratis version for øjeblikket over 200.000 aktive installationer, 2+ millioner downloads og en imponerende 5 ud af 5-stjernede rating (over 850 personer har givet det 5 stjerner).

En af de store ting ved GeneratePress er, at alle mulighederne bruger den indfødte WordPress Customizer, hvilket betyder at du kan se alle de ændringer, du foretager øjeblikkeligt, inden du trykker på udgiverknappen. Dette betyder også, at du ikke behøver at lære et nyt tema kontrolpanel.

Hvor hurtigt er det? Vi lavede en frisk installation af GeneratePress, kørte fem hastighedsprøver i Pingdom og tog gennemsnittet. Den samlede belastningstid var 305 ms med en samlet sidestørrelse på kun 16,8 KB. Det er altid godt at have en baseline test for at se, hvad temaet er i stand til med hensyn til rå ydeevne.

Vi kørte derefter et andet sæt t med en af de præbyggede temaer fra GeneratePress site biblioteket. Dette indeholder billeder, baggrunde, nye sektioner osv. En fordel GeneratePress har, er, at den har mange præ-byggede temaer, der ikke kræver et sidebygger plugin. Du kan se, at den stadig klokkede under 400 ms.

Nu er det naturligvis i et virkeligt miljø, du har måske andre ting kørende som Google Analytics, Facebook remarketing pixel, Hotjar osv. Men du bør nemt kunne sigte efter 1 sekunders mærke. Tjek en grundig gennemgang af GeneratePress over på woorkup.

Vi viser dig flere måder, du kan optimere og fremskynde WordPress nedenfor.

OceanWP

OceanWP-temaet er let og meget udvideligt og giver dig mulighed for at skabe næsten enhver form for hjemmeside, som en blog, portfolio, forretningswebsted og WooCommerce-butik med et smukt og professionelt design. Bygget af Nicolas Lecocq, er den også aktivt opdateret og godt støttet.

Ligesom med GeneratePress er der både en gratis og premium-version tilgængelig. Hvis du kigger på WordPress-depotet, har den gratis version for øjeblikket over 400.000 aktive installationer, og en anden imponerende 5 ud af 5-stjernede rating (over 2.600 mennesker har givet det 5 stjerner).

Hvor hurtigt er det? Vi lavede en frisk installation af OceanWP, kørte fem hastighedsprøver i Pingdom og tog gennemsnittet. Den samlede belastningstid var 389 ms med en samlet sidestørrelse på kun 230,8 KB. Skripterne i OceanWP er lidt større, men intet at skrive hjem om.

Vi kørte derefter et andet sæt tests med et af demo-temaerne fra OceanWPs webstedsbibliotek. Dette indeholder billeder, baggrunde, nye sektioner og krævede Elementor-sidebygger-plugin. Du kan se, at den stadig klokkede under 600 ms.

Du kan tjekke en mere dybdegående anmeldelse af OceanWP på vores blog.

Astra

Astra er et hurtigt, fuldt tilpasset og smukt tema, der passer til blogs, personlige porteføljer, forretningswebsteder og WooCommerce-forretninger. Det er meget let (mindre end 50 KB på frontend) og tilbyder enestående hastighed. Bygget af holdet på Brainstorm Force, er det aktivt opdateret og godt understøttet. Du kan måske genkende dem som skaberne af det populære All In One Schema Rich Snippets-plugin, der har eksisteret i mange år.

Ligesom med GeneratePress og OceanWP er der både en gratis og premium version tilgængelig. Hvis du kigger på WordPress-depotet, har den gratis version for øjeblikket over 400.000 aktive installationer, 1,6+ millioner downloads og en anden imponerende 5 ud af 5-stjernede rating (over 2500 personer har givet det 5 stjerner).

Hvor hurtigt er det? Vi lavede en frisk installation af Astra, kørte fem hastighedsprøver i Pingdom og tog gennemsnittet. Den samlede belastningstid var 243 ms med en samlet sidestørrelse på kun 26,6 KB.

Vi kørte derefter et andet sæt tests med et af demo temaerne fra Astra Starter kit site biblioteket. Dette indeholder billeder, baggrunde, nye sektioner og krævede Elementor-sidebygger-plugin. Du kan se, at den stadig klokkede under 700 ms. Bemærk: Billederne i denne demo blev fuldstændigt komprimeret, men de valgte meget højopløselige fra starten.

Det er vigtigt at tage forskellene mellem hastighedstestene med disse tre temaer med et gram salt. Problemet er, at det er næsten umuligt at køre en fuldstændig præcis side-om-side sammenligning. Det vigtige, som vi ønskede at vise dig, er, at alle disse WordPress-temaer blæser hurtigt, både ud af boksen og i fuld demo!  🚀

Advarsel Om Sidebyggere

Som du sikkert har bemærket, krævede OceanWP og Astra begge sidebyggere at bruge deres webstedsbibliotekstemaer. Her er et par ting at huske på, når du bruger et sidebygger-plugin:

• Nogle sidebyggere kan øge belastningstiden på dit websted. Dette skyldes, at de skal indlæse yderligere CSS og JS for at få tingene til at fungere for dig uden kode. Sådan foregår magien! Vi anbefaler altid frt-test af dit WordPress-websted før og efter installation af en sidebygger.
• Du laverforpligtelse og låser dig ind i den sidebygger til design. Sørg for at vælge en, der opdateres jævnligt og har alt hvad du behøver i det lange træk.

Med det sagt er vi stadig store fans af sidebyggere som Elementor og Beaver Builder. For det meste er de udviklet med ydeevne i tankerne og tilføjer kun lidt overhead. For de fleste er funktionaliteten og brugervenlighed det værd, da disse plugins giver dig mulighed for at oprette alt hvad du kan drømme! De kan også være hurtigere i nogle tilfælde, da de måske er en erstatning for 5+ andre plugins, som du ville have haft brug for ellers.

Men hvis du ikke har brug for et plugin til sidebygger, skal du ikke bare installere en for sjov. Det vil også være interessant at se, hvordan den nye Gutenberg-editor vil spille en rolle i webdesign i løbet af de næste par år.

Det Negative ved WordPress-Plugins

Nu til et scoop på WordPress plugins. Du har muligvis fået at vide, at du ikke skal installere for mange plugins, ellers det ville bremse dit WordPress-websted. Selvom det nogle gange er sandt, er det ikke den mest kritiske faktor. Antallet af plugins er ikke så vigtigt som pluginnets kvalitet. Så er det sagt. 😜

Ligesom med temaer betyder det, hvordan plugin er udviklet, og hvis den blev bygget med ydeevne i tankerne. Vi har mange klienter hos Kinsta, der kører 30-40 plugins, og deres websteder indlæses stadig på godt under et sekund.

Selvom det er sjovt at tilføje kode til dit websted, er det ikke altid praktisk af følgende årsager:

1. Du skal vedligeholde koden selv og holde den opdateret som standardændring. Folk er optaget, hvorfor ikke stole på de fantastiske udviklere, der kender standarderne bedre end de fleste?
2. Det meste af tiden vil et vel kodet plugin ikke introducere meget mere overhead end selve koden.
3. Du er nødt til at huske, at et flertal af WordPress-samfundet ikke er så teknisk dygtigt som udviklerens publikum. Plugins er løsninger, der hjælper med at løse problemer.

Der er selvfølgelig ikke så store plugins derude, som du vil holde dig væk fra. Stol på os; vi har set det værste af det værste på Kinsta. Mange, ikke alle, af de plugins, som vi forbyder hos Kinsta, har vi set, da præstationsproblemer er førstehånds. Vi vil også dykke ind i, hvordan du finder dårlige plugins på dit websted nærmere nedenfor.

Det kan dog ikke ignoreres, at en af de ting, som folk elsker ved WordPress, er dens massive bibliotek af tredjeparts plugins. Men med 56.000+ gratis plugins, der er opført på WordPress.org alene og tusindvis mere opført andetsteds, kan det være svært at finde det ene plugin, du har brug for. Tal om en nål i en høstak! Tjek den liste, vi har lavet af kun de bedste WordPress-plugins på markedet.

Vi forsøger kun at dele ting, vi bruger dagligt. Og ja, vi bruger WordPress-plugins på vores websted ligesom resten af jer. Mange af teammedlemmerne hos Kinsta udvikler og sælger selv plugins.

Et Stort Problem med WordPress-Plugins

Et stort problem med WordPress-plugins er afinstallationsprocessen. Når du installerer et WordPress-plugin eller -emne, gemmer det data i databasen. Problemet er, at når du sletter et plugin ved hjælp af en af standardmetoderne, går det typisk bag tabeller og rækker i din database. Over tid kan dette tilføje op til mange data og endda begynde at bremse dit websted nede. I vores eksempel afinstallerede vi Wordfence-sikkerhedsprogrammet, og det efterlod 24 tabeller i vores database (som vist nedenfor). Det er endnu værre, hvis de står bag data i dit wp_options-bord.

Og foruden databasen efterlader mange plugins også yderligere mapper og filer. I vores erfaring ses det almindeligvis med sikkerheds- og caching-plugins, som skaber yderligere mapper til logning. Efter at Wordfence-pluginet blev slettet, blev vi forladt med en “wflogs” -mappe i vores wp-indholdskatalog. Og vi forsøger ikke at vælge Wordfence, de fleste plugins og temaer på markedet virker sådan.

Hvorfor Gør Udviklere Dette?

Så du undrer dig nok, hvorfor udviklere ikke har selvoprydning, når du afinstallerer og sletter et plugin? Nå gør de det. Men her er et par grunde til, at de nok ikke er lige så indlysende som sådan.

1. De ønsker at beholde indstillinger for brugeren. Hvis du sletter et WordPress-plugin og beslutter at prøve det igen senere, vil alle dine indstillinger og data stadig være der. Selvom dette er super bekvemt, er det ikke den mest effektive måde.
2. De er ligeglade med præstationer. Nogle udviklere kan hævde, at efterladning af tabeller ikke påvirker ydeevnen. Men forestil dig et websted i løbet af ti år, efter at have brugt hundredvis af plugins, der muligvis har genereret tusindvis af rækker eller tabeller. Databaseforespørgsler har en væsentlig indflydelse på din WordPress-webstedets ydeevne, og plugins kan lave mange af disse anmodninger, hvis udvikleren ikke var forsigtig. Generelt skal et velskrevet plugin kun søge de tabeller eller rækker, som det er bundet til, men det er ikke altid tilfældet. Vi har set denne første hånd ved Kinsta, lange database forespørgsler, der bringer et websted til at gennemgå på grund af unødvendige autoloaded data i wp_options tabellen, der er efterladt.
3. De lavede en fejl. WordPress-pluginhåndbogen siger endda, at “mindre erfarne udviklere undertiden begår fejlen ved at bruge deaktiveringskrogen til dette formål.”

Den gode nyhed? Der er måder at rydde op og slippe af med et plugin korrekt. 👏 Tjek vores følgende tutorials:

• Sådan afinstalleres en WordPress-plugin (den rigtige måde)
• Sådan manuelt oprydning tabeller som er efterladt

Optimale WordPress-Indstillinger

Nu for at gå videre til optimale WordPress-indstillinger. Her er et par ændringer, du kan gøre for at hjælpe med at fremskynde dit WordPress-websted. Mange af disse er meget subtile ændringer, men alt hjælper!

Skift Din WordPress Login URL

Som standard er din WordPress-site’s login-adresse domain.com/wp-admin/. Et af problemerne med dette er, at alle bots, hackere og scripts derude også ved dette. Ved at ændre webadressen kan du gøre dig til et mindre mål, og beskytte dig bedre mod hidsige force angreb og reducere båndbredden, der bruges af de robotter, der ramte denne URL gentagne gange.

Hvis du ændrer din WordPress-login-URL, kan det også være med til at forhindre almindelige fejl som “429 For mange anmodninger.” Dette er ikke en løsning, det er kun et lille trick, der kan beskytte dig og reducere belastningen på den pågældende side.

For at ændre din WordPress login-URL anbefaler vi at bruge et af følgende plugins:

• WPS Hide Login (gratis)
• Perfmatters (premium, men indeholder andre præstationsoptimeringsindstillinger. Udviklet af et teammedlem hos Kinsta)

Deaktiver eller Tweak Plugin og Tema Opdateringer

Langsomme WordPress admin dashboards kan påvirkes af netværket, datacenterets placering og endda PHP versioner. Men en anden faktor, som ikke mange mennesker taler om, er WordPress Update Checker, der kører i baggrunden. Dette er et tilfælde, hvor der er mange WordPress-plugins og temaer, der kan skade dig. WeFoster har en stor blogpost om dette, hvor de mønter udtrykket “Tredje parts plugin Update Check Syndrome” eller TPPUCS.

Problemet er hovedsageligt, at den indbyggede WordPress update checker laver en ekstern GET-anmodning bag kulisserne (https://third-party-plugin/update-check.php). Nogle gange kan det være periodisk eller meget ofte. Hvis det sker hele tiden, kan dette medbringe dit admin-dashboard til en gennemgang.

Dette er mere af et problem med, hvordan opdateringscheckeren i WordPress er bygget. Hvis du lider af langsomme WordPress admin dashboard belastningsgange, kan du prøve at give dette et forsøg. Løsningen er at deaktivere automatiske opdateringer. Advarsel: Gør kun dette, hvis du planlægger at kontrollere opdateringer manuelt. Mange opdateringer omfatter sikkerheds- og fejlrettelser.

For at deaktivere opdateringer anbefaler vi at bruge et af følgende plugins:

• Disable All WordPress Updates: Helt gratis uden indstillinger. Gør hvad det siger godt.
• Easy Updates Manager: Giver mere kontrol over selektive opdateringer. Kerneversionen er gratis.

Du kan nemt sætte dig selv en kalenderpåmindelse, deaktiver plugin en gang om ugen, tjek efter opdateringer, og genaktiver den derefter.

Deaktiver Pingbacks

En pingback er en automatiseret kommentar, der bliver oprettet, når en anden blog linker til dig. Der kan også være selv-pingbacks, som oprettes, når du linker til en artikel i din egen blog.

Vi anbefaler, at deaktivere dem, da de genererer værdiløse forespørgsler og ekstra spam på dit websted. Husk, at de mindre opkald dit WordPress-websted skal gøre det bedre, især på websteder med høj trafik. For ikke at nævne det faktum, at en pingback på din egen hjemmeside bare er ret irriterende. Følg trinene herunder for at deaktivere pingbacks.

Trin 1 – Deaktiver Pingbacks fra Andre Blogs

I dit WordPress dashboard klikker du på “Indstillinger → Diskussion.” Under afsnittet Diskussionsindstillinger fjerner du markeringen “Tillad link underretninger fra andre blogs (pingbacks og trackbacks) på nye artikler.”

Trin 2 – Deaktiver Selv-Pingbacks

Når det kommer til at deaktivere selv-pingbacks har du et par muligheder. Du kan bruge det gratis No Self Pings-plugin. Eller du kan bruge en premium plugin som Perfmatters.

Alternativt kan du også deaktivere selv-pingbacks ved at tilføje følgende kode til dit WordPress-temas functions.php-fil. Advarsel, redigering af kilden til et WordPress-tema kan ødelægge dit websted, hvis det ikke gøres korrekt. Tip, du kan nemt tilføje PHP-uddrag som dette med det gratis Code Snippets plugin. Det betyder, at du aldrig behøver at røre ved dit tema.

function wpsites_disable_self_pingbacks( &$links ) {
  foreach ( $links as $l => $link )
        if ( 0 === strpos( $link, get_option( 'home' ) ) )
            unset($links[$l]);
}

add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Begræns Indlæg På Din Blog-Feed

Uanset om dit blog-feed er angivet som din hjemmeside eller er en anden side på dit websted, behøver du ikke 50 miniaturer, der alle indlæses samtidigt. For dem, der kører blogs med høj trafik, er din hjemmeside den vigtigste side på dit websted, og du vil have hurtig indlæsning. Jo færre anmodninger og medier jo bedre med hensyn til ydeevne.

Det er netop også derfor, at pagination blev opfundet (som set nedenfor). Pagination er det, du ser i slutningen af blog feeds, der giver dig mulighed for at gennemse til næste side. Typisk er disse tal, eller de kan bruge “næste/forrige” indlæg. Dit WordPress-tema vil sandsynligvis allerede have tilpasset pagination indbygget.

WordPress indstiller som standard grænsen på friske WordPress installationer til 10, men vi har set dette ændret så mange gange, at vi ikke har tal på det. Så sørg for at dobbelttjekke, hvilken værdi du bruger. Vi anbefaler et sted mellem 8 og 12. Hvis du er nysgerrig, bruger vi 12 på vores Kinsta blog hjemmeside.

Du kan finde denne indstilling i dit WordPress admin dashboard under “Indstillinger → Læsning.” Du kan derefter ændre værdien for “Højst fremvisning af blogsider”.

Hvorfor Cache Er så Vigtigt

Caching er helt klart en af de vigtigste og nemmeste måder at fremskynde WordPress på! Men før vi viser dig, hvordan du bruger caching, er det vigtigt først at forstå, hvordan det virker, og de forskellige former for caching tilgængelig.

Hvad er Caching?

Kort sagt kræver hver webside, der er besøgt på dit WordPress-websted, en forespørgsel til serveren, behandling af den pågældende server (herunder database forespørgsler) og derefter et endeligt resultat, der sendes fra serveren til brugerens browser. Resultatet er dit websted, komplet med alle de filer og elementer, der får det til at se ud som det gør.

Du kan f.eks. have et overskrift, billeder, en menu og en blog. Da serveren skal behandle alle disse anmodninger, tager det noget tid for den komplette webside, der skal leveres til brugeren – især med klumpede eller større websites.

Det er her et WordPress caching plugin kommer i spil! Caching instruerer serveren til at gemme nogle filer på disk eller RAM, afhængigt af konfigurationen. Derfor kan den huske og duplikere det samme indhold, som det har været i fortiden. Det reducerer i grunden mængden af arbejde, der kræves for at generere en sidevisning. Som følge heraf belastes dine websider meget hurtigere, direkte fra cachen.

Nogle andre fordele ved caching inkluderer:

• Din server bruger færre ressourcer – Dette binder i hurtighed, da færre ressourcer giver et hurtigere websted. Det giver dog også mindre belastning på din server. Dette er meget vigtigt, når det kommer til meget dynamiske websteder, som f.eks. Medlemskabswebsteder, og bestemmer hvad du kan og ikke kan tjene fra cache.
• Du får se lavere TTFB – Caching er en af de nemmeste måder at sænke din TTFB på. Faktisk reducerer caching i vores test typisk TTFB med op til 90%!

Typer af Caching

Når det kommer til typer caching, er der to forskellige fremgangsmåder, der almindeligvis anvendes:

1. Caching på server-niveau
2. Caching med et plugin

1. Caching på Server-Niveau

Caching på server-niveau er langt en af de nemmeste tilgange for slutbrugeren. Hvad dette betyder er, at WordPress hosting udbyder håndterer det til dig. På Kinsta udnytter vi følgende fire typer cache, som alle automatisk udføres på software eller server-niveau:

• Bytecode cache
• Object cache
• Page cache
• CDN cache

Det betyder, at du ikke behøver at bekymre dig om at rodde med komplicerede og forvirrende caching-plugins. Du kan stoppe med at Google rundt for de “bedste caching plugins” og fokusere på mere produktive opgaver. 👏

An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀

— WPColt (@WPColt) January 3, 2018

Sidens cache er konfigureret til at fungere lige ud af boksen med standard WordPress. Du behøver ikke at gøre noget! Du skal blot starte dit WordPress-websted, og sidens caching vil begynde at ske.

Vi har også caching regler på plads for e-handelssites som WooCommerce og Easy Digital Downloads. Som standard er visse sider, der aldrig skal cache, som f.eks. Indkøbsvogn, min konto og checkout, udelukket fra caching. Brugere omkaster automatisk cachen, når woocommerce_items_in_cart-cookie eller edd_items_in_cart er registreret for at sikre en jævn og in-sync-kasseproces.

Du kan nemt rydde dit WordPress site cache til enhver tid fra admin værktøjslinjen.

Det er også integreret i vores MyKinsta dashboard. Bare klik på Tools og klik på “Clear Cache.”

2. Caching med et Plugin

Hvis din værtudbyder ikke leverer cache, kan du bruge et tredjepartsprogram til WordPress-caching. På baggrund af vores erfaring anbefaler vi et af følgende:

1. WP Rocket (premium)
2. Cache Enabler (gratis)
3. W3 Total Cache (gratis)

Du kan også tjekke nogle ekstra muligheder i vores dybtgående indlæg om WordPress caching plugins.

Vi støtter også fuldt ud WP Rocket på Kinsta! Vi tillader normalt ikke cache plugins i vores miljø, fordi de er i konflikt med vores indbyggede caching-løsning. Men fra WP Rocket 3.0 bliver deres side caching-funktionalitet automatisk deaktiveret, når de kører på Kinsta-servere.

Dette gør det muligt for Kinsta-klienter at bruge vores hurtige serverniveau-caching, men benytter stadig de fantastiske optimeringsfunktioner, som WP Rocket har at byde på.

Ingen Caching vs Caching

Hvor meget hjælper caching? Beviset er i sumpen.

Vi kørte et par hurtighedstest med Kinstas serverniveau caching, så du kan se den forskel det gør, både med hensyn til total hastighed og TTFB.

Ingen caching

Vi kørte først fem test på Pingdom uden at cache aktiveret og tog gennemsnittet.

Ingen Caching TTFB

Det er også vigtigt at bemærke forskellen i TTFB uden og med caching. TTFB i Pingdom er repræsenteret af den gule “ventende” bar. Som du kan se TTFB uden caching er 192 ms. Du kan se, at den ikke tjenes fra cache, da x-kinsta-cache-overskriften viser en MISS.

Med Caching Aktiveret

Vi aktiverede derefter serverniveau caching og kørte fem tests på Pingdom og tog gennemsnittet.

Som du kan se caching på serverniveau, blev vores sides belastningstid reduceret med 33,77%! Og det er uden ekstra arbejde involveret. Dette websted, vi testede, er også ret optimeret, så større uoptimerede websteder er forpligtet til at se endnu større forskelle.

TTFB med Caching aktiveret

Nu, hvis vi kigger på TTFB’et med caching aktiveret, kan vi se, at det er under 35 ms. Du kan se, at den tjener fra cache, da x-kinsta-cache header viser et HIT..

CDN-cache er ligeledes lige så vigtigt som cache fra din WordPress-vært. Vi vil dykke mere ind i CDN’er længere nedenfor.

Problemer med Caching og Medlemskab Websteder

Medlemskabwebsteder indeholder meget uopnåelige indhold og sider, der løbende ændrer sig. Ting som f.eks. Login-siden for medlemmerne af fællesskabet (som kunne blive ramt konstant afhængigt af webstedets størrelse), checkoutsider for digitale varer eller kurser og diskussionsfora er almindelige skyldige og smertepunkter, da disse ikke typisk kan caches.

Men det slutter ikke der. På standard WordPress-websteder er WordPress dashboard heller ikke cachelagret for “logget ind” brugere. Det er fint, når du har nogle få forfattere og administratorer, men når du pludselig har tusindvis af medlemmer, der bruger instrumentbrættet, forårsager dette straks præstationsproblemer, da ingen af det kan tjene fra cachen på serveren. Det betyder, at du har brug for magt og arkitektur bag kulisserne for at sikkerhedskopiere det. Delt hosting-udbydere vil som regel bukke under for disse omstændigheder.

Objekt Caching for Meget Dynamiske websteder

Når det kommer til WordPress-medlemswebsteder, er dine almindelige cache-opsætninger normalt ikke nok, da de ikke altid udnytter det fuldt ud. Det er her, hvor objekt caching kommer i spil.

Objektcache gemmer resultaterne af databasespørgsler, så næste gang den pågældende bit af data er nødvendig, kan den leveres fra cache uden at spørge databasen. Dette fremskynder PHP-eksekveringstider og reducerer belastningen på din database. Dette bliver ekstremt vigtigt med medlemskabswebsteder! Med WordPress kan du implementere objekt caching på et par forskellige måder:

1. En tredjeparts caching løsning som W3 Total Cache
2. Redis (anbefales)
3. Memcached

Vi tilbyder Redis som et tilføjelsesprogram hos Kinsta, så du kan udnytte vedvarende genstands caching for dine medlemskabswebsteder.

At Analysere Cache

At Analysere Cache x-kinsta-cache header vi nævnte ovenfor? Afhængigt af din hosting udbyder eller caching løsning, kan overskriften blive navngivet noget lidt anderledes. Hver gang en anmodning er foretaget fra dit WordPress-websted, har overskriften en værdi, såsom HIT, BYPASS, MISS og EXPIRED. Dette giver dig mulighed for at se, hvordan din cache udfører.

At øge dit WordPress-sites cache-hitforhold er vigtigt, fordi du vil have så meget af dit websted, at det serveres fra cachen som muligt. Hos Kinsta kan du analysere dataene i vores MyKinsta-analyseværktøj og kinsta-cacheloggene for at afgøre, om der er cache-BYPASSing GET-anmodninger, der kan cachelagres eller POST-anmodninger, der kan fjernes.

Cachekomponentstakken (som vist nedenfor) lader dig se status for hver anmodning, uanset om det var en HIT, BYPASS, MISS eller EXPIRED. Du kan filtrere dataene de seneste 24 timer, 7 dage eller 30 dage.

Cache-komponentdiagrammet giver dig et overblik over dit cache-forhold. Jo flere anmodninger du tjener fra cache jo bedre. Som du kan se i eksemplet nedenfor, er dette WordPress-websted på et 96,2% HIT cache-forhold. Hvilket er godt!

Den øverste cache omdirigerings-sektion lader dig se, hvilke anmodninger der ikke bliver serveret fra cache. Disse kan typisk omfatte CRON-job, admin-ajax-anmodninger, e-handelskøbssider, forespørgselsstrenger og UTM-parametre mv.

Billedoptimering Er et Must

Billedoptimering er en anden ligetil ting, du kan gøre, som har en betydelig indvirkning på din samlede sideindlæsningstider. Dette er ikke valgfrit; hvert websted skal gøre dette!

Store billeder sænker dine websider, hvilket skaber en mindre end optimal brugeroplevelse. Optimering af billeder er processen med at formindske deres filstørrelse ved hjælp af enten et plugin eller script, som igen øger sidens belastningstid. Lossy og lossless compression er to metoder, der almindeligvis anvendes.

Ifølge HTTP Archive, pr. august 2019 udgør billederne i gennemsnit 34% af den samlede websides vægt. Så efter videoer, som er meget sværere at optimere, er billeder klart det første sted du skal starte! Det er vigtigere end JavaScript, CSS og Fonts. Og ironisk nok er en god billedoptimerings-arbejdsgang en af de nemmeste ting at implementere, men mange website ejere overser dette.

Billeder udgjorde i gennemsnit 54% af en sides samlede vægt tilbage i december 2017. Så det ser ud til, at internettet som helhed bliver bedre til billedoptimering! Men 34% er stadig et tal, der ikke kan ignoreres. Hvis du ikke har videoindhold på din hjemmeside, er billeder stadig sandsynligvis dit nr. 1 smertepunkt for sidevægten.

At Finde Balancen (Filstørrelse og Kvalitet)

Det primære mål med formatering af dine billeder, er at finde balancen mellem den laveste filstørrelse og acceptabel kvalitet. Der er mere end én måde at udføre næsten alle disse optimeringer på. En af de mest grundlæggende måder er at komprimere dem, inden du uploader til WordPress. Normalt kan dette gøres i et værktøj som Adobe Photoshop eller Affinity Photo. Eller ved at bruge den nye online Squoosh app fra Google. Men disse opgaver kan også udføres automatisk ved hjælp af plugins, som vi vil gå mere ind i nedenfor.

De to primære ting at overveje er filformatet og den type kompression du bruger. Ved at vælge den rigtige kombination af filformat og komprimeringstype kan du reducere din billedstørrelse med så meget som 5 gange. Du bliver nødt til at eksperimentere med hvert billede eller filformat for at se, hvad der virker bedst.

Før du begynder at ændre dine billeder, skal du sørge for at have valgt den bedste filtype. Der er flere typer filer, du kan bruge:

• PNG – producerer billeder af højere kvalitet, men har også en større filstørrelse. Var oprettet som et tabsløst billedformat, selv om det også kan være tabt.
• JPEG – bruger lossy og lossless optimering. Du kan justere kvalitetsniveauet for en god balance mellem kvalitet og filstørrelse.

Ideelt set bør du bruge JPEG (eller JPG) til billeder med masser af farve og PNG til enkle billeder.

Du bør også overveje at bruge WEBP-billeder på din hjemmeside.

Hvad med GIF’er? Animerede GIF’er er altid sjove, men de dræber webresultater. En masse GIF’er er over 1 MB i størrelse. Vi anbefaler at holde disse til sociale medier og Slack. Hvis der er en, som du ikke kan leve uden i dit blogindlæg, så tag et kig på, hvordan du kan komprimere animerede GIF’er.

Kompressions Kvalitet vs. Størrelse

Her er et eksempel på, hvad der kan ske, du komprimerer et billede for meget. Den første bruger en meget lav kompressionshastighed, hvilket resulterer i den højeste kvalitet (men større filstørrelse). Den anden bruger en meget høj kompressionshastighed, hvilket resulterer i et meget lavt kvalitetsbillede (men mindre filstørrelse). Bemærk: Det originale billede uberørt er 2,06 MB.

Som du kan se, er det første billede ovenfor 590 KB. Det er ret stort for et foto! Det er generelt bedst, hvis du kan holde en websides samlede vægt under 1 eller 2 MB i størrelse. 590 KB ville være en fjerdedel af det allerede. Det andet billede ser forfærdeligt ud, men det er kun 68 KB. Hvad du burde gøre, er at finde en god mellemtingh mellem din komprimeringsrate (kvalitet) og filstørrelsen.

Så vi tog billedet igen med en medium kompressionshastighed, og som du kan se nedenfor ser kvaliteten nu godt ud, og filstørrelsen er 151 KB, hvilket er acceptabelt for et billede i høj opløsning. Dette er næsten 4x mindre end det originale foto med lav kompression. Vi forsøger at holde de fleste af vores billeder under 100 KB-mærket for den bedste ydeevne.

Lossy vs Lossless Optimering

Det er også vigtigt at forstå, at der er to typer kompression, du kan bruge, nemlig lossy og lossless.

Lossy compression indebærer at fjerne nogle af dataene i dit billede. På grund af dette betyder det, at du måske ser nedbrydning (reduktion i kvalitet eller hvad nogle refererer til som pixeleret). Så du skal være forsigtig med, hvor meget du reducerer dit billede. Ikke kun på grund af kvalitet, men også fordi du ikke kan vende processen. Selvfølgelig er en af de store fordele ved lossy kompression, og hvorfor det er en af de mest populære komprimeringsmetoder, at du kan reducere filstørrelsen med en betydelig mængde.

Lossless compression, i modsætning til lossy, reducerer ikke kvaliteten af billedet. Hvordan er det muligt? Det gøres normalt ved at fjerne unødvendige metadata (automatisk genererede data produceret af enheden, der fanger billedet). Den største ulempe ved denne metode er imidlertid, at du ikke vil se en signifikant reduktion i filstørrelsen. Med andre ord vil det tage meget diskplads over tid.

Du vil gerne eksperimentere med, hvad der virker bedst for dig. Men for de fleste brugere anbefaler vi at bruge lossy kompression på grund af det faktum, at du nemt kan komprimere et billede godt over 70% (nogle gange endda over 90%!) Uden meget kvalitetstab. Multiplicér dette med 15 billeder på en side, og det vil spille en vigtig rolle ved at reducere dit websteds belastningstid.

Image Compression Plugins

Den store nyhed er, at der er nogle fantastiske WordPress-billedkomprimeringsprogrammer, du kan bruge til at automatisere hele processen. Her er nogle plugins, vi anbefaler:

• Imagify (lossy og lossless – optimerer billeder eksternt)
• WP Smush (lossy og lossless – optimerer billeder eksternt)

Det vigtigste ved valget af et billedoptimerings plugin er at bruge den, som komprimerer og optimerer billeder eksternt på deres servere. Dette reducerer igen belastningen på dit websted. Alle ovenstående gør dette.

Hvis du er nysgerrig, bruger vi Imagify-plugin’et på Kinsta-webstedet. Den komprimerer automatisk billeder, når vi uploader dem til WordPress mediebiblioteket. Så vi behøver aldrig bekymre os om noget. Over tid kan du få en fornemmelse for det billedkomprimeringsniveau, du vil bruge. Det tilbyder Normal, Aggressive og Ultra.

Vi bruger den aggressive tilstand ved Kinsta og ses typisk 60-70% opsparing afhængigt af billedet. Bemærk: Vi bruger meget flere PNG’er end JPEG’er, fordi de fleste af vores billeder er ikoner og illustrationer, ikke billeder.

Hvor meget hurtigere vil dit WordPress-websted være, hvis du bruger billedkomprimering? Alt afhænger af størrelsen af dine originale billeder og hvad de er efter kompressionen. Men vi kørte nogle hastighedsprøver og fandt ud af, at en kvalitets billedkomprimeringsløsning kan reducere sidetilpasningstider med over 80%!

Lazy Loading

Hvis du har mange billeder, kan du overveje at lazy loade dem. Dette er en optimeringsteknik, der læser synligt indhold, men forsinker downloading og gengivelse af indhold, der vises under folden.

Se vores guide til, hvordan du implementerer doven belastning i WordPress. Dette kan være særligt vigtigt på blogindlæg med masser af gravatar ikoner fra kommentarer. Google har også lige udgivet deres anbefalinger for lazy loading.

Yderligere Billede Optimeringstips

Her er et par sidste billed optimeringstips at gå væk med.

• Dage med uploading af billeder, der kun er dimensioneret til bredden af kolonnen eller DIV, er slut. Responsive billeder træder ud af boksen i WordPress (siden version 4.4) og vil automatisk vise mindre billedstørrelser til mobile brugere.
• SVG’er kan være et andet fantastisk alternativ til at bruge billeder. Alle de håndtegnede illustrationer, du ser omkring Kinsta-webstedet, er SVG’er (vektorer). SVG’er er typisk meget mindre i filstørrelse, men ikke altid. Se vores vejledning om, hvordan du bruger SVG’er på dit WordPress-websted.
• Brug web skrifttyper i stedet for at placere tekst i billeder – de ser bedre ud, når de skaleres og tager mindre plads. Og hvis du bruger en skrifttype generator, kan du optimere dem endnu mere. Se, how we decreased the size of our icon fonts med en hele 97,59% ved hjælp af en skrifttype generator.

Finjuster Din Database

Det næste der kommer, er nogle tip om, hvordan du finjusterer din WordPress database. Ligesom en bil behøver din database vedligeholdelse, da det over tid kan blive oppustet.

Medlemskabswebsteder gør det specielt vanskeligt, da de normalt genererer mere komplekse forespørgsler, hvilket igen giver ekstra latens til at hente informationen fra MySQL-databasen. Meget af dette skyldes alle de ekstra bevægelige dele og store mængder af datasites som disse har. Dette kan også skyldes websteder, der er stærkt afhængige af søgninger til navigation eller bruger WP_Query.

For ikke at nævne, har du også store mængder af samtidige brugere, der løbende spørger databasen.

Brug InnoDB MySQL Storage Engine

Mange ældre websteder bruger stadig MyISAM-lagringsmotoren i deres database. I de senere år har InnoDB vist sig at fungere bedre og være mere pålidelige.

Her er et par fordele ved InnoDB over MyISAM:

• InnoDB har lås på rækken. MyISAM har kun fuld bordlåsning. Dette gør det muligt for dine forespørgsler at blive behandlet hurtigere.
• InnoDB har hvad der kaldes referentiel integritet, der indebærer at støtte udenlandske nøgler (RDBMS) og forholdsbegrænsninger, MyISAM ikke (DMBS).
• InnoDB understøtter transaktioner, hvilket betyder at du kan begå og rulle tilbage. MyISAM gør det ikke.
• InnoDB er mere pålideligt, da det bruger transaktionslogfiler til automatisk gendannelse. MyISAM gør det ikke.

Så nu undrer du dig måske over, kører du InnoDB eller MyISAM? Hvis du kører på et ret nyt WordPress-websted, er du allerede i brug af InnoDB MySQL-lagringsmotor. Men med ældre WordPress-websteder vil du måske lave et hurtigt check. Nogle websteder kan endda have blandede og matchede MyISAM- og InnoDB-tabeller, hvor du kunne se forbedringer ved at konvertere dem hele tiden.

Følg disse enkle trin nedenfor for at kontrollere.

Trin 1

Log ind på phpMyAdmin og klik på din MySQL database.

Trin 2

Lav en hurtig scanning eller en slags kolonne “Type”, og du kan se, hvilken lagrings-motortyper dine tabeller bruger. I dette eksempel nedenfor kan du se, at to af tabellerne stadig bruger MyISAM.

Slet og Begræns Side og Post Revisioner

Når du gemmer en side eller et indlæg i WordPress, skaber det, hvad der hedder en revision. Dette sker i både udkast og allerede offentliggjorte indlæg, der opdateres. WordPress revisioner kan være nyttige, hvis du skal vende tilbage til en tidligere version af dit indhold.

Men revisioner kan også skade ydeevnen på dit WordPress-websted. På store websteder kan dette meget hurtigt løbe op i tusindvis af rækker i din database, som ikke nødvendigvis er nødvendige. Og jo flere rækker du har, desto større er din database i størrelse, hvilket tager meget af din lagerplads. Mens indekser blev oprettet til dette særlige formål, har vi stadig set dette problem drille WordPress-websteder. Der er et par ting, du kan gøre.

1. Slet gamle revisioner

Hvis du har et ældre WordPress-websted med mange sider og indlæg, kan det være på tide at gøre en hurtig oprydning og slette de gamle revisioner. Du kan gøre dette med MySQL, men med alle de dårlige kodestykker, der flyder rundt på internettet, anbefaler vi at lave en sikkerhedskopi af dit websted og bruge et gratis plugin som WP-Sweep.

En anden af vores foretrukne plugins, WP Rocket, har også en databaseoptimeringsfunktion til fjernelse af revisioner.

Hvis du er praktisk med WP-CLI, er der et par kommandoer, du kan bruge til dette.

Log ind på din server via SSH og kør følgende kommando for at få- og se antallet af revisioner i øjeblikket i databasen.

wp revisions list

Hvis du får en fejl, skal du muligvis først installere wp-revisions-cli-pakken med følgende kommando:

wp package install trepmal/wp-revisions-cli

Du kan derefter køre følgende kommando for at rydde op i revisionerne:

wp revisions clean

2. Begræns revisioner

En anden god strategi og en, som vi bruger hos Kinsta, er at begrænse antallet af revisioner, der kan gemmes pr. Post eller side. Selv fastsætte det til noget som ti, vil holde revisioner fra at komme ud af hånden, især hvis du laver en masse opdatering.

For at begrænse revisioner kan du føje følgende kode til din wp-config.php-fil. Koden nedenfor skal indsættes over ‘ABSPATH’ ellers fungerer det ikke. Du kan ændre nummeret til hvor mange revisioner, du vil beholde gemt i din database.

define('WP_POST_REVISIONS', 10);

Eller du kan bruge et plugin som Perfmatters til at begrænse revisioner.

3. Deaktiver Revisioner

Og sidst men ikke mindst, kan du også deaktivere revisioner på dit websted, helt og holdent. Hvis du tager denne rute, anbefaler vi stærkt at følge den første mulighed ovenfor for at slette revisioner og derefter deaktivere dem efterfølgende. På denne måde er din database helt fri for alle gamle revisioner, og ingen nye vil blive tilføjet fremad.

For at deaktivere revisioner kan du føje følgende kode til din wp-config.php-fil. Koden nedenfor skal indsættes over ‘ABSPATH’ ellers fungerer det ikke.

define('WP_POST_REVISIONS', false);

Eller du kan bruge et plugin som Perfmatters til at deaktivere revisioner.

Ryd op i Din wp_options Tabel og Autoloaded Data

Tabellen wp_options bliver ofte overset, når det kommer til overordnet WordPress og database ydeevne. Især på ældre og store websteder, kan dette nemt være synderen for langsomme forespørgselstider på dit websted på grund af autoloaded data, der efterlades fra tredjeparts plugins og temaer. Stol på os; vi ser det hver eneste dag!

Wp_options-tabellen indeholder alle mulige data til dit WordPress-websted, såsom:

• Webstedets webadresse, hjemmeadresse, admin-email, standardkategori, indlæg pr. Side, tidsformat osv
• Indstillinger for plugins, temaer, widgets
• Midlertidigt cachelagrede data

Denne tabel indeholder følgende felter (kolonner):

• option_id
• option_name
• option_value
• autoload (dette er den, vi er interesseret i, når det kommer til ydeevne)

En af de vigtige ting at forstå om wp_options-tabellen er autoload-feltet. Dette indeholder en ja eller en nej værdi (flag). Dette styrer i det væsentlige, om det er lastet af funktionen wp_load_alloptions() eller ej. Autoloaded data er der er indlæst på hver side af dit WordPress-websted. Ligesom vi viser dig, hvordan du deaktiverer bestemte scripts fra indlæsning på hele webstedet, gælder samme idé her. Autoload-attributten er som standard indstillet til “ja” for udviklere, men ikke alle plugins skal teoretisk indlæse deres data på hver side.

Problemet, som WordPress-websteder kan løbe ind, er, når der er en stor mængde autoloaded-data i wp_options-tabellen. Dette er typisk et resultat af følgende:

• Data bliver autoloaded af et plugin, når det skal indstilles til “no.” Et godt eksempel på dette ville være et plugin til kontaktformular. Behøver det at indlæse data på hver side eller bare kontaktsiden?
• Plugins eller temaer er blevet fjernet fra WordPress-webstedet, men deres muligheder er stadig tilbage i wp_options-tabellen. Dette kan betyde, at unødvendige autoloaded data bliver forespurgt på hver anmodning.
• Plugin og temaudviklere lægger data i wp_options-tabellen i stedet for at bruge deres egne tabeller. Der er argumenter på begge sider af dette, da nogle udviklere foretrækker plugins, der ikke opretter yderligere tabeller. wp_options-tabellen var imidlertid ikke designet til at holde tusindvis af rækker.

Hvor meget er for meget autoloaded data? Dette kan naturligvis variere, men ideelt set vil du have mellem 300kB og 1MB. Når du først nærmer dig 3-5 MB-området eller mere, er der højst sandsynlige ting, der kan optimeres eller fjernes fra at blive autoloaded. Og alt andet end 10MB skal tages op med det samme. Dette betyder ikke altid, at det vil forårsage et problem, men det er et godt sted at starte.

Fordi dette er sådan et problem, har vi en helt separat vejledning, du gerne vil læse om, om hvordan du bedst kan fejlmelde autoloaded data, samt hvordan du rydder op.

Ryd Op i Transienter

Medmindre du bruger en objektbuffer, gemmer WordPress forbigående optegnelser i wp_options -tabellen. Typisk gives disse en udløbstid og bør forsvinde over tid. Det er dog ikke altid tilfældet. Vi har set nogle databaser, hvor der er tusindvis af gamle forbigående optegnelser. Faktisk har vi på et websted behandlet nogle korrupte transient registre hvor over 695.000 rækker blev genereret i wp_options-tabellen. Yikes!

Det er også vigtigt at bemærke, at transienter ikke skal autoloaded som standard. Du kan bruge en forespørgsel som nedenstående for at se om der er autoloaded forbigående data.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

En bedre og sikrere mulighed ville være at bruge en gratis plugin som Transient Cleaner eller Delete Expired Transients som kun kan rydde op i de udløbne transienter fra dit wp_options-bord. Det ser imidlertid ud til, at der nu er en funktion i WordPress, tilføjet i 4.9, at husholdninger udløb transienter. Så forhåbentlig sker det automatisk på dit websted nu.

WP Rocket har også mulighed for at oprydning transienter i deres database optimeringsmuligheder.

Ryd Op i WordPress Sessioner

Et andet almindeligt problem, vi har set, er, at nogle gange synkroniseres cron jobs ikke eller brændes ikke ordentligt, og sessionerne bliver derfor ikke ryddet op. Du kan endne op med at få tonsvis af _wp_session_ rækker i din database. I dette eksempel afsluttes det pågældende websted med over 3 millioner rækker i deres wp_options-tabel. Og tabellen var vokset til over 600 MB i størrelse.

Du kan bruge en forespørgsel som den nedenfor for at se, om du løber ind i dette problem:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

I de fleste tilfælde kan du så sikkert slette disse (som et cron job skulle have) med følgende kommando:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Efter rydning af alle de resterende _wp_session_ rows rækker havde tabellen mindre end 1.000 rækker og blev reduceret til 11 MB i størrelse.

Det fastsatte også piggene, som webstedet fik i MySQL.

Tilføj et Indeks Til Autoload

Hvis oprydning af dit wp_options-bord ikke var nok, kan du prøve at tilføje et “indeks” til autoload-feltet. Dette kan i det væsentlige hjælpe det med at blive søgt mere effektivt. Det fantastiske hold over på 10up udførte nogle testscenarier på etwp_options-bord med et typisk antal autoloaded poster for at vise, hvordan tilføjelse af et autoload indeks til wp_options forespørgsler kan øge ydeevnen.

Vi anbefaler også at tjekke disse to ekstra ressourcer fra WP Bullet:

• Sådan tilføjes MySQL Index til wp_options tabel
• Rengøring af wp_options-bordet ved hjælp af WP-CLI

Brug Redis som et Vedvarende Objektcache for WordPress

Redis er en open-source, i-memory datastruktur butik. I forbindelse med WordPress, kan Redis bruges til at gemme værdierne genereret af WordPress ‘native object cache vedvarende, således at cachelagrede objekter kan genbruges mellem sidebelastninger.

Ved hjælp af en vedvarende objektcache som Redis, muliggør genbrug af cachelagrede objekter i stedet for at kræve, at MySQL-databasen forespørges en anden gang for det samme objekt. Resultatet er, at Redis kan reducere belastningen på en websides MySQL-database, samtidig med at sænkning af webstedets responstid og øge webstedets evne til at skalere og håndtere yderligere trafik.

Højt dynamiske websites (WooCommerce, medlemskabswebsteder, fora, diskussionsfora, blogs med ekstremt aktive kommentarsystemer), der ikke kan udnytte sidecaching, er potentielle kandidater til en vedvarende genstand cache-mulighed som Redis.

Hvis du er en Kinsta-klient, tilbyder vi en Redis-tilføjelse. Tjek hvordan du tilføjer Redis til din hosting plan.

Brug Elasticsearch til at Fremskynde WordPress Search

Elasticsearch er en open source fuldtekst søgemaskine. Det bruges til at indeksere data og søge disse data utroligt hurtigt.

I forbindelse med WordPress kan Elasticsearch bruges til at fremskynde forespørgslen af WordPress-databasen. Dette gøres ved at opbygge et indeks for indholdet af dit websteds database og derefter bruge Elasticsearch til at søge indekset meget hurtigere end en MySQL-forespørgsel kan udføre samme søgning.

Hvis du har tid og evne, kan Elasticsearch integreres med et WordPress-websted af en yderst kyndig WordPress og Elasticsearch-udvikler. Hvis dit websted gør relativt standard brug af WP_Query, kan Elasticsearch også integreres ved at installere ElasticPress, et gratis WordPress-plugin fra 10up, tilgængeligt fra WordPress.org, som automatisk integreres med WP_Query-objektet for at generere forespørgselsresultater med Elasticsearch i stedet for MySQL.

Ethvert websted, der gør stor brug af WP_Query kan drage fordel af Elasticsearch. Eksempler på websteder, der kan drage fordel af Elasticsearch:

• Sites, hvor søgning er det primære navigationsmiddel.
• WooCommerce-websteder med et stort antal ordrer, hvor sideadministratorer skal kunne søge i ordlisten regelmæssigt.
• Ethvert websted med et stort antal stillinger, hvor MySQL-forespørgsler producerer uacceptabelt langsomme resultater.

Deaktiver Ikke-Kritiske Funktioner, Der Er Database Intensive

Dette kan virke lidt indlysende, men det kan gøre en verden af forskel, hvis du deaktiverer ikke-kritiske plugins og temafunktioner, der er databaseintensive.

• Populære og/eller relaterede post widgets og plugins er forfærdelige. De har typisk store sitewide forespørgsler.
• Billedoptimerings plugins, der komprimerer billeder ved hjælp af din server. Du bør altid bruge et billedoptimeringsprogram, der optimerer billeder eksternt.

Hvis du besøger Kinsta-bloggen og ruller ned til slutningen af et indlæg, vil du bemærke, at vi har det, vi kalder “håndplukket” relaterede artikler. Disse vælges manuelt af os og tildelt til stillingen. Dette reducerer forespørgslen til næsten ingenting og vil ikke skade effektiviteten af hele dit websted. Tager det mere arbejde? Ja, men det kan være endnu bedre, da du kan vælge, hvad du vil have, læserne skal se.

Så hvordan har vi opnået dette? Vi brugte den fantastiske Advanced Custom Fields plugin og derefter tildelt disse felter til vores blog post type. Dette giver os mulighed for at søge og tildele alt relateret indhold, vi ønsker at hver af vores blogindlæg (som set nedenfor).

Vi anbefaler også at opholde sig fra plugins, der tilføjer en visning/posttæller til dit websted, medmindre du absolut har brug for det. For eksempel, så undgå ting som “792 indlæg” ud for en brugers avatar i forumindlæg eller “5,243 visninger”, når du noterer forumindlæg. Når du har en lang diskussion, vil disse tællere tage en enorm vejafgift på din database. Generelt minimer brugen af tællere og brug dem kun hvis nødvendigt.

Dette gælder også for mange sociale tællere. For eksempel kan du se svartid fra den populære Social Warfare-plugin på 30 sider mere end det næste plugin under det. Caching er aktiveret, men naturligvis har dette plugin en betydelig præstationsafgift. Når du har deaktiveret plugin’et på webstedet, forbedres belastningstider øjeblikkeligt, og lydstyrken af WordPress admin dashboard forbedres.

Brug et Content Delivery Network (CDN)

CDN er kort for indholdsleveringsnetværk. Disse er et netværk af servere (også kendt som POP’er) er placeret over hele kloden. De er designet til at være vært for og levere kopier af dit WordPress-websteds statiske (og undertiden dynamiske) indhold som billeder, CSS, JavaScript og videostrømme.

For det første vil du ikke få en CDN forvirret med din WordPress-vært. Disse er helt separate tjenester. En CDN er ikke en erstatning for din hostingudbyder, men snarere en ekstra måde at øge hastigheden på dit websted. Mens vores vært her hos Kinsta blæser hurtigt, kan en CDN gøre dit websted endnu hurtigere.

Hvordan en CDN Virker

Hvordan virker en CDN nøjagtigt? Nå, for eksempel, når du er vært for din hjemmeside med Kinsta, skal du vælge en fysisk datacenterplacering, som f.eks. USA, Europa, Asien-Stillehavet eller Sydamerika.

Lad os sige, at du vælger US Central. Det betyder, at dit websted er fysisk placeret på en “værtsserver” i Council Bluffs, Iowa. Når folk over i Europa besøger dit websted, vil det tage længere tid for den at indlæse mod nogen, der besøger den fra f.eks. Dallas, TX.

Hvorfor? Fordi dataene skal rejse en længere afstand. Dette er hvad der er kendt som latens. Latens refererer til den tid og eller forsinkelse, der er involveret i transmissionen af data via et netværk. Jo længere afstanden jo større latensen er.

Typer af CDN’er

Der er to forskellige typer indholdsleveringsnetværk:

1. Traditionel Træk CDN
2. Reverse Proxy CD

Traditionelle pull-CDN’er cacher en kopi af alt dit indhold og medier, men en anmodning fra klienten foretages stadig direkte til din hostingudbyder. KeyCDN og CDN77 er eksempler på traditionelle CDN’er.

En omvendt proxy CDN er lidt anderledes. Mens det stadig virker som et CDN, aflyser det alle indgående forespørgsler og fungerer som en mellemliggende server mellem klienten og din vært. Cloudflare og Sucuri er eksempler på reverse proxy-CDN’er. Dette er en grund til, at du skal pege på din DNS direkte til disse udbydere i stedet for din vært.

Fordelene ved disse er, fordi de fungerer som en mellemliggende server, de kan levere stærke webapplikations firewalls, som kan hjælpe med at blokere den dårlige trafik fra nogensinde at ramme dit WordPress site og eller hosting udbyder. En overgang til dette er, at de kommer med lidt ekstra overhead i form af ydeevne i forhold til en traditionel pull-CDN. Men med yderligere ydeevne og sikkerhedsfunktioner kan dette hævdes som ubetydelig.

Nedenfor er et eksempel på, hvad der skete efter at Sucuri blev muliggjort på en kundes websted. Som du kan se det havde en dramatisk indvirkning på mængden af dårlig trafik, der kom igennem. I sidste ende kan disse typer tjenester hjælpe dig med at spare på dine hostingomkostninger.

CDN Speed Tests

Tidligere talte vi om de store fordele ved WordPress caching. Nåh, CDN caching er også super kraftfuld. Dette skyldes, at CDN’er typisk har meget flere serverplaceringer end hosting-udbydere. Det betyder, at de kan cache alle dine aktiver (billeder, JS, CSS) tættere på dine besøgende og servere dem ved lynhurtige hastigheder.

Lad os lave et par hurtige tests for at se, hvor meget hurtigere dit websted kunne være med en CDN.

Uden CDN

Vores testwebsted er vært hos Kinsta og er fysisk placeret på Iowa, USA datacenter. Vi kørte først fem hastighedsprøver i Pingdom (uden CDN aktiveret) og tog gennemsnittet. Vigtigt: Vi bruger London-London-beliggenheden i Pingdom til at demonstrere den virkelige kraft af en CDN. Den samlede belastningstid var 1,03 s.

Med CDN

Vi aktiverede derefter vores CDN og kørte fem yderligere hastighedsprøver i Pingdom. Vores samlede belastningstid er nu 585 ms fra testcentret Europa – Storbritannien – London Pingdom. Så ved at bruge CDN’en kunne vi reducere vores sideindlæsningstider med 43,2%! Det er enormt.

Årsagen til en så drastisk forskel er, at CDN’en har et datacenter i London. Dette betyder, at alle aktiverne er cachelagrede på den pågældende placering og klar til at blive serveret med minimal ventetid.

TTFB uden CDN

Husk at den gule bar i Pingdom står for ventetid, hvilket er tid til første byte (TTFB). På vores hastighedsprøver uden CDN kører den gennemsnitlige TTFB på aktiverne omkring 98 ms.

TTFB med CDN

Når vi aktiverede CDN, faldt den gennemsnitlige TTFB på aktiver i gennemsnit på 15 ms. Så ved at bruge en CDN faldt vores gennemsnitlige TTFB med 84,69%. Dette skyldes primært, at aktiverne blev serveret direkte fra CDN’ens cache.

Hvordan man Aktiverer en CDN

At aktivere en CDN på dit WordPress-websted behøver ikke at være svært, det er ret nemt! Følg blot disse trin.

Trin 1

Vælg en CDN-udbyder og abonner på deres tjeneste. Disse faktureres typisk månedligt eller ved brug af data. De fleste udbydere vil have en lommeregner til at estimere dine omkostninger.

• Hvis du ser på at implementere KeyCDN selv, anbefaler vi at læse denne artikel på CDN for dummies. Hver CDN-udbyder bør også have dokumentation for at hjælpe dig med at komme i gang.
• Vi har dybtgående vejledninger om, hvordan du installerer Cloudflare og hvordan du installerer Sucuri.

Trin 2

Hvis du bruger en traditionel pull-CDN, kan du bruge gratis plugin som CDN Enabler, WP Rocket eller Perfmatters til at integrere det med dit WordPress-websted. Disse plugins linker automatisk dine aktiver til CDN’en. Der er ikke brug for noget arbejde fra din side, for at få dit indhold på CDN; dette er alle hands-off! Reverse Proxy-CDN’er kræver typisk ingen plugins, selvom de nogle gange har dem til at aktivere yderligere features.

Sådan Aktiveres Kinsta CDN

Kan du lide de CDN hastighedstest ovenfor? Vi brugte KeyCDN i disse tests. Den store nyhed
er, at vores Kinsta CDN drives af KeyCDN. Det er et HTTP / 2 og IPv6-aktiveret
indholdsleveringsnetværk med 200+ steder, for at turboloade dine aktiver og medier over hele
kloden. I øjeblikket serveres regioner omfatter Amerika, Sydamerika, Europa, Afrika, Asien og Australien.

Hvis du er en Kinsta-klient, inkluderer vi gratis CDN-båndbredde på alle vores hostingplaner. Du kan aktivere Kinsta CDN i to enkle trin.

Trin 1

Først skal du logge ind på dit MyKinsta dashboard. Klik på dit websted og derefter på Kinsta CDN-fanen.

Trin 2

Klik derefter på “Aktivér Kinsta CDN”. Efter et par minutter bliver CDN’en automatisk implementeret, og dine aktiver tjener fra cache over hele kloden. Det er alt der er til det. 😄

Yderligere CDN-Optimeringer

Her er et par ekstra CDN optimeringer, du måske vil tjekke eller tænke på.

• • Hvis du har mange kommentarer, kan gravatars generere mange anmodninger. De indlæses fra secure.gravatar.com. Tjek denne vejledning om, hvordan du indlæser gravatars fra din CDN i stedet. Vi gør dette på Kinsta hjemmeside. 👍
  • Du kan være vært for dine brugerdefinerede web skrifttyper fra din CDN eller endda Google-skrifttyper på din CDN. Se vores dybtgående vejledning om lokale skrifttyper.
  • Sørg for at indlæse dit favicon fra din CDN. Selvom det er lille, tæller hver anmodning!

Offload Media og E-mail Når Behøvet

Alt, der genererer en anmodning, har indflydelse på dit websteds ydeevne på en eller anden måde. For websteder med hosting af hundredtusinder af filer eller store medier, kan det være klogt at download dette helt. Aflæsning er anderledes end at vise det via en CDN. Med en CDN ligger de oprindelige data stadig hos din vært, CDN har simpelthen flere kopier af den.

Når caching udløber på dine CDN-aktiver, spørger den din vært om de nyeste kopier af filerne. CDN’er er beregnet til at cache filer i lange perioder. Men på grund af det faktum, at de har så mange POP’er, kan der være meget efterspørgsel i gang, da cache udløber i forskellige regioner.

Når du offloader medier eller filer betyder det faktisk at flytte den oprindelige fysiske placering af dem fra din hostingudbyder. Så selvom det ser ud til at filerne serveres fra dit websted, er de virkelig placeret et helt andet sted. Udover at reducere yderligere forespørgsler tilbage til værten, er den første årsag naturligvis også at spare på diskplads.

Offload Media til Amazon S3

En af de mest populære offloading løsninger er Amazon S3. Amazon S3 er en oplagringsløsning, og en del af Amazon Web Services mange produkter. Typisk bruges dette til store websteder, der enten kræver ekstra sikkerhedskopier eller tjener store filer (downloads, software, videoer, spil, lydfiler, PDF-filer osv.). Amazon har vist sig at være meget pålidelig, og på grund af deres massive infrastruktur kan de tilbyde meget lave lageromkostninger. Nogle af S3s kunder omfatter Netflix, Airbnb, SmugMug, Nasdaq, osv.

Fordi de beskæftiger sig helt med bulkoplagring, kan du næsten garantere, at prissætning bliver billigere end din WordPress-vært. Aflæsning af medier til AWS kan være en fantastisk måde at spare penge på og er gratis til dit første år (op til 5 GB lagerplads). Også fordi anmodningerne om dine medier serveres direkte fra Amazon, sætter det mindre belastning på dit WordPress-websted, hvilket betyder hurtigere belastningstider.

Tjek vores dybdegående vejledning om, hvordan du offloader WordPress-medier til Amazon S3. Du kan også bruge en CDN med offloaded media til det bedste fra begge verdener.

Offload Media til Google Cloud Storage

En anden populær offloading-løsning er Google Cloud Storage. Da Kinsta drives af Google Cloud Platform, er vi store fans af deres teknologi og infrastruktur. På grund af Googles massive infrastruktur og det faktum, at de beskæftiger sig med opbevaring i løs vægt, kan de tilbyde meget lave lageromkostninger. Nogle af deres kunder omfatter Spotify, Vimeo, Coca-Cola, Philips, Evernote og Motorola.

Se vores dybdegående vejledning om, hvordan du aflaster WordPress-medier til Google Cloud Storage.

Offload Transactional og Marketing Emails

Uanset om du synes det eller ej, har e-mails betydning for dine server- og serverressourcer. Med nogle værter, især delte værter, misbruger dette måske endda dig suspenderet. Dette bliver især et problem med dem, der forsøger at sende bulk e-mails. Dette er grunden til, at tredjeparts transaktions-e-mail-udbydere eksisterer, og hvorfor mange hostingudbydere blokerer e-mail-levering på standardporte helt og holdent. Vi anbefaler aldrig at bruge din hostingudbyder til e-mail.

Hvis du sender nyhedsbreve eller masse-e-mails, anbefaler vi altid følgende alternativer for at få de bedste resultater:

• Brug en tredjeparts professionel email marketing software, der ikke er en del af WordPress
• Brug en transaktionsmæssig e-mail-udbyder (HTTP API eller SMTP) sammen med WordPress

Andre fordele ved at bruge en tredjeparts service omfatter:

• Bedre email levérbarhed. Lad e-mail-udbyderne gøre, hvad de gør bedst!
• Mindre chance for at blive sortlistet.
• Det kan ikke altid være muligt at oprette DMARC-poster med din hostingudbyder.

Email Marketing Værktøjer

Nogle eksempler på markedsførings e-mails omfatter nyhedsbreve, produkt- og funktionskampagner, salg, hændelsesinvitationer, påmindelser om bord osv. Her er et par e-mailmarkedsværktøjer, vi anbefaler:

• MailChimp – Vi bruger MailChimp på Kinsta.
• MailerLite
• Drip

Transaktionelle e-mail-tjenester

Nogle eksempler på transaktionsemails omfatter købskvitteringer fra WooCommerce eller EDD, meddelelser om oprettelse af konto, forsendelsesmeddelelser, appfejlmeddelelser, nulstilling af adgangskode osv. Hvis du er en Kinsta-klient, baserer vi os på en tredjeparts SMTP-udbyder for at sikre høj leverbarhed . Men afhængigt af dit volumen anbefaler vi altid at flytte denne offsite. Her er et par transaktions e-mail-tjenester, vi anbefaler:

• SendGrid – Vi bruger SendGrid på Kinsta.
• Mailgun – Se hvordan man konfigurerer Mailgun i WordPress.
• SparkPost

Sådan Finder du Flaskehalse og Langsomme Plugins

Nu vil vi dykke ind i nogle tips om, hvordan du finder flaskehalse på dit WordPress-websted, og hvad du kan gøre ved det.

Brug New Relic til Identity Slow Plugins og Database Queries

Der er nogle gode værktøjer på markedet, som kan hjælpe dig med at påpeje og identificere langsomme databaseforespørgsler og plugins, der bruger meget tid. Vi er store fans af New Relic hos Kinsta og bruger det dagligt. New Relic er et PHP overvågningsværktøj, du kan bruge til at få detaljerede præstationsstatistikker på din hjemmeside.

Hvis du er en Kinsta-klient, kan du endda tilføje din egen New Relic-licensnøgle på vores MyKinsta-dashboard.

Brug dog New Relic omhyggeligt, da det påvirker webstedets ydeevne. Det tilføjer JavaScript til din hjemmeside. Vi anbefaler, at du aktiverer det, når du skal fejlfinde, og derefter deaktivere den.

Finde langsomme plugins

Når et WordPress-plugin forårsager generel langsomhed, vil symptomerne variere afhængigt af den aktivitet, plugin’et udfører. Men i mange tilfælde vil du opdage, at et langsom plugin vil påvirke hver side på et WordPress-websted. I tilfælde af det websted, hvis data du ser på billedet nedenfor, blev den generelle langsommelighed observeret på hver forside på siden. Her er hvad New Relic måtte sige om udførelsen af plugins på webstedet.

Umiddelbart kan du se, at adinjector-pluginet indtager mere end 15 gange så meget tid som det næst langsomste plugin.

Når du ser data som dette, kan det være fristende at straks afvise pluginet som dårligt kodet eller på en eller anden måde ineffektivt. Selvom det nogle gange er tilfældet, er det ikke altid tilfældet. Plugin fejlkonfiguration, database langsommelighed eller eksterne ressourcer, der er svage til at reagere, kan få et plugin til at bruge meget tid.

Så når du ser et plugin, der svarer langsomt, er det en god idé at kontrollere flere andre skærme i New Relic for at finde yderligere oplysninger. Transaktionerne, databaserne og de eksterne ressourcer bør alle kontrolleres, inden de beslutter, at deaktivere plugin, er den bedste eller eneste vej frem.

Samlet langsomhed forårsaget af en overvældet database

En dårligt optimeret database kan forårsage generel langsommelighed på et WordPress-websted. Tidligere gik vi over en masse forskellige ting, du kan gøre for at rette op på dette. I New Relic vil denne database relaterede langsommelighed sandsynligvis dukke op på to steder:

• For det første vil du se en ekstern mængde MySQL-aktivitet i oversigten.
• For det andet vil du se, at en eller flere databastabeller bruger meget tid på fanen Databaser.

Start med oversigtsskærmen, et websted med en kæmpende database kan se sådan ud:

For at få et bedre greb omn hvilken databasetabel eller forespørgsel der forårsager problemet, skal du gå til fanen databaser.

Fanen Databaser peger på tabellen og typen af forespørgsel, der bruger mest tid. Hvis du vælger en af posterne i listen, kan du se flere detaljer, herunder nogle stikprøver.

I dette tilfælde peger dataene en finger på autoloaded data i wp_options tabellen. Husk, vi gik over dette tidligere. Sikkert nok bekræfter en hurtig analyse af wp_options-tabellen, at næsten 250 MB data er autoloaded fra denne tabel, hvilket gør dette websted til en åbenbar kandidat til database vedligeholdelse og optimering.

Sørg for at tjekke vores dybtgående vejledning om, hvordan du bruger New Relic til at debugere effektivitetsproblemer på dit WordPress-websted.

Brug Free Query Monitor Plugin

Du kan også bruge det gratis Query Monitor WordPress plugin. Brug den til at identificere og debugere langsom database forespørgsler, AJAX opkald, REST API anmodninger, og meget mere. Derudover rapporterer plugin-webstedets detaljer, f.eks. Scriptafhængigheder og afhængige, WordPress-kroge, der fyrede under sidegenerering, hosting-miljøoplysninger, betingede forespørgselskoder, der blev mødt af den aktuelle side og meget mere.

Pluginet blev udviklet af John Blackbourn, en kerne WordPress-committer, der for øjeblikket er udvikler hos Human Made og tidligere var ansat af WordPress.com VIP – med andre ord en person, der kender WordPress i vid udstrækning. Query Monitor blev tilføjet til WordPress plugin biblioteket i 2013 og har for tiden mere end 10.000 aktive installationer – en imponerende sum for et udviklings plugin. Pluginnets brugerbedømmelse på fem ud fem stjerner hjælper med at forklare, at det er popularitet blandt udviklere.

Se vores komplette vejledning om, hvordan du bruger Query Monitor.

Udnyt Optagelsessteder Uden at Berøre Produktionen

Vi ved ikke, hvad vi ville gøre uden scenarier. Disse kan være uvurderlige, når det drejer sig om fejlfinding af ydeevneproblemer. Heldigvis har Kinsta et-kliks staging-miljøer. Hvis din WordPress-vært ikke tilbyder scenarier, kan du også bruge et plugin som WP Staging, selvom det ikke er så nemt.

Når du har et installationscenter op og kører, er det første, du kan gøre, at deaktivere alle dine plugins. Da dette er en kopi af dit live site, behøver du ikke bekymre dig om at bryde noget. Det er klart en af de nemmeste måder at indsnævre problemer på. Du skal blot gå til plugins, vælg dem alle og vælg “Deaktiver” fra bulk mulighederne.

Herefter kan du overvåge svarstider i New Relic eller Query Monitor og se, hvad der sker. I dette eksempel nedenfor faldt reaktionstiden straks tilbage til normal på webstedet, så vi vidste, at det var et af plugins, der forårsagede et problem. Du kan derefter genaktivere dem en efter én, gentage den samme proces, indtil du finder synderen.

Her er et eksempel på, hvad der skete, da vi aktiverede det plugin, der forårsagede problemet. Indlæsningstider (webtransaktionstider) gik straks tilbage.

Hvad skal du gøre, efter at du har fundet proppen, der forårsager langsomheden? Her er det, vi anbefaler:

1. Opdater dine plugins og temaer til den nyeste version, hvis du ikke allerede har gjort det.
2. Nå ud til udvikleren af pluginnet eller tema og bede dem om hjælp.
3. Find et alternativt plugin, som kan levere den samme funktionalitet.
4. Måske forårsager din PHP-version et problem. Skift din PHP-motor til en lavere version, og se om plugin eller tema derefter fungerer.

Du kan også ansætte en WordPress-udvikler for at løse problemet. Hvis det er præstationsrelateret, skal vi give en personlig shout-out til Mike Andreason på WP Bullet. Han er en fuldtids Kodebar udvikler med speciale i præstationsoptimering, som har hjulpet mange kunder her hos Kinsta med komplekse installationer, som tager deres websted til næste niveau.

Tjek Dine Fejllogs

Checking af fejllogs er aldrig sjovt, men kan afsløre meget om ydeevneproblemer med WordPress-plugins. Hvis du er en Kinsta-klient, kan du nemt se dine fejllogfiler, cache-logfiler og adgangs logfiler lige fra MyKinsta dashboard.

Du kan også aktivere fejllogs ved at tilføje nogle kode til din wp-config.php-fil. For det første vil du gerne oprette forbindelse til dit websted via SFTP. Dernæst download din wp-config.php, så du kan redigere den. Bemærk: Sørg altid for at lave en sikkerhedskopi af denne fil først!

Find den linje der siger /* That's all, stop editing! Happy blogging. */ og lige før det, tilføj følgende (som vist nedenfor):

define( 'WP_DEBUG', true );

Hvis den ovennævnte kode allerede findes i din wp-config.php-fil, men er sat til “false”, skal du blot ændre den til “true”. Dette aktiverer debug-tilstand. Bemærk: Du vil også se advarsler eller fejl i din WordPress-administrator, hvis de eksisterer.

Du kan derefter aktivere fejlfindingsloggen til at sende alle fejl til en fil ved at tilføje følgende kode lige efter WP_DEBUG-linjen (som vist nedenfor):

define( 'WP_DEBUG_LOG', true );

Gem dine ændringer og genopload dette til din server. Fejlene bliver så logget til debug.log filen i din /wp-content/ mappe. Hvis du af en eller anden grund ikke kan se denne fil, kan du altid oprette en.

Brug MyKinsta Analytics

Hvis du er en Kinsta-klient, kan du udnytte de indsats, vi har indbygget i vores MyKinsta Analytics-værktøj.

Under præstationsovervågningssektionen kan du se din gennemsnitlige PHP + MySQL responstid, PHP-gennemgang, AJAX-brug, top gennemsnittet upstream-tid og top maksimal upstream-tid.

Gennemsnitlig PHP + MySQL Response Time

Når du besøger dit WordPress-websted, bruges PHP og MySQL til at kompilere og forespørge de data, du ser på siden. Dette diagram viser dig den gennemsnitlige responstid for PHP-motoren og MySQL-motoren for hver dynamisk forespørgsel, der ikke er cachelagret. At kende disse responstider kan hjælpe dig med at fejle langsommelighed.

PHP Throughput

Throughput angiver antallet af transaktioner pr. Sekund, et program kan håndtere, og i denne rapport refererer det til PHP-gennemgang fra dit WordPress-websted. Med andre ord viser det dig, hvor mange gange et PHP-aktiv blev anmodet om.

AJAX Anvendelse

AJAX er et klientside script, der kommunikerer til og fra en server/database uden behov for en postback eller en komplet sideopdatering. Når det kommer til WordPress, har mange af jer sikkert set dette i dine hastighedsprøver. De to øverste problemer med AJAX omfatter plugins, der forårsager spids og CPU-problemer på bagsiden.

Sørg for at tjekke vores dybdegående indlæg ved diagnosticering af høj Admin-AJAX-brug på dit WordPress-websted.

AJAX-brugsrapporten i MyKinsta-analyse kan være en fantastisk måde at hjælpe dig med fejlfinding af disse typer af problemer, som du kan se, hvis du ser visse AJAX-spikes i bestemte perioder. Dette diagram viser antallet af admin-ajax-anmodninger. Du kan derefter udnytte nogle af de tips i det indlæg, vi nævnte ovenfor, for at indsnævre, hvor de kommer fra.

Top Gennemsnitlig PHP + MySQL Svartid

Denne liste viser de øverste gennemsnitlige svartider fra PHP og MySQL. Disse tal kan være engangs toppende, så det foreslås at sammenligne denne liste med “Top Maksimal Upstream Time.”

Top Maksimal Upstream Tid

Opstrømstid er den samlede tid, der tages for Nginx (og opstrøms servere) til at behandle en anmodning og sende et svar. Tiden måles i sekunder, med millisekund opløsning. Læs mere om Nginx-metrics.

Dit Site Kan Måske Blive Hacket

Hvis du har problemer med at spore et præstationsproblem, kan det meget godt være, at dit websted er hacket, inficeret med malware eller under et DDoS-angreb. Dette kan påvirke dit websteds hastighed og endda responsen på dit WordPress admin dashboard. I disse tilfælde anbefaler vi følgende:

1. Implementere en proxyserver og WAF som Cloudflare eller Sucuri.
2. Bloker dårlige IP-adresser ved hjælp af ovenstående tjenester, eller hvis du er en Kinsta-klient, kan du også blokere IP-adresser fra vores MyKinsta-dashboard.
3. Du kan også implementere geoblokering. Nogle lande er virkelig dårlige, når det kommer til kvaliteten af den trafik, de genererer. Hvis du er under angreb, skal du muligvis blokere hele landet, enten midlertidigt eller permanent.

Fejlfinding med Fejlkoder (HTTP-Statuskoder)

HTTP-statuskoder er som et kort notat fra webserveren, der bliver klistret på toppen af en webside. Det er ikke en del af websiden. I stedet er det en besked fra serveren, der fortæller dig, hvordan tingene gik, da anmodningen om at få vist siden blev modtaget af serveren. Disse kan være uvurderlige, når det kommer til fejlfinding!

Mens der er over 40 forskellige statuskoder, er nedenstående de mest almindelige, vi ser WordPress-brugere, kæmpe med.

429: “For mange anmodninger.” Genereret af serveren, når brugeren har sendt for mange anmodninger i et givet tidsrum (satsbegrænsning). Dette kan nogle gange forekomme fra bots eller scripts, der forsøger at få adgang til dit websted. I dette tilfælde kan du prøve at ændre din WordPress login-URL.

500: “Der opstod en fejl på serveren, og anmodningen kunne ikke gennemføres.” En generisk kode, der simpelthen betyder “intern serverfejl”. Noget gik galt på serveren, og den ønskede ressource blev ikke leveret. Denne kode genereres typisk af tredjeparts plugins, defekt PHP, eller endda forbindelsen til databasesbrud. Se vores vejledninger om, hvordan du løser fejlen ved oprettelse af en databaseforbindelse og andre måder at løse en 500 intern serverfejl på.

502: “Bad Gateway.” Denne fejlkode betyder typisk, at en server har modtaget et ugyldigt svar fra en anden. Nogle gange vil en forespørgsel eller et ønske tage for lang tid, og det bliver derfor annulleret eller dræbt af serveren, og forbindelsen til databasen går i stykker. Se vores dybdegående vejledning om, hvordan du løser fejlen 502 Bad Gateway.

503: “Serveren er ikke tilgængelig til at håndtere denne anmodning lige nu.” Forespørgslen kan ikke udfyldes lige nu. Denne kode kan returneres af en overbelastet server, der ikke kan håndtere yderligere anmodninger.

504: “Serveren, der fungerer som gateway, stoppede ud og ventede på, at en anden server skulle reagere.” Koden blev returneret, når der er to servere involveret i behandlingen af en forespørgsel, og den første server venter på, at den anden server svarer. Læs mere om, hvordan du løser 504 fejl.

Du kan også grave i disse HTTP-responskoder i vores MyKinsta Analytics-værktøj. Vores rapport om reaktionskodefordeling giver dig mulighed for at se et overblik over fordelingen af HTTP-statuskoder, der vises for de ønskede ressourcer.

Rapporten Svarstatistik giver dig mulighed for at se det samlede antal omdirigeringer der sker, fejl, succesrate og fejlforhold. Hvert WordPress-websted vil typisk have et lille fejlrateforhold; dette er helt normalt.

Der er derefter sammenbrud rapporter for hver type fejlkode, såsom 500 fejl, 400 fejl, omdirigeringer mv.

Anbefalinger om Optimering af Back-End

Nu dykker vi ind på nogle måder, så du kan fremskynde WordPress ved at optimere back-end. Back-end involverer typisk alt, der håndteres fuldstændigt af serveren, såsom PHP, HTTP cache overskrifter, GZIP kompression osv.

Opret en Lys 404-Side

Vi har set førstehånds, at meget dynamiske websteder genererer typisk 404 fejl. Din hjemmeside kan generere mere end du tror! Vores MyKinsta-analyseværktøj kan hjælpe dig med at bestemme det nøjagtige beløb (som vist nedenfor).

Årsagen til at disse fejl er dårlige er, at mange 404 sider er meget ressourceintensive. For et meget dynamisk WordPress-websted, vil du undgå en tung 404-side. Opret en simpel 404-skabelon, der undgår at forespørge databasen om muligt, hvis det er muligt. Og selvfølgelig bruge lidt tid og reparer 404 fejlene, da dette ikke kun er ressourceintentivt, det er simpelthen dårligt for brugeroplevelsen.

Ud over at bruge en let 404-side anbefaler vi også at implementere en speciel sidecache-regel til 404 sider. Hos Kinsta cacher vi automatisk 404 sider i 15 minutter. Hvis vores webserver registrerer, at en ny side med den samme URL som en cache 404-side er blevet oprettet, renser vi automatisk cachen. Hvis dit WordPress-sted ikke har cacheable 404 sider, anbefaler vi, at du samarbejder med din host for at føje denne funktion til din webserver.

Forøg PHP-Arbejdere

PHP-arbejdere kan være et begreb, du aldrig har hørt om, men de er hvor mange værter, herunder Kinsta, håndterer begrænsende anmodninger (i stedet for at begrænse dig ved CPU eller RAM, hvilket typisk er, hvad fælles hosting-udbydere gør).

PHP-medarbejdere bestemmer, hvor mange samtidige anmodninger dit websted kan håndtere på et givet tidspunkt. For at sige det enkelt, håndteres hver ubearbejdet anmodning til dit websted af en PHP-medarbejder. Hvis du f.eks. Har 4 anmodninger, der kommer til dit websted på nøjagtig samme tid, og dit websted har 2 PHP-medarbejdere, vil to af disse anmodninger blive behandlet, mens de to andre bliver nødt til at vente i køen, indtil de to første er færdige forarbejdning.

Husk, vi diskuterede tidligere, at et af de største problemer med WordPress-medlemskabswebsteder er alle disse ubesvarede forespørgsler. Derfor bliver PHP-medarbejdere meget vigtige, da de skal arbejde for hver anmodning. Derfor vil disse websteder typisk kræve yderligere PHP-arbejdere for at sikre, at hver anmodning behandles uden forsinkelser og afsluttes med succes.

Hvad sker der, hvis du kontinuerligt maksimerer dine PHP-arbejdere? I grunden begynder køen at skubbe ældre forespørgsler, som kan resultere i 500 fejl på dit websted. Hver af Kinstas hostingplaner indeholder et foruddefineret antal PHP-medarbejdere. Hvis du har problemer med at estimere, hvad dit websted måtte have brug for, kan du altid chatte med vores salgs- eller supportteam.

Udnyt GZIP-Kompression

GZIP er et filformat og et softwareprogram, der bruges til filkomprimering og dekompression. GZIP kompression er aktiveret server-side, og giver mulighed for yderligere reduktion i størrelsen på din HTML, stylesheets og JavaScript-filer.

Når en webbrowser besøger et websted, kontrollerer den det for at se, om webserveren har GZIP aktiveret ved at se, om content-encoding: gzipoverskrift eksisterer. Hvis overskriften er registreret, tjener den op for de komprimerede og mindre filer. Hvis ikke, tjener det de ukomprimerede filer. Hvis du ikke har GZIP aktiveret, vil du højst sandsynligt se advarsler og fejl i hurtighedsprøvningsværktøjer som Google PageSpeed Insights og GTmetrix.

Aktivering af GZIP-komprimering kan medvirke til at reducere størrelsen på din webside, hvilket kan reducere mængden af tid til at hente ressourcen væsentligt, reducere dataforbruget til klienten og forbedre tiden til at køre dine sider første gang. Dette er ret standard nu på tværs af de fleste hostingudbydere, men intet overrasker længere os på dette tidspunkt.

Aktivér Hotlink-Beskyttelse

Konceptet hotlinking er ret ligetil. Du finder et billede på internettet et eller andet sted og bruger webadressen til billedet direkte på dit websted. Dette billede vises på din hjemmeside, men det vil blive serveret fra den oprindelige placering. Dette er meget bekvemt for hotlinkeren, men det er faktisk tyveri, da det bruger det hotlinked sites ressourcer. Det er som om vi skulle komme ind i vores bil og køre væk med benzin, vi nuppede ud fra vores nabos bil.

Hotlinking kan være et stort udløb på ressourcer til målserveren. Forestil dig, om du er på en delt WordPress-vært og Huffington Post pludselig forbinder dine billeder. Du kan gå fra et par hundrede forespørgsler en time på dit websted til et par hundrede tusind. Dette kan endda resultere i en suspension af din hosting konto. Dette er en grund til ikke kun at bruge en højtydende vært (som kan håndtere hikke som dette), men også for at aktivere hotlink-beskyttelse, så det sker ikke.

Se vores vejledning om, hvordan du forhindrer hotlinking.

Minimer Omdirigeringer og Tilføj Dem på Serverniveau

For mange omdirigeringer er altid noget, du skal passe på. Enkle omdirigeringer som en enkelt 301 omdirigering, HTTP til HTTPS eller www til ikke-www (omvendt) er fine. Og mange gange er det nødvendigt i visse områder af dit websted. Men hver har en pris på dit websteds præstation. Og hvis du begynder at stable omdirigeringer oven på hinanden, er det vigtigt at indse, hvordan de påvirker dit websted. Dette gælder for side- og post omdirigeringer, omdirigeringer af billeder, alt.

En omdirigering vil generere en 301 eller 302 på status header status.

Hvor meget påvirker omdirigeringer dit website? Lad os lave en lille test. Først kører vi en fart test på vores kontakt os side: https://perfmatters.io/contact/. Som du kan se nedenfor, får vi en samlet belastningstid på 417 ms.

Vi ændrer derefter webadressen lidt og kører en anden hastighedstest for at se virkningen af flere omdirigeringer. http://www.perfmatters.io/contact. Som du kan se, tager den samme side nu 695 ms at indlæse. Det er en stigning på 66%. Yikes!

Brug af gratis WordPress-plugins til implementering af omdirigeringer kan nogle gange medføre ydeevneproblemer, da de fleste bruger wp_redirect-funktionen, hvilket kræver ekstra kodekørsel og ressourcer. Nogle af dem tilføjer også autoloaded data til din wp_options tabel, hvilket øger database bloat. Tilføjelsen af dem på serverniveau er, hvor de skal gøres. Vi tillader dig at gøre det på MyKinsta med vores omdirigerings regel værktøj.

Du kan også se en fuldstændig oversigt over, hvor mange omdirigeringer der sker på dine websteder i vores MyKinsta-analyseværktøj. Se det samlede antal 301, 302 og 304.

Se vores indgående post på WordPress omdirigeringer, og de bedste metoder til hurtigere ydeevne.

Lad ikke Cron Jobs Komme Ud af Kontrol

CRON-job (WP-Cron) bruges til at planlægge gentagne opgaver til dit WordPress-websted. Men over tid kan disse komme ud af kontrol og forårsage præstationsproblemer. Du kan bruge det gratis WP Crontrol-plugin til at kontrollere et håndtag på alle Cron-jobene, der sker på dit websted.

Vi har også set ydeevneproblemer med den WordPress-indbyggede Cron-handler: WP-Cron. Hvis et websted ikke har nok PHP-medarbejdere, vil der undertiden komme en forespørgsel ind, WordPress vil trække cronen, men cron må vente på arbejderen og sidder derfor bare der. En bedre tilgang er at deaktivere WP-Cron og bruge system cron i stedet. Dette anbefales endda i den officielle pluginhåndbog.

Hvis du vil deaktivere WP-Cron, skal du tilføje følgende til din wp-config.php-fil lige før linjen der siger “Det er alt, trin redigering! God blogging. “Bemærk: Dette deaktiverer det fra at køre på sidebelastning, ikke når du kalder det direkte via wp-cron.php.

define('DISABLE_WP_CRON', true);

Derefter skal du planlægge wp-cron.php fra din server. Hvis du er en Kinsta-klient, er systemkroner allerede aktiveret og kører hvert 15. minut som standard. Du kan også få hyppigheden øget ved at nå ud til vores supportteam. Hvis du er bekendt med SSH, kan du styre serverkroner fra kommandolinjen.

Tilføj Cache-Control og Udløber Headers (Bestem Cache Length)

Ethvert script på dit WordPress-websted skal have en HTTP cache header knyttet til den (eller det skulle det). Dette bestemmer, hvornår cachen på filen udløber. For at rette op på dette skal du sikre dig, at din WordPress-vært har de korrekte cache-control header til at angive et bestemt tidspunkt, hvor ressourcen ikke længere er gyldig. Mens begge overskrifter kan bruges sammen, behøver du ikke nødvendigvis at tilføje begge overskrifter. cache-kontrol er nyere og normalt den anbefalede metode. og expires headers setup. Hvis du ikke gør det, vil du højst sandsynligt se advarsler om, at du skal tilføje udløber overskrifter eller udnytte browserens caching i hastighedsprøvningsværktøjer.

Mens cache-control header til at angive et bestemt tidspunkt, hvor ressourcen ikke længere er gyldig. Mens begge overskrifter kan bruges sammen, behøver du ikke nødvendigvis at tilføje begge overskrifter. cache-kontrol er nyere og normalt den anbefalede metode.
tænder klientsiden caching og angiver den maksimale alder af en ressource, anvendes expires header til at angive et bestemt tidspunkt, hvor ressourcen ikke længere er gyldig. Mens begge overskrifter kan bruges sammen, behøver du ikke nødvendigvis at tilføje begge overskrifter. cache-kontrol er nyere og normalt den anbefalede metode.

Kinsta tilføjer automatisk HTTP cache overskrifter på alle server anmodninger, og hvis du bruger en CDN, vil de højst sandsynligt også tilføje disse overskrifter til dig.

Hvis din server mangler disse overskrifter, kan du manuelt tilføje dem.

Tilføjelse af Cache-Control Header i Nginx

Du kan tilføje cache-control header i Nginx ved at tilføje følgende til din serverskonfigurets serverplacering eller blokering.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Tilføjelse af Expires Header i Nginx

Du kan tilføje expires headers i Nginx ved at tilføje følgende til din serverblok. I dette eksempel kan du se, hvordan du angiver forskellige udløbstider baseret på filtyper.

Tilføjelse af Cache-Control Header i Apache

Du kan tilføje cache-control headers i Apache ved at tilføje følgende til din .htaccess-fil. Kodestykker kan tilføjes øverst eller nederst på filen (før # BEGIN WordPress eller efter # END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"

Tilføjelse af Expires Header i Apache

Du kan tilføje expires headers i Apache ved at tilføje følgende til din .htaccess-fil.

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES HEADER CACHING ##

Det er også vigtigt at bemærke, at du kun kan tilføje HTTP-cache overskrifter på ressourcer på din server. Hvis du får en advarsel om det, skal du muligvis udnytte browserens caching på anmodning fra en tredjepart. Der er ikke noget du kan gøre, da du ikke har anmodning om deres server. Fælles skyldige er Google Analytics-script og markedsføringspixels, som Facebook og Twitter.

Hvis du forsøger at rette dette med Google Analytics-scriptet, kan du være vært for det lokalt eller på din CDN (selvom det ikke er officielt understøttet) med et plugin som Perfmatters eller WP Rocket.

Tilføj Sidste Modificerede og ETag Headers (Validere Cache)

Dernæst har vi yderligere to sæt af overskrifter, last-modified og etag. Mens cache-control og expires headers hjælper browseren med at afgøre om filen er ændret siden sidste gang, den blev anmodet om. Eller rettere, validerer de cachen. Hvis disse ikke er korrekt indstillede, kan du se en advarsel om, at du skal “Specificere en cache-validator.”

Disse overskrifter bør medtages på hvert originerserverrespons, da de begge validerer og indstiller cachens længde. Hvis overskrifterne ikke findes, genererer den hver gang en ny anmodning om ressourcen, hvilket øger belastningen på din server. Ved hjælp af caching-overskrifter sikres det, at efterfølgende forespørgsler ikke skal indlæses fra serveren, hvilket sparer båndbredde og forbedrer ydeevnen for brugeren.

Kinsta tilføjer automatisk ovenstående overskrifter på alle serverforespørgsler, og hvis du bruger en CDN, vil de højst sandsynligt også tilføje disse overskrifter til dig. Ligesom med cache-control og expires, kan du ikke manuelt indstille disse HTTP-overskrifter på eksterne ressourcer.

Last-Modified Header

Den last-modified overskrift sendes normalt automatisk fra serveren. Dette er et overskrift, som du generelt ikke behøver at tilføje manuelt. Det sendes for at se, om filen i browserens cache er blevet ændret siden sidste gang, den blev anmodet om. Du kan se på headerforespørgslen i Pingdom eller bruge Chrome DevTools til at se værdien af den sidst ændrede overskrift.

ETag Header

ETag-overskriften ligner også den sidst ændrede overskrift. Det bruges også til at validere cachen for en fil. Hvis du kører Apache 2,4 eller højere, tilføjes ETag-overskriften automatisk automatisk ved hjælp af FileETag-direktivet. Og så vidt Nginx går, er ETag-headeren blevet aktiveret som standard siden 2016.

Du kan aktivere ETag header manuelt i Nginx ved hjælp af følgende kode.

etag on

Tilføj en Variant: Accept-Encoding Header

vary: Accept-Encoding skal inkluderes på hvert originerserverrespons, da det fortæller browseren, hvorvidt klienten kan håndtere komprimerede versioner af indholdet. Hvis dette ikke er korrekt indstillet, kan du muligvis se en advarsel om, at du skal “Specify a Vary: Accept-Encoding Header.”

Lad os f.eks. sige, at du har en gammel browser uden gzip-komprimering og en moderne browser med den. Hvis du ikke bruger vary: Accept-Encoding header, kan din webserver eller CDN cache den ukomprimerede version og levere den til den moderne browser ved en fejltagelse, hvilket igen gør ondt på dit WordPress-site. Ved at bruge overskriften kan du sikre, at din webserver og/eller CDN leverer den relevante version.

Kinsta tilføjer automatisk ovenstående overskrifter på alle serverforespørgsler, og hvis du bruger en CDN, vil de højst sandsynligt også tilføje disse overskrifter til dig. Ligesom med de andre cacheoverskrifter, vi har diskuteret ovenfor, kan du ikke manuelt indstille denne overskrift på eksterne ressourcer.

Add Vary: Accept-Encoding Header in Apache

Du kan tilføje varianten: Accept-Encoding header i Apache ved at tilføje følgende til din .htaccess fil.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Add Vary: Accept-Encoding Header in Nginx

Du kan tilføje variabler: Accept-Encoding header i Nginx ved at tilføje følgende kode til din config-fil. Alle Nginx-konfigurationsfiler er placeret i /etc/Nginx/ directory. Den primære Konfigurationsfil er /etc/Nginx/Nginx.conf.

gzip_vary on

Ændring af WordPress-Hukommelsesgrænsen i wp-config.php

Som angivet i WordPress Codex, med WordPress Version 2.5, giver WP_MEMORY_LIMIT dig mulighed for at angive den maksimale mængde hukommelse, der kan forbruges af PHP. Denne indstilling kan være nødvendig, hvis du modtager en besked som “Tilladt hukommelsesstørrelse på xxxxxx bytes udmattet”.

Som standard vil WordPress forsøge at øge hukommelsen tildelt til PHP til 40 MB for et enkelt websted og 64 MB til multisite. De definerer hukommelsesgrænserne i filen ./wp-includes/default-constants.php, på linjer 32 – 44 (kilde).

Du har så også PHP memory_limit på serveren af din hostingudbyder. Det er to forskellige ting. Ved Kinsta indstiller vi standard memory_limit til 256M. Hvis du løber ind i den udtjente fejl i hukommelsesstørrelsen, kan du prøve at øge PHP-hukommelsesgrænsen i WordPress.

Tilføj følgende til din wp-config.php file, lige før linjen der siger “That’s all, stop editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink har også en stor blogpost, der beskriver WordPress-hukommelsesgrænseproblemet mere detaljeret. Han giver også en ændring af den kode, du kan bruge. I stedet for at indstille mængden manuelt kan du indstille den til PHP memory_limit-værdien.

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Tips om Front-End-Optimering og Eksterne Tjenester

Nu dykker vi ind på nogle måder, så du kan fremskynde WordPress ved at optimere front-end. Front-end indebærer typisk alt, der håndteres fuldstændigt af klientsiden browser, såsom CSS, JavasScript, billeder osv. Dette omfatter også at analysere eksterne tjenester, du har indlæst på dit websted, og hvordan de påvirker din samlede belastningstid.

To af de vigtigste mål, du bør have, når det kommer til optimering af front-end er:

• Reducerer din samlede webside størrelse. Størrelsen af din CSS, JavaScript, billeder betyder noget. En 4 MB hjemmeside vil typisk indlæse meget langsommere end en 1 MB hjemmeside. Paul Calvano har dog en god artikel om indvirkningen af sidevægten på belastningstiden, og hvordan det er vigtigt at sørge for, at det ikke er det eneste, du sporer, da det nogle gange kan være vildledende.
• Reducere HTTP-anmodninger og eksterne tjenester. Med HTTP/2 kan flere anmodninger og svar nu sendes samtidig med en enkelt TCP-forbindelse. Selvom dette er fantastisk til ydeevne, kan reducerende HTTP-anmodninger stadig hjælpe med at fremskynde dit WordPress-websted. Dette inkluderer også at reducere det samlede antal eksterne forespørgsler og tjenester. Hver af disse tilføjer yderligere forsinkelser som DNS-opslag, TLS-forbindelser og netværksforsinkelse.

Speed Test dit WordPress Site for at Få en Basislinje

Når det kommer til at optimere fronten af dit websted, er det altid godt at starte med en basislinje. Dette betyder normalt, at du skal køre en hastighedsprøve. Der er mange forskellige måder, du kan gøre dette på, se vores liste over 15 fantastiske testværktøjer til hjemmesiden.

Se vores dybdegående vejledninger om, hvordan du bruger Pingdom og hvordan du bruger GTmetrix. Her er et par ting at huske på, når hastighedsprøvning:

1. Vælg et værktøj og tag det med

Vi er store fans af Pingdom, GTmetrix, WebPageTest, PageSpeed Insights og Chrome DevTools. Det betyder dog ikke så meget hvilket hastighedsprøvningsværktøj du bruger, da det gør din konsekvent. De har alle forskellige måder at måle og kvantificere hastighed på, så vælg et værktøj og hold det i alle dine test og optimeringer. Selv Google siger at vælge en.

2. Må Ikke Være Besat Over et Perfekt Score

Mange af værktøjerne som Google PageSpeed Insights, har alle en eller anden form for hastighed eller ydeevne-score. Det er vigtigt at huske, at scoren ikke altid betyder så meget som din hjemmeside hastighed og opfattet ydeevne af brugeren. Resultatet er der for at hjælpe med at måle hvor godt du klarer det. Men besættelse over en perfekt 100/100 eller en score i nogle tilfælde, kan være spild af tid. Og større websteder med mange eksterne scripts og reklamer får aldrig en perfekt score, hvilket er helt ok.

3. Placeringen af Dine Testproblemer

Den placering du vælger, når hastighedsprøvningen betyder noget. Da vi blev diskuteret i et tidligere afsnit, er årsagen hertil, at dette er alt sammen i forhold til, det datacenter du vælger. TTFB, netværk latens, alle kommer i spil. Så test dit websted både fra et sted, der ligger tæt på dit datacenter og et langt væk. Dette vil også hjælpe dig med at se, hvor meget en indvirkning et CDN kan have på dit WordPress-websted.

4. Test Flere Gange på Grund af Caching

Da vi gik over tidligere i afsnittet om caching, hvis cachen for nylig er blevet ryddet eller er udløbet på din WordPress-vært eller CDN, vil den registrere en “MISS” på HTTP-overskriften. Det betyder, at dit websted eller dit aktiv ikke tjener fra cachen.

For at kunne se hastigheden på hele dit websted skal du se alt, hvad der skal læses fra cache, din startside og alle aktiver registrere et “HIT”. Dette kræver nogle gange at køre din hastighedsprøve flere gange. Du kan derefter tage gennemsnittet.

Lad os nu flytte ind i nogle front-end optimeringer, du kan lave på dit WordPress-websted.

Eliminer Render-Blocking JavaScript og CSS

En advarsel om at blokerende JavaScript og CSS muligvis vises, når du har filer, der forhindrer siden i at blive lastet hurtigst muligt. Specifik JS og CSS er undertiden betingede, hvilket betyder, at de ikke skal vise det overordnede indhold. Du kan forhindre dem i at blive blokerende ved at bruge async og udskifte attributter.

For at eliminere blokerende JavaScript og CSS skal du gøre følgende:

Ryd JS Fra Den Kritiske Renderingsti

Flytning af JavaScript ud af den kritiske gengivelsessti udføres typisk ved at tilføje enten defer eller async-attributten til script-HTML-elementerne, der kalder JavaScript-ressourcer.

• Async-attributten fortæller browseren, at den skal begynde at downloade ressourcen med det samme uden at bremse HTML-parsing. Når ressourcen er tilgængelig, er HTML-parsering pauset, så ressourcen kan indlæses.
• Defer-attributten fortæller, at browseren holder af med at hente ressourcen, indtil HTML-parsing er færdig. Når browseren er færdig med HTML’en, downloades og returneres alle udskudte scripts i den rækkefølge, de vises i dokumentet.

Optimer levering af CSS ressourcer

Optimering af leveringen af CSS betyder i det væsentlige, at du skal finde ud af, hvordan du laver en uhindret blokering.

• Identificer de stilarter, der kræves for at lave det overordnede indhold og levere de stilarter inline med HTML’en.
• Brug CSS betingelsesmæssigt kun på enheder, når det er nødvendigt.
• Indlæse resterende CSS asynkront.

Hvis du gør alt ovenfor, kan det nogle gange være en vanskelig proces, og det tager helt sikkert nogle tweaking ud fra de scripts, du har indlæst på dit websted. Her er et par WordPress-plugins, der kan hjælpe:

• Autoptimize
• Async JavaScript
• Hummingbird

For en mere detaljeret forklaring og gennemgå, anbefaler vi at tjekke vores indlæg om at eliminere renderblokerende JavaScript og CSS.

Kombiner Ekstern CSS og JavaScript i WordPress

Den kombinerede eksterne CSS-advarsel ses typisk, når du bruger en CDN, fordi du er vært for dine CSS-filer på et eksternt domæne, f.eks. Cdn.domain.com. Tidligere er en hurtig måde at løse dette på at sammenkæde dine CSS-filer, eller kombinere dem, så de indlæses i en enkelt anmodning.

Men hvis du kører over HTTPS med en udbyder, der understøtter HTTP/2, er denne advarsel ikke længere så relevant som den plejede at være. Med HTTP/2 kan flere CSS-filer nu indlæses parallelt over en enkelt forbindelse. Og over 86% af browsere understøtter HTTP/2.

Men det betyder ikke nødvendigvis, at denne optimering er helt død. I nogle tilfælde har vi set dette stadig gør WordPress-websteder hurtigere. Det afhænger af filernes størrelse og hvor mange af dem der er. Derfor er dette en optimering, vi anbefaler, at du stadig tester på dit websted.

En af de nemmeste måder at kombinere dine eksterne CSS- og JavaScript-filer på er med det gratis Autoptimize plugin. Efter at have kombineret dem, vil du se en “autoptimize_xxxxx.css” eller “autoptimize_xxxxx.js” fil. Det understøtter også at loade dem fra din CDN. Du kan også gøre dette med WP Rocket plugin.

Se vores indgående post om, hvordan du kombinerer eksternt CSS og JavaScript i WordPress.

Brug Minification på HTML, CSS og JavaScript

Vi kan reducere mængden af data, som browseren skal downloade ved at minimere HTML-, CSS- og JavaScript-ressourcer. Minifiering er processen med at fjerne unødvendige tegn som kommentarer og whitespace fra kildekoden. Disse tegn er yderst nyttige i udvikling, men de er ubrugelige for browseren at gøre siden.

Ikke-minificeret HTML

Her er et eksempel på ikke-minificeret HTML-kode.

Minificeret HTML

Her er et eksempel på minificeret HTML-kode.

Du kan bruge det gratis Autoptimize plugin eller WP Rocket til nemt at reducere dine filer.

Hvis du er Kinsta-kunde, så har du adgang til kode minifikationsfunktionen indbygget direkte i MyKinsta-dashboardet. Dette giver kunderne mulighed for hurtigt og nemt at aktivere automatisk CSS- og JavaScript-minificering med et klik på en knap og vil effektivt fremskynde dit websted uden manuel indsats.

Brug Cookie Frie Domæner

Generelt, når du serverer indhold som billeder, JavaScript, CSS, er der ingen grund til, at en HTTP-cookie ledsager den, da det skaber ekstra omkostninger. Når serveren har indstillet en cookie til et bestemt domæne, skal alle efterfølgende HTTP-anmodninger til det pågældende domæne indeholde cookien. Denne advarsel ses typisk på websteder med et stort antal anmodninger.

Vi har et dybtgående indlæg om, hvordan vi skal håndtere det statiske indhold fra en cookieless domæne advarsel. Mange gange kan du ignorere denne advarsel, da nye protokoller som HTTP/2 nu gør dette mindre vigtigt. Omkostningerne ved en ny forbindelse er normalt dyrere end streaming af alt over den samme forbindelse.

En nem måde at løse denne advarsel på er at bruge en CDN-udbyder, der kan ignorere cookies samt stripe cookies, som helt forhindrer klienten i at modtage Set-Cookie-responsoverskriften. KeyCDN er en CDN-udbyder, der tilbyder denne funktion. Som standard kan du se, at følgende to muligheder er aktiveret. Dette er et nemt alternativ uden at skulle røre med at flytte og konfigurere dit websted til at levere statiske aktiver fra et separat underdomæne.

Hvis du kører Cloudflare, kan du ikke deaktivere cookies på ressourcer, der serveres via deres netværk. CloudFlare indeholder deres egen sikkerhedscookie i din header. Igen er disse cookies meget små, og præstationsimplikationerne er ekstremt små. Men hvis du bruger CloudFlare, er der ingen måde at omgå denne advarsel.

En anden måde at komme rundt på er at genkonfigurere dit WordPress-websted for at levere de statiske aktiver fra et nyt domæne eller underdomæne.

Deaktiver Embeds i WordPres

Da de udgav WordPress 4.4, slog de funktionen oEmbed sammen i kernen. Dette giver brugerne mulighed for at indlejre YouTube-videoer, tweets og mange andre ressourcer på deres websteder ved blot at indsætte en webadresse, som WordPress automatisk konverterer til en indlejring og giver et live preview i den visuelle editor. Med opdateringen blev WordPress selv en oEmbed-udbyder.

Denne funktion er nyttig for mange mennesker, og du vil muligvis beholde den aktiveret. Men hvad det betyder er, at det også genererer en ekstra HTTP-anmodning på dit WordPress-websted for at indlæse wp-embed.min.js-filen. Og dette belastes på hele webstedet. Mens denne fil kun er 1,7 KB, tilføjes ting som disse over tid. Selve anmodningen er undertiden en større aftale end indholdets downloadstørrelse.

Du kan nemt deaktivere denne fil fra indlæsning. Her er tre forskellige muligheder:

• Mulighed 1 – Deaktiver embeds med plugin
• Mulighed 2 – Deaktiver embeds med kode
• Mulighed 3 – Flyt JavaScript Inline

Deaktiver Emojis i WordPress

På samme måde som embeds i WordPress 4.2 tilføjede de støtte til emojis til kernen for ældre browsere. Det store problem med dette er, at det genererer en ekstra HTTP-anmodning på dit WordPress-websted for at indlæse filen wp-emoji-release.min.js Og dette belastes hele webstedet. Mens denne fil kun er 10,5 KB, er det ubrugeligt, hvis du ikke bruger emojis på dit websted.

Der er et par forskellige måder at deaktivere Emojis i WordPress. Du kan gøre det med et gratis plugin eller med kode.

• Deaktiver Emojis med et plugin
• Deaktiver Emojis med kode

Sådan Fremskyndes WordPress Comments eller Deaktiver Tema

En optaget kommentar sektion på et websted kan forårsage mange præstationsproblemer. Tænk bare på de ressourcer, der går til at få kommentarer til at fungere:

• En database er nødvendigfor at trække eksisterende kommentarer op.
• Databaseindlægr oprettes for hver ny kommentar.
• Kommentarer og kommentarmetadata modtages og behandles af en besøgers browser.
• Eksterne ressourcer, såsom Gravatars, anmodes om, downloades og indlæses (kræver et separat DNS opslag).
• I mange tilfælde skal store JavaScript- og jQuery-ressourcer downloades og behandles for at få kommentarsystemet til at fungere som det skal.

Her er fire forskellige muligheder, du kan gøre for at fremskynde WordPress-kommentarer:

Mulighed 1 – Deaktiver kommentarer

Hvis dit websted ikke får meget mange kommentarer, og du ikke tror, at de tilføjer nogen værdi, kan det være bedre at deaktivere kommentarer helt og holdent. Husk, at kommentarer kan påvirke din SEO, da Google typisk vil gennemgå disse som ekstra indhold på siden, så du bør kun godkende kommentarer af høj kvalitet. Tjek disse tre nemme måder at deaktivere kommentarer på:

• Deaktiver kommentarer i WordPress-indstillingerne
• Deaktiver kommentarer med plugin
• Deaktiver kommentarer med kode

Mulighed 2 – Optimer native WordPress-kommentarer

Din anden mulighed ville være at optimere det native WordPress-kommentarsystem. En måde ville være at reducere antallet af kommentarer, der blev lastet med den indledende sidebelastning.

1. Gå til Indstillinger → Diskussion i WordPress-administrationsområdet.
2. Se efter afsnittet Andre kommentarindstillinger.
3. Marker afkrydsningsfeltet ud for Bryd kommentarer ind til sider med og tilføj en værdi for antallet af kommentarer, du vil vise med den indledende sideindlæsning.

En anden mulighed du har er at bruge vært Gravatars på din CDN. Dette er den tilgang, vi tager på Kinsta.

Som standard, når WordPress-kommentarer er indlæst, kræver hver enkelt unik Gravatar en HTTP-anmodning. Så hvis en side er indlæst med kommentarer fra 50 forskellige kommentatorer, kræves der 50 HTTP-anmodninger for at downloade alle disse Gravatars. Som du kan forestille dig, kan dette påvirke din sidens hastighed. For ikke at nævne det faktum, at vi har set den eksterne DNS opslag til gravatar.com være langsommere og i nogle tilfælde endda timeout.

Hvis du kigger å Gravatars på Kinsta-bloggen, kan du se, at de lastes fra Kinsta.com (inklusive vores CDN). Tjek hvordan du indlæser gravatars fra din CDN.

Mulighed 3 – Brug et tredjeparts kommentar system

Din tredje mulighed er at bruge et tredjeparts kommentar system. Hvis dit websted er hostet på en billig, ressourcehævdet delt server, kan det være med at fremskynde sider med mange kommentarer ved at bruge et tredjeparts kommentarsystem. Det er de samme ideer som billedoptimering, offload arbejdet. Men hvis du er hosted hos Kinsta eller en anden kvalitetswebhosting, vil det ikke være meget at skifte til en tredjepart for at hjælpe dit websteds hastighed og kan sænke det.

Sørg altid for at teste det tredjeparts kommentarsystem, du forsøger. Kig på alle de separate anmodninger Disqus genererer (som vist nedenfor). Mens de fleste af disse forespørgsler indlæses asynkront, vil du stadig opdage en ekstra belastningstid, hvis du bruger Disqus.

Mulighed 4 – Lazy Load Kommentarer

Din fjerde mulighed er at dovne belastnings kommentarer, så de ikke sænker den indledende sidegengivelse. Her er et par plugins, du måske vil tjekke ud:

• Lazy Load for Comments: Denne plugin giver dig mulighed for at latte indlæse native WordPress-kommentarer.
• Disqus Conditional Load: Hvis du vil bruge Disqus kommentar systemet, er dette et must-have plugin til doven belastning kommentarer.

Deaktiver WordPress RSS-feeds

Hvis du ikke bruger bloggingdelen af WordPress på dit websted, kan du deaktivere WordPress RSS-feeds. Selv om dette ikke har stor indflydelse på ydeevne, hjælper alt. Det er også en mindre ting, du skal bekymre dig om.

Tjek disse to forskellige måder at deaktivere RSS-feeds i WordPress:

• Disable RSS Feed med Plugin
• Disable RSS Feed med Code

Brug Prefetch og Preconnect

Resource tips og direktiveringer som prefetch og preconnect kan være en fantastisk måde at fremskynde WordPress bag kulisserne. KeyCDN har en fremragende artikel og oversigt over resource hints.

Prefetch

DNS-prefetch giver dig mulighed for at løse domænenavne (udfør et DNS-opslag i baggrunden), før en bruger klikker på et link, hvilket igen kan medvirke til at forbedre ydeevnen. Det gøres ved at tilføje et rel="dns-prefetch"-tag i overskriften på dit WordPress-websted.

<link rel="dns-prefetch" href="//domain.com">

Nogle almindelige ting at bruge DNS-prefetching til er din CDN-URL, Google Fonts, Google Analytics osv.

 <link rel="dns-prefetch" href="//cdn.domain.com/">
 <link rel="dns-prefetch" href="//fonts.googleapis.com/">
 <link rel="dns-prefetch" href="//www.google-analytics.com">

Prefetch understøttes også af de fleste moderne browsere. Se vores vejledning om, hvordan du føjer kode til din WordPress header.

Eller du kan nemt implementere DNS-prefetch ved hjælp af et plugin som Perfmatters. Du skal blot klikke på fanen “Ekstra” i Perfmatters-plugin’et og tilføje domæner. Format: //domain.tld (one per line)

Preconnect

Preconnect gør det muligt for browseren at oprette tidlige forbindelser før en HTTP-anmodning, hvilket eliminerer omdrejningstiden og sparer tid for brugerne.

Forbindelse er et vigtigt værktøj i din optimeringsværktøjskasse … det kan eliminere mange dyre rundrejser fra din forespørgselssti – i nogle tilfælde reducerer forespørgselsforsinkelsen af hundredvis og endda tusindvis af millisekunder. – lya grigorik (kilde)

Det gøres ved at tilføje et rel =”preconnect”-tag i overskriften på dit WordPress-websted.

<link rel="preconnect" href="//domain.com">

Et par eksempler på ting du bør udnytte for at inkludere din CDN URL eller Google fonts

 <link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

Forbindelse understøttes af de fleste moderne browsere, med undtagelse af Internet Explorer, Safari, IOS Safari og Opera Mini. Se vores vejledning om, hvordan du føjer kode til din WordPress header.

Eller du kan nemt implementere preconnect ved hjælp af et plugin som Perfmatters. Du skal blot klikke på fanen “Ekstra” i Perfmatters-plugin’et og tilføje domæner. scheme://domain.tld (en pr. Linje).

Deaktiver Scripts på en Per Side/Post-Base

En anden meget kraftfuld måde at fremskynde WordPress på er at grave gennem hver anmodning, der indlæses på dine sider og indlæg. Du vil sandsynligvis ende med at finde scripts, der indlæser hele webstedet, som ikke burde.

Du kan bruge et premium plugin som Perfmatters, som har en “Script Manager” -funktion indbygget. Dette giver dig mulighed for at deaktivere scripts (CSS og JavaScript) på en pr. Side post-basis, eller endda hele webstedet med et enkelt klik. Igen er dette plugin udviklet af et holdmedlem hos Kinsta.

Nogle eksempler på, hvad dette kan bruges til:

• Den populære kontaktformular 7-plugin lægger sig på hver side og indlæg. Du kan nemt deaktivere det overalt med et klik og aktiver kun på din kontaktside.
• Sociale deling af plugins skal kun indlæses på dine indlæg. Du kan nemt deaktivere det overalt og kun indlæse posttyper eller endda brugerdefinerede posttyper.
• Indholdsfortegnelsen (TOC) indlæser på hver side og post. Med scripts manager kan du nemt styre, hvor du vil have det.

Hvorfor er Nogle Plugins Kodet på Denne Måde?

Du kan måske undre sig over, hvorfor alle plugin-udviklere ikke kun indlæser deres scripts, når pluginet er registreret på siden? Nå, det er lidt mere kompliceret end det. Hvis du f.eks. Har et plugin som Kontaktformular 7, har det også kortkoder, som giver dig mulighed for at placere det overalt. Dette inkluderer at droppe det i en widget. Med WordPress er det meget sværere at forespørge data fra dem, når du dequeuer scripts i modsætning til forespørgsel af data fra post eller side metadata.

Derfor skyldes mange gange dette brugbarhedsproblemer. Jo mindre chance de har for et plugin til at bryde, jo færre billetter og support vil de have. Men med mange plugins på markedet, er der måder at komme rundt på dette og kode for ydeevne, hvis de ville. Uheldigvis giver det rene antal downloads og brugere en prioritet til kodning for brugervenlighed.

Touring Script Manager

Vi giver dig en lille rundvisning i Script Manager. Når du har klikket på det i din værktøjslinje, vil du blive præsenteret for alle de scripts, der indlæses på den aktuelle URL, både JavaScript og CSS-filer. Derefter har du følgende muligheder:

1. Status On (standardindstilling)
2. Status Off: Deaktiver overalt (du kan derefter vælge hvilke indlægstyper du vil aktivere den sammen med den aktuelle URL)
3. Status Off: Deaktiver kun på nuværende webadresse (dette er meget nyttigt til brug på din hjemmeside)
4. Status Off: Undtagelser (nuværende URL, posttype eller arkiv)

Alt er grupperet sammen af plugin eller tema navn. Dette gør det super nemt at deaktivere et helt plugin på én gang. Typisk vil et WordPress-plugin både have JavaScript og CSS-fil. Et WordPress-tema kan have 10+ filer.

Når du har valgt og eller ændrer indstillingerne, skal du sørge for at trykke “Gem” nederst. Du kan derefter teste i et webstedshastighedsværktøj for at sikre, at scriptene ikke længere læses på siden eller posten. Sørg for at rydde din cache først! Og hvis noget går galt på dit websted visuelt, kan du altid genaktivere det i indstillingerne for at vende tilbage til normal.

I en speed test fra woorkup kunne de reducere de samlede belastningstider med 20,2%. På deres hjemmeside alene kunne de reducere antallet af HTTP-anmodninger fra 46 ned til 30. Deres sidestørrelse faldt også fra 506,3 KB til 451,6 KB.

For andre måder at gøre deaktiver script, kan du se vores blogindlæg om, hvordan du deaktiverer WordPress-plugins fra indlæsning.

Analyse af Tredjeparts Ydeevne

Alt i alt, hvad du kalder eksternt fra dit websted, har belastningstid konsekvenser. Hvad gør dette problem endnu værre er, at nogle af dem kun er langsomt intermitterende, hvilket gør problemet mere problematisk.

En ekstern tredjepartstjeneste kan betragtes som noget, der kommunikerer med dit WordPress-websted uden for din egen server. Her er et par almindelige eksempler, vi møder regelmæssigt:

• Sociale medier platforme som Twitter, Facebook og Instagram (widgets eller konverteringspixel)
• 3rd-party reklame netværk som Google Adsense, Media.net, BuySellAds, Amazon Associates
• Website analyse og sporing scripts som Google Analytics, Crazy Egg, Hotjar, AdRoll
• A / B testværktøjer som Optimizely, VWO, Unbounce
• WordPress kommentarsystemer som Disqus, Jetpack, Facebook kommentarer
• Sikkerhedskopierings- og sikkerhedsværktøjer som VaultPress, Sucuri, CodeGuard
• Sociale delingsværktøjer som SumoMe, HelloBar
• CDN-netværk som KeyCDN, Amazon CloudFront, CDN77 og StackPath
• Eksternt hosted Javascript

Hvor meget påvirker nogle af disse tredjeparts trackers ydeevne? I vores egen casestudie så vi, at tredjeparts scripts øgede sidelastningstiden med 86,08%.

Ghostery målte også de top 500 amerikanske domæner i Alexa, og resultaterne var forbløffende, selv om det ikke var overraskende for os. Websites var 2 gange langsommere, da der ikke blev blokeret nogen trackers. Hvilket betyder, at disse scripts til tredjepartssporing er en af de primære bidragydere til at sænke sidernes hastigheder på nettet.

Du skal være meget forsigtig på dit WordPress-websted. Kun et dårligt tredjepart API-opkald kan timeout hele dit websted! Ja, det skal ikke fungere på den måde, men i mange tilfælde gør det. Vi har set det flere gange, end vi kan regne med.

New Relic giver en fremragende og nem måde at overvåge dine eksterne tjenester over tid. I dette eksempel nedenfor kan vi se eksterne opkald lavet til twitcount.com, graph.facebook.com og widgets.pinterest.com.

Det er vigtigt, at når du tilføjer en ny funktion eller et plugin til dit websted, undersøger du de eksterne ressourcer, der indlæses fra det. Jo mindre jo bedre!

Altid Optimere Med Mobile First i Tankerne

Google begyndte at lancere sit mobil-first indeks den 26. marts 2018. Tidligere har Googles krypterings-, indekserings- og rangordningssystemer brugt desktopversionen af hjemmesider. Mobil-første indeksering betyder, at Googlebot nu bruger den mobile version af dit WordPress-websted til indeksering og rangering. Dette hjælper med at forbedre søgeoplevelsen for mobile brugere.

Når det kommer til at optimere dit websted til mobil-først, er hastighed en af de vigtigste faktorer at fokusere på. Hastighed spiller en vigtig rolle i alt fra brugbarhed til afvisningsprocenter og bestemmer, om potentielle købere vil vende tilbage til dit websted. Faktisk er hastigheden nu en destinationsside faktor for Google Søgning og annoncer til mobil søgninger.

Dårlige mobiloplevelser vil medføre, at flertallet af brugerne kommer aldrig tilbage. Ifølge den seneste Google-sidehastighedsrapport var den gennemsnitlige tid, et mobilwebsted tog for at indlæse i 2018, 15 sekunder. Kan du forestille dig at vente så længe at indlæse en enkelt side? Forbløffende.

Brugere kræver (og fortjener) bedre. Ifølge samme sidens hastighedsrapport forlader 53% af de besøgende på mobilen sider, der tager længere tid end en mishandlet tre sekunder at indlæse.

Langsom mobile oplevelser dræber ikke konverteringer. De forhindrer dig i endda at få en chance for at konvertere kundeemner. Da sideindlæsningstider stiger med blot et par sekunder, sandsynligvis en person der hopper og klatrer eksponentielt. Her er et par ting at overveje, når optimering til mobil.

Tjek Din Mobil Trafik

Det er altid vigtigt at se, hvor meget mobil trafik du får, da dette måske kan ændre dine prioriteringer lidt. Du kan se, hvor mange mobile enheder, der besøger dit websted i Google Analytics under “Målgruppe → Mobil → Oversigt.” Som du kan se på dette websted, er over 67% af alt trafik fra mobil. Det er en del!

Hvis du er en Kinsta-klient, kan du også tjekke din mobil versus desktop-trafik i MyKinsta Analytics. Som du kan se på dette websted, er over 88% af trafikken fra skrivebordet. Det er altid vigtigt at kontrollere og ikke bare påtage sig. Bare fordi alle siger, at det går mobilt, betyder det ikke altid, at det er for dit websted. Se på dataene.

Sørg for, at dit websted er responsivt

I 2019, har din hjemmeside bare at være lydhør! Det betyder, at det bruger medieforespørgsler til automatisk at scanne ting på mobile enheder. Hvis du stadig ikke har gjort dette, er du sandsynligvis allerede bag din konkurrence. Alle WordPress-temaerne, vi nævnte tidligere i dette indlæg, er fuldt lydhør og ser fantastisk ud på alle enheder.

Brug Googles mobil-venlige værktøj til til at teste og sikre, at dit website overholder alle kravene.

Dobbeltcheck For at Sikre, at Srcset Fungerer

Tidligere var det meget vigtigt, at du uploade billeder i målestok og ikke lade CSS ændre størrelsen på dem. Dette er imidlertid ikke længere så vigtigt, da WordPress 4.4 nu understøtter responsive billeder (ikke nedskaleret af CSS). WordPress opretter automatisk flere størrelser af hvert billede, der uploades til mediebiblioteket. Ved at inkludere de tilgængelige størrelser af et billede i en srcset-attribut, kan browsere nu vælge at downloade den mest passende størrelse og ignorere de andre. Se et eksempel på, hvordan din kode ser ud nedenfor.

På grund af alle tredjeparts image plugins og tilpasninger derude, har der været mange gange hvor vi har set dette ikke fungerer korrekt. Derfor er det vigtigt at kontrollere, at dine billeder korrekt får srcset-attributten tilføjet med forskellige versioner til forskellige skærmstørrelser. Billedoptimering er nu vigtig for evigt.

Google AMP Kan Være en Løsning For Dig

Google AMP (Accelerated Mobile Pages Project) blev oprindeligt lanceret tilbage i oktober 2015. Projektet er baseret på AMP HTML, en ny åben ramme, der udelukkende er bygget ud af eksisterende webteknologier, hvilket gør det muligt for websites at oprette letvægts-websider. For at sige det simpelthen, giver det en måde at servere en fjernet version af din nuværende webside.

Vi har en slags kærlighed og hader-forbindelse med Google AMP, og det gør også meget af fællesskabet. Vi har testet det selv og så ikke gode resultater. Det betyder dog ikke, at du ikke vil. Hvert websted er anderledes, og Google AMP bliver konstant forbedret.

Du kan hurtigt komme i gang med Google AMP på dit WordPress-websted med et af følgende plugins:

• AMP til WordPress
• AMP til WP

Se vores dybtgående vejledning om, hvordan du får Google AMP-opsætning. Og hvis du har brug for det, skal du deaktivere Google AMP. Det er ikke bare noget, du kan deaktivere og så er du færdig.

Resumé

Som du sikkert kan fortælle, er vi besat med alle de forskellige måder, du kan fremskynde WordPress på. At have et hurtigt websted hjælper med at booste dine placeringer, forbedrer crawlbarheden for søgemaskiner, forbedrer konverteringsraterne, øger tiden på webstedet og reducerer din bounce rate. For ikke at nævne det faktum, at alle elsker at besøge en hurtig hjemmeside!

Vi håber, at denne speed up guide var nyttig, og at du var i stand til at tage et par ting væk og anvende dem på dit WordPress-websted. Hvis ja, så tag et øjeblik og del det.

Savnede vi noget vigtigt? I så fald vil vi gerne høre om det. Lad os vide din hurtigere WordPress-tips nedenfor i kommentarerne.