Advanced searched / Layered Navigation / Facet Navigatie || Speed Optimization
Momenteel zijn wij bezig een eigen seo-optimized layered navigation op te zetten. Voorbeelden van Layered navigations (omdat hier niet echt een uniforme naam voor lijkt te bestaan?):
- http://tweakers.net/categorie/215/mobiele-telefoons/producten/
- http://www.laptopshop.nl/category/45702/laptops.html?source=leftnav
De layered navigation welke wij willen opzetten bevat vele (1000+) producten welke conditionele elementen bevat:
- Aantallen tonen; bij het selecteren van bijvoorbeeld de kleur blauw worden alle andere aantallen van bijvoorbeeld categorieën (laptop, tablet, etc.), merken (Apple, Acer, etc.) bijgewerkt.
- Weergave producten; producten worden bij iedere selectie direct bijgewerkt.
We hebben dit concept werkend, maar snelheid blijkt een duidelijke uitdaging. Wat ik graag zou willen opstarten hier is een duidelijk topic met ideeën en mogelijk werkende truuks wanneer iemand dergelijke navigatie zelf wil opzetten.
Aangezien dit nauw samenhangt met hoe de database is ingericht is het onder het topic 'databases & SQL' geschaard.
Mocht er meer info nodig zijn let me know. Hopelijk komen we met constructieve tips die niet alleen ons, maar ook toekomstige projecten kunnen helpen.
Note: mocht hier online al goede documentatie voor bestaan (gezocht maar niet gevonden) zou dat ook super zijn.
Gewijzigd op 25/05/2013 12:12:39 door Nick Nick
Bij Tweakers en Coolblue lijkt de snelheid nauwelijks een probleem. Dus voordat we ons over trucs buigen, is het wel interessant om te weten hoe je het nu hebt opgelost.
Aan een database zal het zelden liggen. Je filtert namelijk op een handvol duidelijk afgebakende criteria. Dat kan met 1.000, 10.000 of 100.000 records in een fractie van een seconde.
In grote lijnen:
- We hebben 1 database gevuld met alle mogelijke product variabelen in 1 product tabel.
- De handmatig ingevoerde kenmerken van een product (denk daarbij aan de kleur) zitten echter met verscheidene andere kenmerken in 1 veld in XML vorm.
Juist deze kenmerken worden nu ook actief gebruikt in de layered navigation, iets wat voorheen niet voorzien was. Het uitlezen van alle XML van alle losse producten kost teveel tijd wanneer ook conditioneel de aantallen steeds moeten worden geupdated.
Bij ons duurt het daardoor ongeveer 4 seconden voordat een pagina laad. Dat lijkt niet wenselijk. We hebben geprobeerd een tussenoplossing te tonen waarbij de navigatie en aantallen steeds asynchroon werden getoond.
Met andere woorden, eerst worden alle producten getoond die aan de zoek-condities voldoen (dit gaat vrij vlot), daarna worden de (conditionele) menuitems getoond met de productaantallen die daarbij horen.
Ook dit bleek niet wenselijk, alhoewel we asynchroon (alleen) de aantallen laten inlezen wel als een mogelijke speed-winst zien wanneer e.a.a. na omzetting van kenmerken in eigen velden nog niet het gewenste effect heeft opgeleverd. De aantallen zouden dan nog steeds bijvoorbeeld een halve seconde later worden getoond terwijl de pagina, met producten al leesbaar zijn.
Wellicht zijn er verdere optimalisatietips? Wat wij verder hebben bedacht maar nog niet hebben doorgevoerd:
- Momenteel hebben we 1 algemene layered navigation welke binnen 1 tabel met alle producten zoekt. We hebben er al aan gedacht om 'productgroepen' te vormen (tablets, laptops en desktops kunnen bijvoorbeeld het productgroep kenmerk 'computers' krijgen toegewezen). Bezoekers zouden dan eerst een productgroep selecteren waardoor er binnen een kleinere groep producten gezocht hoeft te worden. Bijvoorbeeld door een aparte tabel te vormen met alleen de 'computer' productgroep producten (die gesynct wordt met de hoofd-producttabel) er in met uitsluitend de kenmerken er in die gebruikt worden bij het uitgebreid zoeken kan e.e.a. wellicht verder worden versneld. Een product kan namelijk meer kenmerken bevatten dan er gebruikt worden in het uitgebreid zoeken. Deze productgroep tabel met uitsluitend layered-navigation kenmerken bevat tevens alleen de producten die ook daadwerkelijk op voorraad zijn om het aantal (vooral in de toekomst wanneer meer producten blijven binnenkomen) beperkt blijft.
- Bovengenoemde voorbeeld om asynchroon product-aantallen in te lezen
We hebben nog geen idee of bovenstaande ideeën ook voordeel gaan opleveren. Hier hebben we namelijk geen ervaring mee. Jullie input en wellicht compleet andere optimalisatiepunten worden sterk gewaardeerd.
Gewijzigd op 25/05/2013 13:45:08 door Nick Nick
Daarna zijn er inderdaad wat trucs die je kunt gebruiken om de UX te verbeteren. Als je bijvoorbeeld 500 producten overhoudt, is er toch niemand die ze allemaal kan overzien. Je toont er dus 10 tot 20 en breidt de selectie vervolgens alleen op verzoek van de client uit.
Wij maken gebruik van pagination om het te tonen aantal producten in te dammen. Ik zag ook dat zalando bijvoorbeeld steeds het productaanbod asynchroon uitbreid bij het verder naar beneden scrollen van een pagina. Ik weet niet wat daar de ervaringen mee zijn.
Uberhaupt worden producten bij ons nu niet asynchroon ingeladen. Ik ben nog niet helemaal zeker of dit SEO-technisch wenselijk is, maar er van uitgaande dat dat geen probleem is (bijvoorbeeld door de eerste set producten gewoon synchroon in te laden en na 20 producten steeds asynchroon), kan dit de snelheid dan nog verder sterk verbeteren? Ik vermoed dat dit wel verschil kan maken doordat simpelweg minder images ingelezen worden, maar database technisch heb ik hier geen ervaring mee...
Gewijzigd op 25/05/2013 14:38:28 door Nick Nick