Monitoring 5 min lukuaika

Synteettinen valvonta vai todellisten käyttäjien valvonta (RUM): kumpi sinulle?

Synteettiset tarkistukset testaavat sivustoasi aikataulun mukaan, RUM mittaa todellisia käyntejä. Miten kumpikin toimii, mitä kumpikin ei näe ja mistä aloittaa.

Synteettinen valvonta testaa verkkosivustoasi tai API:asi skriptatuilla pyynnöillä aikataulun mukaan, kävipä sivustolla kukaan tai ei. Todellisten käyttäjien valvonta (RUM) mittaa, mitä oikeat kävijät kokevat, heidän selaimessaan toimivalla skriptillä, mutta vain silloin, kun he käyvät sivustolla. Synteettiset tarkistukset kertovat, että jokin on rikki, usein ennen kuin asiakkaat huomaavat. RUM kertoo, kuinka nopea ja sujuva sivusto on sen käyttäjille heidän omilla laitteillaan ja verkoillaan. Aloita synteettisillä tarkistuksilla käytettävyyden valvontaan ja lisää RUM, kun todellisten kävijöiden kokema suorituskyky on kysymys, johon tarvitset vastauksen.

Miten synteettinen valvonta toimii

Valvontapalvelu esittää kävijää. Se lähettää tunnetusta sijainnista kiinteän aikataulun mukaan pyynnön tai ajaa skriptin ja arvioi tuloksen. Koska se tekee joka kerta saman asian, tulokset ovat vertailukelpoisia tarkistuksesta toiseen, ja kello 03.00 sattunut vika löytyy kello 03.00 ilman ainuttakaan kävijää. Synteettisellä valvonnalla on useita muotoja:

Käytettävyystarkistukset: yksi pyyntö URL-osoitteeseen, isäntään tai porttiin, josta tarkistetaan tilakoodi, vasteaika ja usein myös sisältö. Tämä on yksinkertaisin muoto; katso mitä käytettävyyden valvonta on.

API-tarkistukset: pyyntö, jolla on metodi, otsakkeet ja runko, sekä tarkistukset palautuvalle JSONille.

Monivaiheiset polut: kokonainen käyttäjäpolku, kuten kirjautuminen tai kassalla maksaminen, ajettuna vaihe vaiheelta joko tavallisina HTTP-pyyntöinä tai oikeassa selaimessa, joka suorittaa JavaScriptiä.

Suorituskyvyn laboratoriotestit: Lighthousen kaltainen työkalu lataa sivun simuloidulla laitteella ja verkolla ja pisteyttää sen.

Miten todellisten käyttäjien valvonta toimii

Todellisten käyttäjien valvonta lisää sivuillesi skriptin. Se lukee jokaisen kävijän selaimessa ajoitustietoja, joita selaimet tarjoavat standardirajapintojen, kuten Navigation Timingin, kautta, ja lähettää ne keräyspalvelimelle. Kun käynnit kootaan yhteen, saat jakaumia: kuinka kauan sivujen lataaminen kestää, kuinka nopeasti ne reagoivat klikkauksiin ja mitkä sivut tuottavat JavaScript-virheitä, eriteltynä maan, laitteen ja selaimen mukaan.

Koska tulokset ovat jakaumia, RUM raportoi prosenttipisteitä yksittäisten lukujen sijaan. Googlen Core Web Vitals -mittarit mitataan sivulatausten 75. prosenttipisteessä, ja hyvän kokemuksen raja-arvot ovat:

Largest Contentful Paint (lataus): enintään 2,5 sekuntia.

Interaction to Next Paint (reagointi): enintään 200 millisekuntia.

Cumulative Layout Shift (visuaalinen vakaus): enintään 0,1.

On myös RUM-dataa, jota et kerää itse. Googlen Chrome UX Report (CrUX) julkaisee kenttädataa sen sallivilta Chromen käyttäjiltä sivu- ja sivustokohtaisesti, kunhan liikennettä on riittävästi. Sitä dataa Google käyttää Core Web Vitals -mittareihin hakutuloksissa.

Rinnakkain

Synteettinen valvontaTodellisten käyttäjien valvontaKuka tuottaa datanValvontapalvelu, aikataulun mukaanKävijäsi, kun he käyvät sivustollaVaatii liikennettäEiKylläVaatii skriptin sivuillesiEiKylläHavaitsee katkonKyllä, seuraavassa tarkistuksessaEpäsuorasti, kun dataa ei enää tuleKattaaSkriptaamasi sivut ja polutJokaisen sivun, jolla käydäänLaitteet ja verkotMuutama tunnettuKaikkien kävijöidesiTuloksetOnnistui tai epäonnistui, ajoitus per tarkistusJakaumat ja prosenttipisteetSopii parhaitenKäytettävyyteen, hälytyksiin ja julkaisujen jälkeisten regressioiden havaitsemiseenTodelliseen suorituskykyyn, Core Web Vitals -mittareihin ja selaimen virheisiin

