Veiktspējas ieskatu atklāšana: React eksperimentālā _tracingMarker datu vākšana un apkopošana

Nepārtraukti mainīgajā tīmekļa izstrādes ainavā veiktspēja nav tikai funkcija; tas ir būtisks atšķirības faktors. React lietojumprogrammām veiktspējas izpratne un optimizācija ir vissvarīgākā, lai nodrošinātu nevainojamu un saistošu lietotāja pieredzi. Lai gan React jau sen piedāvā izstrādātāju rīkus veiktspējas analīzei, nesenie eksperimentālie uzlabojumi sola sniegt vēl dziļāku ieskatu. Šis raksts iedziļinās aizraujošajā, lai arī eksperimentālajā, _tracingMarker datu vākšanas un veiktspējas datu apkopošanas jomā React ietvaros, piedāvājot globālu perspektīvu par tās potenciālu un pielietojumu.

Veiktspējas nepieciešamība globalizētā digitālajā pasaulē

Izstrādātājiem, kas mērķē uz globālu auditoriju, lietojumprogrammu veiktspējas nozīmi nevar novērtēt par zemu. Lietotāji dažādos kontinentos ar atšķirīgu interneta ātrumu, ierīču iespējām un tīkla apstākļiem sagaida, ka viņu lietojumprogrammas ielādēsies ātri un reaģēs nekavējoties. Lēna lietojumprogramma var izraisīt lietotāju neapmierinātību, augstu atteikuma gadījumu skaitu un galu galā – biznesa iespēju zaudēšanu. Tāpēc ir būtiskas stabilas veiktspējas uzraudzības un optimizācijas stratēģijas. React kā viena no populārākajām JavaScript bibliotēkām lietotāja saskarņu veidošanai spēlē izšķirošu lomu, ļaujot izstrādātājiem radīt veiktspējīgas lietojumprogrammas. Eksperimentālu funkciju, piemēram, _tracingMarker, ieviešana liecina par apņemšanos šīs iespējas vēl vairāk uzlabot.

Izpratne par React veiktspējas uzraudzības rīkiem: īss pārskats

Pirms iedziļināties _tracingMarker specifikā, ir lietderīgi īsi aplūkot React esošās veiktspējas uzraudzības iespējas. React Developer Tools, pārlūkprogrammas paplašinājums Chrome un Firefox, ir bijis noderīgs, palīdzot izstrādātājiem profilēt komponentu renderēšanu, identificēt vājās vietas un izprast komponentu dzīves ciklus. Tādas funkcijas kā Profiler cilne ļauj izstrādātājiem ierakstīt mijiedarbības, analizēt renderēšanas laikus un vizualizēt izmaiņu (commit) ilgumus. Tomēr šie rīki bieži sniedz momentuzņēmumus un prasa manuālu darbību, lai savāktu datus konkrētiem scenārijiem. Ir kļuvusi acīmredzama nepieciešamība pēc automatizētākiem, detalizētākiem un apkopojamiem veiktspējas datiem.

Iepazīstinām ar eksperimentālo _tracingMarker

_tracingMarker ir eksperimentāla funkcija React ietvaros, kuras mērķis ir nodrošināt standartizētāku un programmatisku veidu, kā instrumentēt un vākt veiktspējas datus. Tās pamatkoncepcija ir saistīta ar konkrētu punktu atzīmēšanu React lietojumprogrammas izpildes plūsmā. Šos marķierus pēc tam var izmantot, lai mērītu dažādu operāciju ilgumu, izsekotu notikumu laiku un galu galā apkopotu šos datus visaptverošai veiktspējas analīzei.

Ko _tracingMarker nodrošina?

• Detalizēta instrumentācija: Izstrādātāji var izvietot marķierus ap konkrētiem koda segmentiem, komponentu dzīves cikla metodēm vai pielāgotu loģiku, lai precīzi izmērītu to izpildes laiku.
• Notikumu laika noteikšana: Tas ļauj noteikt atsevišķu notikumu laiku React ekosistēmā, piemēram, stāvokļa atjauninājumus, komponentu izraisītus tīkla pieprasījumus vai sarežģītu aprēķinu pabeigšanu.
• Automatizēta datu vākšana: Atšķirībā no manuālām profilēšanas sesijām, _tracingMarker veicina veiktspējas datu vākšanu lietojumprogrammas darbības laikā, potenciāli arī produkcijas vidē (rūpīgi apsverot).
• Datu apkopošanas potenciāls: Ar šiem marķieriem savāktie strukturētie dati ir ideāli piemēroti apkopošanai, ļaujot analizēt tendences, identificēt bieži sastopamas veiktspējas problēmas un salīdzināt dažādas lietotāju sesijas vai vides.

