Klik hier om uw onlangs bekeken pagina's en meest bekeken pagina's weer te geven.
Verbergen

Mobiele analyse in PageSpeed Insights

PageSpeed Insights analyseert een pagina om te zien of deze voldoet aan onze aanbeveling om een pagina in een mobiel netwerk binnen één seconde weer te geven. Uit onderzoek is gebleken dat een vertraging van meer dan één seconde de gedachtestroom van de gebruiker onderbreekt en tot een slechte ervaring leidt. Het is onze bedoeling de aandacht van de gebruiker vast te houden op de pagina en een optimale ervaring te bieden, ongeacht het apparaat of het type netwerk.

Het valt niet mee om een pagina binnen één seconde weer te geven. Gelukkig hoeft de pagina niet in zijn geheel binnen dit tijdsbestek te worden weergegeven. We moeten de inhoud boven de vouw (ATF; Above The Fold) binnen één seconde leveren en weergeven, zodat de gebruiker zo snel mogelijk de interactie met de pagina kan aangaan. Terwijl de gebruiker de eerste pagina met inhoud interpreteert, kan vervolgens de rest van de pagina op progressieve wijze op de achtergrond worden geladen.

Aanpassingen voor mobiele netwerken met een lange wachttijd

Als u wilt voldoen aan het ATF-criterium van één seconde voor mobiele apparaten, wordt u geconfronteerd met unieke uitdagingen die zich niet voordoen bij andere netwerken. Gebruikers geven uw site mogelijk weer via verschillende 2G-, 3G- en 4G-netwerken. De netwerkwachttijden zijn aanzienlijk langer dan bij een bekabelde verbinding en verbruiken een aanmerkelijk deel van de toegestane 1000 ms voor het weergeven van de ATF-inhoud:

  • Roundtrip van 200-300 ms voor 3G-netwerken
  • Roundtrip van 50-100 ms voor 4G-netwerken

3G is wereldwijd het meest gebruikte netwerk en hoewel er over de hele wereld 4G-netwerken worden geïmplementeerd, mag u aannemen dat het merendeel van uw gebruikers uw site weergeeft via een 3G-netwerk. Daarom moeten we ervan uitgaan dat elk netwerkverzoek gemiddeld 200 milliseconden in beslag neemt.

Laten we dit in gedachten houden en terugwerken. Als we uitgaan van het typische verloop van de communicatie tussen een browser en een server, neemt alleen de netwerkoverhead al 600 ms van de beschikbare tijd in beslag: een DNS-zoekactie om de hostnaam (bijvoorbeeld google.nl) te herleiden naar een IP-adres, een netwerkroundtrip om de TCP-handshake uit te voeren en tot slot een volledige netwerkroundtrip om het HTTP-verzoek te versturen. Dit betekent dat we slechts 400 ms overhouden!

Weergave in minder dan één seconde

Als we de netwerkwachttijd van de beschikbare tijd aftrekken, houden we slechts 400 milliseconden over en moet er nog behoorlijk wat werk worden verricht. De server moet de reactie renderen, de applicatiecode aan de clientzijde moet worden uitgevoerd en de browser moet de inhoud indelen en renderen. Met dit in het achterhoofd zouden de volgende criteria ons moeten helpen binnen de beschikbare tijd te blijven:

(1) De server moet de reactie renderen (< 200 ms)
De serverreactietijd is de tijd die de server nodig heeft om de initiële HTML te retourneren. De netwerktransporttijd wordt niet meegerekend. Omdat we zo weinig tijd hebben, moet de reactietijd tot een minimum worden beperkt, idealiter binnen 200 milliseconden en liefst nog minder.
(2) Het aantal omleidingen moet zo beperkt mogelijk worden gehouden
Extra HTTP-omleidingen kunnen één of twee extra netwerkroundtrips toevoegen (twee als er een extra DNS-zoekactie is vereist), waardoor er honderden milliseconden extra wachttijd bij 3G-netwerken kan optreden. Daarom raden we webmasters met klem aan het aantal omleidingen te minimaliseren of idealiter te elimineren. Dit is met name belangrijk voor het HTML-document (vermijd zo veel mogelijk 'm dot'-omleidingen).
(3) Het aantal roundtrips voor de eerste weergave moet zo beperkt mogelijk worden gehouden

