Media & Publishing: sztuczne-rosliny.pl

#sztuczne-rosliny.pl, nettbutikk for kunstige planter av høy kvalitet

De som handler her har som regel et rom foran seg og et mål i hodet. En innkjøper skal fylle en kontorresepsjon, en restaurant vil ha noe grønt som tåler varme og lite lys, en messebygger trenger en vegg med planter som står i tre dager og deretter pakkes ned igjen. Butikken selger kunstige trær, gress, blomster og potter til den typen oppdrag, og driver i tillegg prosjektsalg mot kontorer, hoteller, kjøpesentre og arkitekter, med montering og rådgivning på stedet. Selskapet holder til i Warszawa og har en avdeling i Białystok, og sortimentet omfatter blant annet brannhemmende og UV-bestandige varianter (kilde: sztuczne-rosliny.pl).

Leveransen tok rundt seks uker. Teknisk står butikken på WordPress med en egen produktmodell, Redis som objektcache, HTML5, CSS3 og SASS i grensesnittet, AJAX i søket og CDN foran bildefilene. Layout og plassering av elementene kom fra kunden, og på den bygget jeg malstrukturen, datamodellen og integrasjonene.

#To måter å lete på, som krasjer i samme katalog

Kunstige planter kjøpes med øynene og velges med tall. Førsteinntrykket kommer fra et bilde, men beslutningen faller på høyde, materiale, pottetype og om planten passer inn i rommet den skal stå i. Det betyr at katalogen må betjene to helt forskjellige måter å lete på samtidig.

Den ene er bla for inspirasjon. Her er bildet innholdet, rekkefølgen betyr noe, og kunden vet ikke på forhånd hva hun leter etter. Den andre er parametrisk utvalg. Der vet kunden nøyaktig at det skal være mellom hundre og tjue og hundre og åtti centimeter høyt, i svart potte, og alt annet er støy. En butikk som bare løser den første blir en bildekatalog uten kjøpsvei. En som bare løser den andre ser ut som et regneark og selger ikke et produkt der utseendet er halve argumentet.

Hele den tekniske prioriteringen i dette prosjektet følger av den spenningen. Bildene må være store nok til at bladverket kan vurderes, og attributtene må være strukturerte nok til at et filter kan sammenligne dem. Begge deler koster, og de koster på hver sin kant av systemet: det ene i leveranse av filer, det andre i databasearbeid.

#Datamodellen, felter framfor brødtekst

Produktmodellen ligger i egne innholdstyper og egendefinerte felt. Høyde, materiale, farge, pottetype, produsent og spørsmålet om varianten er brannhemmende eller UV-bestandig er verdier i databasen, ikke setninger i en beskrivelse.

Forskjellen blir synlig i det øyeblikket noen trenger en høyde. Står målet bare i beskrivelsen, blir filteret fra hundre og tjue til hundre og åtti centimeter aldri laget, for det finnes ingenting å sammenligne. Man kan lappe på det med stikkord som høy og ekstra høy, men da er grensen en smakssak, hver redaktør trekker den ulikt, og kunden får vite den faktiske størrelsen først på produktsiden. For en bestilling til en hotellobby med gitt takhøyde er det forskjellen mellom ett minutt og en returforsendelse på to meter.

Prisen for denne strukturen bør nevnes høyt. Å legge inn et produkt tar lengre tid, fordi skjemaet har et titalls felt i stedet for ett tekstvindu. Settet med attributter må tenkes ferdig på forhånd, for å endre det senere er en datamigrering og ikke en tekstrettelse. Investeringen betaler seg ved hvert nye hundre artikler og ved hver ombygging av utseendet, siden felter kan skyves inn i et nytt oppsett med én mal, mens opplysninger i løpende tekst må skrives om for hånd.

#Leverandørdata fra to kontinenter

