Perfmatters, konfigurationsguide

Om jag i morgon fick veta att jag bara fick ta med mig ett plugin till en öde ö, skulle jag förmodligen ta Perfmatters och om jag hade en fanklubb skulle jag registrera mig och gå på alla deras konserter.

Jag har använt det sedan januari 2021 och det har varit ett av de plugins som har löst flest problem och det som bidrar mest och bäst till att lätta på laddningshastigheten.

Essential

Det är ett av de verktyg som du inte ens ifrågasätter den avlägsna möjligheten att inte betala när den årliga förnyelsedagen kommer. Vilket för övrigt är mycket ekonomiskt för användning på en enda webbplats. Det kostar bara 24,95 dollar och har en rabatt på 15 % för efterföljande förnyelser. Så från och med det andra året är det 21,21 dollar för ynka 21,21 dollar.

Eftersom jag har granskat några av dess funktioner separat, väntade en mer djupgående analys och installationshandledning. Det är syftet med det här inlägget.

Om konfigurationen

Ansvarsfriskrivning: Självklart är de on- och off-ikoner jag har lagt till från min konfiguration, som är det bästa jag kunde få för den här bloggen. Det betyder inte att den är idealisk för din miljö.

Varje scenario är annorlunda. Du måste studera varje alternativ och förstå det, experimentera med dess beteende och bestämma vad som är bäst i ditt fall. För detta finns det inget bättre än att testa dina alternativ ett efter ett och utvärdera resultaten.

En annan sak att tänka på är att dubbla verktyg kommer att kollidera. Det finns andra insticksprogram som WP Rocket eller servercacheinsticksprogrammet med Litespeed som har vissa funktioner som gör exakt samma sak. Att aktivera dem tillsammans kan orsaka konflikter. Du måste utvärdera vilken som fungerar bäst och hålla dig till endast en av dem.

Fliken Allmänt

Den allmänna fliken innehåller de vanligaste verktygen. Bredvid dem alla hittar du en länk till deras motsvarande hjälp. Var inte rädd för att prova dem. Allting är reversibelt. Om du klickar på knappen återgår allt till sitt ursprungliga tillstånd och här har ingenting hänt

Inaktivera emojis

I WordPress version 4.2 från 2015 lades stöd för emojis till i kärnan för äldre webbläsare.

Även om de inte är alltför tunga (18 KB plus annan JS) kan du inaktivera dem eftersom de laddar wp-emoji-release.min.js JavaScript på varje sida i din blogg och en mindre begäran är alltid en mindre begäran.

Inaktivera dashicons

Dashicons är det officiella ikonteckensnittet för WordPress admin sedan version 3.8. Vissa mallar använder det på framsidan genom att ladda CSS-filen dashicons.min.css. Många moderna teman och plugins använder dock redan sina egna ikoner, SVGs eller inga ikoner alls. Så om du inte använder dashicons kan du inaktivera dem eftersom formatmallen lägger till onödig laddningstid och även blockerar rendering.

Att inaktivera dem från Perfmatters påverkar inte WordPress adminpanel, som använder dem. Endast dashicons på front-end tas bort när du inte är inloggad.

Inaktivera inbäddning (Embebs)

När du lägger till en länk från din blogg i redigeraren känner WordPress igen den och visar den som sådan (om du inte har ändrat stilen).

Om du inte bryr dig om inbäddningar kan du inaktivera dem och lätta på belastningen lite. Jag har inte stängt av dem eftersom jag har märkt att länkar med förhandsgranskningar tenderar att få bra klickfrekvens när de används som relaterade länkar mellan stycken.

Inbäddning eller embeds kom med WordPress version 4.4. Nackdelen är att de kom med en extra kod som läggs till genom att inkludera ännu ett JavaScript att ladda: wp-embed.min.js

Att inaktivera embeds på din blogg förhindrar också andra bloggar från att bädda in länkar från din webbplats med den förhandsgranskningen, men det tar bort det oEmbed-specifika JavaScript, inaktiverar filtrering av oEmbed-resultat,
tar bort oEmbed-linkupptäckt och även alla embed rewrite-regler.

