Cloudflare ali Fastly: napačen preizkus lahko izbere napačen CDN

Med Cloudflare in Fastly izberite na podlagi meritev svojega prometa, ne splošne lestvice hitrosti. Za spletno mesto z obiskovalci v Sloveniji lahko lokacija merjenja, velikost datotek in delež zadetkov v predpomnilniku spremenijo vrstni red ponudnikov. Preizkus že shranjenih majhnih datotek zato ne pove, kako hitro se bodo nalagale celotne strani.

Uporaben odgovor da ponovljiv 14-dnevni preizkus: oba CDN-ja naj dostavljata enake objekte iz istega izvora, meritve pa naj zajamejo slovenska in druga pomembna evropska omrežja. Zadetke in zgrešitve predpomnilnika obravnavajte ločeno. Poleg časa do prvega bajta merite tudi prikaz glavne vsebine strani.

Zakaj javna primerjava ne odloči namesto vas

Javna meritev opisuje promet in konfiguracije, ki so bili vključeni vanjo. Fastly je v analizi 99 izvorov, ki so prešli s Cloudflare na Fastly, zahteval najmanj dva opazovana meseca pri vsakem ponudniku in določeno zaporedje prehoda. Njen rezultat velja za tako izbrano skupino spletnih mest; ne napove razlike za vašo kombinacijo obiskovalcev, vsebine in nastavitev.

Razlika je lahko že v sestavi zahtevkov. Pogosto zahtevana slika je lahko shranjena blizu obiskovalca, redko zahtevana pa zahteva pot do izvornega strežnika. Spletno mesto, na katerem prevladuje prilagojen HTML, bo zato obremenilo CDN drugače kot mesto z veliko predpomnjenimi slikami. Enotna številka za široko geografsko območje poleg tega združi povezave, ki za vaše občinstvo morda niso značilne.

Najprej določite, kaj sme CDN shraniti

Cloudflarova dokumentacija predpomnilnika navaja, da so statične vsebine, kot so slike, CSS in JavaScript, praviloma primerne za privzeto predpomnjenje, dinamični HTML pa zahteva ustrezna pravila. Če pri enem ponudniku HTML posebej shranjujete, pri drugem pa ne, primerjate različni poti do odgovora. Pred meritvijo zato za vsak razred vsebine popišite pravila in dejanski odziv, ne le nastavitev v nadzorni plošči.

Obema storitvama zagotovite iste različice objektov, izvorni strežnik ter primerljive glave za predpomnjenje. Uskladite obravnavo poizvedbenih parametrov, piškotkov in preusmeritev; zabeležite tudi stiskanje in morebitno obdelavo slik. Če ena storitev dostavi pomanjšano sliko, druga pa izvirnik, je razlika v času prenosa tudi posledica različnih bajtov. To je lahko koristen podatek o celotni konfiguraciji, vendar ni čista primerjava omrežne poti.

Zgrešitev predpomnilnika razkrije še odziv izvora. Pri zadetku je odgovor lahko na voljo na robu omrežja, pri zgrešitvi pa CDN počaka na pridobitev objekta. Čas izvora in stanje predpomnilnika zato zapisujte ob posamezni meritvi. Počasnejšega zahtevka brez teh podatkov ni mogoče zanesljivo pripisati ponudniku CDN.

Lokacije in objekti naj sledijo obiskom

Za slovensko občinstvo izberite merilne točke na dejanskih slovenskih dostopovnih omrežjih, po možnosti na fiksnih in mobilnih povezavah. Dodajte evropske države, iz katerih prihaja pomemben delež vašega prometa. Zahtevek iz podatkovnega centra in obisk prek mobilnega omrežja lahko potujeta po različnih poteh, zato lokacijo in vrsto povezave ohranite v rezultatih.

Nabor objektov sestavite iz dnevnikov zahtevkov ali analitike spletnega mesta. Vključite običajne majhne datoteke CSS in JavaScript, slike različnih velikosti, večje prenose ter strani, ki jih obiskovalci dejansko odpirajo. Pri obeh ponudnikih uporabite iste različice in zapišite velikost odgovorov. Redkemu velikemu prenosu v skupnem rezultatu ne pripišite enake teže kot objektu, ki ga potrebuje večina obiskov.