Kā _tracingMarker darbojas konceptuāli?

Savā būtībā _tracingMarker darbojas, izmantojot pārlūkprogrammas veiktspējas API, piemēram, High Resolution Time API vai Performance Timeline API, vai arī ieviešot savus laika noteikšanas mehānismus. Kad tiek sastapts _tracingMarker, tas var ierakstīt sākuma laiku. Kad tiek sasniegts atbilstošs beigu marķieris vai konkrēta operācija beidzas, tiek aprēķināts un saglabāts ilgums. Šos datus pēc tam parasti savāc veiktspējas uzraudzības sistēma.

_tracingMarker eksperimentālais raksturs nozīmē, ka tā API un implementācijas detaļas var mainīties. Tomēr pamatprincips – koda instrumentēšana ar nosauktiem marķieriem veiktspējas mērīšanai – paliek nemainīgs.

Datu vākšanas stratēģijas ar _tracingMarker

_tracingMarker efektivitāte ir atkarīga no tā, cik efektīvi tiek vākti veiktspējas dati. Tas ietver stratēģisku marķieru izvietošanu un stabilu datu vākšanas mehānismu.

Stratēģiska marķieru izvietošana

Patiesais _tracingMarker spēks rodas no pārdomātas izvietošanas. Apsveriet šādas jomas:

• Komponentu renderēšanas cikli: Komponenta renderēšanas procesa sākuma un beigu atzīmēšana var atklāt, kuri komponenti tiek renderēti visilgāk, īpaši atjauninājumu laikā. Tas ir būtiski, lai identificētu nevajadzīgi pārrenderējamus komponentus. Piemēram, sarežģītā e-komercijas platformā ar dinamiskiem produktu sarakstiem, atsevišķu produktu karšu renderēšanas atzīmēšana varētu norādīt uz veiktspējas problēmām meklēšanas vai filtru lietošanas laikā.
• Datu ielāde un apstrāde: API izsaukumu, datu transformāciju un stāvokļa atjauninājumu, kas saistīti ar datu ielādi, dzīves cikla instrumentēšana var izcelt tīkla latentumu vai neefektīvu datu apstrādi. Iedomājieties ceļojumu rezervēšanas lietojumprogrammu, kas ielādē lidojumu datus no vairākiem API; katras ielādes un sekojošā datu apstrādes soļa atzīmēšana var atklāt, kurš API ir lēns vai kur klienta puses apstrāde ir vājā vieta.
• Lietotāju mijiedarbības: Laika mērīšana kritiskām lietotāju mijiedarbībām, piemēram, pogu klikšķiem, veidlapu iesniegšanai vai meklēšanas vaicājumiem, sniedz tiešu ieskatu lietotāja uztvertajā veiktspējā. Sociālo mediju lietojumprogrammā laika atzīmēšana no brīža, kad lietotājs publicē komentāru, līdz tā parādīšanās ekrānā ir vitāli svarīgs veiktspējas rādītājs.
• Trešo pušu integrācijas: Ja jūsu lietojumprogramma paļaujas uz trešo pušu skriptiem vai SDK (piemēram, analītikai, reklāmai vai tērzēšanai), šo integrāciju izpildes laika atzīmēšana var palīdzēt izolēt veiktspējas pasliktināšanos, ko izraisa ārēji faktori. Tas ir īpaši svarīgi globālām lietojumprogrammām, kurās var būt atšķirīgi tīkla apstākļi trešo pušu resursiem.
• Sarežģīta biznesa loģika: Lietojumprogrammām ar lielu skaitļošanas loģiku, piemēram, finanšu modelēšanas rīkiem vai datu vizualizācijas platformām, šo pamata loģikas bloku izpildes atzīmēšana ir būtiska, lai izprastu un optimizētu skaitļošanas veiktspēju.

Datu savākšana

Kad marķieri ir izvietoti, savāktie dati ir jāsavāc. Var izmantot vairākas pieejas:

