Rakendus: mõõda oma veebisaidi reageerimisaega selle lihtsa mõõdikute tööriistaga
Kui veebisait laadib aeglaselt, pole alati selge, milles süüdi on. Kas see on... DNS pakkuja? Server ise? Või midagi vahepealset? Veebispetsialistide abistamiseks viivituste tekkimise kohtade kindlaksmääramisel olen sellel saidil avaldanud tööriista, mis mõõdab serveri kogu elutsüklit. HTTP päring, alates domeeni eraldamisest kuni sisu edastamiseni.
See brauseripõhine tööriist kasutab serveripoolset diagnostikat reaalse HTTP-päringu simuleerimiseks ja selle ajastuskomponentide analüüsimiseks. See võib olla kasulik nii domeeni auditeerimisel, aeglaselt laadiva partneri tõrkeotsingul kui ka muudel juhtudel. APIvõi lihtsalt võrdlusanalüüs CDN toimivus URL-ide lõikes.
Kasutage allolevat tööriista mis tahes avalikkusele suunatud reklaami toimivuse analüüsimiseks. URL:
Kuidas tulemusi lugeda
Testi käivitamisel käivitab tööriist reaalajas testi. cURL päringu ja annab sekunditega üksikasjaliku ajainfo. Siin on iga esitatud mõõdiku tähendus:
- DNS-i otsingu aeg: See viitab ajale, mis kulub domeeninime vastavaks domeeninimeks määramiseks. IP aadressKui see arv on kõrge, võib see viidata aeglastele nimeserveritele, DNS-i leviku probleemidele või DNS-teenuse pakkuja kehvale jõudlusele. Google soovitab hoida selle alla 50 ms, kusjuures kõik üle 100 ms loetakse potentsiaalseks pudelikaelaks.
- TCP ühenduse aeg: See mõõdab, kui kaua kulub TCP-ühenduse loomiseks serveriga. Siinsed viivitused võivad viidata võrgu latentsusele, tulemüüridele või kaugusele algse serverini. Eelistatud on väärtused alla 100 ms; püsivad ajad üle 150 ms võivad viidata võrgu või marsruutimise ebatõhususele.
- TLS-käepigistuse aeg (HTTPS (ainult): Kui päring esitatakse HTTPS-i kaudu, kajastab see number turvalise ühenduse läbirääkimistele kulunud aega. Aegunud šifrikomplektid, aegunud sertifikaadid või ülekoormatud servaserverid võivad põhjustada pika TLS käepigistus. Google peab optimaalseks aega alla 100 ms, samas kui üle 200 ms võib viidata turvalisuse või jõudluse valekonfiguratsioonile.
- Eelülekande aegSee hõlmab DNS-i, TCPja TLS – kõik, mis toimub enne tegeliku päringu saatmist. See kajastab kumulatiivset käivitusaega enne, kui server hakkab päringut töötlema. Ideaalne edastuseelne aeg jääb vahemikku 100–300 ms; kõike, mis ületab 400 ms, tuleks uurida etapp-faasilt.
- Aeg esimese baidi (TTFB): See mõõdik mõõdab aega, mis kulub serveril vastuse saatmise alustamiseks pärast päringu vastuvõtmist. Kõrge TTFB võib viidata serveripoolsetele viivitustele, nagu aeglased andmebaasipäringud, vahemällu salvestamata dünaamiline sisu või serveri kehv jõudlus. Google'i soovitus on hoida TTFB alla 200 ms; püsivad väärtused üle 500 ms viitavad serveripoolsetele või infrastruktuuri probleemidele.
- Kogu ülekandeaeg: See on kogukestus päringu algusest kuni viimase baidi vastuvõtmiseni. Kui teie TTFB on kiire, kuid koguaeg on aeglane, võib see olla tingitud vastuse suurusest, serveri piiramisest või sisu edastamise viivitustest. Püüdke lairibaühenduse HTML-i koormuste puhul saavutada alla 500 ms; üle 1 sekundi võib viidata tihendamata ressurssidele või ebaefektiivsele edastamisele.
- HTTP olekukood: See on vastuse kood serveri tagastatud (nt 200 õnnestumise korral, 301/302 ümbersuunamiste korral, 404 mitteleidmise korral). See annab konteksti selle kohta, kuidas server päringuga tegeles.
See tööriist ei simuleeri lihtsalt päringut – see käivitab selle otse minu serveris, kasutades PHP-d cURL teek. See tähendab, et näete seda, mida server näeb, mitte ainult seda, mida teie brauser tajub. See on mugav jõudlusprobleemide tõrkeotsinguks, mis ei pruugi teie kohalikust võrgust nähtavad olla.
Proovige tööriista ja testige julgelt mitmesuguseid URL-e – oma avalehte, konkreetset API-lõpp-punkti või kaugressurssi, millele te toetute. Mida sügavam on teie arusaam neist ajastusmõõdikutest, seda kiiremini saate oma veebijõudlust diagnoosida ja parandada.
seotud Martech Zone sisu
