Večina nasvetov o hitrosti Shopify optimizira številko, ki je nihče, ki pri tebi kupuje, ne vidi. Povedali ti bodo, stisni slike, vklopi lazy loading, spravi oceno v zeleno, in nič od tega ni napačno. Le preskoči vprašanje, ki je najprej pomembno: kateri del počasnosti te dejansko stane naročil?
To je pogled praktika konverzij na to vprašanje, ne vodnik po performance inženirstvu. Shopifyjeva lastna razvijalska dokumentacija inženirsko stran že pokriva in bolje, kot bi jo jaz. Česar ne pokriva: zakaj projekti za hitrost še naprej propadajo v trgovinah, ki so stiskanje že opravile.
Meritve, ki štejejo, in tista, ki zavaja
Trije Core Web Vitals in njihove mejne vrednosti za "dobro", iz Googlove lastne dokumentacije:
| Metrika | Dobro | Kaj kupec doživi |
|---|---|---|
| Largest Contentful Paint | znotraj 2,5s | koliko traja, da se pojavi bistvo |
| Interaction to Next Paint | 200ms ali manj | ali se dotiki zdijo takojšnji |
| Cumulative Layout Shift | 0,1 ali manj | ali se stran premika pod palcem |
Ena opomba o pravilnosti, ker je veliko vsebin o hitrosti Shopify pri tem zastarelih: Interaction to Next Paint je zamenjal First Input Delay in je leta 2024 postal stabilen Core Web Vital. Če ti vodnik še pravi, da optimiziraj FID, ni bil posodobljen dve leti, kar ti nekaj pove o preostanku njegovih nasvetov.
Zdaj tista, ki zavaja. Lighthouse ocena je laboratorijski test na simulirani napravi in jo je mogoče premakniti, ne da bi kupec kaj občutil. Google ocenjuje podatke s polja od pravih obiskovalcev. Trgovina lahko torej v Lighthouse gre s 42 na 78, ne objavi ničesar, kar bi stranka opazila, in poroča o uspešnem projektu za hitrost. Ta izid sem videl prodan kot zmago več kot enkrat.
Optimiziraj tisto, na kar kupec čaka. Nato preveri, ali se je premaknila konverzija, ne ocena.
Zakaj delo na hitrosti propade: začne se prepozno
Najpogostejša napaka, ki jo vidim čez Shopify projekte, ni manjkajoča tehnika. Je vrstni red. Hitrost se obravnava kot lak, ki se nanese po tem, ko je oblikovanje končano.
Ko gradnja doseže fazo "zdaj pa optimizirajmo performance", so drage odločitve že padle. Hero čez celoten zaslon. Ilustracije, izvožene kot raster namesto SVG. Samodejni video nad pregibom. Drsenje, ki utripa belo, ker si nič ne rezervira prostora. Štiri aplikacije, ki vsaka vbrizga svojo skripto. Na tej točki ostaneta le stiskanje in lazy loading, in zato se toliko projektov za hitrost konča z nekoliko hitrejšo različico strani, ki je bila po zasnovi strukturno težka.
Konkretne stvari, ki jih v tej fazi znova in znova najdem, približno po pogostosti:
- Visok time to first byte, ki je obstajal že pred prenovo. Nihče ga ne preveri, preden na njem gradi. To je težava razvijalca, ne moja, in najti jo je treba pred oblikovalskim delom, ne po njem.
- Rastrske ilustracije, kjer bi zadostoval SVG. Linijske grafike in ikone, izvožene kot PNG, pogosto v 2x, pogosto več sto kilobajtov za nekaj, kar bi kot vektor bilo nekaj kilobajtov.
- Sunkovito drsenje, ki utripa belo. Vsebina, ki si ne rezervira prostora. To je težava Cumulative Layout Shift in je hkrati preprosto neprijetno, in prav to te stane.
- Samodejni video nad pregibom. Kar nas pripelje k sorodnemu argumentu.
Argument o videu, ki v resnici ni o hitrosti
Običajno nasprotujem videu na strani izdelka in zagovarjam statični posnetek zaslona, teža strani pa je šele tretji razlog.
Prva dva: video sproži vprašanja, ki jih mora kupec razrešiti, preden iz njega dobi vrednost. Kako dolg je? Moram ustaviti, da preberem podrobnost? Statična slika stvari, z oznakami, dostavi isto informacijo v času enega pogleda. In video, ki ga je treba gledati, tekmuje z nakupno odločitvijo, namesto da bi jo podpiral.
In res, škoduje hitrosti nalaganja. Ampak če je tvoj edini argument proti videu teža strani, boš to razpravo izgubil pri stranki, ki ji je pomemben občutek znamke, in prav bo tako. Močnejši argument je, da svojo nalogo opravlja slabše.
Težek hero je težava hierarhije v kostumu hitrosti
Zlasti na straneh zbirk je največji posamezen element pogosto dekorativen hero, in nagon pravi: stisni ga.
Boljše vprašanje je, zakaj je tam. Namen strani zbirke je pripeljati obiskovalca do izdelkov čim hitreje. Prevelik hero nad mrežo izdelkov je v bistvu šum: potisne edino stvar, zaradi katere stran obstaja, pod pregib in te hkrati stane tvoj Largest Contentful Paint.
Stiskanje te slike ti da hitro različico strani, ki še vedno zavlačuje prikaz izdelkov. Odstranitev reši obe težavi hkrati, in to je splošna oblika najbolj vrednega dela na hitrosti: popravek je pogosto brisanje, ne optimizacija. Zato tudi to delo pripada tistemu, ki odgovarja za hierarhijo strani, ne tistemu, ki odgovarja za gradbeni cevovod.
Dve sorodni pasti na isti površini:
- Besedilo za iskalnike, ki blokira pot do izdelka na straneh zbirk. Ni ga treba odstraniti, lahko pa se zbledi ali gre v harmoniko, da ostane berljivo za iskalnike, brez zavlačevanja klika.
- Prazen prostor, ki se bere kot konec strani. Sploh ni težava hitrosti, ampak povzroči isti poslovni izid kot počasna stran: ljudje ne pridejo do izdelkov.
Aplikacije: preveri, kaj prinesejo, preden preveriš njihovo velikost
Večina Shopify aplikacij nalaga skripte na vsako stran, ne glede na to, ali stran funkcijo uporablja. Običajen nasvet je odstraniti tiste, ki jih ne potrebuješ, kar je pravilno in nezadostno.
Dražji vzorec je prekrivanje: več aplikacij, ki opravljajo isto delo, torej nalagaš več skript za eno funkcijo. Odprl sem trgovine, ki so hkrati poganjale več aplikacij za pakete, in pošten opis je, da je malo zmešnjava: nasprotujoče se obnašanje košarice, podvojene skripte, in nihče ne more povedati, katera prinaša prihodek.
Aplikacije torej najprej presojaj po tem, kaj vsaka prinese, nato po tem, koliko stane v teži. Aplikacija s pravo stopnjo pripetja je vredna svoje skripte. Tri aplikacije, ki si eno funkcijo delijo med sabo, niso.
Kaj ni moje delo in kaj s tem narediti
Neposredno o obsegu, ker se tu veliko nasvetov o hitrosti preprodaja.
Če je tvoj time to first byte slab, tvoj Liquid v temi opravlja drago delo v zankah, potrebuješ odločitve o strežniškem izrisu ali je treba tvoj sklad aplikacij razvozlati na ravni kode, je to delo razvijalca. To ti povem, namesto da bi se pretvarjal, da bo oblikovalski pregled to rešil, in vredno je vedeti, preden kogarkoli najmeš: to sta dva različna projekta.
Kar pa delam, je del, ki je ustvaril težo: kaj je prišlo na stran, v kakšnem vrstnem redu, in ali je tisto, na kar čaka tvoj Largest Contentful Paint, izdelek ali dekoracija.
Kako to zaporedno urediti, če začenjaš zdaj
- Pridobi podatke s polja pred mnenji. Core Web Vitals pravih obiskovalcev, ne Lighthouse zagon na tvojem prenosniku po pisarniškem wifiju.
- Ugotovi, kaj je tvoj element Largest Contentful Paint v resnici. V mnogih Shopify trgovinah je to dekorativna slika. Že samo to dejstvo projekt običajno postavi na novo.
- Vprašaj, kaj vsak težek element prinese. Brisati, nato stiskati. V tem vrstnem redu, ker je stiskanje nečesa, kar ne bi smelo obstajati, zapravljeno delo.
- Time to first byte preveri ločeno in ga predaj razvijalcu, če je slab. Ne oblikuj na počasnem strežniku.
- Meri konverzijo, ne ocene. V oknu, ki ga določiš vnaprej, na metriki, ki ustreza spremembi.
Pri peti točki velja ista omejitev kot povsod: smiseln A/B test potrebuje približno 200 do 250 konverzij in okoli 5.000 sej na varianto. Večina trgovin z $50k do $1m na mesec spremembe hitrosti tako ne more izolirati, torej izmeriš čisto stanje pred in po ter na glas poveš, da počneš prav to.
Opomba o statistikah, ki jih boš videl citirane
Vsak članek o hitrosti citira številko, ki povezuje milisekunde s prihodkom. Namenoma nisem citiral nobene, ker ko sem iskal primarne vire za slavne, jih je večina vodila do blogov ponudnikov, svetovalskega marketinga ali drug do drugega.
Preverljive so Googlove objavljene mejne vrednosti zgoraj in preprost mehanizem: človek, ki čaka na stran, na katero ni želel čakati, bo z večjo verjetnostjo odšel. To zadostuje za utemeljitev dela. Ne potrebuješ izposojene statistike brez vira, in navesti jo te stane verodostojnosti prav pri tistem tehničnem kupcu, ki preveri.
Sorodno branje: Popolni vodič po Shopify CRO · Optimizacija Shopify blagajne · Audit optimizacije konverzij
Če želiš vedeti, ali je tvoja počasnost težava oblikovanja ali težava razvijalca, preden komurkoli plačaš za popravilo, rezerviraj brezplačen 30-minutni klic. Povem ti, katera od dveh je, tudi kadar je odgovor, da potrebuješ razvijalca in ne mene.
