Optimer sidekald i SharePoint på moderne og klassiske udgivelseswebstedssider i Microsoft 365
Både SharePoint i Microsoft 365 moderne og klassiske udgivelseswebsteder indeholder links, der indlæser data fra (eller foretager kald til) SharePoint-funktioner og CDN'er. Jo flere opkald en side foretager, jo længere tid tager det at indlæse siden. Dette kaldes slutbrugerens opfattelse af ventetid eller EUPL.
Denne artikel hjælper dig med at forstå, hvordan du kan bestemme antallet og virkningen af kald til eksterne slutpunkter fra dine moderne og klassiske udgivelseswebstedssider, og hvordan du begrænser deres effekt på ventetider, som slutbrugeren opfatter.
Bemærk!
Du kan finde flere oplysninger om ydeevnen på moderne SharePoint-portaler under Ydeevne i den moderne SharePoint-oplevelse.
Brug værktøjet Sidediagnosticering til SharePoint til at analysere sidekald
Værktøjet Sidediagnosticering til SharePoint er en browserudvidelse til Microsoft Edge- og Chrome-browsere, der analyserer både SharePoint i microsoft 365 moderne portal og klassiske sider til udgivelse af websteder. Værktøjet indeholder en rapport for hver analyseret side, der viser, hvordan siden klarer sig i forhold til et defineret sæt ydeevnekriterier. Hvis du vil installere og få mere at vide om værktøjet Sidediagnosticering til SharePoint, skal du gå til Brug værktøjet Sidediagnosticering til SharePoint.
Bemærk!
Værktøjet Sidediagnosticering fungerer kun for SharePoint i Microsoft 365 og kan ikke bruges på en SharePoint-systemside.
Når du analyserer en SharePoint-webstedsside med værktøjet Sidediagnosticering til SharePoint, kan du se oplysninger om eksterne kald i resultatet Anmodninger til SharePoint i ruden Diagnosticeringstest . Linjen vises med grønt, hvis webstedssiden indeholder færre end det oprindelige antal opkald, og rød, hvis siden overskrider det oprindelige tal. Det oprindelige tal er forskelligt for moderne og klassiske sider, fordi klassiske webstedssider bruger HTTP1.1, og moderne sider bruger HTTP2.0:
- Moderne webstedssider må ikke indeholde mere end 25 opkald
- Klassiske udgivelsessider må ikke indeholde mere end 6 opkald
Mulige resultater omfatter:
- Opmærksomhed kræves (rød): Siden overskrider det oprindelige antal opkald
- Der kræves ingen handling (grøn): Siden indeholder færre end det oprindelige antal kald
Hvis resultatet Anmodninger til SharePoint vises i afsnittet Opmærksomhed kræves , kan du klikke på resultatet for at få flere oplysninger, herunder det samlede antal kald på siden og en liste over URL-adresserne.
Løs problemer med ydeevnen, der er relateret til for mange kald på en side
Hvis en side indeholder for mange kald, kan du bruge listen over URL-adresser i anmodningerne til SharePoint-resultaterne til at afgøre, om der er gentagne kald, kald, der skal batches, eller kald, der returnerer data, der skal cachelagres.
Batching af REST-kald kan hjælpe med at reducere ydeevnen. Du kan få flere oplysninger om batching af API-kald under Foretag batchanmodninger med REST API'erne.
Hvis du bruger en cache til at gemme resultaterne af et API-kald, kan det forbedre ydeevnen af en varm anmodning ved at tillade klienten at bruge de cachelagrede data i stedet for at foretage et ekstra kald for hver efterfølgende sideindlæsning. Der er flere måder at nærme sig denne løsning på, afhængigt af forretningskravet. Hvis dataene vil være de samme for alle brugere, er det typisk en god mulighed at reducere API-trafik i forhold til et websted ved hjælp af en cachelagringstjeneste på mellemniveau, f.eks . Azure Redis Cache, da brugerne anmoder om dataene fra cachelagringstjenesten i stedet for direkte fra SPO. Det eneste SPO-kald, der kræves, er at opdatere cachen på det midterste niveau. Hvis dataene varierer på individuel brugerbasis, kan det være bedst at implementere en cache på klientsiden, f.eks. LocalStorage eller endda en cookie. Dette vil stadig reducere opkaldsmængderne ved at fjerne efterfølgende anmodninger fra den samme bruger i cachens varighed, men det vil være mindre effektivt end en dedikeret cachelagringstjeneste. PnP giver dig mulighed for at bruge LocalStorage med lidt yderligere udvikling påkrævet.
Før du foretager sideændringer for at afhjælpe problemer med ydeevnen, skal du notere sideindlæsningstiden i analyseresultaterne. Kør værktøjet igen efter din revision for at se, om det nye resultat er inden for grundlinjestandarden, og kontrollér indlæsningstiden for den nye side for at se, om der var en forbedring.
Bemærk!
Sideindlæsningstiden kan variere afhængigt af en række faktorer, f.eks. netværksbelastning, klokkeslæt på dagen og andre midlertidige forhold. Du bør teste indlæsningstiden for siden et par gange før og efter at have foretaget ændringer for at hjælpe dig med at beregne gennemsnittet af resultaterne.
Relaterede emner
Ydeevne i den moderne SharePoint-oplevelse
Brug Microsoft 365 Content Delivery Network (CDN) med SharePoint