Door de manier waarop TCP de capaciteit van een verbinding schat (oftewel TCP Slow Start), kan een nieuwe TCP-verbinding niet meteen de volledig beschikbare bandbreedte tussen de client en de server gebruiken. Hierdoor kan de server maximaal 10 TCP-pakketten versturen tijdens de eerste roundtrip voor een nieuwe verbinding (ca. 14 Kb). Vervolgens moet er worden gewacht totdat deze gegevens door de client zijn ontvangen, voordat het overbelastingsbereik kan worden uitgebreid en er meer gegevens kunnen worden geleverd.

Vanwege dit TCP-gedrag is het belangrijk uw inhoud te optimaliseren om het aantal vereiste roundtrips voor de levering van de benodigde gegevens voor de eerste paginaweergave te minimaliseren. De ATF-inhoud is idealiter minder dan 14 Kb groot, zodat de browser al na één roundtrip een beeld van de pagina kan schetsen. Daarnaast is het belangrijk te weten dat de limiet van 10 pakketten (IW10) het gevolg is van een recente update van de TCP-standaard. Om van deze wijziging te kunnen profiteren, moet u zorgen dat uw server is bijgewerkt met de nieuwste versie. Anders geldt waarschijnlijk de limiet van 3 tot 4 pakketten.

(4) Vermijd blokkerend extern JavaScript en CSS in de ATF-inhoud

Voordat een browser een pagina kan weergeven voor de gebruiker, moet de pagina worden geparseerd. Als er tijdens het parseren een niet-asynchroon of blokkerend extern script wordt aangetroffen, wordt het parseren gestopt en moet de bron worden gedownload. Elke keer dat dit gebeurt, vindt er een netwerkroundtrip plaats, waardoor de tijd voor de eerste weergave van de pagina langer wordt.

Hierdoor moeten het JavaScript en de CSS die nodig zijn om het gebied boven de vouw weer te geven, inline worden geplaatst en moet het JavaScript of de CSS waarmee functionaliteit aan de pagina wordt toegevoegd, pas worden geladen nadat de ATF-inhoud is geladen.

(5) Reserveer tijd voor de browserlay-out en weergave (200 ms)
Het proces om de HTML en CSS te parseren en het uitvoeren van JavaScript vergt tijd en clientbronnen. Afhankelijk van de snelheid van het mobiele apparaat en de complexiteit van de pagina kan dit proces honderden milliseconden in beslag nemen. Wij adviseren 200 milliseconden te reserveren voor de browseroverhead.
(6) Optimaliseer de JavaScript-uitvoering en weergavetijd
Uitvoering van gecompliceerde scripts en inefficiënte code kan tientallen tot honderden milliseconden in beslag nemen. Gebruik de hulpprogramma's voor ontwikkelaars in de browser om uw code te profileren en optimaliseren. Bekijk onze interactieve cursus voor het gebruik van de hulpprogramma's voor ontwikkelaars van Chrome.

Veelgestelde vragen

