De Prestaties van het Web, die uw Lighthouse Score 100 houden.

De kwaliteit van de ervaring van websites is essentieel voor het bereiken van de bedrijfsdoelstellingen van uw website en de tevredenheid van uw bezoekers.

Adobe Experience Manager (AEM) is geoptimaliseerd voor uitstekende ervaringen en optimale webprestaties. Met de Real Use Monitoring (RUM) De inzameling van verrichtingsgegevens, de informatie wordt onophoudelijk verzameld van gebiedsgebruik en biedt een manier om op echte metingen van gebruiksprestaties te herhalen zonder het moeten op de gegevens wachten CRuX om gevolgen van code en plaatsingsveranderingen te tonen. Het is gemeenschappelijk voor gebiedsgegevens die in RUM worden verzameld om van de laboratoriumresultaten af te wijken, aangezien het netwerk, de geo-plaats en de verwerkingscapaciteit voor echte apparaten veel meer divers zijn dan de gesimuleerde voorwaarden in een laboratorium.

De Google PageSpeed Insight-service is bewezen om een groot hulpmiddel van de laboratoriummeting te zijn. Hiermee kunt u de trage verslechtering van de prestatie- en ervaringsscore van uw website voorkomen.

Als u uw project begint met Boilerplate zoals in Zelfstudie voor ontwikkelaars, krijgt u een zeer stabiele Lighthoudingsscore op PageSpeed Insight voor zowel mobiel als bureaublad op 100. Op elke component van de aanstekersscore is er enige buffer voor de projectcode te verbruiken en nog steeds binnen de grenzen van een perfecte 100 vuurtoren score.

Testen van uw verzoeken om gegevens te wissen

Het blijkt moeilijk te zijn om uw Lighthoutenscore te verbeteren zodra deze laag is, maar het is niet moeilijk om deze te behouden 100 als u voortdurend test.

Wanneer u een trekkrachtverzoek (PR) op een project opent, worden test URLs in de beschrijving van uw project gebruikt om de Dienst van Inzichten PageSpeed tegen in werking te stellen. De AEM GitHub bot zal automatisch je PR mislukken als de score onder is 100 met een beetje buffer om enige volatiliteit van de resultaten te verklaren.

De resultaten zijn bedoeld voor de mobiele vuurtorenscore, omdat deze meestal moeilijker te bereiken zijn dan desktopcomputers.

Waarom Google PageSpeed Insights?

Veel teams en individuen gebruiken hun eigen configuraties voor het meten van Lighthouse-scores. Verschillende teams hebben hun eigen testapparatuur ontwikkeld en gebruiken hun eigen testtools met configuraties die zijn opgezet als onderdeel van hun doorlopende monitoring- en prestatierapportagepraktijken.

De prestaties van een website beïnvloeden zijn rangschikkingen in onderzoeksresultaten, die door de Kernwestraties in het crUX- rapport wordt weerspiegeld. Google heeft een goede greep op de relevante gemiddelde combinaties van apparaatinformatie (bijvoorbeeld schermgrootte) en de netwerkprestaties van deze apparaten. Maar uiteindelijk is SEO de ultieme arbiter van wat goede versus slechte webprestaties zijn. Aangezien de specifieke configuratie een bewegend doel is, zouden de prestatiespraktijken met de huidige gemiddelde apparaten en netwerkkenmerken globaal moeten worden gericht.

In plaats van een projectspecifieke configuratie voor Lighthouse-tests te gebruiken, gebruiken we de voortdurend bijgewerkte configuraties die worden gezien als onderdeel van de strategieën voor mobiele apparaten en desktops waarnaar wordt verwezen in de nieuwste versies van de Google PageSpeed Insights-API.

Hoewel er nog meer inzicht kan zijn dat sommige ontwikkelaars denken dat ze andere methoden kunnen gebruiken om Lighthouse-scores te meten, zodat ze een betekenisvol en vergelijkbaar prestatiegesprek over verschillende projecten kunnen voeren, moet er een manier zijn om prestaties universeel te meten. De standaard Dienst van het Inzicht PageSpeed is de meest gebiedende, meest algemeen aanvaarde laboratoriumtest wanneer het komt om uw prestaties te meten.

Het is echter belangrijk om te onthouden dat de aanbevelingen die u van PageSpeed Insights krijgt, niet noodzakelijkerwijs tot betere resultaten leiden, vooral hoe dichter u bij een vuurtoren-score van 100.

De Kernsteden van het Web (CWV) die door de ingebouwde gegevensinzameling RUM worden verzameld spelen een belangrijke rol in het bevestigen van resultaten. Bij kleine veranderingen is het echter door de variatie van de resultaten en het gebrek aan voldoende gegevenspunten (verkeer) gedurende een korte periode onpraktisch om in de meeste gevallen statistisch relevante resultaten te verkrijgen.

Driefasige lading (E-L-D)

Als u de lading die op een webpagina staat, in drie fasen verdeelt, is het relatief eenvoudig om een zuivere vuurtorsenscore te behalen en daarom een basislijn voor een geweldige klantervaring in te stellen.

De drie fasen van de laadbenadering verdelen de lading en de uitvoering van de pagina in drie fasen

Fase E: ager

In de enthousiast fase, alles wat geladen moest worden voor waar LCP die moet worden weergegeven, wordt geladen. In een project bestaat dit gewoonlijk uit de opmaak, de CSS-stijlen en JavaScript-bestanden.

In veel gevallen worden de LCP element is bevat in een blok (vaak gemaakt door automatische blokkering), waar het blok .js en .css moeten ook worden geladen.

