Hoe u Page Speed-monitoring instelt

Hoofdinstellingen

Voor dit checktype is er geen aparte screenshot van de groep Hoofdinstellingen, maar elke regelaar erin is standaard bij elk monitortype van HostTracker:

• Domein/IP - de URL of het domein om te laden. Accepteert een volledige URL of een kaal domein.
• Naam - een optioneel label dat wordt getoond in uw dashboard, waarschuwingen, rapporten en widgets. Leeg gelaten wordt de URL gebruikt.
• Intervalschema / Cronschema - een gesegmenteerde schakelaar tussen een eenvoudig terugkerend interval en een volledige cron-expressie (voorinstellingen voor elk uur, dagelijks, wekelijks, maandelijks, of geavanceerde cron-syntax). Het minimaal beschikbare interval hangt af van uw pakket.
• Tags - vrije labels om deze monitor te groeperen en te filteren.
• Volledig log - bewaart elk individueel checkresultaat voor deze monitor zonder ze te groeperen.
• Open statistieken - laat u de statistieken en logs van deze monitor delen met anderen, inclusief mensen die niet zijn aangemeld.

Deze groep bevat ook de schakelaar Ingeschakeld die de monitor pauzeert of hervat.

Pagina-configuratie

• Device emulation - een keuzelijst die de pagina laadt zoals een specifiek apparaat dat zou doen: viewportgrootte, user-agent-string en touch-inputemulatie. De standaard is Desktop. De lijst met beschikbare apparaten wordt live opgehaald uit de eigen mogelijkheden van de agentvloot, dus de exacte opties kunnen na verloop van tijd groeien; kies het apparaat dat het beste past bij hoe uw bezoekers de pagina bekijken.
• Page load timeout - de maximale tijd die de pagina heeft om klaar te zijn met laden, van 1 tot 40 seconden. Is de pagina dan nog niet klaar, dan faalt de check.

Beide instellingen veranderen wat de cijfers betekenen, en ook of de check slaagt. Een telefoongrootte viewport kan een andere reeks afbeeldingen, lay-out en scripts activeren dan een desktopviewport van dezelfde pagina, dus de timing van een mobiel-geëmuleerde run is niet rechtstreeks vergelijkbaar met een desktoprun - behandel elke apparaatinstelling als zijn eigen baseline. Page load timeout is een plafond, geen doel: het bepaalt alleen het punt waarop de check opgeeft en een mislukking meldt. Stelt u het te dicht bij de normale laadtijd van uw pagina in, dan verandert gewone variatie in valse alarmen; stel het in met marge en kijk in plaats daarvan naar de werkelijke laadtijd in uw resultaten.

Antwoordvalidatie

Dit is geen Core Web Vitals-score - HostTracker berekent hier geen Lighthouse-achtig prestatiecijfer. In plaats daarvan telt het concrete mislukkingen op browserniveau en resourcegebruikslimieten, en beslist u zelf welke daarvan als Down moeten tellen. Elke drempel hieronder kan op 0 worden gezet (of, voor CPU en geheugen, op "geen drempel") om hem uit te schakelen.

Page health:

• Document/IFrame loading fail threshold - de check gaat Down zodra minstens dit aantal documenten of iframes op de pagina niet laadt. Bereik 0-50; 0 schakelt hem uit.
• CPU usage threshold - de check gaat Down wanneer het CPU-gebruik van de pagina (per core) dit percentage bereikt. De schuif dekt alleen 80-100%, dus hij vangt zware CPU-pieken op in plaats van gewone belasting; een aparte regelaar "geen drempel" schakelt hem helemaal uit, wat de standaard is.
• Memory usage threshold - de check gaat Down wanneer het geheugengebruik van de pagina dit bedrag bereikt, in megabytes. Bereik 1-1000 Mb in stappen van 50 Mb, of "geen drempel" om uit te schakelen, wat de standaard is.
• Client-side errors threshold - de check gaat Down zodra minstens dit aantal browserconsolefouten optreedt tijdens het laden van de pagina. Bereik 0-50; 0 schakelt hem uit.
• Client-side warns threshold - hetzelfde idee voor consolewaarschuwingen. Bereik 0-50; 0 schakelt hem uit.

Content Load Checks:

• Page load timeout without XHR - een alternatieve, kortere timeout die geldt zodra alle achtergrond-XHR/AJAX-verzoeken van de pagina tot rust zijn gekomen, los van de Page load timeout hierboven. Staat deze op 0 (de standaard), dan geldt alleen de hoofd-page-load-timeout; een waarde groter dan 0 laat u een pagina accepteren waarvan de zichtbare inhoud klaar is terwijl achtergrondpolling nog doorgaat.
• Total load fails threshold - de check gaat Down zodra minstens dit aantal resources, van welke soort dan ook, niet laadt. Bereik 0-50; 0 schakelt hem uit.
• Script / Stylesheet / Image / Font / AJAX request fails threshold - hetzelfde mislukkingsaantal, uitgesplitst per resourcetype, zodat u een wispelturige advertentieafbeelding kunt tolereren zonder een kapot script te tolereren. Elk gaat van 0-50, 0 schakelt hem uit.

Monitoringlocaties