Inaktivera XML-RPC

XML-RPC är ett protokoll som lades till i WordPress 3.5 för att möjliggöra fjärranslutningar och om du inte använder WordPress-appen för att publicera eller redigera din blogg från mobilen är det viktigt att inaktivera det eftersom det innebär allvarliga säkerhetsrisker.

Mycket få plugins kräver det, jag känner bara till en som använder det: JetPack. En multifunktionell plugin som inte rekommenderas eftersom den avsevärt hämmar prestandan.

När XML-RPC är avaktiverat är det bara att kontrollera dess status genom att besöka yourdomain.com/xmlrpc.php för att se till att den endast returnerar ett 403-felmeddelande.

Du kan också kontrollera det med den här kontrollern. Om du får ett sådant meddelande betyder det att XML-RPC är inaktiverat.

Ta bort jQuery Migrate

Det introducerades i WordPress 3.6 och är inte längre aktiverat som standard sedan WP 5.5 och senare.

Även om de flesta mallar och insticksprogram inte behöver det finns det fortfarande några som kräver det för någon mindre funktion. I mitt fall finns det två plugins som använder den, Ultimate Membership Pro och Rank Math för en statistikfält (som jag inte använder) som bara visas för administratörer. Vissa plugins för hantering av samtycke till cookies använde det fortfarande tills nyligen.

jQuery Migrate är en resurs för utvecklare som gör att kod med äldre beroenden kan kommunicera med ny kod.

Chansen är stor att du inte har några plugins som behöver det, så jQuery Migrate lägger till den onödiga överbelastningen av jquery-migrate.min.js JavaScript

Kontrollera ändå dokumentationen för dina plugins innan du inaktiverar den eller fråga deras utvecklare (vi kommer att se hur du inaktiverar den för specifika webbplatser senare).

Dölj WordPress-versionen

Det här alternativet har inget mystiskt, det döljer helt enkelt versionen av WordPress du har installerat från nyfikna ögon som en säkerhetsåtgärd.

Detta, som kan göras på olika sätt, är användbart om du är sen med att uppdatera något där sårbarheter dyker upp med din version som kan utnyttjas eller kärnan kan äventyras. Genom att dölja versionen gör du det åtminstone mindre lätt för angripare som letar efter kryphål.

Även om endast en kodrad tas bort och det görs främst för säkerheten, är det för optimeringsentusiaster bara ytterligare en nypa som läggs till den totala summan som ska subtraheras.

Ta bort länken wlwmanifest

Detta är en tagg som visas i varje WordPress-installation och användes av Windows Live Writer, som slutade uppdateras och stöds i januari 2017.

Precis som ovan är det bara onödig kod, så en rad mindre.

Ta bort RSD-länken

En annan överbliven tagg som dyker upp i varje WordPress-installation.

Om du redigerar din webbplats från webbläsaren behöver du den inte alls. Den används också av vissa tredjepartsapplikationer som använder XML-RPC-förfrågningar, som du förmodligen redan har inaktiverat. Så det är onödig kod att ta bort.

Ta bort den korta länken

Detta används för att skapa en kort länk med siffror för dina sidor och inlägg som lägger till den här taggen:

<link rel='shortlink' href='https://dominio.com?p=123' />

Om du använder "fina" korta permalänkar, som domain.com/%postname% finns det ingen anledning att behålla den här utan användning, mer onödig kod att kasta.

Inaktivera RSS-flöde

WordPress genererar olika typer av RSS-flöden som standard. Även om RSS-flöden fortfarande är användbara för en blogg kan du inaktivera flödet om din webbplats är ganska statisk eller om du helt enkelt inte använder den som en blogg.

Ta bort länkar från RSS-flöden

Precis som WordPress genererar RSS-flöden genererar det också länkar till dessa RSS-flöden för dina sidor, inlägg, kommentarer, kategorier, taggar osv. Du kan låta dina RSS-flöden vara aktiverade och ändå ta bort RSS-flödeslänkarna. Syftet med detta är att ta bort ytterligare och sannolikt oanvänd kod från din sida.