Če uporabite testni domeni, preverite, ali DNS, certifikati ali preusmeritve spreminjajo pot zahtevka. Zahtevke za oba CDN-ja na posamezni merilni točki izmenjujte v istih časovnih oknih. S tem zmanjšate vpliv ure merjenja in vrstnega reda ogrevanja predpomnilnika, primerjava pa ostane povezana z istimi pogoji.

Ponovljiv 14-dnevni preizkus

Pred začetkom določite seznam objektov, merilne točke, pogostost zahtevkov in pravila za razvrščanje podatkov. Nato 14 zaporednih dni zbirajte parne meritve v enakih časovnih oknih. Nastavitve med preizkusom ohranite stabilne; vsako nujno spremembo označite, da prizadetih meritev ne združite z ostalimi.

1. Pri vsakem objektu zabeležite izvor, velikost, glave, preusmeritve in vključene optimizacije. Pred prvo meritvijo preverite, da obe poti vračata pričakovano vsebino in primerljive odzivne kode.
2. Zadetke merite po nadzorovanem ogretju predpomnilnika, zgrešitve pa z ločenimi testnimi objekti ali nadzorovanim čiščenjem. Stanje preverite v odzivih oziroma dnevnikih. Zahtevkov, ki zaradi pravil obidejo predpomnilnik, ne združujte z zgrešitvami sicer predpomnljivih objektov.
3. Za vsak zahtevek shranite čas, lokacijo, omrežje, vrsto in velikost objekta, stanje predpomnilnika, čas do prvega bajta ter trajanje prenosa. Pri nalaganju celotnih strani zabeležite še podatke brskalnika ob primerljivih napravah in povezavah.
4. Če vključite meritve resničnih obiskovalcev, promet med ponudnika razdelite sočasno in preverite sestavo skupin po napravah, omrežjih ter obiskanih straneh. Zaporedna tedenska menjava lahko zajame tudi spremembo prometa ali obremenitve izvora.

Sintetične meritve in meritve obiskovalcev poročajte ločeno. Prve omogočajo nadzor nad objektom in stanjem predpomnilnika; druge pokažejo nalaganje dejanskih strani v raznovrstnih razmerah. Obe skupini sta uporabni, če je ob rezultatu jasno navedeno, kaj je bilo izmerjeno.

TTFB, LCP in počasnejši del prometa

TTFB pokaže, kdaj začne prihajati odgovor, vendar zajame več kot delo CDN-ja. Po opredelitvi TTFB na web.dev pri nalaganju strani vključuje tudi preusmeritve, iskanje DNS in vzpostavljanje povezave. Ločeno ga primerjajte za HTML in posamezne datoteke ter za zadetke in zgrešitve; ob zgrešitvah upoštevajte odziv izvora.

Opis LCP na web.dev metriko veže na prikaz največjega vidnega slikovnega, besedilnega ali video elementa in vanjo vključuje tudi zamude pred prvim bajtom. Hitrejši TTFB zato sam ne zagotovi hitrejšega prikaza glavne vsebine. Pri primerjavi preverite, kateri element je bil izmerjen, kako se nalaga in ali ga sploh dostavlja primerjani CDN.

Za vsako kombinacijo lokacije, vrste objekta in stanja predpomnilnika navedite število meritev, mediano in 95. percentil. Mediana opiše običajnejši primer, percentil pa počasnejši del prometa; pri majhnem vzorcu je slednji manj stabilen. Skupni rezultat utežite po dejanskih deležih obiskov, ob njem pa ohranite razčlenitev, da ne skrijete slabšega rezultata za pomembno skupino uporabnikov.

Odločite se glede na promet, ki ga imate

Prednost dajte konfiguraciji, ki pri vašem občinstvu dosledneje dosega cilje za prikaz strani in sprejemljivo obremenitev izvora. Če se ponudnika izmenjujeta na vrhu med majhnimi zadetki, velikimi prenosi in zgrešitvami, naj odločitev sledi deležu teh primerov v dejanskih obiskih. Ob majhni ali nestalni razliki preverite še stroške po svojem prometnem profilu ter delo, potrebno za vzdrževanje pravil in odstranjevanje zastarele vsebine.

Sklep zapišite skupaj s pogoji, pri katerih velja: lokacijami, vrstami objektov, deležem zadetkov in nastavitvami izvora. Tako bo ob spremembi občinstva ali vsebine jasno, kateri del primerjave je treba ponoviti.

Preberite tudi:

• Ponovni poskus agenta lahko podvoji dejanje: zaščitite stranske učinke