Pagina-aanroepen optimaliseren in moderne en klassieke publicatiepagina's van SharePoint

Zowel moderne als klassieke publicatiesites van SharePoint bevatten koppelingen waarmee gegevens worden geladen uit (of oproepen doen naar) SharePoint-functies en CDN's. Hoe meer aanroepen door een pagina worden uitgevoerd, hoe langer het duurt om de pagina te laden. Dit staat bekend als door eindgebruikers waargenomen latentie of EUPL.

Dit artikel helpt u inzicht te krijgen in het bepalen van het aantal en de impact van aanroepen naar externe eindpunten vanaf uw moderne en klassieke publicatiesitepagina's en hoe u het effect ervan op de waargenomen latentie door eindgebruikers kunt beperken.

Opmerking

Zie Prestaties in de moderne SharePoint-ervaring voor meer informatie over prestaties in moderne SharePoint-portals.

Het hulpprogramma Paginadiagnose voor SharePoint gebruiken om pagina-aanroepen te analyseren

Het hulpprogramma Paginadiagnose voor SharePoint is een browserextensie voor de nieuwe browsers Microsoft Edge (https://www.microsoft.com/edge) en Chrome waarmee zowel de pagina's van de moderne SharePoint-portal als de klassieke publicatiesite worden geanalyseerd. Het hulpprogramma biedt een rapport voor elke geanalyseerde pagina waarin wordt weergegeven hoe de pagina presteert op basis van een gedefinieerde set prestatiecriteria. Als u het hulpprogramma Paginadiagnose voor SharePoint wilt installeren en meer wilt weten over het hulpprogramma Paginadiagnose voor SharePoint, gaat u naar Het hulpprogramma Paginadiagnose voor SharePoint gebruiken.

Opmerking

Het hulpprogramma Paginadiagnose werkt alleen voor SharePoint en kan niet worden gebruikt op een SharePoint-systeempagina.

Wanneer u een SharePoint-sitepagina analyseert met het hulpprogramma Paginadiagnose voor SharePoint, ziet u informatie over externe aanroepen in het resultaat Aanvragen voor SharePoint in het deelvenster Diagnostische tests . De regel wordt groen weergegeven als de sitepagina minder dan het basislijnaantal aanroepen bevat en rood als de pagina het basislijnnummer overschrijdt. Het basislijnnummer verschilt voor moderne en klassieke pagina's omdat klassieke sitepagina's HTTP1.1 gebruiken en moderne pagina's HTTP2.0 gebruiken:

• Moderne sitepagina's mogen niet meer dan 25 aanroepen bevatten
• Klassieke publicatiepagina's mogen niet meer dan 6 aanroepen bevatten

Mogelijke resultaten zijn:

• Aandacht vereist (rood): de pagina overschrijdt het aantal aanroepen volgens de basislijn
• Geen actie vereist (groen): de pagina bevat minder dan het basislijnaantal aanroepen

Als het resultaat Aanvragen voor SharePoint wordt weergegeven in de sectie Aandacht vereist , kunt u op het resultaat klikken voor meer informatie, inclusief het totale aantal aanroepen op de pagina en een lijst met DE URL's.

Prestatieproblemen met betrekking tot te veel aanroepen op een pagina oplossen

Als een pagina te veel aanroepen bevat, kunt u de lijst met URL's in de resultaten Aanvragen voor SharePoint gebruiken om te bepalen of er sprake is van herhaalde aanroepen, aanroepen die batchgewijs moeten worden uitgevoerd of aanroepen die gegevens retourneren die in de cache moeten worden opgeslagen.

Batchverwerking van REST-aanroepen kan helpen om de overhead van de prestaties te verminderen. Zie Batchaanvragen maken met de REST API-API's voor meer informatie over het batchen van API-aanroepen.

Het gebruik van een cache om de resultaten van een API-aanroep op te slaan, kan de prestaties van een warme aanvraag verbeteren door de client toe te staan de gegevens in de cache te gebruiken in plaats van een extra aanroep te doen voor elke volgende paginalading. Er zijn meerdere manieren om deze oplossing te benaderen, afhankelijk van de bedrijfsbehoefte. Als de gegevens voor alle gebruikers hetzelfde zijn, is het gebruik van een cachingservice in de middelste laag, zoals Azure Redis-cache, een goede optie om HET API-verkeer voor een site aanzienlijk te verminderen, omdat de gebruikers de gegevens zouden aanvragen bij de cachingservice in plaats van rechtstreeks bij SPO. De enige SPO-aanroepen die nodig zijn, zijn het vernieuwen van de cache van de middelste laag. Als de gegevens per individuele gebruiker fluctueren, is het misschien het beste om een cache aan de clientzijde te implementeren, zoals LocalStorage of zelfs een cookie. Dit vermindert nog steeds de aanroepvolumes door latere aanvragen van dezelfde gebruiker voor de cacheduur te elimineren, maar is minder efficiënt dan een toegewezen cacheservice. Met PnP kunt u LocalStorage gebruiken met weinig extra ontwikkeling.

Voordat u pagina-revisies aanbrengt om prestatieproblemen op te lossen, noteert u de laadtijd van de pagina in de analyseresultaten. Voer het hulpprogramma opnieuw uit na de revisie om te zien of het nieuwe resultaat binnen de basislijnstandaard valt en controleer de laadtijd van de nieuwe pagina om te zien of er een verbetering is opgetreden.

Opmerking

De laadtijd van pagina's kan variëren op basis van verschillende factoren, zoals netwerkbelasting, tijdstip van de dag en andere tijdelijke omstandigheden. U moet de laadtijd van de pagina een paar keer testen voor en na het aanbrengen van wijzigingen, zodat u het gemiddelde van de resultaten kunt berekenen.

Verwante onderwerpen

Afstemmen SharePoint prestaties

Prestaties van Office 365 afstemmen

Prestaties in de moderne SharePoint-ervaring

Netwerken voor contentlevering

Het CDN (Content Delivery Network) van Office 365 gebruiken met SharePoint