Inaktivera autopingbacks

En pingback är i princip en automatisk kommentar med en länk som skapas som ett meddelande på din blogg när en annan blogg länkar till dig. En autopingback skapas när du länkar till en artikel i din egen blogg.

Numera använder nästan ingen dem och de externa pingbacks du kan få är oftast skräppost, de slösar bara resurser och kan till och med skapa skadliga eller tillfälliga länkar som är trasiga och därför skadliga för SEO.
Precis som trackbacks tillhör de bloggarens förflutna, när länkning som en bloggfilosofi var tradition som en del av netiketten.

Inaktivering av REST API

WordPress REST API tillhandahåller API-slutpunkter för WordPress-datatyper som gör det möjligt för utvecklare att interagera med webbplatser på distans genom att skicka och ta emot JSON-objekt.

Det gör det möjligt att korsreferera data med andra webbplatser och med programvara som är skriven i PHP eller något annat språk.

Det finns olika plugins, tjänster och program som använder REST API, enligt Perfmatters är detta några av dem:

Yoast SEO och Ryte dashboard widget, Jetpack, vissa kontaktformulär, Wordfence och vissa WooCommerce dashboardspecifika widgets.
Det används också av Gutenberg blockeditor för att kommunicera när du gör ändringar på sidor och inlägg. Om du inaktiverar den helt och hållet får du ett felmeddelande "Uppdateringen misslyckades".

Perfmatters erbjuder tre alternativ. Aktiverad (standard), inaktiverad för icke-administratörer och inaktiverad när du är utloggad.

Ta bort REST API-bindningar

Som standard ingår en REST API-länk i typhuvudet:

<link rel='https://api.w.org/' href='https://domain.com/wp-json/' />

En rubrik skickas också i varje begäran och en API-tagg läggs till i RSD-slutpunkten ( Really Simple Discovery ). All den här koden kan man slippa genom att aktivera alternativet för att ta bort dess bindningar.

Inaktivera Google Maps

Just det, inaktivera Google Maps API.

Vissa WordPress-mallar och plugins har Google Maps API inbyggt och erbjuder ofta inget sätt att inaktivera det. Google Maps kan ställa till det för din bloggs prestanda även om förfrågningarna laddas asynkront. Normalt sett görs en begäran via det officiella Google Maps API.

Bara för att ladda en karta på din blogg kan upp till 20 HTTP-förfrågningar göras till Google Maps. Beroende på integrationen kan du göra färre eller till och med fler förfrågningar.

Om du inte behöver dem bör du inaktivera dem.

Exkludera avaktivering av Google Maps genom post-ID-nummer

Om du dock inte har något annat val än att bädda in kartor kan du utesluta avaktiveringen endast för de inlägg där du behöver lägga till dem. För att göra detta måste du i följande ruta lägga till ID-numret för varje inlägg separerat med kommatecken.

Inaktivera mätaren för lösenordets styrka

Detta infördes i de senaste versionerna av WordPress och WooCommerce. Det är en inbyggd mätare för lösenordsstyrka som tvingar användarna att använda starka lösenord och laddar flera filer som: /wp-admin/js/password-strength-meter.min.js och /wp-includes/js/zxcvbn.min.js

zxcvbn.min.js kan väga mer än 800 KB

Om du använder WooCommerce finns filen också ibland i den här sökvägen:

/wp-content/plugins/woocommerce/assets/js/frontend/password-strength-meter.min.js

Beroende på varje mall och hur utvecklaren har ställt saker och ting i kö, laddas dessa filer ibland på hela webbplatsen. Av prestandaskäl bör de endast laddas på sidorna "konto", "utcheckning" och "återställning av lösenord".

Om du fortfarande hittar dessa skript bland förfrågningarna efter att du har inaktiverat den, vänligen konsultera dokumentationen för din mall och dokumentationen för eventuella plugins som du tror kan använda den här funktionen.

Inaktivering av kommentarer

Om du inte behöver kommentarerna eller om du har bestämt dig för att få slut på skräppost på det mest radikala sättet kan du inaktivera möjligheten för dina läsare att kommentera. Kommentarsformuläret kommer att försvinna.

