Wat is het kritieke weergavepad?

Het optimaliseren van deze evenementen resulteert in aanzienlijk snellere webpagina’s.
tijdlijn en middelen Het kritieke weergavepad kan iets heel moois doen …

Het geeft u de mogelijkheid om een ​​grote webpagina met veel bronnen sneller te laden dan een kleine webpagina met weinig bronnen. Dat vind ik leuk.

Aangezien de meeste webpagina’s veel verschillende componenten bevatten, is het niet altijd mogelijk om alles gewoon te verwijderen om een ​​pagina sneller te laden. Als je je ooit hebt afgevraagd: “Wat kan ik nog meer doen om mijn pagina’s snel te maken?” of “Hoe verwacht Google dat pagina’s in één seconde worden geladen?” dan is dit concept iets voor jou.
Het optimaliseren van het kritieke weergavepad
webpagina laden

Laten we voor de duidelijkheid een paar dingen definiëren:

kritisch - absoluut noodzakelijk
render - display of show (in ons geval worden onze webpagina's "gerenderd" wanneer ze door een gebruiker kunnen worden gezien)
pad - de reeks gebeurtenissen die ertoe leiden dat onze webpagina in een browser wordt weergegeven
beginweergave - ook bekend als "boven de vouw", de beginweergave is het gedeelte van een webpagina dat zichtbaar is voor een gebruiker voordat deze schuift

Met andere woorden, het weergavepad is gewoon een reeks gebeurtenissen die plaatsvinden om uw webpagina in een browser te laten verschijnen.

Aangezien vrijwel elke website op internet onnodige stappen neemt om te renderen, is dit de plek waar echt zinvolle en merkbare optimalisaties kunnen plaatsvinden.

Het optimaliseren van het kritieke weergavepad kan seconden duren voordat uw pagina is geladen. Het is echt de snelste weg naar snellere webpagina’s.
Het pad
html, css en javascript

Om een ​​webpagina weer te geven, moet een browser alle bronnen ophalen die door de webpagina worden opgeroepen. Een eenvoudig voorbeeld is een webpagina met één afbeelding, één css-bestand en één javascript-bestand.

Laten we eens kijken naar het pad dat deze pagina neemt voordat deze wordt weergegeven …

browser downloadt het html-bestand
browser leest de html en ziet dat er één css-bestand, één javascript-bestand en één afbeelding zijn
browser begint met het downloaden van de afbeelding
browser besluit dat het de webpagina niet kan weergeven zonder eerst de css en javascript te krijgen
browser downloadt het CSS-bestand en leest het om ervoor te zorgen dat er niets anders wordt aangeroepen
browser besluit dat het de webpagina nog steeds niet kan weergeven totdat het javascript heeft
browser downloadt het javascript-bestand en leest het om ervoor te zorgen dat er niets anders wordt aangeroepen
Browser besluit nu dat deze de webpagina kan weergeven

Het bovenstaande pad is voor een zeer eenvoudige webpagina, geef nu aan hoe uw pad eruit moet zien.

Je hebt waarschijnlijk sociale knoppen, verschillende CSS-bestanden, verschillende javascript-bestanden, veel afbeeldingen, widgets en misschien ook audio of video.
Dit betekent dat je renderpad waarschijnlijk een grote puinhoop is
rommelige set bestanden die naar elkaar wijzen

De meeste websites hebben absoluut vreselijke renderpaden omdat ze zoveel dingen aanroepen dat de browser moet laden voordat de webpagina kan worden weergegeven.

Dit is uw voordeel ten opzichte van anderen. Als u uw pagina’s sneller maakt dan uw concurrenten, gaat u bezoekers blij maken (Google vindt het leuk als u dat doet).
Het renderen
Pagina wordt langzaam geladen

Er zijn bepaalde soorten bronnen die onze webpagina’s noemen en die de weergave van onze webpagina’s daadwerkelijk blokkeren.

De twee meest voorkomende zijn de CSS-bestanden en de javascript-bestanden.

Het maakt niet uit hoeveel van deze je hebt, de browser moet elk van deze bestanden downloaden en parseren voordat het iets aan de gebruiker kan tonen. Laten we eens kijken naar een al te vaak scenario …

WordPress-blogs gebruiken thema’s. Bijna elk WordPress-thema heeft verschillende CSS-bestanden.

Velen hebben zes of zeven css-bestanden (dit is de reden waarom de paginasnelheid richtlijn “externe CSS-bestanden combineren” bestaat). Al die CSS kan in slechts één bestand zijn, maar wanneer u uw thema toevoegt, is het feit dat het verschillende CSS-bestanden heeft. Dus voordat er zelfs maar één letter van uw blog kan worden weergegeven, moet de browser elk van die bestanden laden en ontleden (zes of zeven retourreizen naar een server om te beginnen). Dit staat bekend als het blokkeren van css.

De bezoeker van uw pagina staart naar een leeg wit scherm terwijl dit gebeurt omdat er niets zal verschijnen totdat deze “kritieke” stappen zijn voltooid.
middelen om één webpagina te laden

Maar zelfs nadat je CSS is gedownload, kan je blog nog niet worden weergegeven omdat het ook bekend is dat WordPress-thema’s verschillende JavaScript-bestanden hebben. De pagina wordt nog steeds niet weergegeven omdat deze in veel gevallen JavaScript-bestanden ontvangt. Dit staat bekend als het blokkeren van JavaScript.

Een typische weergave van een WordPress-blogpagina kan dus twintig rondreizen vereisen om alleen de belangrijkste CSS- en JavaScript-bestanden te krijgen. Maar wacht, nu heb je ook sociale knoppen of widgets … uh oh, voor elk van die verschillende CSS- en JavaScript-bronnen zijn ook nodig.

Je laadt misschien tientallen dingen voordat je bericht aan een gebruiker wordt getoond. Ouch. (om te weten te komen wat uw pagina laadt, gebruikt u onze tool voor paginaverzoeken)