Pažangus „React“ našumas: nuo kūrėjų versijų iki žiniatinklio darbuotojų

Pagrindinis » Pitonas » Pažangus „React“ našumas: nuo kūrėjų versijų iki žiniatinklio darbuotojų

„React“ gali atrodyti žaibiškai greita iš karto, bet programai augant, stebėtinai lengva pridėti subtilių našumo regresijų. kurie sklandžiai veikiančias sąsajas paverčia vangiais, daug baterijos eikvojančiais monstrais. Ilgi sąrašai, sunkūs komponentai, nepatogios būsenų struktūros ir derinimo klaidos gamybinėje aplinkoje – visa tai kaupiasi, kol vartotojai pradeda palikti jūsų puslapius.

Geros naujienos yra tai, kad „React“ turi platų įrankių rinkinį, skirtą matuoti, suprasti ir gerinti atvaizdavimo našumą., o supanti ekosistema (ryšių rinkiniai, profiliavimo įrankiai, langų bibliotekos, žiniatinklio darbuotojai, SSR sistemos) suteikia viską, ko reikia, kad jūsų vartotojo sąsaja būtų sklandi net ir dideliu mastu. Šiame vadove išsamiai apžvelgsime šiuos įrankius, parodysime, kaip jie dera tarpusavyje, ir išryškinsime keletą mažiau akivaizdžių gudrybių, kurias komandos dažnai praleidžia, bet kurios tikrai vertos dėmesio.

Naudokite tinkamą „React“ versiją: kūrimas, gamyba ir profiliavimas

Pirmasis bet kurios „React“ programos našumo patikrinimas yra patikrinimas, ar siunčiate gamybinę, o ne kūrimo versiją.Kūrimo versijoje yra daugybė draugiškų įspėjimų, papildomų patikrinimų ir derinimo pagalbininkų, kurie yra fantastiški koduojant, bet pastebimai lėtesni ir didesni produkcijos aplinkoje.

Kurią versiją naudojate, galite patvirtinti naudodami „React Developer Tools“ naršyklės plėtinį.Kai atidarote svetainę naudodami „React“, plėtinio piktogramos fonas gamybinėje aplinkoje yra tamsus, o kūrimo aplinkoje – raudonas. Jei savo svetainėje matote raudoną spalvą, jūsų paketavimo konfigūracija neatitinka teisingos versijos.

Projektams, paleidžiamiems naudojant „Create React App“, optimizuoto gamybos paketo generavimas yra toks pat paprastas, kaip paleisti kūrimo scenarijų., kuris išveda sumažintą paketą į build/ katalogą. Vietinės plėtros metu turėtumėte laikytis npm start (arba lygiavertį) ir gamybinę versiją paleiskite tik diegimo tikslais arba realistiškiems našumo testams.

Jei pasikliaujate „React“ ir „React DOM“ UMD vieno failo kompiliacijomis (pavyzdžiui, nesusietoje aplinkoje), įsitikinkite, kad įtraukėte failus, kurie baigiasi .production.min.jsBet koks nesumažintas arba negamybinis failas skirtas tik kūrimui ir jūsų vartotojams sukels nereikalingų derinimo išlaidų.

Paketų rengyklės: „Browserify“, „Rollup“, „Brunch“ ir „webpack“

Skirtingiems paketų kūrėjams reikalingi skirtingi pakeitimai, kad būtų galima visiškai optimizuoti „React“ gamybinius procesus., tačiau visi jie vadovaujasi ta pačia pagrindine idėja: nustatyti aplinką į gamybinę, pašalinti tik kūrėjams skirtas šakas ir sumažinti gautą „JavaScript“.

Naudojant „Brunch“, rekomenduojama įdiegti minifierio įskiepį, pvz. terser-brunch, tada paleiskite savo kūrimą su gamybos vėliava (pavyzdžiui, su -p). Ši konfigūracija užtikrina, kad kūrimo laiko įspėjimai būtų pašalinti, o galutinis paketas būtų agresyviai suspaustas.