Detta är listan över åtgärder som Perfmatters kommer att försöka utföra när alternativet Inaktivera kommentarer är aktiverat:

• Inaktivera den inbyggda widgeten för senaste kommentarer.
• Ta bort rubriken X-Pingback.
• Ta bort länkar till kommentarsflöden.
• Inaktivera förfrågningar om kommentarsflöden.
• Ta bort kommentarslänkar från administrationsfältet.
• Ta bort stöd för kommentarer för alla typer av inlägg.
• Stäng kommentarsfilter.
• Ta bort kommentarslänkar från administrationsmenyn.
• Inaktivera den inbyggda diskussionssidan.
• Dölja kommentarer från kontrollpanelen.
• Dölj alternativet för kommentarsinställningar från profilsidan.
• Återge en tom kommentarmall på begäran.
• Ta bort skriptet för kommentarssvar.

Kom ihåg att om du väljer ett mjukare alternativ kan du stänga kommentarer endast för vissa inlägg från redigeringen av varje inlägg genom att avmarkera den här rutan.

Eller så kan du från Inställningar/kommentarer ställa in dem så att de stängs efter ett visst antal dagar.

Ta bort webbadresser från kommentarer

Som standard innehåller WordPress-kommentarer ett webbplatsfält som skapar en nofollow-länk (även om spammare inte har något emot detta) i kommentarsförfattarens namn.

Om du inte vill ta hand om länkar som går sönder med tiden, har för få kommentarer eller helt enkelt vill stämpla bort skräppost kan du radera alla webbadresser som besökare lägger till i kommentarerna i ett enda svep.

Om du aktiverar detta tar du också bort URL-fältet från formuläret för framtida kommentarer.

Lägg till en tom favicon

Om du redan har en favicon på din webbplats bör du låta det här alternativet vara inaktiverat.

Att lägga till en vit favicon är användbart om du skapar och testar många nya WordPress-installationer. Genom att lägga till en tom favicon slipper du ladda upp en favicon för varje webbplats. Om du glömmer det kan det dessutom generera ett 404-fel i hastighetstestverktygen.

Ta bort globala stilar

Från och med WordPress 5.9 lades ytterligare inline-kod till för att förbättra duotone-stilar (CSS- och SVG-kod). De flesta användare kommer förmodligen inte att använda den här funktionen, och problemet är att den lägger till 311 rader (ominerade) kod till varje sida på din webbplats som delas upp så här:

196 rader CSS före body-taggen och 115 rader SVG-kod som också läggs till före /body-taggen.

En stor del av koden använder!important;-taggar, vilket inte heller är idealiskt.
Perfmatters tror att detta kan vara en bugg, så de lägger till detta alternativ som ett enkelt sätt att ta bort all denna onödiga kod medan problemet löses.

Hearbeat, recensioner och autosparande

WordPress Heartbeat API använder /wp-admin/admin-ajax.php för att utföra AJAX-samtal från webbläsaren.

Detta är bra eftersom det sparar dina utkast och förhindrar att en oväntad avstängning gör att du förlorar dem, men det kan också orsaka hög CPU-användning och galna mängder PHP-anrop. Om du till exempel låter din kontrollpanel vara öppen kommer den att fortsätta att skicka POST-förfrågningar till den här filen med jämna mellanrum, var 15:e sekund. Du kan öka frekvensen upp till 60 sekunder för att mildra detta.

I det första alternativet kan du välja när och var den utlöses.

Med det tredje alternativet kan du begränsa antalet revideringar av dina poster för att spara utrymme, till exempel om du ställer in det på 10 kommer endast de 10 senaste att sparas och de tidigare kommer att raderas.

Slutligen kan du ställa in intervallet för automatisk lagring av utkast. Som standard sparar WordPress dem automatiskt var 60:e sekund. Om du ökar intervallet måste du dock spara manuellt oftare, detta förhindrar att webbläsaren "hänger" så mycket när du är i administrationsområdet och sparar också mindre skrivningar till databasen.