Sortimentet kommer fra produsenter i Asia og i Europa, og det betyr at produktdata ankommer i ulike formater, med ulik frekvens og i ulik kvalitet. Én leverandør sender et regneark med full spesifikasjon, en annen en fil der høyden oppgis snart i centimeter og snart i tommer, og der fargenavnet finnes i tre skrivemåter.

Synkroniseringslaget har én oppgave som kommer før alt annet: å føre dette ned til ett ordforråd før det treffer katalogen. Det er kjedelig arbeid som avgjør alt som skjer etterpå, for et materialfilter virker bare når ti skrivemåter av samme plasttype er slått sammen til én verdi. Verdier som ikke lar seg plassere skal stoppe synlig i en liste, ikke slippes gjennom i stillhet. Fem minutter redaksjonsarbeid er billigere enn et produkt som ligger på lager og aldri dukker opp i et søk.

Den andre avgjørelsen er hvem som eier hvilket felt. Lagerbeholdning og innkjøpspris tilhører leverandøren og kan overskrives ved hver kjøring. Beskrivelse, bilder og kategoriplassering er butikkens eget arbeid og kan det ikke, ellers sletter nattens import det redaksjonen har bygget. Fraværet av den avgjørelsen er den vanligste årsaken til havari i produktintegrasjoner, og den melder seg alltid på samme måte: morgenen etter importen står produsentens tekst tilbake på halve katalogen.

Den tredje saken gjelder varer som går ut hos leverandøren. Å slette dem dreper en adresse som ligger i søkeresultater og i bokmerkene til innkjøpere. Bedre er å merke produktet som utilgjengelig, holde siden i live og vise alternativer ved siden av. I denne bransjen er det å foreslå et lignende tre uansett en normal del av salget, og varer skaffes på bestilling.

#Ytelse handler om filtrene, ikke om forsiden

Søk og filtrering går asynkront, så innsnevring laster ikke hele siden på nytt og listen svarer med en gang. Behagelig for kunden, dyrt for databasen, for hver bevegelse av høydeglideren er en egen spørring.

Filtrering på flere attributter samtidig er den dyreste operasjonen på en produktliste i WordPress. Spørringen binder sammen tabellene for taksonomirelasjoner og tilleggsfelt, og for hver aktive betingelse vokser antallet koblinger raskere enn antallet filtre. Flaskehalsen i en slik butikk er derfor ikke forsiden, som alle tester, men kategorivisningen med tre valgte filtre, som ingen tester.

Tre praktiske slutninger ble stående. Resultatet av vanlige filterkombinasjoner hører hjemme i cache for seg, fordi den samme kombinasjonen kommer tilbake oftere enn man tror. Tellerne ved siden av filtervalgene, altså opplysningen om hvor mange artikler som skjuler seg bak hvert alternativ, er den dyreste delen av visningen, og det bør være en bevisst avgjørelse om de er verdt arbeidet. Og tester har bare mening på en produksjonskopi med full katalog. På en tom installasjon med tjue produkter er alt raskt, fordi databasen får plass i minnet og ingenting trenger å være optimalisert.

Trafikken fordeler seg heller ikke jevnt over året. Den stiger foran høytidene og i periodene der bedrifter pusser opp kontorer og lokaler, og enkeltdager kan gi et mangedobbelt av vanlig belastning. Å stille inn etter et månedssnitt er derfor lite verdt. Det som teller er oppførselen i topptimen, og der avgjør ikke kodens hastighet, men hvor mange forespørsler som i det hele tatt når fram til applikasjonen. Bildene bærer mesteparten av vekten, og det er CDN-et som tar den transporten bort fra serveren.

#Kassen, betalingen og grensen for cache

Butikken er koblet til betalingsløsninger og ordrebehandling. Det er her ytelsesarbeidet må stanse, og det er verdt å forstå hvorfor.

Handlekurv, ordreoppsummering og siden etter betaling er per definisjon forskjellige for hver bruker. Å legge dem i full sidecache ender i den verste feilen en nettbutikk kan produsere, nemlig en fremmed handlekurv i egen nettleser. Disse stiene er derfor holdt utenfor sidecache, og farten hentes et annet sted: objektcachen i Redis korter ned arbeidet med å sette sammen siden også der et ferdig svar ikke kan lagres.