• Pārlūkprogrammas izstrādātāju rīki: Vietējai izstrādei un atkļūdošanai pārlūkprogrammas izstrādātāju rīki (piemēram, Chrome DevTools Performance cilne) bieži var interpretēt un parādīt datus no React eksperimentālajiem izsekošanas mehānismiem, nodrošinot tūlītēju vizuālu atgriezenisko saiti.
• Pielāgota žurnalēšana: Izstrādātāji var ieviest pielāgotus žurnalēšanas risinājumus, lai uztvertu marķieru datus un nosūtītu tos uz konsoli vai vietējo failu analīzei izstrādes laikā.
• Veiktspējas uzraudzības pakalpojumi (PMS): Produkcijas vidēm integrācija ar specializētu veiktspējas uzraudzības pakalpojumu ir vismērogojamākā un efektīvākā pieeja. Šie pakalpojumi ir paredzēti, lai vāktu, apkopotu un vizualizētu veiktspējas datus no liela lietotāju skaita visā pasaulē. Piemēri ietver Sentry, Datadog, New Relic vai pielāgotus risinājumus, kas veidoti ar rīkiem, piemēram, OpenTelemetry.

Integrējoties ar PMS, ar _tracingMarker savāktie dati parasti tiktu nosūtīti kā pielāgoti notikumi vai posmi (spans), bagātināti ar kontekstu, piemēram, lietotāja ID, ierīces tipu, pārlūkprogrammu un ģeogrāfisko atrašanās vietu. Šis konteksts ir būtisks globālai veiktspējas analīzei.

Veiktspējas datu apkopošana: neapstrādātu datu pārvēršana praktiskos ieskatos

Neapstrādāti veiktspējas dati, lai arī informatīvi, bieži ir pārāk apjomīgi. Patiesā vērtība parādās, kad šie dati tiek apkopoti un analizēti, lai atklātu tendences un modeļus. Veiktspējas datu apkopošana ar _tracingMarker nodrošina dziļāku izpratni par lietojumprogrammas darbību dažādos lietotāju segmentos un vidēs.

Galvenie apkopošanas rādītāji

Apkopojot datus, kas savākti ar _tracingMarker, koncentrējieties uz šiem galvenajiem rādītājiem:

• Vidējais un mediānas ilgums: Izpratne par operācijas tipisko laiku nodrošina bāzes līniju. Mediāna bieži ir izturīgāka pret izņēmumiem nekā vidējais rādītājs.
• Procentiles (piem., 95., 99.): Šie rādītāji atklāj veiktspēju, ko pieredz lēnākā lietotāju bāzes daļa, izceļot potenciāli kritiskas problēmas, kas skar nozīmīgu minoritāti.
• Ar operācijām saistīto kļūdu līmenis: Veiktspējas marķieru korelācija ar kļūdām var norādīt uz operācijām, kas ir ne tikai lēnas, bet arī pakļautas kļūmēm.
• Ilgumu sadalījums: Laika sadalījuma vizualizēšana (piemēram, izmantojot histogrammas) palīdz noteikt, vai veiktspēja ir pastāvīgi laba, vai arī pastāv liela atšķirība.
• Ģeogrāfiskie veiktspējas sadalījumi: Globālai auditorijai ir būtiski apkopot veiktspējas datus pa reģioniem vai valstīm. Tas var atklāt problēmas, kas saistītas ar CDN veiktspēju, serveru tuvumu vai reģionālo interneta infrastruktūru. Piemēram, lietojumprogramma varētu darboties nevainojami Ziemeļamerikā, bet ciest no augsta latentuma Dienvidaustrumāzijā, norādot uz nepieciešamību pēc labākas satura piegādes vai reģionālu serveru izvietošanas.
• Ierīču un pārlūkprogrammu tipu sadalījumi: Dažādām ierīcēm (galddatoriem, planšetdatoriem, mobilajām ierīcēm) un pārlūkprogrammām ir atšķirīgas veiktspējas īpašības. Datu apkopošana pēc šiem faktoriem palīdz pielāgot optimizācijas. Sarežģīta animācija varētu labi darboties augstas klases galddatorā, bet būt nozīmīgs veiktspējas slogs mazjaudīgā mobilajā ierīcē jaunattīstības tirgū.
• Lietotāju segmentu veiktspēja: Ja jūs segmentējat savus lietotājus (piemēram, pēc abonēšanas līmeņa, lietotāja lomas vai iesaistes līmeņa), veiktspējas analīze katram segmentam var atklāt specifiskas problēmas, kas skar noteiktas lietotāju grupas.