Woocommerce

Om optimeringsalternativen för Woocommerce kommer jag bara att säga att de finns, men jag kommer att undvika varje kommentar eftersom det är brukligt i det här huset att inte recensera något som jag inte har väldigt klart för mig, vilket är fallet. Jag avinstallerade WooCommerce i juli 2021 och jag minns knappt något om svaret på dessa optimeringar så jag hänvisar till deras dokumentation:

• Inaktivera WooCommerce skript och stilar
• Inaktivera cart snippets
• Inaktivera WooCommerce-statusrutan
• Inaktivera WooCommerce-widgetar

URL för inloggning

En annan intressant funktion är möjligheten att ändra standardinloggningsadressen till administrationsområdet som WordPress ställer in på yourdomain/wp-admin. Den gör exakt samma sak som pugins som WPS Hide Login.

Du hittar tre fält:

I det första fältet kan du ändra inloggningsadressen för wp-admin till vad du vill, till exempel "yourdomain.com/potato", vilket gör att du undviker brute force-attacker och andra attacker som vanligtvis riktar in sig på standardadressen. Skriv bara ner den och/eller försök att inte göra det till en konstig url med för många tecken så att du inte glömmer den (även om du alltid kan hämta den genom att gå till tabellen wp_options / perfmatters_options )

Det andra fältet (Disabled Behavior) anger vilken url besökaren som landar på yourdomain/wp-admin ska skickas till med tre möjligheter:

• Meddelande (standard): Visar ett meddelande till besökaren. Du kan anpassa meddelandet med vilken text som helst genom att lägga till den i fältet Meddelande.
• 404 Mall: Användaren skickas till en 404-sida.
• Hem-URL: Användaren omdirigeras till hemsidan.

Tillgångar

Det är här det blir riktigt intressant.

Script Manager, grädden på moset

Perfmatters Script Manager är utan tvekan deras mest kraftfulla och användbara verktyg. Enbart detta är värt varenda krona av den lilla summa du betalar för insticksprogrammet och dess support.

Med den kan du inaktivera de skript och CSS som används av varje plugin och förhindra att de laddas på ett inlägg eller en sida, på båda ställena eller på hela webbplatsen, filtrera efter inloggade eller utloggade användare, efter enheter och lägga till undantag, även för kategorier och taggar.

Detta kan drastiskt öka laddningshastigheten (särskilt på hemsidan) genom att eliminera onödiga förfrågningar där insticksprogram inte används, t.ex. formulär eller annat.

Mandatory Usage Mode (MU) tar Script Manager mycket längre. Det ger mycket mer kontroll och ger möjlighet att inaktivera förfrågningar och krokar för WordPress-plugins samt inline CSS och JS. Nu kan du kontrollera alla aspekter av ett insticksprogram, från dess front-end skript, inline-kod och MySQL-förfrågningar var du vill.

I dess globala vy hittar du alla tillämpade inställningar ifall du en dag behöver omorganisera, ändra, lägga till nya eller ta bort några.

Den har en ganska komplett dokumentation. Om du inte är van vid den här typen av verktyg kan det vara skrämmande till en början, men så fort du provar det kommer du att upptäcka att det är mycket lätt att använda.

JavaScript

Skjuta upp och fördröja JavaScript.

Båda kan bidra till att förbättra FCP och LCP

Genom att lägga till attributet defer i varje icke-kritisk JavaScript-fil påskyndas sidans första innehållsmålning (FCP). Detta innebär att JavaScript laddas ner under HTML-analyseringen och utförs efter att sidan har laddats färdigt (när analyseringen har avslutats). Med andra ord skjuts nedladdningen av javascriptet till slutet av sidan så att den utförs i slutet av processen.

Med fördröjning förbättras LCP- och TBT-resultaten. JavaScript fördröjs enligt användarinteraktionen, vilket påskyndar den första målningen av sidan när något inte behövs omedelbart, t.ex. tunga skript från tredje part som Google Adsense, Google Analytics, Facebooks konverteringspixlar eller Google Ads och liknande.