Mitä kumpikin jättää näkemättä

Synteettisen valvonnan katvealueet

Polut, joita et skriptannut. Jos kassapolku testaa yhtä tuotetta, toisen kategorian rikkinäinen sivu jää huomaamatta.

Kävijöidesi sijainti. Yhdestä kaupungista tehty tarkistus näkee sen kaupungin reitin palvelimellesi, ei toisella mantereella mobiiliverkossa olevan kävijän reittiä.

Oikeat laitteet. Hidas puhelin, selainlaajennus tai vanha selainversio voi rikkoa tai hidastaa sivun, joka läpäisee jokaisen tarkistuksen.

RUM:n katvealueet

Ei kävijöitä, ei dataa. Yöllä, uudella sivulla tai vähäisen liikenteen sivustolla RUM:lla on vähän tai ei mitään kerrottavaa.

Katkot. Kun sivusto on alhaalla, skripti ei koskaan lataudu, joten mitään ei raportoida. Aukko kaaviossa jää helposti huomaamatta, eikä se herätä ketään.

Kävijät, joita et voi mitata. Mainosten esto ja evästevalinnat voivat estää skriptin, joten data kuvaa niitä kävijöitä, jotka sallivat sen.

Kuorma. Skripti itsessään on sivulle lisätyötä. Lataa se asynkronisesti ja tarkista sen koko.

Laboratoriodata vs. kenttädata

Sama jako näkyy suorituskykytyökaluissa, joissa puhutaan laboratorio- ja kenttädatasta. Lighthouse-pisteet ovat laboratoriodataa: yksi synteettinen sivulataus simuloidulla keskitason puhelimella ja verkolla. CrUX ja oma RUM-datasi ovat kenttädataa: sitä, mitä todelliset käynnit mittasivat. Ne ovat usein eri mieltä. Sivu voi saada heikot pisteet laboratoriossa ja silti läpäistä Core Web Vitals -mittarit kentällä, koska useimmilla kävijöillä on nopeat laitteet, tai päinvastoin. Käytä laboratoriodataa ongelmien löytämiseen ja korjaamiseen sekä julkaisujen vertailuun keskenään ja kenttädataa sen arviointiin, mitä kävijät oikeasti saavat. Vinkit nopeammin latautuvaan verkkosivustoon auttavat molemmissa, ja mikä on hyvä vasteaika käsittelee palvelinpuolta.

Kummasta aloittaa

Jokainen sivusto: synteettiset käytettävyystarkistukset etusivulle ja sivuille, jotka tuovat rahaa. Katko maksaa enemmän kuin hidas sivu, ja vain synteettiset tarkistukset hälyttävät siitä luotettavasti. Tarkistuslista siitä, mitä valvoa, luettelee kattamisen arvoiset URL-osoitteet.

Verkkokaupat ja SaaS-tuotteet: lisää monivaiheiset polut kassalle tai kirjautumiselle, jotta rikkinäinen polku huomataan, vaikka jokainen yksittäinen sivu vastaisi 200.

Sivustot, joille hakuliikenne on tärkeää: seuraa CrUX:n Core Web Vitals -mittareita ja päivittäistä laboratoriotestiä, jotta hidas julkaisu huomataan ennen kuin se näkyy sijoituksissa.

Suuret tai kansainväliset yleisöt ja monimutkaiset käyttöliittymät: lisää RUM, niin näet suorituskyvyn ja JavaScript-virheet maittain, laitteittain ja sivuittain.

Miten ne toimivat yhdessä

Kuvitellaan verkkokauppa, joka julkaisee uuden kassan tiistai-iltapäivänä. Keskiviikkona kello 03.12 maksuvaihe alkaa aikakatkaista. Kukaan ei ole ostoksilla, joten RUM ei näytä mitään poikkeavaa, mutta synteettinen kassapolku epäonnistuu, toinen tarkistus vahvistaa sen ja päivystävä kehittäjä saa hälytyksen. Korjattu kello 03.30 mennessä. Torstaina RUM näyttää, että uuden kassan Interaction to Next Paint on kaksinkertaistunut Android-kävijöillä, mitä mikään nopealta palvelimelta tehty synteettinen tarkistus ei olisi huomannut. Toinen työkalu huomasi katkon, toinen hitaan kokemuksen. Näin työt yleensä jakautuvat.

Mitä Uptimecheck kattaa ja mitä ei

Uptimecheck on synteettisen valvonnan palvelu. Se ei lisää sivuillesi RUM-skriptiä, joten omien kävijöidesi ajoituksiin ja JavaScript-virheisiin tarvitset sen rinnalle erillisen RUM-työkalun. Tätä se tekee:

Käytettävyyden valvonta: HTTP(S)-, ping- ja porttitarkistukset jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista, avainsana-, JSON- ja otsaketarkistuksineen, ja jokainen virhe vahvistetaan toisesta sijainnista ennen hälytystä. Vasteajat eritellään DNS:ään, yhteyden muodostukseen, TLS:ään, palvelimeen ja lataukseen.

Käyttäjäpolkujen valvonta: enintään 10 vaihetta, kuten sivun avaaminen, kirjautuminen, lomakkeen lähettäminen tai API-kutsu, ja arvot siirtyvät vaiheesta seuraavaan. Pelkkiä pyyntöjä käyttävät polut voivat toimia minuutin välein; oikeassa selaimessa ajettavat polut suorittavat JavaScriptiä ja klikkauksia enintään 15 minuutin välein, ja epäonnistuneesta vaiheesta otetaan kuvakaappaus.

Sivunopeuden valvonta: päivittäinen Lighthouse-testi mobiilille ja työpöydälle etusivulle ja enintään 4 muulle sivulle sekä, sivuille ja sivustoille, joilla on tarpeeksi käyntejä, Chrome UX Reportista se, mitä todelliset Chromen käyttäjät kokivat 28 päivän aikana. Saat hälytyksen, kun sivun pisteet laskevat asettamasi rajan alle.

Käyttäjäpolun määrittämisestä kerrotaan ohjeissa kirjautumisen tai kassan valvonta polulla ja sivunopeuden tarkistaminen. Paketit alkaen 9 €/kk vuosilaskutuksella tai 12 €/kk kuukausilaskutuksella, alv 0 %; katso hinnoittelusivu.

Tiedä viasta ennen kuin kävijäsi kertovat siitä. Kokeile Uptimecheckiä ilmaiseksi 14 päivää, luottokorttia ei tarvita.

Kysymykset

Mikä ero on synteettisellä valvonnalla ja todellisten käyttäjien valvonnalla?

Synteettinen valvonta testaa sivustoa skriptatuilla pyynnöillä aikataulun mukaan tunnetuista sijainneista. Todellisten käyttäjien valvonta kerää ajoitukset ja virheet oikeiden kävijöiden selaimista sivulla olevan skriptin avulla.

Tarvitsenko sekä synteettisen valvonnan että RUM:n?

Useimmat sivustot aloittavat synteettisillä tarkistuksilla, koska ne hälyttävät katkoista ja rikkinäisistä poluista. Lisää RUM, kun haluat tietää, kuinka nopea sivusto on todellisille kävijöille heidän omilla laitteillaan ja verkoillaan.

Voiko todellisten käyttäjien valvonta havaita katkoja?

Ei luotettavasti. Kun sivusto on alhaalla, skripti ei lataudu, joten dataa ei yksinkertaisesti enää tule. Käytä käytettävyystarkistuksia saadaksesi hälytyksen.

Tarjoaako Uptimecheck todellisten käyttäjien valvontaa?

Ei. Uptimecheck ajaa synteettisiä tarkistuksia: käytettävyystarkistuksia, monivaiheisia polkuja ja päivittäisiä Lighthouse-testejä. Sivunopeuden valvonnat näyttävät lisäksi todellisten Chromen käyttäjien Core Web Vitals -arvot Googlen Chrome UX Reportista, kun sivulla tai sivustolla on tarpeeksi liikennettä.

Jatka lukemista

Monitoring 7 min lukuaika

Mikä on hyvä verkkosivuston vasteaika?

Vasteaika on se, kuinka kauan palvelimelta kestää vastata pyyntöön, ei se, kuinka kauan sivun lataaminen kestää. Mikä on hyvä, miksi valvonta ja selaimet mittaavat eri tavoin ja mikä hidastaa sivustoja.

Luku

Guides 5 min lukuaika

429 Too Many Requests: pyyntörajoitukset, Retry-After ja backoff

429 tarkoittaa, että asiakasohjelma lähetti liian monta pyyntöä liian lyhyessä ajassa. Miten pyyntörajoitukset toimivat, mitä Retry-After kertoo, miten viivettä pidennetään ja miksi käytettävyyden valvonta voi törmätä rajoitukseen.

Luku

Guides 5 min lukuaika

403 Forbidden -virhe: mitä se tarkoittaa ja miten sen korjaa

403 tarkoittaa, että palvelin ymmärsi pyynnön ja kieltäytyi siitä. Tavalliset syyt, mitä kävijä voi kokeilla, miten ylläpitäjä löytää estävän säännön ja miksi valvonta saa 403:n, vaikka selain ei saa.

Luku

Katkot ovat menneisyyttä.

Luo ensimmäinen valvontasi alle minuutissa – tai tutustu ensin live-demoon.

14 päivän ilmainen kokeilu · Sen jälkeen ilmainen 5 valvonnalle · Ei luottokorttia