Apkopošanas tehnikas

Apkopošanu var veikt dažādos veidos:

• Servera puses apkopošana: Veiktspējas uzraudzības pakalpojumi parasti veic apkopošanu savā aizmugursistēmā. Tie saņem neapstrādātus datu punktus, apstrādā tos un glabā vaicājumiem pieejamā formātā.
• Klienta puses apkopošana (ar piesardzību): Dažos scenārijos pamata apkopošanu (piemēram, vidējo rādītāju vai skaita aprēķināšanu) varētu veikt klientā pirms datu nosūtīšanas, lai samazinātu tīkla trafiku. Tomēr tas jādara apdomīgi, lai neietekmētu pašu lietojumprogrammas veiktspēju.
• Datu noliktavas un biznesa inteliģences rīki: Uzlabotai analīzei veiktspējas datus var eksportēt uz datu noliktavām un analizēt, izmantojot BI rīkus, kas ļauj veikt sarežģītas korelācijas ar citiem biznesa rādītājiem.

Praktiski piemēri un lietošanas gadījumi (globāla perspektīva)

Apskatīsim, kā _tracingMarker un datu apkopošanu var pielietot reālos, globālos scenārijos:

1. piemērs: E-komercijas norēķinu procesa optimizācija

Scenārijs: Globāla e-komercijas platforma piedzīvo konversijas rādītāju kritumu norēķinu procesā. Lietotāji dažādos reģionos ziņo par atšķirīgu veiktspējas līmeni.

Ieviešana:

• Izvietot _tracingMarker ap galvenajiem soļiem: maksājumu informācijas validācija, piegādes iespēju ielāde, pasūtījuma apstrāde un pirkuma apstiprināšana.
• Vākt šos datus kopā ar lietotāja ģeogrāfisko atrašanās vietu, ierīces tipu un pārlūkprogrammu.

Apkopošana un ieskati:

• Apkopot marķiera 'ielādēt piegādes iespējas' ilgumu.
• Ieskats: Analīze atklāj, ka lietotāji Austrālijā un Jaunzēlandē piedzīvo ievērojami ilgākas aizkaves (piem., 95. procentile > 10 sekundes), salīdzinot ar lietotājiem Ziemeļamerikā (mediāna < 2 sekundes). Tas varētu būt saistīts ar piegādes API servera atrašanās vietu vai CDN problēmām šajā reģionā.
• Rīcība: Izpētīt CDN kešatmiņu piegādes iespējām APAC reģionā vai apsvērt reģionālos piegādes partnerus/serverus.

2. piemērs: Lietotāju ievadīšanas uzlabošana SaaS lietojumprogrammā

Scenārijs: Programmatūras kā pakalpojuma (SaaS) uzņēmums pamana, ka lietotāji jaunattīstības tirgos pamet sākotnējo ievadīšanas plūsmu, kas ietver preferenču iestatīšanu un integrāciju ar citiem pakalpojumiem.

Ieviešana:

• Atzīmēt laiku, kas nepieciešams katram ievadīšanas vedņa solim: lietotāja profila izveide, sākotnējā datu importēšana, integrācijas iestatīšana (piem., savienošanās ar mākoņglabāšanas pakalpojumu) un gala konfigurācijas apstiprināšana.
• Atzīmēt arī konkrēto integrācijas moduļu veiktspēju.

Apkopošana un ieskati:

• Apkopot 'integrācijas iestatīšanas' ilgumu pēc lietotāja valsts un integrācijas veida.
• Ieskats: Dati rāda, ka lietotājiem dažās Dienvidamerikas un Āfrikas daļās ir grūtības integrēties ar konkrētu mākoņglabāšanas pakalpojumu sniedzēju, ar augstāku kļūdu līmeni un ilgāku laiku. Tas varētu būt saistīts ar tīkla nestabilitāti vai šī pakalpojumu sniedzēja reģionālo API veiktspēju.
• Rīcība: Nodrošināt alternatīvas integrācijas iespējas šajos reģionos vai piedāvāt robustāku kļūdu apstrādi un atkārtošanas mehānismus konkrētajai integrācijai.

