Optimera sidanrop i SharePoint på moderna och klassiska publiceringswebbplatssidor i Microsoft 365
Både SharePoint i Microsoft 365 moderna och klassiska publiceringswebbplatser innehåller länkar som läser in data från (eller gör anrop till) SharePoint-funktioner och CDN:er. Ju fler anrop som görs av en sida, desto längre tid tar det att läsa in sidan. Detta kallas slutanvändarens upplevda svarstid eller EUPL.
Den här artikeln hjälper dig att förstå hur du fastställer antalet och effekten av anrop till externa slutpunkter från dina moderna och klassiska publiceringswebbplatssidor och hur du begränsar deras effekt på slutanvändarens upplevda svarstid.
Obs!
Mer information om prestanda i moderna SharePoint-portaler finns i Prestanda i den moderna SharePoint-upplevelsen.
Använda verktyget Siddiagnostik för SharePoint för att analysera sidanrop
Verktyget Siddiagnostik för SharePoint är ett webbläsartillägg för Microsoft Edge- och Chrome-webbläsare som analyserar både SharePoint på moderna microsoft 365-portalens och den klassiska publiceringswebbplatsens sidor. Verktyget innehåller en rapport för varje analyserad sida som visar hur sidan presterar mot en definierad uppsättning prestandakriterier. Om du vill installera och lära dig mer om verktyget Siddiagnostik för SharePoint går du till Använd verktyget Siddiagnostik för SharePoint.
Obs!
Verktyget Siddiagnostik fungerar bara för SharePoint i Microsoft 365 och kan inte användas på en SharePoint-systemsida.
När du analyserar en SharePoint-webbplatssida med verktyget Siddiagnostik för SharePoint kan du se information om externa anrop i resultatet Begäranden till SharePoint i fönstret Diagnostiktester . Raden visas i grönt om webbplatssidan innehåller färre anrop än baslinjenumret och röd om sidan överskrider baslinjenumret. Baslinjenumret skiljer sig åt för moderna och klassiska sidor eftersom klassiska webbplatssidor använder HTTP1.1 och moderna sidor använder HTTP2.0:
- Moderna webbplatssidor får inte innehålla fler än 25 anrop
- Klassiska publiceringssidor får inte innehålla fler än 6 anrop
Möjliga resultat är:
- Uppmärksamhet krävs (röd): Sidan överskrider baslinjenumret för anrop
- Ingen åtgärd krävs (grön): Sidan innehåller färre än baslinjenumret för anrop
Om resultatet Begäranden till SharePoint visas i avsnittet Uppmärksamhet krävs kan du klicka på resultatet för information, inklusive det totala antalet anrop på sidan och en lista över URL:erna.
Åtgärda prestandaproblem som rör för många anrop på en sida
Om en sida innehåller för många anrop kan du använda listan över URL:er i resultaten begäranden till SharePoint för att avgöra om det finns upprepade anrop, anrop som ska batchas eller anrop som returnerar data som ska cachelagras.
Batchbearbetning av REST-anrop kan bidra till att minska prestandakostnaderna. Mer information om batchbearbetning av API-anrop finns i Skapa batchbegäranden med REST-API:erna.
Om du använder en cache för att lagra resultatet av ett API-anrop kan du förbättra prestandan för en varm begäran genom att tillåta att klienten använder cachelagrade data i stället för att göra ytterligare ett anrop för varje efterföljande sidinläsning. Det finns flera sätt att hantera den här lösningen beroende på affärsbehovet. Om data vanligtvis är desamma för alla användare är det ett bra alternativ att använda en cachelagringstjänst på mellannivå som Azure Redis-cachen för att avsevärt minska API-trafiken mot en webbplats, eftersom användarna begär data från cachelagringstjänsten i stället för direkt från SPO. Det enda SPO-anrop som behövs är att uppdatera mellannivåns cacheminne. Om data varierar individuellt kan det vara bäst att implementera en cache på klientsidan, till exempel LocalStorage eller till och med en cookie. Detta minskar fortfarande samtalsvolymerna genom att eliminera efterföljande begäranden som görs av samma användare under cachens varaktighet, men är mindre effektivt än en dedikerad cachelagringstjänst. Med PnP kan du använda LocalStorage med lite ytterligare utveckling som krävs.
Innan du gör sidrevisioner för att åtgärda prestandaproblem bör du anteckna sidinläsningstiden i analysresultaten. Kör verktyget igen efter revisionen för att se om det nya resultatet ligger inom baslinjestandarden och kontrollera den nya sidinläsningstiden för att se om det fanns en förbättring.
Obs!
Sidinläsningstiden kan variera beroende på en mängd olika faktorer, till exempel nätverksbelastning, tid på dagen och andra tillfälliga förhållanden. Du bör testa sidinläsningstiden några gånger före och efter att du har gjort ändringar för att hjälpa dig att beräkna resultatet i genomsnitt.
Relaterade ämnen
Justera prestandan i Microsoft 365
Prestanda i den moderna SharePoint-upplevelsen
Använda Microsoft 365 Content Delivery Network (CDN) med SharePoint