De ontwikkeling van WordPress 6.2 introduceerde verbeteringen in de manier waarop het kernontwikkelingsteam werkt, wat resulteerde in een constante focus op prestaties bij elke ontwikkelingsstap. Deze nieuwe processen vangen problemen op op het moment dat wijzigingen worden doorgevoerd, waardoor ze de definitieve versie niet halen.

De twee verbeteringen die verantwoordelijk zijn voor deze wijziging zijn:

Nieuwe prestaties leiden tot geautomatiseerde benchmarking

Dankzij deze twee verbeteringen kon het WordPress-team de prestaties onderdeel maken van de ontwikkeling van elk onderdeel van WordPress, waardoor het in wezen werd toegevoegd aan hun ontwikkelings-DNA.

Lessen uit WordPress 6.1

De vorige versie van WordPress, versie 6.1, werd gekenmerkt door een algemene afname van de prestaties, wat WordPress prestatieregressie noemt.

Een prestatieregressie is wanneer een verbetering leidt tot een afname van de prestaties.

Wat ze ontdekten, is dat hoewel ze de grootste oorzaak van prestatieregressie hebben verholpen en verschillende prestatieverbeteringen hebben aangebracht, de algehele prestaties van de site nog steeds naar beneden werden gehaald door de prestatieverslechterende veranderingen.

WordPress legde de les uit die ze hadden geleerd van versie 6.1:

“Ondanks andere prestatieverbeteringen die deze releases hebben gehaald, hebben regressies de verbeteringen uiteindelijk teniet gedaan.”

… Hoe meer regressie er is, hoe minder impact de rest van de algehele prestatieverbeteringen zullen hebben.”

Prestatiemanager WordPress-ontwikkeling

Het ontwikkelingsproces van WordPress 6.2 werd afgerond met de coördinatie van een nieuwe lead performance rol.

De performance manager initieert geen veranderingen en verbeteringen. Dat was de taak van het ontwikkelteam.

De prestatieleider coördineerde gewoon tussen teams.

Elk van de teams is verantwoordelijk voor de prestatiewinsten van hun projecten.

De persoon die verantwoordelijk was voor de actie legde uit hoe het werkte:

“Hierdoor kon ik nauw samenwerken met andere bijdragers, deze ondersteunen en onze benaderingen voor prestatiemeting met hen coördineren.

… de prestatiewinsten in deze release zijn het resultaat van het uitstekende werk van verschillende medewerkers om zwakke punten in de prestaties te identificeren.

De introductie van de Performance Lead-rol … zorgde gewoon voor een betere weergave van de prestaties naast andere leden van het releaseteam.

Geautomatiseerde WordPress-benchmarking

WordPress merkte op dat prestatieregressies onopgemerkt bleven omdat niet alle wijzigingen handmatig werden gecontroleerd op impact op de algemene release.

Om de tekortkoming aan te pakken dat niet alle kernwijzigingen handmatig kunnen worden getest, heeft WordPress geautomatiseerde prestatiebenchmarking voor alle wijzigingen geïntroduceerd.

Geautomatiseerde prestatiebenchmarking meet de impact van elke wijziging om verborgen prestatieknelpunten te detecteren voordat ze de definitieve releases bereiken.

WordPress beschrijft deze workflowwijziging:

“Verschillende bijdragers hebben samengewerkt om een ​​CI-workflow te introduceren die geautomatiseerde prestaties meet in de kern van WordPress…

Met deze CI-workflow worden nu de kernprestatiestatistieken van WordPress voor elke commit gelogd en zijn ze beschikbaar in dit dashboard.

Dit stelt ons in staat om gemakkelijk een mogelijke achteruitgang te detecteren waar deze eerder onopgemerkt zou zijn gebleven.”

De WordPress 6.1-update introduceerde prestatieregressies in Gutenberg, problemen die vroegtijdig zouden zijn opgemerkt met geautomatiseerd testen.

