En dag började jag undersöka prestandan för webbplatsen jag arbetade med. Den främsta anledningen till det var att en av de OKR:er jag arbetade med är att öka konverteringsfrekvensen i onboarding-delen av webbplatsen. Jag bestämde mig för att fokusera på att förbättra webbplatsens laddningstid. Det finns många fallstudier online som visar hur laddningstiden påverkar konverteringsfrekvensen. De visar att de första sekunderna har störst inverkan på konverteringsfrekvensen och att bara en sekunds fördröjning i laddningstiden resulterar i upp till 7 % förlust av konverteringar. När det gäller sidstorlekar är mindre alltid mer.
Att använda Lighthouse-verktyget från Chrome DevTools är den bästa utgångspunkten för att förbättra en webbplats prestanda. Lighthouse kör granskningar mot din webbplats och genererar en rapport med prestandamått och saker du kan göra för att förbättra prestandapoängen.
Det här är granskningsresultaten jag fick. Mätvärden som visas i orange är de som kan förbättras. Rapporten visar också tips om hur man kan förbättra dessa mätvärden. Lighthouse identifierade CSS som min resurs för renderingsblockering och en av de föreslagna förbättringarna för webbplatsen var att minska oanvänd CSS. Denna förbättring påverkar både FCP (First Contentful Paint) och LCP (Largest Contentful Paint) mätvärden. Om du kör rapporten på din webbplats och även får ett förslag om att minska oanvänd CSS, är den här artikeln för dig. Jag visar de saker jag gjorde på min webbplats som hjälpte till att förbättra FCP- och LCP-mätvärdena.
Innan jag gjorde några ändringar i koden ville jag se hur lång tid det tar för stilarket att laddas när någon besöker webbplatsen för första gången någonsin. Jag ville veta detta eftersom jag antog att majoriteten av de som besöker onboarding-delen av webbplatsen besöker webbplatsen för första gången. Det betyder att de inte har några resurser från webbplatsen cachade i sin webbläsare. Jag testade den första sidans inläsning med olika nätverkshastigheter.
Du kan testa sidinläsningar på fliken Nätverk i Chrome DevTools genom att välja "Inaktivera cache" och välja en nätverksprofil (Ingen begränsning, Snabb 3G, Långsam 3G eller en anpassad profil som du kan skapa).
Nedan visas resultatet för profilen Ingen strypning. Stilarket är 325 kB (67 kB komprimerat) och tar 218 ms att ladda (och nästan 5 sekunder på långsam 3G).
Storleken på paketen för stilmallar förbises ofta när man kodar en app. Många utvecklare anser att CSS är endast tilläggsformat, vilket innebär att de ofta lägger till nya stilar i stilmallen, men aldrig tar bort gamla oanvända. Det beror på att det är krångligt att ta bort gamla stilar, tar mycket tid och man måste kontrollera hela kodbasen för att vara säker på att stilen man tagit bort inte används någonstans. Men CSS behöver inte vara en stor och ohanterlig röra! Jag ska visa några enkla saker jag gjorde som kan hjälpa till att minska storleken på CSS-stilmallar. Exemplen nedan är alla från ett Angular-projekt, men du kan återanvända samma principer i vilken JS-kod som helst.
Om du stöter på stilar som ser ut som samma duplicerade stilar med några mindre ändringar, kom ihåg DRY-principen. Vanligtvis kan dessa stilar vara en bra kandidat för att använda CSS-variabler. Detta gäller särskilt för stilar som används för flera teman. Jag visste att projektet stödde flera teman så jag började med att granska koden för dem. Jag hittade stilarket som innehöll stilar för olika teman, det fanns ett tiotal av dem och de skapades alla med en mixin som tar fyra parametrar: två teckensnitt och två färger.
När denna SCSS-fil kompilerades till CSS genererades cirka 500 rader kod för varje tema. Stilarna för varje tema var desamma, med den enda skillnaden att de fyra parametrarna i mixinen var desamma. Istället för att generera nya stilar för varje tema skapade jag bara ett tema som tar CSS-variabler och sedan ställer in deras värden via Javascript.
Så istället för ett värde som "Inter UI" kan vi använda en CSS-variabel som var( — font-header) och sedan ställa in den variabeln beroende på vilket tema som är valt. Vi måste först definiera värden för varje tema:
Sedan skapade jag ett direktiv som prenumererade på temaändringar (ett BehaviourSubject som returnerar temanamnet varje gång temat ändras), använde ett temanamn för att hitta temavärden definierade i themes.const.ts och satte dem i CSS-variabler.
Eftersom det fanns tio teman i temanas stilarket, minskade CSS-variabler filstorleken till 1/10 av den ursprungliga storleken.
CSS @import används för att importera en CSS-fil till en annan CSS-fil. Jag hade ett globalt stilark som använde @import för att ladda två andra stilark. Till slut samlades alla stilar i en stor fil. CSS är renderingsblockerande, vilket innebär att webbläsaren inte kan visa något innehåll förrän detta stora paket har laddats ner. Så istället för att samla allt i en fil är det bättre att separera stilark och ladda dem parallellt. Eftersom projektet hade tre distinkta stilkategorier – temastilar, äldre stilar och nya stilar, bestämde jag mig för att separera dem i tre paket.
Jag tog bort @import ‘tailwind'; och @import ‘theme'; från stilar.scss och definierade tre paket: temastilar, äldre stilar och nya stilar. Detta kan konfigureras i angular.json.
PurgeCSS är ett verktyg som analyserar dina filer, matchar de CSS-selektorer som används och tar bort oanvända. Detta är särskilt användbart om du använder ett CSS-ramverk som Bootstrap och bara använder en liten del av selektorerna från det ramverket. PurgeCSS kan integreras i byggprocessen i postbuild -skriptet som körs efter att byggskriptet har slutförts. Du kan läsa mer om att integrera PurgeCSS i byggprocessen här . Jag har återanvänt skriptet från den här artikeln och bara ändrat konfigurationen av vilka CSS-paket som ska rensas.
purgecss -css dist/legacy-styles*.css dist/theme-styles*.css — innehåll dist/index.html dist/*.js -o dist/
Jag har konfigurerat PurgeCSS för att rensa paket med äldre stilar och temastilar, men jag har hoppat över paketet med nya stilar eftersom det stilarket använder Tailwind, och Tailwind genererar bara CSS för klasser som används, så det skulle vara onödigt att rensa den här filen. Se till att jämföra original- och rensade filer för att säkerställa att allt är korrekt konfigurerat.
Här är resultaten efter att ha kört PurgeCSS.
Nedan visas storlekarna och laddningstiderna för nya paket.
Om vi jämför det med det ursprungliga paketet kan vi se en minskning av storleken från 325 kB till 107 kB (eller från 67 kB till 21 kB komprimerat) och en minskning av laddningstiden från 218 ms till 81 ms (eftersom dessa paket laddas parallellt är den totala laddningstiden tiden för det paket som tar längst tid att ladda). Det är en minskning av storlek och laddningstid på ~67 % .
Jag körde Lighthouse-rapporten igen, jämförde resultaten och såg förbättringar i nästan alla mätvärden. (Lighthouse-poäng kan ändras på grund av inneboende webbinvariabilitet, så se till att köra rapporten flera gånger innan du drar slutsatser).
Att spara ett par hundra millisekunder vid den första laddningen kanske inte låter mycket, men det räckte för att rapporten skulle flytta sidans totala prestandapoäng från genomsnittlig till snabb. Om det är något jag vill att du ska komma ihåg från den här artikeln så är det att det inte är så svårt att förbättra webbprestanda som det ibland verkar och att några enkla justeringar kan påverka laddningstiden för din webbplats avsevärt. Förutom CSS-förbättringar kan du dra nytta av bildkomprimeringar, lazy-loading av dina JS-moduler eller att ersätta tunga beroenden. Om du använder Lighthouse-verktyget vet du mer om vilken del av din app som behöver uppmärksammas. Har du några prestandatips eller kommentarer? Lämna dem i kommentarerna! :)
