Prestaties is een term waarvan we weten dat we er constant aan moeten denken (en aan werken) , maar om verschillende redenen hebben we de neiging om het te vergeten. De waarheid is dat het zo'n overweldigend onderwerp kan zijn dat wanneer je met deze problemen wordt geconfronteerd, het moeilijk is om te weten waar je moet beginnen.
En hoewel we tegenwoordig veel tools hebben waarmee we onze apps kunnen testen om te zien hoe ze het doen, kan het tegelijkertijd een beetje lastig zijn om te begrijpen hoe ze werken (en soms heel moeilijk) , dus met de beperkte tijd die we hebben, leggen we het vaak aan de kant omdat de resultaten minder opvallen dan andere dingen, zoals het verzenden van een nieuwe functie of het oplossen van een vervelende bug.
In dit artikel zal ik enkele eerste ideeën behandelen over waarom het ons iets zou kunnen schelen, hoe we aan de slag kunnen gaan en hoe we het onderdeel kunnen maken van onze dagelijkse workflows.
Maar eerst is het een goed idee om een paar dingen door te nemen om zowel het belang van prestaties te begrijpen als om er de juiste verwachtingen over te scheppen:
Waarom zou ik me druk maken om prestaties?
Hoewel ze op het eerste gezicht minder opvallen, kunnen de prestaties van onze app of website nog groter zijn (en vaak negatief) impact hebben op onze gebruikers, ze soms zelfs wegjagen en ervoor kiezen om naar een andere site te gaan. Als uw app aan een bedrijf toebehoort, kan dit een nog slechter resultaat opleveren, waardoor klanten worden weggejaagd en een potentiële verkoop verloren gaat aan een concurrent die een 'sneller' heeft site dan die van jou.
We kunnen tal van statistieken vinden die door grote bedrijven zijn gedeeld over hoe vertragingen van zelfs 1 seconde of minder terwijl het laden van hun inhoud hun verkoop kan beïnvloeden of verkeer kan wegjagen, dus je vraagt je af of dat soort impact kan gebeuren met bekende merken, wat kan het met de onze doen?
Geen wondermiddel
Zoals de meeste goede dingen in het leven, is het hebben van een performante app niet gemakkelijk, en het is belangrijk om dat meteen te begrijpen. Werken aan prestatiegerelateerde zaken brengt veel... nou ja, werk met zich mee. Helaas is er geen wonderbaarlijk pakket of bibliotheek die we kunnen gebruiken en zullen al onze problemen oplossen (maar wie weet, misschien op een dag, je weet wel, met like 🤖🤖🤖 en zo) , maar dat betekent niet dat het onmogelijk is om het tegenovergestelde te bereiken. Het oplossen van prestatieproblemen en het verbeteren van onze apps is relatief eenvoudig:
- Verzamel wat gegevens.
- Experimenteer.
- Verzamel nieuwe gegevens en vergelijk.
- Conclusies trekken (ook wel behouden wat werkte, ongedaan maken wat niet werkte) .
Hoewel sommige van deze onderdelen verschillende implicaties kunnen hebben (en sommige misschien een beetje lastig zijn) , het proces is altijd hetzelfde, waardoor deze twee dingen nog belangrijker zijn om in gedachten te houden:
- Wat in een andere app werkt, is misschien niet het juiste voor de jouwe :Dit betekent niet dat goede praktijken en algemeen advies moeten worden afgewezen, het is vaak nuttig advies dat ons zal helpen daar te komen, alleen dat het misschien niet juist (of de grootste prioriteit) is voor uw gebruiksgeval .
- Prestatie draait vaak om afwegingen .
Herschrijvingen zijn minder waarschijnlijk dan verbeteringen
Als ontwikkelaars is vaak onze eerste reactie wanneer we betrokken raken bij een project dat problemen heeft, na te denken over het herschrijven van die code. De waarheid is dat we dit meestal niet kunnen doen vanwege tijdgebrek, budgetten of andere prioriteiten. Daarom is het een goed idee om na te denken over het verbeteren van de huidige codebase waar we aan werken in plaats van deze weg te gooien en een nieuwe te schrijven. Hiermee kunnen we resultaten vergelijken met werkelijke gegevens die al heel lang live zijn en een beter idee krijgen van de impact die elke wijziging heeft.
En als we ooit een herschrijving mogen doen, zijn er een heleboel dingen die we waarschijnlijk in gedachten zullen houden om het beter te maken.
Dus, met dit alles in gedachten, hoe beginnen we?:Met een plan .
Klaar om een plan te maken
Beginnen met werken zonder te weten wat we moeten bereiken, zal waarschijnlijk meer problemen veroorzaken dan het oplost. Als we begrijpen wat de focus van het werk moet zijn en een plan maken over hoe het moet worden uitgevoerd, kunnen we daadwerkelijke overwinningen behalen die relevant zijn voor het hoofddoel van onze app.
Wacht, doel, wat bedoel je?
Identificeer het hoofddoel van uw aanvraag
Wanneer we een app of een website bouwen, is waarschijnlijk een van de eerste vragen die we onszelf moeten stellen:Wat probeert deze app te bereiken? . In de meeste gevallen is het doel vrij duidelijk:iets verkopen, inhoud tonen, een dienst verlenen enzovoort. Hoewel het identificeren van het hoofddoel eenvoudig kan zijn, is het vaak moeilijk om een duidelijk idee te krijgen van hoe de app zich moet concentreren om dat doel te bereiken.
Die focus verschilt meestal tussen apps, vooral als ze onder verschillende categorieën vallen, en het hangt nauw samen met waar onze prestatie-inspanningen zich op zouden moeten concentreren.
Laten we bijvoorbeeld zeggen dat we een website bouwen om cookies te verkopen. Het hoofddoel van de site zou vrij duidelijk zijn:die heerlijke verkopen. Bij het plannen van de functies van de startpagina van de site, weten we dat we waarschijnlijk deze secties zullen hebben:
- Een header met een mooi logo en een menu met coole animaties.
- Een lijst met alle beschikbare cookies.
- Een zijbalk met contactgegevens, links naar sociale media, aanmelding voor nieuwsbrieven voor promoties en enkele advertenties.
- Een coole voettekst met alle juridische informatie.
Als we teruggaan naar wat ons hoofddoel is (cookies verkopen) , en we nadenken over het belang van elke sectie en hoe deze zich verhoudt tot het doel, kunnen we waarschijnlijk aannemen dat onze gebruikers niet echt om sommige dingen op die lijst geven en dat ze de site bezoeken om wat cookies te krijgen (en dat willen wij ook) . Dus met dat in gedachten, moeten we waarschijnlijk onze best doen om ze eerst en zo snel mogelijk de lijst met cookies te laten zien in plaats van tijd en middelen te besteden aan het weergeven van het menu en de animaties (hoe cool ze ook zijn) of de zijbalk met de links naar sociale media, dus daar moet ons plan op gericht zijn.
Maak een plan voor geleidelijke verbeteringen (5-10% per keer)
Een heel belangrijk ding om te begrijpen als we het over prestaties hebben, is dat het een voortdurende inspanning is en dat het zeer waarschijnlijk is dat we niet elk probleem meteen kunnen oplossen. Een groot deel hiervan is meten en experimenteren, dus er is veel heen en weer tussen nieuwe dingen proberen, afwegingen analyseren en op basis daarvan beslissingen nemen. Ook is de kans groot dat de wijzigingen die we aanbrengen geen grote verschillen zullen hebben in termen van percentages, maar dat betekent niet dat het geen overwinningen zijn, integendeel, elke verbetering die we maken zal een impact hebben op elke gebruiker die onze site bezoekt en hun ervaring beter zal maken.
Denk er zo over na:als we een app hebben die is gebouwd met JavaScript en deze leeft in een bundelbestand van 500 kb, zal een gebruiker die onze site bezoekt 500 kb aan code downloaden die door zijn browser moet worden geparseerd, geïnterpreteerd en gecompileerd. Laten we zeggen dat we een manier vinden om wat verbeteringen aan dat bestand aan te brengen en dat we uiteindelijk de bundel met 10% verkleinen. Ook al lijkt 10 niet veel, het is nog steeds 50 kb minder dat we verzenden (en dat zal moeten worden geparseerd, geïnterpreteerd en gecompileerd) , dus niet alleen dingen worden sneller geladen, maar onze gebruikers zullen het op prijs stellen dat ze minder gegevens hoeven te downloaden om de app te gebruiken (vooral die op mobiele netwerken) .
Dus, met dat in gedachten, is het een goede vuistregel om te plannen voor geleidelijke verbeteringen tussen 5-10% op elke werkcyclus. Als we meer kunnen krijgen, uitstekend, maar alles tussen die cijfers zou geweldig en realistisch moeten zijn, omdat in het begin de overwinningen groter en merkbaarder zullen zijn, maar naarmate we verder komen, zal het moeilijker zijn om plekken voor verbetering te vinden. Na elke cyclus van verbeteringen kunnen we nieuwe monsters krijgen en plannen maken voor de volgende.
Verkrijg je gegevens
De laatste stap voordat u aan het werk gaat, is om echte gegevens te krijgen van de huidige prestaties van onze app om de pijnpunten te identificeren en prioriteit te geven aan het werk. Dat doen we door te meten.
Meten
Waarom je zou moeten meten
Wanneer ik nadenk over waarom we moeten meten, denk ik graag aan deze principes:
- Soms lijken dingen snel, maar dat zijn ze niet.
- Soms ziet het er goed uit, maar kan het beter.
- Soms lijken dingen traag, maar het is niet hun fout.
Browsers zijn sneller dan ooit, dus tegenwoordig kunnen veel dingen sneller dan we kunnen opmerken, maar dat betekent niet noodzakelijk dat ze inderdaad snel zijn . Daaronder gebeuren veel dingen waarvan we pas een duidelijk idee krijgen als we onder de motorkap kijken en zien hoe alles wordt geladen, hoeveel tijd elk onderdeel in beslag neemt en of het problemen veroorzaakt.
Door tools te gebruiken om elk onderdeel van onze app te meten, krijgen we een duidelijk beeld van hoe alles er echt uitziet, en wordt het gemakkelijker om de problemen te identificeren en het werk te plannen.
Hoe te meten
Er zijn tegenwoordig veel tools waarmee we een duidelijk idee krijgen van hoe onze app presteert en zelfs advies krijgen over hoe we eventuele problemen kunnen verbeteren. Van die alternatieven zijn degene die ik graag gebruik:
Vuurtoren (web, CLI, CI)
Google Lighthouse is tegenwoordig waarschijnlijk de beste tool om prestatie-audits uit te voeren voor onze app. Het zorgt voor het controleren van verschillende laadscenario's, hoe we omgaan met bronnen en geeft zelfs advies over het verbeteren van gevonden problemen, zelfs als het gaat om toegankelijkheid en SEO. Het beste is dat er meerdere manieren zijn om het uit te voeren (via de Google Web Dev-site, Chrome-extensie of zelfs Chrome Dev Tools) , en kan zelfs worden opgenomen in onze dagelijkse workflow als build-check met hun GitHub-integratie.
PageSpeed Insights
Als u een tijdje geleden een URL in PageSpeed Insights en Lighthouse had gemeten, kreeg u vaak sommige verschillende informatie, scores en advies, dus het is handig om beide te gebruiken en die informatie te consolideren. Momenteel is het een stuk dichterbij, maar het kan geen kwaad om beide te blijven controleren om er zeker van te zijn dat we alle gevonden problemen aanpakken.
Pingdom Website Snelheidstest
Audits uitvoeren met een externe tool zoals Pingdom is ook handig om extra gegevens te hebben die we kunnen vergelijken. Een van de leuke dingen aan deze in het bijzonder, is dat het ons in staat stelt om te testen hoe onze site laadt vanaf verschillende locaties, dus als we een wereldwijd publiek bereiken, hebben we een beter idee van hoe zij onze site zien. inhoud.
Chrome-ontwikkelaarstools
En als laatste, maar zeker niet de minste, is het het tabblad Prestaties van Chrome Dev Tools, dat een van onze beste vrienden zal zijn tijdens lokale ontwikkeling. Hiermee kunnen we alles opnemen wat er gebeurt met onze site terwijl deze wordt geladen, inclusief hoeveel code wordt geparseerd, in welke volgorde, of we onze CPU te veel laten werken en hoe lang alles duurt, wat ons een duidelijk beeld geeft. beeld van mogelijke knelpunten waar we aan moeten werken.
Prioriteer problemen en definieer de grotere impact
Onthoud een paar secties geleden waar we Het identificeren van het hoofddoel van uw app hebben besproken ? Nu we echte gegevens hebben en weten waar de pijnpunten zijn, is het gemakkelijker om een idee te krijgen van welke van die punten dat doel beïnvloeden. Met dat in gedachten is het belangrijk om prioriteiten te stellen en een lijst samen te stellen met dingen die een grotere impact zullen hebben, aangezien die overwinningen niet alleen ten goede komen aan gebruikers, maar ook aan alles wat we met onze app proberen te bereiken.
Aanvullende tips
Zoek uit hoe u prestaties in uw planning kunt passen (de goede oude 20%)
Zoals het vaak gebeurt met tests tijdens softwareontwikkeling, moeten we de manier waarop we over prestaties denken veranderen en het beschouwen als onderdeel van het proces in plaats van een extra. De beste manier om dit te doen en het deel uit te laten maken van de cultuur van onze teams, is proberen een manier te vinden om het in onze planning op te nemen. Een goed idee is om aan het begin van elke sprint 10-20% van onze tijd te besteden aan prestatieproblemen. Als we dit een voortdurende inspanning en onderdeel van ons wekelijkse werk maken, zal het niet alleen iets worden waar iedereen om geeft, maar uiteindelijk zullen er minder problemen zijn om aan te vallen en zullen de inspanningen niet zo belangrijk zijn.
Het goede aan prestatieverbeteringen is dat ze meestal gekoppeld zijn aan overwinningen voor het bedrijf, dus het is niet zo moeilijk om hier tijd aan te besteden als andere technische taken, zoals het refactoren van bepaalde code, het verbeteren van tooling en andere.
Voortijdige optimalisatie
Voortijdige optimalisatie is een van de grote problemen bij het nadenken over prestaties. Het is gemakkelijk om verstrikt te raken in te ver vooruit denken en proberen te komen met de beste manier om zaken aan te pakken die we misschien nooit zullen bereiken, dus het is een goed idee om je er in het begin niet al te veel zorgen over te maken, maar tegelijkertijd, houd een oogje in het zeil en probeer mogelijke problemen te identificeren die zich op een bepaald moment kunnen voordoen.
Alles en overal testen
Een van de grote fouten die we als ontwikkelaars meestal maken, is het testen van apps onder de beste omstandigheden (lokaal, op onze computer, met een snelle internetverbinding) . Maar we moeten ons afvragen, is dat de realiteit van onze gebruikers? Waarschijnlijk niet. Daarom is het een goed idee om bij het testen verschillende scenario's te emuleren (tragere CPU's of netwerkverbindingen) en kijk hoe onze app zich gedraagt. Het is belangrijk om te onthouden dat dingen er altijd geweldig uitzien onder de beste omstandigheden, maar alleen onder bepaalde beperkingen beginnen we de scheuren te zien 😔.
Gelukkig voor ons is het eenvoudig om die omstandigheden te simuleren en nu te testen, dankzij de Chrome Dev Tools:
Throttle-CPU
Throttle-netwerk
Speel wat met die instellingen en laad je app opnieuw, zodat je hem onder die gesimuleerde omstandigheden kunt zien.
Opmerking :Deze voorwaarden worden bewaard zolang Chrome Dev Tools is geopend. Zodra we het sluiten, gaan we terug naar de normale instellingen.
Verkrijg gegevens over uw gebruikers (apparaten, browsers) en kijk wat ze gebruiken en waar u aan moet denken
Met tools zoals Google Analytics is het gemakkelijker dan ooit om een duidelijk beeld te krijgen van niet alleen waar uw gebruikers zijn, maar ook wat ze gebruiken wanneer ze uw site bezoeken:browsers, apparaten, besturingssystemen en zelfs schermresoluties. Het hebben van die gegevens zal je superkracht zijn om erachter te komen waar je je op moet concentreren en om verspilde inspanningen te voorkomen.
Als u bijvoorbeeld gegevens verzamelt en beseft dat 100% van uw gebruikers naar uw site komen met de nieuwste versie van Chrome op Desktop en niemand andere browsers of mobiele apparaten gebruikt, kunt u veilig prioriteit geven aan problemen die hen aangaan en niet focus (zo veel) op uw mobiele versie of met ondersteuning van oude versies van andere browsers. Integendeel, als je die gegevens niet hebt, zou je talloze uren moeten besteden aan het oplossen van bugs die waarschijnlijk geen impact hebben op je gebruikers.
En nu:laten we aan het werk gaan!
En nu we de gegevens hebben, de ideeën en weten waar we ons op moeten concentreren, is het tijd om aan de slag te gaan!. Maar, hoe doen we dat? Nou, dat is voor het volgende artikel ✌️.
Oorspronkelijk gepubliceerd op mijn blog op xabadu.dev