För båda alternativen kan du lägga till undantag och aktivera beteendet Delay Timeout, detta ställer in en timeout som automatiskt laddar skript efter 10 sekunder om ingen användarinteraktion har upptäckts. Detta är valfritt och är inaktiverat som standard.

Fördröj Timeout

Om du aktiverar det här alternativet har du möjlighet att ställa in fördröjningstidsuttaget till ett annat värde med hjälp av ett av dessa filter.

Det i exemplet är inställt på 7 sekunder.

add_filter('perfmatters_delay_js_timeout', function($timeout) {
    return '7';
});

De rekommenderar att man inte ställer in timeoutvärdet för kort, annars kommer JS-fördröjningsfunktionen inte att fungera korrekt. Dessutom kommer allting, oavsett timeoutvärdet, i 99 % av fallen att utlösas vid den första användarinteraktionen, oavsett om det är rullning, klickning eller den första musrörelsen.

CSS

Perfmatters säger att det enklaste sättet att lösa varningen "Reduce unused CSS" är att aktivera den här funktionen, som jag recenserade när den fortfarande var i betaversion, som gör allt automatiskt. Utvecklarna hävdar att de har testat den på hundratals webbadresser (med olika mallar och inställningar) och det här är några av de resultat som de hävdar att de har fått:

• Genomsnittlig FCP-minskning på 15,20 %.
• Genomsnittlig minskning av LCP med 19,66 %.
• Genomsnittlig TTI-minskning på 14,95 %.

Innan de aktiverar funktionen "Remove unused CSS" i Perfmatters rekommenderar de att man tar bort alla befintliga CSS-förladdningar som har ställts in i Perfmatters (exklusive Google Fonts lokala formatmallar).
Slå inte samman CSS (saker som ofta görs med WP Rocket, Litespeed, Autoptimize och andra). CSS-sammanslagning är en föråldrad optimeringsteknik sedan HTTP/2. I vissa fall kan kombinationen av CSS försämra prestandan(i mitt fall har det inte gjort det) och slutligen ska du se till att du inte försöker ta bort oanvänd CSS med ett annat plugin.

Det finns tre metoder för borttagning:

• Fördröjning (standard): Alla ursprungliga CSS-stilblad (oanvänd CSS) fördröjs och laddas vid användarinteraktion. Detta är det rekommenderade alternativet.
• Asynkron: Alla ursprungliga CSS-formatmallar (oanvända CSS) laddas via asynkron. Den här metoden kan hjälpa till att undvika pop-in, eftersom formatmallarna exekveras asynkront medan sidan laddas. Denna metod ger en något högre LCP/FCP än fördröjningsbeteendet.
• Ta bort: Alla ursprungliga CSS-formatmallar (oanvända CSS) tas bort. Detta är den mest aggressiva metoden, men kommer förmodligen också att kräva att undantag läggs till. Den rekommenderas endast för avancerade användare.

Det finns ingen hemlighet här annat än att experimentera i en testmiljö och mäta resultaten, både isolerat och i samspel med de andra funktionerna.

Vissa av dessa funktioner kan inaktiveras på alla inlägg eller sidor i WP-redigering.

Kod

En användbar klassiker som många andra plugins innehåller, något som till och med kan göras för hand, men som förenklar och underlättar driften av att lägga till anpassad kod i rubriken, kroppen eller sidfoten på din blogg.

Följande fält skriver ut kod direkt till front-end, så det måste vara giltig HTML. Detta inkluderar inline CSS inom <style>-taggar eller inline JS inom <script>-taggar. Du kan också ladda upp en JS- eller CSS-fil.

Det finns inget stöd för serverbaserade språk som PHP. Om du vill lägga till egen PHP-kod rekommenderas det att du använder insticksprogrammet Code Snippets.

Förladdning av

I Förladdning använder det första alternativet"Instant Page" biblioteket instant.page och laddar en liten JS-fil på mindre än 2 KB(instantpage.js) lokalt på din webbplats och används för att förinföra webbadresser när en användare håller muspekaren över en länk eller en bild i skrivbordsversionen. I mobilversionen laddas URL:n för när användaren börjar trycka på länken på skärmen och innan han eller hon släpper den.