Retur fra betalingsløsningen er et eget grensetilfelle som må prøves på en produksjonskopi. Kunden kan lukke nettleseren før hun sendes tilbake, komme tilbake to ganger, eller treffe en servervarsling fra betalingsleverandøren som er raskere enn hennes egen videresending. Ordrestatus må følge av den varslingen og ikke av om en nettleser nådde riktig adresse. Snur man det om, ligger betalte ordrer som ubetalte i systemet, og det oppdages først når noen avstemmer regnskapet.

#Bildene er produktbeskrivelsen

I denne bransjen er fotografiet ikke en illustrasjon, men selve spesifikasjonen. Kjøperen vurderer grønnfargen, bladstrukturen og måten planten sitter i potta på, og det er nettopp der forskjellen går mellom en kunstig plante som holder og en som avsløres fra to meters avstand. Derfor er galleriene store, filene tunge, og nesten hele vekten på siden ligger her. Det lar seg ikke løse ved å fjerne bilder, så det må håndteres i leveringen.

Arbeidsdelingen er enkel nok. CDN-et tar bort trafikken serveren ikke burde bruke tid på, og leverer filene fra et punkt nærmere den besøkende. Redis korter ned arbeidet med å sette sammen selve siden. I tillegg kommer bildeoptimalisering og en grense for hvor mye stilark og skript en visning får dra med seg, for i en katalog der bildene allerede er tunge er hvert ekstra skript et valg som går ut over produktet.

Et forhold som er lett å overse gjelder listevisningen. En kategoriside med femti produkter laster femti bilder, og da er det ikke størrelsen på ett bilde som avgjør, men summen. Miniatyrer må derfor genereres i den størrelsen de faktisk vises i, ikke skaleres ned i nettleseren fra en fil ment for produktsiden. Det er en detalj i oppsettet og en av de få endringene som merkes på en mobil over et vanlig mobilnett.

#Våre handlinger

På vår side lå gjennomføringen av butikken på grunnlag av layouten kunden leverte: produktmodellen med parametriske felt, katalog- og produktvisninger, søk med filtrering, kobling mot betaling og ordrebehandling, cachelaget og forberedelse av katalogen for indeksering. Det viktigste kravet var at den som forvalter sortimentet skal kunne legge inn en ny plante uten utvikler, og at en besøkende når riktig produkt på få steg.

Ett forhold krever særlig oppmerksomhet i en parametrisk butikk. Kategorisider og filterresultater lager svært mange adresser som bare skiller seg i rekkefølgen på parametrene, og det er den klassiske måten å tynne ut synligheten til en katalog. Det må avgjøres på forhånd hvilke kombinasjoner som skal være egne, indekserbare sider, og hvilke som forblir et navigasjonsverktøy uten egen adresse i søkemotoren. Jeg har ingen målinger av effekten av dette arbeidet, så jeg oppgir ingen.

#Oppsummering

Kvaliteten på denne butikken ble avgjort av datamodellen, ikke av det grafiske laget. Produktparametere lagret som felt i stedet for som setninger ga filtreringen som hele kjøpsveien hviler på. Avklaringen av hvilke felt som tilhører leverandøren og hvilke som tilhører butikken gjorde det mulig å synkronisere sortimentet uten å slette redaksjonens arbeid. Å holde kjøpsveien utenfor full sidecache og samtidig gjøre den raskere med objektcache forente ytelse med korrekte ordrer.

Til neste leveranse følger det tekniske laget og arbeidsmåten med: WordPress med egen produktmodell, Redis, CDN og testing av filtre og betaling på en produksjonskopi. Det som ikke følger med er attributtordboken til denne butikken og integrasjonene mot leverandørene, for begge ble laget for et konkret sortiment og konkrete filformater. Et nytt prosjekt starter med en omfangsanalyse, og tilbudet kommer etter den.