3. piemērs: Satura ielādes optimizēšana globālai ziņu platformai

Scenārijs: Ziņu vietne cenšas nodrošināt ātrus rakstu ielādes laikus lasītājiem visā pasaulē, īpaši mobilajās ierīcēs ar ierobežotu joslas platumu.

Ieviešana:

• Atzīmēt galvenā raksta satura, 'slinki' ielādēto attēlu, reklāmu un saistīto rakstu ielādi.
• Pievienot datiem tagus ar ierīces tipu (mobilais/galddators) un aptuveno tīkla ātrumu, ja to var noteikt.

Apkopošana un ieskati:

• Apkopot 'slinki ielādēto attēlu' ilgumu mobilajiem lietotājiem reģionos ar ziņotu lēnāku interneta ātrumu.
• Ieskats: 99. procentile attēlu ielādei ir pārmērīgi augsta mobilajiem lietotājiem Dienvidaustrumāzijā, norādot uz lēnu attēlu piegādi, neskatoties uz CDN izmantošanu. Analīze rāda, ka tiek pasniegti neoptimizēti attēlu formāti vai lieli faili.
• Rīcība: Ieviest agresīvāku attēlu kompresiju, izmantot modernus attēlu formātus (piemēram, WebP), kur tie tiek atbalstīti, un optimizēt CDN konfigurācijas šiem reģioniem.

Izaicinājumi un apsvērumi

Lai gan _tracingMarker piedāvā aizraujošas iespējas, ir svarīgi apzināties izaicinājumus un apsvērumus, kas saistīti ar tā eksperimentālo raksturu un veiktspējas datu vākšanu:

• Eksperimentālais statuss: Kā eksperimentāla funkcija, API var mainīties vai tikt noņemta nākamajās React versijās. Izstrādātājiem, kas to pieņem, jābūt gataviem iespējamai koda pārstrādei.
• Veiktspējas virsizdevumi: Koda instrumentēšana, pat ar efektīviem mehānismiem, var radīt nelielus veiktspējas virsizdevumus. Tas ir īpaši kritiski produkcijas vidēm. Ir nepieciešama rūpīga testēšana, lai nodrošinātu, ka pati instrumentācija negatīvi neietekmē lietotāja pieredzi.
• Datu apjoms: Detalizētu datu vākšana no lielas lietotāju bāzes var radīt milzīgu datu apjomu, kas noved pie uzglabāšanas un apstrādes izmaksām. Ir būtiskas efektīvas apkopošanas un paraugu ņemšanas stratēģijas.
• Privātuma apsvērumi: Vācot veiktspējas datus no lietotājiem, īpaši produkcijā, ir stingri jāievēro privātuma noteikumi (piemēram, GDPR, CCPA). Datiem jābūt anonimizētiem, kur tas ir iespējams, un lietotājiem jābūt informētiem par datu vākšanu.
• Apkopošanas sarežģītība: Stabilas datu apkopošanas un analīzes sistēmas izveide prasa ievērojamas inženierijas pūles un zināšanas. Bieži vien praktiskāk ir izmantot esošos veiktspējas uzraudzības risinājumus.
• Pareiza datu interpretācija: Veiktspējas dati dažkārt var būt maldinoši. Ir svarīgi izprast kontekstu, korelēt ar citiem rādītājiem un izvairīties no pārsteidzīgu secinājumu izdarīšanas. Piemēram, ilgs marķiera ilgums var būt saistīts ar nepieciešamu, lai arī lēnu, sinhronu operāciju, nevis obligāti neefektīvu.
• Globālā tīkla mainība: Datu apkopošana globāli nozīmē saskarties ar ļoti atšķirīgiem tīkla apstākļiem. Tas, kas izskatās pēc lēnas klienta puses operācijas, varētu būt tīkla latentums. Lai atšķirtu šos, nepieciešama rūpīga instrumentācija un analīze.

Labākās prakses _tracingMarker ieviešanai

Izstrādātājiem, kas vēlas izmantot _tracingMarker potenciālu, apsveriet šīs labākās prakses:

