Invoering
Een snelle webapp is een succesvolle webapp. Uw taak als ontwikkelaar is pas klaar als u zowel de werkelijke als de waargenomen prestaties van uw app hebt geoptimaliseerd. Het is niet alleen simpelweg het juiste om te doen om ervoor te zorgen dat uw gebruikers een uitstekende ervaring hebben, maar er zijn ook zeer praktische en belangrijke zakelijke redenen om te optimaliseren. Amazon heeft een omzetdaling van 1% gemeten voor elke 100 ms websitelatentie, en Google heeft een omzetdaling van 20% gemeten voor elke vertraging van 0,5 seconde ( citaat . Dat zijn echte cijfers met echte gevolgen voor uw bedrijf en webapp.
Websnelheid is zo belangrijk dat Google er zelfs alles aan doet om het internet sneller te maken . Als je nog een reden nodig hebt om de prestaties van je app te optimaliseren, heeft Google aangekondigd dat de paginasnelheid is toegevoegd aan hun rankingalgoritme .
Er zijn veel gepubliceerde best practices voor het optimaliseren van de prestaties van uw web-app, waaronder twee geweldige boeken ( High Performance Web Sites en Even Faster Web Sites ). Technieken op de server (implementeer de juiste cachecontroleheaders) en op de client (zorg voor beeldbreedte- en hoogte-attributen) worden gecombineerd tot een end-to-end-strategie voor het optimaliseren van de prestaties. Met zoveel tips en trucs is het soms moeilijk in te schatten hoe ze allemaal aansluiten bij het echte leven en uw echte web-app.
Gelukkig biedt Chrome DevTools (inbegrepen in elk exemplaar van Chrome) een uitstekende tool die uw webapp inspecteert en aangepaste aanbevelingen doet om de prestaties te verbeteren en de latentie te verminderen. Dit artikel gaat in op het Auditspaneel, dat qua reikwijdte vergelijkbaar is met de zeer populaire YSlow- tool, en hoe u het kunt gebruiken om uw website te versnellen, de latentie te verminderen en de gebruikerstevredenheid te vergroten.
Let op: de tool Audits Panel is momenteel alleen beschikbaar in Chrome, maar we verwachten dat andere WebKit-browsers deze uiteindelijk zullen integreren.
Aan de slag
Om te illustreren hoe het Auditspanel prestatieverbeteringen in webapps kan aanbevelen, richten we de tool op onze eigen www.html5rocks.com . We zullen het Auditspaneel gebruiken om onze site nog sneller te maken.
Het starten van DevTools is net zo eenvoudig als het gebruik van het Chrome-pictogram (rechtsboven in het Chrome-venster) en het selecteren van Tools > Developer Tools.
Lees de officiële documentatie voor meer informatie over hoe u aan de slag kunt gaan met DevTools.
Het Auditspaneel bevindt zich in het knoppenpaneel met de hoofdtools. U zult merken dat het Auditspaneel, eenmaal geselecteerd, de analyse van uw webapp nog niet heeft doorlopen. Het uitvoeren van alle heuristieken kan traag zijn, vooral voor een grote webapp zoals Gmail, dus de tool is standaard uitgeschakeld.
Laten we erin duiken door op de knop Uitvoeren te klikken, waarmee de webapp opnieuw wordt geladen terwijl de prestatieheuristieken zijn ingeschakeld. Nadat de pagina opnieuw is geladen, ziet u een lijst met aanbevelingen die lijkt op de onderstaande schermafbeelding.
U zult merken dat het Auditpaneel de suggesties classificeert op basis van ernst, waarbij de meest ernstige suggesties zijn gemarkeerd met een rode stip en de suggesties met gemiddelde ernst zijn gemarkeerd met een gele stip. Met deze kleurcodering kunt u de suggesties prioriteren, waarbij u zich eerst op de belangrijkste (en grootste winst) concentreert.
Het getal tussen haakjes, volgend op de suggestie, geeft aan hoeveel exemplaren de Audit Tool heeft gedetecteerd. Er waren bijvoorbeeld twaalf gevallen van 'Gebruik browsercaching'. Dit geeft u een idee van hoe vaak de suggestie kan worden toegepast.
Snelheidsstrategieën
Zoals eerder vermeld, zijn er tal van bekende en zwaar geteste strategieën voor het optimaliseren van de prestaties van webapps. We zullen ze in dit artikel niet allemaal uitgebreid bespreken, maar je kunt gemakkelijk meer informatie en details vinden. Handige bronnen voor meer informatie over de specifieke kenmerken van webapp-optimalisatie zijn onder meer de tutorials Laten we het web sneller maken en De latentie van hoge schaalbaarheid is overal en kost u omzet .
Het Auditpanel groepeert zijn suggesties in twee categorieën: Netwerkgebruik en Webpaginaprestaties.
Volgens het Auditpanel moeten we om het netwerkgebruik te verbeteren:
- Maak gebruik van browsercaching
- Maak gebruik van proxy-caching
- minimaliseer de cookiegrootte
- serveer statische inhoud vanuit een cookieloos domein
- geef de afmetingen van de afbeelding op
Om de prestaties van webpagina's te verbeteren, moeten we:
- optimaliseer de volgorde van stijlen en scripts
- verwijder ongebruikte CSS-regels
Laten we eens kijken naar een van de strategieën waarop we ons kunnen concentreren om de prestaties van htmlrocks.com te verbeteren.
Maak gebruik van browsercaching
Laten we bijvoorbeeld eerst eens kijken naar de aanbeveling om browsercaching te benutten. Wat betekent dit specifiek? Als we de optie in de gebruikersinterface openen, krijgen we de volgende details te zien:
- Voor de volgende bronnen ontbreekt een cachevervaldatum. Bronnen die geen vervaldatum specificeren, worden mogelijk niet door browsers in de cache opgeslagen.
- De volgende cachebare bronnen hebben een korte levensduur.
- De volgende bronnen kunnen expliciet niet in de cache worden opgeslagen. Overweeg om ze indien mogelijk cachebaar te maken.
Caching van bronnen is een uitstekende manier om het netwerkgebruik te verbeteren, wat leidt tot lagere bandbreedterekeningen voor de ontwikkelaar en snellere responstijden voor de gebruiker. Helaas vertelt de tool je niet precies wat je moet doen, dus we moeten wat dieper op de aanbevelingen ingaan en onze kennis van prestatie-optimalisaties van web-apps gebruiken om deze suggesties toe te passen.
Caching
Zonder in HTTP-caching te duiken, kunnen we zeker enkele basisprincipes behandelen. Het HTTP-protocol bevat caching-instructies , waardoor de server en de client de hoeveelheid gegevens die via de draad moet worden overgedragen, kunnen verminderen. De server kan de client bijvoorbeeld vertellen de bron voor een bepaalde tijd lokaal op te slaan, waardoor het niet meer nodig is om de bron opnieuw op te vragen. De client kan ook vragen of de serverbron nieuwer is dan de bron die lokaal is opgeslagen. Idealiter zou de server, als een bron statisch is, de client moeten vertellen de bron lokaal op te slaan en te voorkomen dat de server in de toekomst om de bron wordt gevraagd. Er zijn, zoals u zich kunt voorstellen, ongelooflijk veel details over HTTP-caching, maar het algemene thema is "de hoeveelheid gegevens die over de draad worden verzonden verminderen door bronnen lokaal op de client op te slaan".
Niet-cachebare bronnen repareren
Laten we één aanbeveling diepgaand bekijken en leren hoe u de Audit-aanbeveling kunt verbinden met andere tools binnen DevTools. Laten we specifiek kijken hoe we dit kunnen oplossen: "De volgende bronnen kunnen expliciet niet in de cache worden opgeslagen."
Omdat caching via het HTTP-protocol wordt uitgevoerd, moeten we kijken naar het HTTP-verzoek en -antwoord voor de bron http://www.html5rocks.com/. Klik eenvoudig op de bron om de oorspronkelijke verzoek- en antwoordkoppen en details te bekijken.
Vervolgens wordt u naar het paneel Netwerk, Bronnen of Bronnen geleid (afhankelijk van het type bron waarop u hebt geklikt) met meer informatie. In dit geval worden we naar het netwerkpaneel geleid.
We proberen te bevestigen dat de server de klant heeft verteld "de startpagina van html5rocks.com niet in de cache op te slaan". Om dit te doen, klikken we op de bron om naar de Response Headers te kijken, aangezien dit de headers en instructies zijn die door de server worden verzonden.
Cache-Control header.En ja hoor, de server stuurde de header "Cache-Control: no-cache" naar de client. Dit vertelt de klant, zoals u zich kunt voorstellen, altijd om de bron te vragen en deze niet lokaal in de cache op te slaan. Concreet luidt de HTTP-specificatie voor "no-cache" :
"Als de no-cache-richtlijn geen veldnaam specificeert, mag een cache het antwoord NIET gebruiken om aan een volgend verzoek te voldoen zonder succesvolle hervalidatie bij de oorspronkelijke server. Hierdoor kan een oorspronkelijke server caching voorkomen, zelfs door caches die zijn geconfigureerd om verouderde antwoorden op klantverzoeken te retourneren."
Dit is precies de reden waarom het Auditpanel aanbeveelt om caching in te schakelen, omdat de server en de client anders potentieel redundante informatie verzenden.
Nu we de hoofdoorzaak van de Audit-suggestie hebben bevestigd, hoe kunnen we dit oplossen? In dit geval omvat de oplossing configuratie of code aan de serverzijde. Afhankelijk van uw configuratie kunt u caching inschakelen via de configuratie van uw webserver of via configuraties in uw webapp-framework. Concreet moet u een Expires-header en een Cache-Control: private met een max-age-parameter opnemen voor elke bron die u in de cache wilt opslaan.
Suggesties zijn precies dat: suggesties
Houd er rekening mee dat het Auditpanel verbeteringen aanbeveelt op basis van generieke heuristieken. Het past best practices toe die u in de loop der jaren heeft geleerd, op uw specifieke web-app. Meestal zijn deze aanbevelingen terecht en moeten ze ter harte worden genomen.
Er zijn echter enkele gevallen waarin de aanbeveling correct kan zijn, maar niet daadwerkelijk tot enige verbetering leidt. Als uw pagina bijvoorbeeld slechts één grote afbeelding heeft, raadt het Auditpaneel aan om breedte- en hoogtekenmerken toe te voegen aan de <img> -tag (zodat de weergave-engine de afmetingen van de afbeelding kent zonder de afbeelding te hoeven downloaden en inspecteren). Hoewel dit over het algemeen een goed advies is, zal het niet veel helpen als de afbeelding het enige element op de pagina is.
Vergeet niet deze suggesties toe te passen nadat u ze begrijpt. En vergeet niet de prestaties voor en na de veranderingen te meten, om er zeker van te zijn dat er daadwerkelijk sprake is van verbetering.
Samenvatting
Het Auditspaneel is een uitstekende en gebruiksvriendelijke tool die u snel laat zien hoe u de prestaties van uw webapp kunt optimaliseren. Snelheid is een cruciaal attribuut voor webapps, omdat veel bedrijven directe correlaties hebben gevonden tussen prestaties en omzet of activiteit. Het optimaliseren van de prestaties van uw app is niet alleen het juiste voor uw gebruikers, maar ook voor het bedrijfsresultaat.