• Locaties - een doorzoekbare selectievakjesboom van regio's en individuele monitoringpunten. Kies specifieke locaties of laat "All world" aangevinkt.
• Hercontrolestrategie - wat er gebeurt wanneer een check een statuswijziging detecteert. Standaard draait de check opnieuw vanaf meerdere locaties en accepteert hij de nieuwe status via meerderheidsstemming, ter bescherming tegen een valse melding vanaf één wispelturige locatie. Alternatieven: een vastgesteld aantal locaties moet een Down bevestigen (onthult een schuif voor Down-bevestigingen van 1 tot 7); helemaal geen hercontrole; volledige overeenstemming van elke hercontrolelocatie; of volledige overeenstemming voor Down terwijl Up slechts een meerderheid nodig heeft.
• Als geselecteerde locaties onbeschikbaar zijn - "Alleen geselecteerde locaties" (standaard) wacht tot uw gekozen locaties terugkomen; "Dichtstbijzijnde locaties" vervangt ze door de dichtstbijzijnde beschikbare; "Elke locatie" valt wereldwijd terug.

Waarschuwingsabonnementen

Een schakelaar abonneert elk contact in één stap op Up/Down-gebeurtenissen, of een doorzoekbare tabel laat u individuele contacten onafhankelijk abonneren op Down, Up en Repeat (herhaalde Down-herinneringen). Laat u dit onderdeel leeg, dan worden er voor deze monitor geen waarschuwingen verstuurd - het paneel waarschuwt u daar expliciet voor.

Rapportabonnementen

Hetzelfde patroon geldt voor uptimerapporten: een schakelaar abonneert elk contact op Weekly- en Monthly-rapporten, of u kiest Daily, Weekly en Monthly per contact afzonderlijk.

Uitgewerkt voorbeeld

Stel dat u wilt bekijken hoe een afrekenpagina presteert voor mobiele shoppers. U kiest Page Speed, voert de URL van de afrekenpagina in, en zet Device emulation op een telefoonprofiel in plaats van Desktop, want het meeste verkeer op die pagina is mobiel. Laat Page load timeout ruim boven de normale laadtijd van de pagina - het is een plafond bedoeld om echte mislukkingen te vangen, geen prestatiedoel. Zet in Antwoordvalidatie de Document/IFrame loading fail threshold op 1, want de pagina laadt gewoonlijk een betaal-iframe en u wilt weten of dat stopt met laden. Laat de drempels voor CPU- en Memory-gebruik op "geen drempel", want een afrekenpagina is zelden CPU- of geheugenintensief en die drempels beginnen sowieso pas bij 80%. Zet de Total load fails threshold op 2 of 3 in plaats van 0, zodat één wispelturige tracker van een derde partij uw team niet elke keer alarmeert bij een hikje, terwijl een echt kapotte lading de check nog steeds laat afgaan. Laat Page load timeout without XHR op 0, want afrekenpagina's pollen vaak op de achtergrond naar de betaalstatus en dat hoort niet te bepalen of de check slaagt of faalt. Draai de check vanaf twee of drie locaties dicht bij uw echte klanten, houd de standaard hercontrolestrategie op meerderheidsstemming aan, abonneer uw wachtdienstcontact op Down- en Repeat-waarschuwingen, en stel een wekelijks rapport in naar een gedeeld teamadres.

Probleemoplossing

• De check meldt Down maar de pagina ziet er prima uit wanneer u hem zelf opent. Een laadmislukkingsteller (Script, Image, Total, enzovoort) sloeg waarschijnlijk aan op een wispelturige resource van een derde partij, zoals een advertentienetwerk of analyticsscript, in plaats van uw eigen pagina. Controleer welke teller afging voordat u een echte storing aanneemt, en overweeg hem van 0 naar 1 of 2 te verhogen als die wispelturigheid een bekend, tolereerbaar patroon is.
• Laadtijden veranderden merkbaar nadat u Device emulation wisselde. Verwacht, geen regressie: een ander apparaatprofiel verandert het viewport, de user agent en de touch-emulatie, wat verandert wat de pagina laadt en hoe die wordt weergegeven. Vergelijk timings alleen binnen dezelfde apparaatinstelling.
• De check blijft de Page load timeout raken, ook al laadt de pagina prima in uw eigen browser. De monitoringlocatie kan ver van uw server liggen, of de timeout meet de volledige lading inclusief trage achtergrondverzoeken. Verhoog de timeout met echte marge, en probeer een Page load timeout without XHR groter dan 0 als de pagina op de achtergrond blijft pollen nadat de zichtbare inhoud klaar is.
• De drempels voor CPU- of Memory-gebruik lijken nooit af te gaan, zelfs bij een zware pagina. Beide beginnen op "geen drempel", en de CPU-schuif dekt eenmaal ingeschakeld alleen 80-100%. Is het bijhouden van zwaar resourcegebruik belangrijk, zet de regelaar dan expliciet uit "geen drempel" en kies een waarde binnen het bereik.
• Consolewaarschuwingen van advertentie- of analyticsscripts blijven de Client-side warns threshold laten afgaan. Veel scripts van derden loggen waarschuwingen die geen echte problemen zijn. Laat deze drempel op 0, of zet hem boven het normale aantal waarschuwingen van uw pagina.

Gerelateerd

• Browsertoegangstiming-monitoring - de productpagina voor dit checktype.
• Gratis page-speed-test - voer een eenmalige check uit voordat u doorlopende monitoring instelt.
• Handleiding Transaction Check - om een meerstaps-gebruikersreis te scripten in plaats van één paginalading te bekijken.
• Regels voor antwoordvalidatie - de regeltaal die wordt gebruikt om HTTP- en API-checks te valideren.
• Hoe u de snelheid van een website controleert - de eenmalige test, en wat elk tijdcijfer betekent.
• Alle monitoringhandleidingen - de opzetgids voor elk ander checktype.