Wat is de invloed van 4G-netwerken op de bovenstaande criteria voor mobiele netwerken?
Een van de belangrijke verbeteringen in 4G-netwerken is de kortere roundtripwachttijd. Dit helpt enorm om de totale netwerkoverheadtijd te reduceren, die voor 3G-netwerken momenteel meer dan 50% van de beschikbare tijd van één seconde bedraagt. 3G is wereldwijd het meestgebruikte type netwerk en dit zal ook nog wel enkele jaren zo blijven. U moet de pagina's dus optimaliseren voor 3G-gebruikers.
Ik gebruik een JavaScript-bibliotheek, zoals JQuery. Nog advies?
Veel JavaScript-bibliotheken, zoals JQuery, worden gebruikt om de pagina uit te breiden met extra interactiviteit, animaties en andere effecten. Veel van deze gedragingen kunnen veilig worden toegevoegd nadat de ATF-inhoud wordt weergegeven. Onderzoek of u het uitvoeren en laden van dergelijk JavaScript kunt verplaatsen tot na het laden van de pagina.
Ik gebruik een JavaScript-framework om de pagina te bouwen. Nog advies?
Als de inhoud van de pagina is opgebouwd met JavaScript aan clientzijde, moet u kijken of u de relevante JavaScript-modules inline kunt plaatsen om extra netwerkcommunicatie te vermijden. Als u gebruikmaakt van weergave aan serverzijde, kunt u de prestaties met betrekking tot het laden van de eerste pagina aanzienlijk verbeteren. Geef JavaScript-sjablonen op de server weer, plaats de resultaten inline in het HTML-document en gebruik sjablonen aan clientzijde zodra de app is geladen.
Hoe kunnen SPDY en HTTP 2.0 helpen?
SPDY en HTTP 2.0 proberen beide de wachttijd voor het laden van pagina's te reduceren door efficiënter gebruik te maken van de onderliggende TCP-verbinding (multiplexing, headercompressie, prioriteitsaanduiding). Daarnaast kunt u met serverpush de prestaties nog verder verbeteren door de extra netwerkwachttijd te elimineren. We adviseren u SPDY-ondersteuning aan uw servers toe te voegen en over te stappen op HTTP 2.0 zodra de standaard klaar is.
Hoe identificeer ik de essentiële CSS op mijn pagina?
Open in 'Hulpprogramma's voor ontwikkelaars' in Chrome het venster 'Audits' en voer een rapport voor een webpaginaprestaties uit. Zoek in het gegenereerde rapport naar 'Remove unused CSS rules' (Ongebruikte CSS-regels verwijderen). Of gebruik een tool of script van derden om te bepalen welke CSS-selecties op elke pagina zijn toegepast.
Kunnen deze praktische tips worden geautomatiseerd?
Jazeker. Er zijn verschillende commerciële en open-source WPO-producten (Web Performance Optimization) die u kunnen helpen aan alle of bepaalde bovenstaande criteria te voldoen. Bekijk de PageSpeed-optimalisatietools voor open-source oplossingen.
Hoe configureer ik mijn server om aan dit criterium te voldoen?
Zorg er op de eerste plaats voor dat er een actuele versie van het besturingssysteem op uw server wordt uitgevoerd. Als u wilt profiteren van het grotere initiële TCP-overbelastingsbereik (IW10), heeft u Linux kernel 2.6.39+ nodig. Voor andere besturingssystemen raadpleegt u de documentatie.
Als u de reactietijd van de server wilt optimaliseren, instrumenteert u uw code of gebruikt u een oplossing voor applicatiebewaking om uw knelpunten te identificeren, bijvoorbeeld scripting runtime, databaseaanroepen, RPC-verzoeken, weergave, enzovoort. Het doel is de HTML-reactie binnen 200 milliseconden weer te geven.
Hoe zit het met CSP (Content Security Policy, inhoudsbeveiligingsbeleid)?
Als u CSP gebruikt, moet u uw standaardbeleid mogelijk bijwerken.
Ten eerste moeten er waar mogelijk geen inline CSS-kenmerken voor HTML-elementen worden gebruikt (bijvoorbeeld &lt p style=...&gt), aangezien deze kenmerken vaak leiden tot overbodige dubbele codes en met CSP standaard worden geblokkeerd (uitgeschakeld via 'unsafe inline' voor 'style-src'). Als CSP is ingeschakeld, worden alle inline scripttags standaard geblokkeerd. Als u inline JavaScript gebruikt, moet u het CSP-beleid bijwerken om scripthashes of nonces te kunnen gebruiken of gebruikt u 'unsafe-inline' om ervoor te zorgen dat alle inline scripts worden uitgevoerd. Als u werkt met inline stijlen, moet u het CSP-beleid bijwerken om stijlhashes of nonces te gebruiken of gebruik 'unsafe-inline' om ervoor te zorgen dat alle inline stijlblokken worden verwerkt.

Heeft u meer vragen? In onze discussiegroep op pagespeed-insights-discuss kunt u vragen stellen en feedback geven.