„Browserify“ atveju paprastai sujungiate kelias transformacijas tam tikra tvarka.: pirmiausia kreipkitės envify visame pasaulyje švirkšti NODE_ENV="production", tada taikyti uglifyify globaliai, kad būtų ištrinti kūrimo importai ir kodo keliai, ir galiausiai perduotas paketas terser skirtas modifikavimui ir glaudinimui. Eilės tvarka čia svarbi, nes kiekvienas žingsnis paruošia kodą kitai transformacijai.

Naudodami „Rollup“, sujungiate tris papildinius, kad pasiektumėte efektyvią produkcijos kūrimo technologiją.: replace sukuria aplinką gamybai, commonjs leidžia sujungti „CommonJS“ modulius ir terser atlieka galutinį sumažinimą ir iškraipymą. Šis derinys sukuria nedidelį, gamybai paruoštą paketą be tik kūrėjams skirtų pagalbininkų.

Naudojant „webpack 4“ ir naujesnes versijas, įjungus gamybos režimą, automatiškai suaktyvinamos įvairios optimizacijos, įskaitant mažinimą.. Nustatymas mode: 'production' laidai Terser po gaubtu ir įgalina React gamybinę elgseną tol, kol NODE_ENV atitikmenys. Paprastai nereikia pridėti atskiro sumažinimo įrenginio, nebent turite labai specifinių reikalavimų.

„React“ profiliavimo versijos

Be įprastų kūrėjų ir gamybinių versijų, „React“ taip pat siūlo specialią profiliavimo versiją, skirtą našumo analizei.Šis variantas apdoroja „React“ vidinius įrankius, kad tokie įrankiai kaip „DevTools Profiler“ galėtų rinkti labai išsamią laiko informaciją.

Norėdami naudoti profiliavimo kompiliavimą naršyklės aplinkoje, importuokite react-dom/profiling VIETOJ react-dom/client ir paprastai sukonfigūruoja paketavimo programos slapyvardį, kad nereikėtų kiekvieno importavimo atlikti rankiniu būdu. Kai kurios sistemos jau turi žymę arba režimą, kad galėtumėte perjungti šį elgesį.

Ankstesnės „React“ versijos (iki 17) rėmėsi standartine vartotojo laiko nustatymo API. kad naršyklės našumo skydelyje būtų matomi žymės ir matavimai. Šiuolaikinė „React“ versija šias galimybes susieja su specialiu „Profilerio“ skirtuku „React DevTools“ programoje, kad galėtumėte tiesiogiai analizuoti komponentus.

„React“ našumo supratimas ir matavimas

Negalite pataisyti to, ko neišmatuojate, todėl našumo vertinimas „React“ sistemoje visada turėtų prasidėti nuo profiliavimo.Tai reiškia, kad reikia naudoti naršyklės įrankius ir „React“ specifinius profiliavimo įrankius, kad būtų galima pamatyti, kur iš tikrųjų praleidžiama laiko ir kurie komponentai pakartotinai atvaizduojami dažniau nei turėtų.

„Chrome DevTools“ našumo skydelis yra jūsų pagrindinis naršyklės veikimo supratimo šaltinis.„JavaScript“ vykdymas, tinklo užklausos, išdėstymas, piešiniai, įvykių ciklo vėlavimai ir pasirinktiniai pėdsakai – visa tai rodoma vieningoje laiko juostoje. „React“ integruojasi į šį rodinį su specializuotais pėdsakais, kurie atskleidžia sistemai būdingą veiklą.

„Modern React“ pateikia planuoklės, komponentų ir serverio sekimus, kurie sutampa su įprastais naršyklės sekimaisTai suteikia sinchronizuotą tinklo, „JavaScript“ ir „React“ atnaujinimų vaizdą, kuris yra labai naudingas, kai ieškote nereikalingų elementų ar keistų užstrigimų, kurie atsiranda tik esant apkrovai.

Planuoklio sekimas ir pateikimo etapai

Planuoklė yra vidinė „React“ abstrakcija, kuri koordinuoja darbą pagal skirtingus prioritetus.Našumo pėdsakuose matysite atskirus poskyrius blokavimo darbams (dažnai sinchroniniams vartotojo inicijuotiems atnaujinimams), perėjimo darbams (fono vartotojo sąsajos atnaujinimams, kuriuos suaktyvina startTransition), Su įtampa susijusios užduotys ir neveiklūs darbai, kurie atliekami, kai nėra jokių skubesnių darbų.