Geautomatiseerde prestatietests vinden plaats bij elke belangrijke commit op GitHub om te meten hoe WordPress presteert op blogs en klassieke thema’s.

De tests verzamelen ook servertijdstatistieken met behulp van de nieuwste versie van PHP.

Lees hier meer over geautomatiseerde prestatiebewaking: Geautomatiseerde prestatiebewaking in WordPress Core.

WordPress-bijdragers werkten samen

WordPress-bijdragers werkten om gebieden te identificeren die verbeterd moesten worden met een hernieuwde focus op prestaties.

De prestatieprofilering van de WordPress-kernserver is gedaan met behulp van Xdebug, XHProf en Blackfire (SaaS) open source-tools.

Het benchmarken van de WordPress-kern was minder eenvoudig omdat de ontwikkelgroepen verschillende tools gebruikten.

We standaardiseren momenteel de tools die worden gebruikt om prestaties te meten, zodat alle teams hetzelfde meten met dezelfde set tools.

Feit: WordPress 6.2 werkt beter

Het resultaat van geautomatiseerde prestatiebenchmarking en prestatiecoördinatie tussen ontwikkelingsteams is een substantiële verbetering van de prestatiestatistieken.

WordPress gedeeld:

“Op basis van laboratoriumbenchmarks laadt WordPress 6.2 in totaal 14-18% sneller voor blogthema’s en 2-5% sneller in totaal voor klassieke thema’s (zoals gemeten door inhoud groter te schilderen / LCP).

Met name de serverprestaties (zoals gemeten door Time to First Byte / TTFB) ervaren een aanzienlijke toename van 17-23% voor blogthema’s en 3-5% voor klassieke thema’s, wat direct bijdraagt ​​aan de tijd van algemene belasting

Prestatietesten vinden niet alleen plaats in de belangrijkste commit-fase, maar er wordt ook benchmarking gedaan voor alle WordPress-releasekandidaten.

WordPress beschrijft dit proces:

“Met name op dit moment wordt aanbevolen om de productie-ZIP-versie van de WordPress-kern te gebruiken (bijvoorbeeld een bepaalde bèta- of RC-versie) in plaats van deze te meten in de kern van de WordPress-ontwikkelomgeving.

De opdracht “benchmark-web-vitals” die in de vorige sectie werd genoemd, is perfect voor deze use-case omdat het hoogwaardige prestatiestatistieken biedt die zowel server- als clientprestaties vastleggen.

De resulterende gegevens kunnen worden vergeleken met dezelfde statistieken van bijvoorbeeld de vorige stabiele release, om een ​​idee te krijgen van hoe de kernprestaties van WordPress zijn veranderd (hopelijk verbeterd!) in de nieuwe versie.”

WordPress draaide de prestaties om

WordPress heeft de afgelopen jaren hard gewerkt om prestatieverbeteringen te integreren in de ontwikkelingsworkflow.

Al vroeg voerde het prestatieteam verbeteringen door, zoals het verminderen van overbodige of onnodige JavaScript-lading voor elke pagina en het toevoegen van zaken als het lui laden van afbeeldingen.

Maar nu bouwt het prestatieteam prestatiebenchmarking rechtstreeks in de ontwikkelingsfase van elke verbeterde component op GitHub-commitniveau en gebruikt het geautomatiseerde prestatiebenchmarking om verbeteringen op te schalen.

In wezen heeft WordPress met succes prestaties toegevoegd aan het DNA van het ontwikkelingsproces.

Dit is een van de meest ingrijpende veranderingen in de manier waarop WordPress wordt ontwikkeld en een teken dat WordPress op weg is om de achterstand op andere contentmanagementsystemen in te halen.

WordPress kan eindelijk terugkeren naar het prestatiespel.

Lees de volledige WordPress-aankondiging, waarin de voortgang wordt beschreven en links naar de tools die worden gebruikt om de prestaties te benchmarken.

De voordelen van het stellen van prioriteiten en het meten van prestaties in WordPress 6.2

Uitgelichte afbeelding door Shutterstock/Asier Romero

Source link