Efter 65 millisekunder startar förladdningen av URL:en automatiskt i bakgrunden.

Det här verktyget är motsvarigheten till Litespeeds"Instant Click" och WP Rockets"Preload Links", så om du använder det här alternativet i någon av dessa två plugins bör du avaktivera det för att prova Perfmatters.

I mitt fall har det fungerat lite bättre än motsvarande alternativ i Litespeed även om det bör noteras att det i vissa fall kan öka serverbelastningen.

Precis som med Javascript- och CSS-alternativen bör användningen av förladdning och föranslutning användas enligt dina behov baserat på olika tester.

Förladdning av kritiska bilder (de som är ovanför fold) är ett alternativ som fortfarande befinner sig i betaversionen och som kan bidra till att minska den tid det tar att måla större innehåll (LCP) i Core Web Vitals.

Detta är vanligtvis bilder som en logotyp, en framträdande bild i ett inlägg, en huvudbild på en landningssida osv. När du förinstallerar dem flyttas de till toppen av vattenfallet och talar i princip om för webbläsaren att de har prioritet och ska laddas omedelbart.

Du kan välja mellan noll, för att förinstallera ingen (standardalternativet) och fem bilder. Permatters rekommenderar att du väljer två eller högst tre eftersom Chrome har en gräns på två förinlästa bilder som visas högst upp i vattenfallet.

Lättviktig laddning

En annan klassisk prestandarelaterad funktion som WordPress har inkluderat nativt sedan utgåvan av 5.4 år 2020.

I mitt fall använder jag Litespeed-alternativet eftersom jag i testerna fann något bättre resultat, trots detta fungerar Perfmatters-alternativet riktigt bra och tillämpar det även på CSS för bakgrundsbilderna.

Typsnitt

En annan bra sak. Det här alternativet, som lades till i version 1.7.4 av Perfmatters 1.7.4släpptes den 7 juni 2022. Det gör att du kan vara värd för och ladda upp Google Fonts lokalt med ett par klick.

Fördelarna med att hosta teckensnitt lokalt är många, du får full kontroll över dem, du eliminerar alla dessa förfrågningar och därmed laddningstiden och du kan bestämma hur de ska serveras.

Funktionen lokaliserar automatiskt alla Google Fonts-referenser som finns på din blogg, laddar ner motsvarande typsnitt från fonts.google.com och är värd för dem lokalt på din server i katalogen: /wp-content/cache/perfmatters/your-domain.com/fonts/

I dethär andra inlägget förklaras användningen mer i detalj.

CDN

Det finns inget speciellt här och det finns lite att kommentera. Ett verktyg, alltid användbart att lägga till den CDN du använder. Eftersom jag använder QUIC.CLOUD har jag inte behövt det ännu.

Analytics

Även om jag inte använder det nu eftersom jag påbörjat övergången till Matomo och förpassat hanteringen av Analytics-skriptet till mitt plugin för hantering av RGPD/CCPA-cookiemedgivande, som också hanterar det korrekt, men jag vet att det fungerar mycket bra med Perfmatters eftersom jag använde det förr i tiden.

Härifrån kan du vara värd för Google Analytics-skriptet lokalt. Detta bidrar till att snabba upp din webbplats genom att minska ytterligare DNS-uppslag och lösa problemet med att "utnyttja webbläsarens cache" med deras skript.

Enligt Perfmatters ger Googles eget skript ironiskt nog en varning om caching, men det beror på att de har en mycket kort utgångstid för HTTP-cachehuvudet. Om du är värd för det själv kommer HTTP-cache-huvudena från ditt eget CDN eller din egen server att tillämpas automatiskt. Med andra ord får du full kontroll över skriptets caching.

De påpekar också att detta verktyg inte stöds officiellt av Google, men att det har använts i flera år utan problem.

Om du är värd för Google Analytics lokalt och serverar skriptet från ditt eget CDN eller din egen server kan du också dra nytta av en enda HTTP/2-anslutning.