Kiekvienas renderinimo etapas pereina kelis skirtingus etapus, kuriuos galite peržiūrėti laiko juostoje.atnaujinimo etapas (kas suaktyvino renderinimą), renderinimo etapas (kuriame „React“ iškviečia jūsų komponentus ir sukuria kitą medį), patvirtinimo etapas (kuriame DOM yra mutuojamas ir maketo efektai, pvz. useLayoutEffect bėgimas) ir likusi poveikio fazė (kur pasyvūs poveikio efektai, pvz. useEffect (paprastai nubėga po dažymo).

Kaskadiniai atnaujinimai – būsenos pakeitimai, suplanuoti renderinimo metu – yra klasikinis paslėptų našumo problemų šaltinis.Kūrimo metu „React“ gali juos pažymėti laiko juostoje ir netgi parodyti, kuris komponentas ir metodas suplanavo papildomą atnaujinimą, taip padėdamas išvengti netyčinių vaizdavimo ciklų ar pakartotinio darbo.

Komponentų takelis: flamegrafai renderiams ir efektams

Komponentų takelis vaizduoja, kiek laiko trunka kiekvieno komponento (ir jo palikuonių) atvaizdavimas. naudojant flamegrafą. Kuo platesnis blokas grafe, tuo daugiau laiko tas komponentų podmedis sugaišo tame vaizdavimo etape.

„React“ taip pat rodo efektų trukmę kaip atskirą liepsnos grafiką. su spalvų schema, kuri atspindi atitinkamą planuoklio takelio fazę, todėl galite iš karto atskirti renderavimo laiką nuo efekto laiko.

Papildomi įvykiai, pvz., prijungimai, atjungimai, pakartotiniai prijungimai ir atjungimai, šiuose flamegrafuose rodomi kaip anotacijos.Pavyzdžiui, bus pažymėta naujos medžio dalies montavimas arba nugriovimas, o kai kurie elementai, pvz. <Activity> komponentai gauna savo prijungimo / atjungimo žymeklius.

Kūrimo versijoje spustelėjus renderio įrašą komponentų takelyje, parodomi pakeisti propsai., kuris yra nepaprastai naudingas, kai bandote susekti nereikalingus renderius ar rekvizitus, kurie nuolat keičia nuorodas, iš tikrųjų nepakeisdami reikšmės.

Serverio takeliai: užklausos ir serverio komponentai

Jei naudojate „React Server“ komponentus, našumo įrankiai taip pat gali parodyti serverio pusės elgesį.„Serverio užklausų“ takelis kaupia pažadus, kurie galiausiai tiekia duomenis serverio komponentams, įskaitant iškvietimus į fetch arba asinchroninės failų sistemos operacijos.

„React“ bando sugrupuoti trečiųjų šalių pagalbinėse programose sukurtus pažadus į vieną bendrą apimtį. taigi pamatysite vieną loginę operaciją, pvz. getUser o ne tuzinas žemo lygio fetch skambučiai. Spustelėjus intervalą, parodoma, kur jis buvo sukurtas, ir, jei yra, išspręsta reikšmė arba atmetimo priežastis.

Atskiras serverio komponentų takelis rodo, kiek laiko užtrunka serverio komponentų medžiai ir jų laukiami pažadai, taip pat flamegrafo pavidalu. Kai „React“ gali vienu metu pateikti serverio komponentus, ji sukuria pagrindinį takelį ir papildomus lygiagrečius takelius; jei lygiagretumas viršija tam tikrą skaičių, papildomas darbas grupuojamas, kad rodinys būtų įskaitomas.

Nereikalingų renderių mažinimas: React.memo, useMemo, useCallback ir PureComponent

Vienas didžiausių ir dažniausiai pasitaikančių našumo nuostolių „React“ programose yra nereikalingas pakartotinis atvaizdavimas.Kiekvieną kartą, kai atnaujinamas pagrindinis komponentas, jo vaikai pagal numatytuosius nustatymus yra atvaizduojami iš naujo, net jei jų įvesties duomenys (propai) yra identiški ir išvesties DOM iš tikrųjų nepasikeistų.

„React“ siūlo keletą įrankių, skirtų šiam veltui atliekamam darbui sumažinti: React.memo funkciniams komponentams, React.PureComponent klasės komponentams ir useMemo/useCallback kabliukai vertybėms stabilizuoti, perduodamoms kaip atramosJie stebuklingai neišsprendžia visų našumo problemų, tačiau apgalvotai naudojami gali turėti didelės įtakos.

React.memo apvynioja funkcinį komponentą ir praleidžia pakartotinį vaizdavimą, kai jo propsai yra šiek tiek lygūs ankstesniemsTai vertingiausia, kai komponentas dažnai atvaizduojamas su tais pačiais prop'ais, turi sudėtingą atvaizdavimo logiką arba turite įrodymų iš Profiler, kad tai yra kliūtis.

Įsimindami komponentą, taip pat turite užtikrinti, kad jo propsai be reikalo nekeistų tapatybės.Sukūrus naują objektą arba įterptinę funkciją pirminiame JSX faile kiekvieno vaizdavimo metu, paviršutiniškas palyginimas bus negaliojantis ir vaikas bus priverstas iš naujo vaizduoti, net jei loginiai duomenys yra tie patys.

Tai kur useMemo bei useCallback Įeiti: useMemo stabilizuoja objekto arba masyvo reikšmes, gautas iš kitos būsenos, kad jos keistųsi tik tada, kai keičiasi jų priklausomybės, ir useCallback teikia stabilias funkcijų nuorodas atgaliniams iškvietimams, perduotiems įsimintiems vaikams.

Klasės komponentai: shouldComponentUpdate ir React.PureComponent

Iš esmės dauguma „React“ renderinimo optimizavimų susiveda į tai, ar reikia kontroliuoti, ar shouldComponentUpdate grąžina „true“ arba „false“Numatytasis įgyvendinimas visada grąžina „true“, o tai reiškia, kad bet koks prop arba būsenos pakeitimas suaktyvina to komponento ir jo podmedžio vaizdavimą ir suderinimą.

Perskirdamas shouldComponentUpdate, galite trumpai sujungti darbus su poskyriais, kurių nereikia atnaujintiJei grąžinsite „false“, „React“ nekvies render() tam komponentui ar bet kuriam jo palikuoniui ir net nepalygins naujų ir senų virtualių DOM mazgų tai medžio daliai.

Apsvarstykite nedidelį komponentų medį, kuriame kai kurie mazgai grąžina klaidingą reikšmę iš shouldComponentUpdate„React“ gali visiškai praleisti perėjimą į tas šakas, o kiti mazgai, kuriuose metodas grąžina „true“, bus pilnai apdoroti. Galiausiai DOM mutacijas sukels tik tie mazgai, kurių pateikta išvestis iš tikrųjų pasikeitė.

Nes rašymo paprotys shouldComponentUpdate Logika kartojasi, „React“ pristato React.PureComponent, kuris įgyvendina paviršutinišką dabartinių ir ankstesnių propsų bei būsenos palyginimą. Jei niekas iš esmės nepasikeitė, „React“ gali saugiai praleisti to klasės komponento pakartotinį atvaizdavimą.

Nekintamumas ir kodėl paviršutiniškas palyginimas gali nepavykti

Paviršutiniškas palyginimas daro prielaidą, kad pasikeitus vertei, pasikeis ir jos nuoroda – ši prielaida panaikinama vos tik pakeičiate esamus masyvus ar objektus.Tai klasikinis klaidų šaltinis, kai nekintamumu pagrįstas optimizavimas derinamas su keičiamomis duomenų struktūromis.

Įsivaizduokite a ListOfWords komponentas, kuris gauna words masyvą ir pateikia juos atskirtus kableliais, suporuotas su tėvu WordAdder komponentas, kuris į tą patį masyvą įterpia naują žodį. Jei ListOfWords tęsiasi PureComponent, paviršutiniškas palyginimas matys tą pačią masyvo nuorodą ir darys prielaidą, kad niekas nepasikeitė, todėl vartotojo sąsaja nebus atnaujinta.

Pataisymas yra vengti tiesiogiai keisti props arba būseną ir vietoj to kurti naujus masyvus arba objektus, kai keičiasi duomenys.. Vietoj words.push(newWord), jūs naudotumėte words.concat(newWord) arba išplitimo sintaksė [...words, newWord], kuri sukuria naują masyvo nuorodą ir suaktyvina teisingus atnaujinimus.

Tas pats principas galioja ir objektams: užuot perskirstęs colormap.right = 'blue' esamam objektui grąžintumėte naują objektą naudodami Object.assign({}, colormap, { right: 'blue' }) arba objekto išplitimo sintaksė { ...colormap, right: 'blue' }Tai garantuoja, kad paviršutiniškas palyginimas mato naują nuorodą ir atpažįsta pokytį.

Kai duomenys tampa giliai įterpti, rankinis nekintamumo palaikymas gali tapti sudėtingas.Tokios bibliotekos kaip „Immer“ arba „immutability-helper“ leidžia rašyti kodą, kuris atrodo imperatyvus ir mutuojantis, tuo pačiu metu kuriant naujas nekintamas struktūras, kurios puikiai dera su... PureComponent bei React.memo.

Ilgų sąrašų ir sudėtingų vartotojo sąsajų virtualizavimas

Šimtų ar tūkstančių DOM mazgų atvaizdavimas vienu metu yra vienas greičiausių būdų pagerinti „React“ našumą., ypač žemos klasės įrenginiuose arba derinant su sudėtingais išdėstymais ir vaizdais. Net ir efektyviai suderinant, vien tiek mazgų atmintyje ir ekrane yra brangu.

Langų naudojimas arba sąrašų virtualizavimas išsprendžia šią problemą, pateikdamas tik tą sąrašo dalį, kuri šiuo metu matoma peržiūros srityje.Vartotojui slenkant, „React“ prijungia naujus elementus, patenkančius į rodinį, ir atjungia tuos, kurie slenka žemyn, išlaikydama maždaug pastovų atvaizduojamų eilučių skaičių.

Populiarios bibliotekos, pvz. react-window bei react-virtualized pateikti daugkartinio naudojimo komponentus sąrašams, tinkleliams ir lentelėms kurios įgyvendina efektyvias virtualizacijos strategijas. Jos tvarko matematinius veiksmus, kuriuos elementus atvaizduoti, dydžio nustatymą, konteinerių slinkimą ir net begalinį įkėlimo elgesį.

Virtualizacijos diegimas paprastai apima tris dalis: tinkamo komponento pasirinkimas (pvz. FixedSizeList vienodoms eilėms arba VariableSizeList dinaminiams aukščiams), suteikiant konteineriui fiksuotą aukštį su overflow: scrollir pateikiant tik tą elemento komponentą, kurio prašo biblioteka, paprastai įsimintą su React.memo kad būtų išvengta nereikalingų pakartotinių perteikimų.

Gerai atlikta virtualizacija užtikrina sklandų slinkimo našumą ir mažą atminties naudojimą net ir dirbant su dideliais duomenų rinkiniaisRealaus pasaulio programėlės naudoja šį metodą, kad efektyviai naršytų didžiulėse kolekcijose – muzikos apžvalgose, el. prekybos kataloguose, gautuosiuose – nesustodamos vartotojo sąsajos.

Prieinamumas reikalauja šiek tiek daugiau dėmesio naudojant virtualizuotus sąrašusTurite užtikrinti, kad klaviatūros naršymas veiktų, fokusavimas būtų tinkamai valdomas elementus prijungiant ir atjungiant, o ekrano skaitytuvai turėtų pakankamai konteksto per ARIA atributus, kad suprastų šiuo metu matomą sąrašo dalį.

Būsenos valdymas, virtualus DOM ir komponentų struktūra

Virtualus DOM dažnai klaidingai suprantamas kaip stebuklinga priemonė, tačiau iš tikrųjų tai tik išmanus diferenciacijos sluoksnis.„React“ palaiko jūsų vartotojo sąsajos atvaizdavimą atmintyje ir lygina naują medį su senuoju, kad nuspręstų, kurios DOM operacijos yra būtinos.

Net ir esant tokiam efektyvumui, kiekvienas perteikimas ir skirtumas vis tiek kainuoja laiką, todėl jūsų tikslas yra kuo labiau sumažinti didelių poskyrių perteikimo dažnumą.Čia susikerta būsenos valdymas, komponentų ribos ir įsiminimo strategijos.

Pirmiausia pasirinkite tinkamą būsenos valdymo strategiją, atsižvelgdami į savo programos sudėtingumąVietinė reagavimo būsena (useState, useReducer) yra maža ir paprasta mažiems komponentams, o tokios bibliotekos kaip „Redux“ arba lengvos saugyklos, tokios kaip „Zustand“, gali centralizuoti sudėtingesnę globalią būseną su optimizuotais prenumeratos modeliais.

Antra, struktūrizuokite savo būseną taip, kad susiję duomenys būtų sugrupuoti protingaiKartais tai reiškia kelių sujungimą. useState iškvietimus sujungia į vieną objektą, kad atnaujinimai būtų nuoseklūs; kitais atvejais efektyviau yra skaidyti būseną, kad nepriklausomi veiksniai neverstų vienas kito iš naujo atvaizduoti.

Atnaujinant būseną, gautą iš ankstesnių reikšmių, visada naudokite funkcinius atnaujinimus z setCount(prev => prev + 1)ir išlaikyti nekintamumą klonuojant masyvus ir objektus, o ne juos mutuojant vietoje. Tai lemia nuspėjamą elgesį ir puikiai dera su įsiminimo ir „PureComponents“ funkcijomis.

Patogi nykščio taisyklė – išlaikyti valstiją kuo labiau lokalizuotąKuo aukščiau medyje saugoma būsenos reikšmė, tuo daugiau komponentų bus iš naujo atvaizduojama jai pasikeitus. Nukreipus būseną žemyn iki komponentų, kurie ją iš tikrųjų naudoja, apribojamas kiekvieno atnaujinimo sprogdinimo spindulys.

Galiausiai, didelius komponentus suskaidykite į mažesnes, tikslines dalis, kurių rekvizitai retai keičiasiĮsimintini lapų komponentai su stabiliais prop'ais sumažina virtualaus DOM „React“ diferencijavimo poreikį ir sutrumpina kelią iki minimalaus DOM atnaujinimų rinkinio.

Kodo skaidymas, lėtas įkėlimas ir geresnis išteklių įkėlimas

„JavaScript“ paketo dydis yra pagrindinis prasto našumo, ypač mobiliuosiuose tinkluose, veiksnys.Jei jūsų „React“ paketo atsisiuntimas ir analizė trunka kelias sekundes, vartotojai atsijungs dar gerokai prieš pamatydami jūsų gražią vartotojo sąsają.

Kodo skaidymas su React.lazy bei Suspense padeda pakraunant komponentus pagal poreikį, o ne siunčiant viską iš ankstoUžuot sujungę visas funkcijas į pradinį paketą, dinamiškai importuojate tik tas dalis, kurios reikalingos konkretiems maršrutams ar sąveikoms.

Įprasta strategija yra maršruto lygio padalijimas, kur kiekvienas puslapis yra atskira dalis ir įkeliamas tik tada, kai vartotojas į ją pereina. Galite žengti toliau ir padalinti didelius funkcijų komponentus arba retai naudojamas paneles, jei tik jas apvyniosite Suspense su atitinkama atsargine vartotojo sąsaja.

Atidėtas įkėlimas taip pat taikomas paveikslėliams. Pridedant loading="lazy" į <img> žymės atideda žemiau matomos dalies esančių vaizdų įkėlimą, kol jie pasislenka į rodinį, taip taupydami pralaidumą ir pagreitindami pradinį piešimą. Norėdami gauti sudėtingesnių efektų, galite naudoti bibliotekas, pvz. react-lazy-load-image-component palaiko neryškius vietos žymeklius ir laipsnišką įkėlimą.

Įgyvendinant kodo skaidymą, svarbu subalansuoti fragmentų dydžius ir vartotojo patirtį.Per didelis skaidymas gali sukurti per daug mažų užklausų, o nepakankamas skaidymas palieka didelį pradinį paketą. Geri atsarginiai sprendimai ir klaidų ribos aplink „tingius“ komponentus yra būtini, kad nepavykusios tinklo užklausos nesugadintų visos programos.

Serverio pusės atvaizdavimas, „React“ serverio komponentai ir serverio veiksmai

Serverio pusės atvaizdavimas (SSR) atvaizduoja jūsų „React“ programą serveryje ir siunčia HTML klientui, o tai gali žymiai pagerinti suvokiamą našumą ir SEO.Vartotojai greičiau pamato naudingą turinį, o paieškos sistemos gali patikimiau indeksuoti jūsų puslapius.

Tokios sistemos kaip „Next.js“ leidžia SSR ir srautinį HTML naudoti kasdienėse programose.Jūs gaunate duomenis serveryje, pateikiate komponentus HTML formatu – kartais net kaip srautą – ir tada kliento pusėje hidratuojate tą žymėjimą, kad jis taptų interaktyvus.

Be klasikinės SSR, „React Server“ komponentai perkelia daugiau jūsų vartotojo sąsajos logikos į serverio pusę., leidžiant jums pateikti komponentus, kurie niekada nesiunčiami klientui. Tai gali žymiai sumažinti kliento paketo dydį ir supaprastinti duomenų gavimą, nes serverio komponentai gali tiesiogiai kreiptis į duomenų bazes arba API.

Serverio veiksmai išplečia šią idėją, leisdami apibrėžti funkcijas, kurios veikia serveryje, bet yra aktyvuojamos kliento komponentų.Tai pašalina daugybę standartinių REST galinių taškų ar specialiai sukurtų API tvarkyklių ir gali supaprastinti mutacijų, formų pateikimo ir kitų būsenos operacijų tvarkymą.

Kartu naudojami SSR, serverio komponentai ir serverio veiksmai suteikia jums platų vaizdavimo strategijų spektrą.Svarbus turinys gali būti greitai transliuojamas iš serverio, sudėtinga logika lieka ne kliento rankose, o „React“ vykdymo aplinka viską sujungia į darnią vartotojo patirtį.

Sunkių darbų perleidimas žiniatinklio darbuotojams

Net geriausiai optimizuotas „React“ medis strigs, jei pagrindiniame gijoje vykdysite daug procesoriaus apkrovų reikalaujančias užduotis.Brangūs skaičiavimai blokuoja atvaizdavimą, vėluoja įvykių apdorojimą ir sukelia programėlės nereagavimo jausmą.

„Web Workers“ suteikia galimybę perkelti šias sunkias užduotis į foninį gijąJūs siunčiate duomenis darbuotojui, leidžiate jam susumuoti skaičius arba apdoroti didelius duomenų rinkinius, o tada gaunate rezultatą per pranešimų perdavimą, palikdami pagrindinę giją laisvą tvarkyti vartotojo sąsajos atnaujinimus.

Įprasti žiniatinklio darbuotojų darbo krūviai apima duomenų analizę, vaizdų apdorojimą, realaus laiko analizę arba sudėtingas modeliavimą.Pavyzdžiui, žaidimai, sukurti naudojant žiniatinklio steką, dažnai deleguoja pagrindinę žaidimo logiką darbuotojui, o pagrindinis siūlas yra skirtas atvaizdavimui ir įvesties apdorojimui.

Darbuotojo integravimas su „React“ apima atskiro scenarijaus failo sukūrimą, klausymąsi onmessage darbuotojo viduje ir siunčiant pranešimus iš jūsų komponentųKomponente sukuriate darbuotojo egzempliorių, siunčiate jam įvestis su postMessage ir atnaujinti būseną, kai ji atsako, idealiu atveju išvalant darbuotoją, kai komponentas atjungiamas.

Tokios bibliotekos kaip „Comlink“, „workerize“ ar „bundler“ papildiniai gali supaprastinti šį modelį. panaikinant žemo lygio pranešimų perdavimą ir suteikiant API, kuri atrodo kaip asinchroninių funkcijų iškvietimas, o tai lengviau paaiškinama „React“ kodo bazėje.

Svarbiausi naršyklės ir naudotojo orientuoti rodikliai, į kuriuos reikia atkreipti dėmesį

Aukštesniu lygmeniu bendras žiniatinklio našumas dažniausiai stebimas naudojant į vartotoją orientuotus rodiklius. pavyzdžiui, „First Contentful Paint“ (FCP), „Largest Contentful Paint“ (LCP) ir „Time to Interactive“ (TTI). Jie leidžia suprasti, kaip greitai vartotojai pamato turinį ir kada jie gali su juo sąveikauti.

Įprastuose įrenginiuose sveikos „React“ programos siekia, kad FCP būtų maždaug per 1.8 sekundės, LCP – per maždaug 2.5 sekundės, o TTI – gerokai per 4 sekundes., nors tikslios ribos gali skirtis priklausomai nuo projekto. Jei nuolat viršijate šiuos skaičius, tai reiškia, kad reikia patobulinti jūsų paketus, vaizdavimo strategiją arba serverio atsako laiką.

Tokie įrankiai kaip „Lighthouse“, „WebPageTest“ ir „Chrome“ našumo skydelis padeda išmatuoti šiuos rodiklius sintetinių bandymų aplinkose.Norint gauti realių įžvalgų, realaus pasaulio vartotojų stebėjimo (RUM) įrankiai, tokie kaip „SpeedCurve“, „Datadog“, „LogRocket“ ar „Sentry“, seka faktinius vartotojų seansus ir lėtą patirtį susieja su kodo pakeitimais.

„React“ sukurta „Profiler“ API puikiai integruojasi su šiuo paveikslėliugalite apvynioti savo medžio dalis <Profiler>, registruoti lėtus vaizdavimus ir susieti juos su konkrečiais vartotojų srautais. Naudojant kartu su serverio ir tinklo stebėjimu, tai suteikia išsamų našumo vaizdą nuo pradžios iki galo.

Praktinis komandos darbo eiga našumo derinimui

Realiuose projektuose našumo derinimas veikia geriausiai, kai jis traktuojamas kaip pasikartojantis darbo eiga, o ne kaip vienkartinis valymas.Paprastas keturių fazių ciklas – nustatymas, tyrimas, įgyvendinimas, patvirtinimas – padeda išvengti atsitiktinių mikrooptimizacijų ir sutelkti pastangas ten, kur jos svarbiausios.

Identifikavimas reiškia profilių, metrikų ir vartotojų ataskaitų naudojimą konkretiems simptomams nustatyti. pavyzdžiui, lėtai įkeliami puslapiai, mažas kadrų dažnis arba didelis nutraukusių puslapių skaičius tam tikrų srautų metu. Jums reikia išmatuojamų problemų, o ne nuojautų.

Tyrimas siekia išsiaiškinti tikrąją priežastįGalbūt puslapyje yra dešimtys paslėptų „iframe“ elementų, galbūt tam tikras komponentas per dažnai atvaizduojamas iš naujo arba kiekviename maršrute įkeliama didžiulė tiekėjo biblioteka. Čia labai remiatės „React DevTools Profiler“ ir „Chrome“ laiko juosta.

Įgyvendinimas – tai tikslinių pataisymų taikymas– įsiminti svarbų komponentą, virtualizuojant ilgą sąrašą, skaidant paketą, perkeliant darbą žiniatinklio darbuotojui arba įjungiant SSR tam tikriems puslapiams. Kiekvienas pakeitimas turėtų būti pakankamai mažas, kad būtų galima jį apgalvoti.

Patvirtinimas yra paskutinis ir dažnai labiausiai nepastebimas žingsnisPakartotinai paleidžiate profiliavimo scenarijus ir patikrinate metrikų ataskaitų suvestines, kad įsitikintumėte, jog pakeitimas iš tikrųjų pagerino skaičius ir nesukėlė regresijos kitur sistemoje.

Kai suderinate tinkamą „React“ sudarymą, apgalvotą įsiminimą, nekintamų būsenų praktikas, sąrašų virtualizavimą, strateginį kodo skaidymą, SSR, „Web Workers“ ir nuolatinį matavimą, gaunate „React“ programas, kurios išlieka greitos ir reaguoja greitai, net ir joms tampant sudėtingesnėms.Aukščiau aprašyti metodai skirti ne per ankstyvam mikroderinimui, o architektūros kūrimui, kurioje našumas išlieka natūraliu šalutiniu produktu, o ne nuolatine kova.