Optimera sidsamtal i SharePoint moderna och klassiska publiceringswebbplatssidor
Både SharePoint moderna och klassiska publiceringswebbplatser innehåller länkar som läser in data från (eller ringer till) SharePoint och CDN. Ju fler samtal en sida ringer, desto längre tid tar det att läsa in sidan. Detta kallas för att slutanvändaren uppfattas som fördröjning eller EUPL.
Den här artikeln hjälper dig att förstå hur du fastställer antal och påverkan på samtal till externa slutpunkter från dina moderna och klassiska publiceringswebbplatssidor och hur du kan begränsa effekten på slutanvändarens uppfattas svarstid.
Anteckning
Mer information om prestanda i SharePoint moderna portaler finns i Prestanda i det moderna SharePoint upplevelsen.
Använda siddiagnostik för SharePoint för att analysera sidsamtal
Siddiagnostik för SharePoint är ett webbläsartillägg för nya Microsoft Edge ( och Chrome-webbläsare som analyserar både moderna SharePoint Online-portalen och klassiska https://www.microsoft.com/edge) publiceringswebbplatssidor. Verktyget innehåller en rapport för varje analyserad sida som visar hur sidan fungerar mot en definierad uppsättning prestandavillkor. Mer information om verktyget Siddiagnostik för SharePoint finns i Använda verktyget Siddiagnostik för SharePoint Online.
Anteckning
Verktyget Siddiagnostik fungerar bara för SharePoint Online 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 samtal i fönstret Diagnostiktest i begäran om SharePoint-webbplats. Linjen visas i grönt om webbplatssidan innehåller färre än baslinjenumret och röd om sidan överskrider baslinjenumret. Baslinjenumret skiljer sig 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 samtal
- Klassiska publiceringssidor får innehålla högst 6 samtal
Möjliga resultat är:
- Obs! Obligatoriskt (rött): Sidan överskrider baslinjenumret för samtal
- Ingen åtgärd krävs (grön): Sidan innehåller färre än originalantalet samtal
Om resultatet Requests to SharePoint visas i avsnittet Attention required (åtgärder krävs) kan du klicka på resultatet för mer information, inklusive det totala antalet samtal på sidan och en lista över URL:er.

Åtgärda prestandaproblem som är relaterade till för många samtal på en sida
Om en sida innehåller för många samtal kan du använda listan med URL-adresser i url-förfrågningar till SharePoint-resultat för att avgöra om det finns upprepade samtal, samtal som ska batchas eller samtal som returnerar data som ska cachelagras.
Att batcha REST-samtal kan minska prestandan. Mer information om API-anropsbatchning finns i Göra batchbegäranden med REST-API:er.
Om du använder en cache för att lagra resultaten av ett API-anrop kan du förbättra prestandan för en uppvärmningsbegäran genom att låta klienten använda cachelagrade data i stället för att ringa ytterligare ett samtal för varje efterföljande sidinläsning. Det finns flera sätt att hantera den här lösningen beroende på affärsbehovet. Vanligtvis om data är samma för alla användare är en cachelagringstjänst på mellannivå som Azure Redis-cache ett bra alternativ för att avsevärt minska API-trafiken mot en webbplats eftersom användarna skulle begära data från cachelagringstjänsten i stället för direkt från SPO. De enda SPO-anrop som behövs är att uppdatera cachen på mittnivån. Om data fluktuerar för enskilda användare kan det vara bäst att implementera en klientbaserad cache, som LocalStorage eller till och med en cookie. Det här kommer fortfarande att minska samtalsvolymerna genom att du eliminerar efterföljande förfrågningar som görs av samma användare under cachelängden, men kommer att vara 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 sidändringar för att åtgärda prestandaproblem bör du anteckna inläsningstiden för sidan i analysresultatet. Kör verktyget igen efter ändringen för att se om det nya resultatet ligger inom baslinjestandarden och kontrollera inläsningstiden för den nya sidan för att se om det finns en förbättring.

Anteckning
Sidinläsningstiden kan variera beroende på en mängd faktorer, till exempel nätverksbelastning, tid på dagen och andra tillfälliga villkor. Du bör testa inläsningstiden några gånger före och efter ändringarna för att beräkna medelvärdet för resultatet.
Relaterade ämnen
Justera SharePoint onlineprestanda
Prestanda i modern SharePoint upplevelse
Använda Office 365 Content Delivery Network (CDN) med SharePoint Online