De bloklader ontverbergt secties geleidelijk, wat betekent dat alle blokken van de eerste sectie voor moeten worden geladen LCP zichtbaar worden. Daarom kan het zinvol zijn om een kleinere sectie te hebben die zo weinig als nodig boven aan een pagina bevat.

Het is een goede regel van duim om de gezamenlijke lading vóór te houden LCP wordt weergegeven onder 100 kb, wat meestal resulteert in een LCP gebeurtenis sneller dan 1560 ms (LCP scoring bij 100 in PSI). Vooral op mobiele apparaten is de bandbreedte van het netwerk meestal beperkt, dus het wijzigen van de laadvolgorde vóór LCP minimaal tot geen effect heeft.

Een tweede oorsprong laden van of verbinding maken met vóór de LCP voorgekomen is sterk ontmoedigd aangezien het vestigen van een tweede verbinding (TLS, DNS, enz.) voegt een aanzienlijke vertraging toe aan de LCP.

Fase L: Lazy

In de lui fase, wordt het gedeelte van de lading geladen die totale het blokkeren tijd niet beïnvloedt (TBT) en uiteindelijk de eerste invoervertraging (FID).

Dit omvat onder andere het laden van blokken (JavaScript en CSS) en het laden van alle resterende afbeeldingen op basis van hun loading="lazy" en andere JavaScript-bibliotheken die niet worden geblokkeerd. De lazy fase is over het algemeen alles wat er in de verschillende blocks u gaat creëren om de projectbehoeften te dekken.

In deze fase zou het nog steeds raadzaam zijn dat het grootste deel van de lading afkomstig is van dezelfde oorsprong en door de eerste partij wordt gecontroleerd, zodat er zo nodig wijzigingen kunnen worden aangebracht om negatieve gevolgen voor TBT, TTI en FID.

Fase D: Vertraagd

In de vertraagd in de fase, worden de delen van de lading geladen die geen directe invloed op de ervaring hebben en/of niet door het project worden gecontroleerd en van derden afkomstig zijn. Denk aan marketing, toestemmingsbeheer, uitgebreide analyses, chat/interactiemodules enz. die vaak worden geïmplementeerd via oplossingen voor tagbeheer.

Het is belangrijk te begrijpen dat de start van deze fase aanzienlijk moet worden vertraagd om het effect op de algehele gebruikerservaring tot een minimum te beperken. De vertraagde fase moet ten minste drie seconden na de LCP-gebeurtenis duren om voldoende tijd te laten voor de rest van de ervaring om te worden opgelost.

De vertraagde fase wordt meestal binnen de delayed.js Dit fungeert als een eerste 'catch-all' voor scripts die zorgen voor TBT. In het ideale geval TBT de problemen worden verwijderd uit de manuscripten in kwestie of door hen buiten de belangrijkste draad (in een Webarbeider) te laden of enkel de daadwerkelijke het blokkeren tijd uit de code te verwijderen. Als de problemen zijn opgelost, kunnen deze bibliotheken eenvoudig worden toegevoegd aan de luie fase en eerder worden geladen.

In het ideale geval is er geen tijd voor blokkeren in uw scripts. Dit is soms moeilijk te bereiken met veelgebruikte technologie zoals tagbeheer of het maken van gereedschappen om grote JavaScript-bestanden te maken die worden geblokkeerd terwijl de browser deze parseert. Vanuit het oogpunt van prestaties is het aan te raden deze technieken te verwijderen, ervoor te zorgen dat de afzonderlijke scripts deze niet blokkeren en afzonderlijk laden als aparte kleinere bestanden.

Koptekst en voettekst

De koptekst en met name de voettekst van de pagina bevinden zich niet in het kritieke pad naar de LCPDaarom worden ze asynchroon in hun respectievelijke blokken geladen. Over het algemeen moeten bronnen die niet dezelfde levenscyclus delen (wat betekent dat ze op verschillende momenten worden bijgewerkt met ontwerpwijzigingen) in afzonderlijke documenten worden bewaard om de cacheketen tussen de oorsprong en de browser eenvoudiger en effectiever te maken. Als u deze bronnen apart houdt, neemt de hit-ratio van het cachegeheugen toe en wordt de invalidatie van het cachegeheugen en de complexiteit van het cachebeheer verminderd.

Lettertypen

Omdat weblettertypen vaak een bandbreedtebelasting vormen en vanaf een andere oorsprong worden geladen via een lettertypeservice zoals https://fonts.adobe.com of https://fonts.google.com, is het grotendeels onmogelijk om lettertypen te laden voordat de LCP, en daarom worden zij gewoonlijk toegevoegd aan de lazy-styles.css en worden geladen na de LCP wordt weergegeven.

LCP-blokken

Er zijn situaties waarin LCP -element is niet opgenomen in de markering die naar de client wordt verzonden. Dit gebeurt wanneer er sprake is van een indirecte bewerking of opzoekhandeling (bijvoorbeeld een service die wordt aangeroepen, een fragment dat wordt geladen of een opzoekopdracht die moet worden uitgevoerd in een .json) voor de LCP element.
In dergelijke situaties is het belangrijk dat het laden van de pagina wacht met het raden van LCP kandidaat (momenteel de eerste afbeelding op de pagina) totdat het eerste blok de noodzakelijke wijzigingen in het DOM heeft aangebracht.
Om te identificeren op welke blokken moet worden gewacht alvorens voor LCP laden, kunt u de blokken toevoegen die de LCP aan de LCP_BLOCKS array in scripts.js.

Bonus: Snelheid is groen

Het is niet alleen een goed idee om snel, klein en snel renderende websites te maken die uitzonderlijke ervaringen opleveren die beter zijn omgezet, maar ook een goede manier om de CO2-uitstoot te verminderen.