Optimalisere sidekall i SharePoint i moderne og klassiske sider for publiseringsnettsteder i Microsoft 365
Både SharePoint i microsoft 365 moderne og klassiske publiseringsnettsteder inneholder koblinger som laster inn data fra (eller ringer til) SharePoint-funksjoner og CDN-er. Jo flere anrop som foretas av en side, jo lengre tid tar det å laste inn siden. Dette kalles sluttbruker som oppfattet ventetid eller EUPL.
Denne artikkelen hjelper deg med å forstå hvordan du fastslår antallet og virkningen av anrop til eksterne endepunkter fra de moderne og klassiske publiseringsnettstedssidene, og hvordan du begrenser effekten på sluttbrukeren som oppfatter ventetiden.
Obs!
Hvis du vil ha mer informasjon om ytelse i moderne SharePoint-portaler, kan du se Ytelse i den moderne SharePoint-opplevelsen.
Bruke verktøyet Sidediagnose for SharePoint til å analysere sideanrop
Verktøyet Sidediagnose for SharePoint er en nettleserutvidelse for Microsoft Edge- og Chrome-nettlesere som analyserer både SharePoint i den moderne Microsoft 365-portalen og klassiske publiseringsnettstedssider. Verktøyet inneholder en rapport for hver analyserte side som viser hvordan siden yter mot et definert sett med ytelsesvilkår. Hvis du vil installere og finne ut mer om sidediagnose for SharePoint-verktøyet, kan du gå til verktøyet For sidediagnose for SharePoint.
Obs!
Sidediagnoseverktøyet fungerer bare for SharePoint i Microsoft 365, og kan ikke brukes på en SharePoint-systemside.
Når du analyserer en SharePoint-områdeside med verktøyet Sidediagnose for SharePoint, kan du se informasjon om eksterne anrop i Forespørsler til SharePoint-resultat i diagnosetestruten . Linjen vises i grønt hvis områdesiden inneholder færre enn opprinnelig antall kall, og rød hvis siden overskrider det opprinnelige tallet. Grunnlinjenummeret er forskjellig for moderne og klassiske sider fordi klassiske nettstedssider bruker HTTP1.1 og moderne sider bruker HTTP2.0:
- Moderne nettstedssider bør ikke inneholde mer enn 25 anrop
- Klassiske publiseringssider bør ikke inneholde mer enn seks kall
Mulige resultater inkluderer:
- Oppmerksomhet kreves (rød): Siden overskrider opprinnelig antall kall
- Ingen handling kreves (grønn): Siden inneholder færre enn opprinnelig antall kall
Hvis resultatet av Forespørsler til SharePoint vises i delen Oppmerksomhet kreves , kan du klikke resultatet for detaljer, inkludert totalt antall anrop på siden og en liste over nettadressene.
Utbedre ytelsesproblemer relatert til for mange oppkall på en side
Hvis en side inneholder for mange anrop, kan du bruke listen over nettadresser i resultatene av Forespørsler til SharePoint til å avgjøre om det finnes gjentatte anrop, anrop som skal utføres, eller kall som returnerer data som skal bufres.
Batching REST-samtaler kan bidra til å redusere ytelseskostnader. Hvis du vil ha mer informasjon om API-anropsgruppering, kan du se Foreta satsvise forespørsler med REST-API-ene.
Hvis du bruker en hurtigbuffer til å lagre resultatene av et API-kall, kan du forbedre ytelsen til en varm forespørsel ved å la klienten bruke de bufrede dataene i stedet for å foreta et ekstra kall for hver etterfølgende sidebelastning. Det finnes flere måter å nærme seg denne løsningen på, avhengig av forretningskravet. Vanligvis hvis dataene vil være de samme for alle brukere, er bruk av en hurtigbufringstjeneste på mellomnivå som Azure Redis-hurtigbuffer et flott alternativ for å redusere API-trafikk betydelig mot et nettsted, da brukerne vil be om dataene fra hurtigbufringstjenesten i stedet for direkte fra SPO. Det eneste SPO-anropet som trengs, er å oppdatere hurtigbufferen på mellomnivå. Hvis dataene varierer på individuell brukerbasis, kan det være best å implementere en hurtigbuffer på klientsiden, for eksempel LocalStorage eller til og med en informasjonskapsel. Dette vil fortsatt redusere samtalevolumer ved å fjerne etterfølgende forespørsler fra samme bruker for hurtigbuffervarigheten, men vil være mindre effektiv enn en dedikert hurtigbufringstjeneste. Med PnP kan du bruke LocalStorage med lite ekstra utvikling som kreves.
Før du foretar siderevisjoner for å løse ytelsesproblemer, noterer du sideinnlastingstiden i analyseresultatene. Kjør verktøyet på nytt etter revisjonen for å se om det nye resultatet er innenfor grunnlinjestandarden, og kontroller den nye sideinnlastingstiden for å se om det var en forbedring.
Obs!
Sideinnlastingstiden kan variere basert på en rekke faktorer, for eksempel nettverksbelastning, klokkeslett og andre midlertidige forhold. Du bør teste innlastingstiden for siden et par ganger før og etter at du har gjort endringer for å hjelpe deg med å finne gjennomsnittet av resultatene.
Beslektede emner
Ytelse i den moderne SharePoint-opplevelsen
Bruke Microsoft 365 Content Delivery Network (CDN) med SharePoint