• Sāciet lokāli: Sāciet ar _tracingMarker izmantošanu savā izstrādes vidē, lai izprastu tās iespējas un eksperimentētu ar marķieru izvietošanu.
• Prioritizējiet galvenās jomas: Koncentrējiet instrumentāciju uz kritiskām lietotāju plūsmām un zināmām veiktspējas vājajām vietām, nevis mēģiniet atzīmēt visu.
• Izstrādājiet datu stratēģiju: Plānojiet, kā savāktie dati tiks glabāti, apkopoti un analizēti. Izvēlieties piemērotu veiktspējas uzraudzības pakalpojumu vai izveidojiet pielāgotu risinājumu.
• Uzraugiet virsizdevumus: Regulāri mēriet savas instrumentācijas ietekmi uz veiktspēju, lai nodrošinātu, ka tā nepasliktina lietotāja pieredzi.
• Izmantojiet jēgpilnus nosaukumus: Piešķiriet saviem marķieriem skaidrus, aprakstošus nosaukumus, kas precīzi atspoguļo to, ko tie mēra.
• Kontekstualizējiet datus: Vienmēr vāciet attiecīgo kontekstu (lietotāja aģents, atrašanās vieta, ierīces tips, pārlūkprogrammas versija) kopā ar veiktspējas rādītājiem.
• Iterējiet un uzlabojiet: Veiktspējas optimizācija ir nepārtraukts process. Nepārtraukti analizējiet savus apkopotos datus un uzlabojiet savu instrumentāciju, kad jūsu lietojumprogramma attīstās.
• Sekojiet līdzi jaunumiem: Sekojiet React eksperimentālo funkciju ceļa kartei un dokumentācijai, lai uzzinātu par _tracingMarker atjauninājumiem un izmaiņām.

React veiktspējas uzraudzības nākotne

Tādu funkciju kā _tracingMarker izstrāde liecina par React pastāvīgo apņemšanos sniegt izstrādātājiem sarežģītus veiktspējas ieskatus. Kad šīs funkcijas nobriedīs un kļūs integrētākas pamatbibliotēkā vai izstrādātāju rīkos, mēs varam sagaidīt:

• Standartizēti API: Stabilāki un standartizētāki API veiktspējas instrumentācijai, padarot ieviešanu vieglāku un uzticamāku.
• Uzlaboti izstrādātāju rīki: Dziļāka integrācija ar React Developer Tools, kas ļauj intuitīvāk vizualizēt un analizēt izsekotos datus.
• Automātiskā instrumentācija: Iespēja, ka noteiktus veiktspējas aspektus automātiski instrumentēs pats React, samazinot manuālo darbu, kas nepieciešams no izstrādātājiem.
• Mākslīgā intelekta vadīti ieskati: Nākotnes veiktspējas uzraudzības risinājumi varētu izmantot MI, lai automātiski identificētu anomālijas, ieteiktu optimizācijas un prognozētu potenciālās veiktspējas problēmas, pamatojoties uz apkopotajiem datiem.

Globālai izstrādātāju kopienai šie sasniegumi nozīmē jaudīgākus rīkus, lai nodrošinātu, ka lietojumprogrammas darbojas optimāli katram lietotājam neatkarīgi no viņa atrašanās vietas vai ierīces. Spēja programmatiski vākt un apkopot detalizētus veiktspējas datus ir nozīmīgs solis ceļā uz patiesi atsaucīgu un augstas veiktspējas globālu lietojumprogrammu izveidi.

Noslēgums

React eksperimentālais _tracingMarker pārstāv daudzsološu robežu veiktspējas uzraudzībā, piedāvājot potenciālu detalizētai datu vākšanai un sarežģītai apkopošanai. Stratēģiski izvietojot marķierus un īstenojot stabilas datu vākšanas un analīzes stratēģijas, izstrādātāji var gūt nenovērtējamus ieskatus savas lietojumprogrammas veiktspējā dažādās globālās lietotāju bāzēs. Lai gan tas joprojām ir eksperimentāls, tā principu un potenciālo pielietojumu izpratne ir būtiska jebkuram izstrādātājam, kura mērķis ir nodrošināt izcilu lietotāja pieredzi mūsdienu savienotajā digitālajā pasaulē. Šai funkcijai attīstoties, tā neapšaubāmi kļūs par neaizstājamu rīku veiktspējas apzinīgu React izstrādātāju arsenālā visā pasaulē.

Atruna: _tracingMarker ir eksperimentāla funkcija. Tās API un uzvedība var mainīties nākamajās React versijās. Vienmēr skatiet oficiālo React dokumentāciju, lai iegūtu visjaunāko informāciju.