Webwinkel Forum

Vaak is de standaard zoekfunctie van een webshop pakket niet heel best. Meestal gebruik je plugins of, zoals wij deden, externe software om de zoekfunctie te laten werken.

Dat brengt wat risico's met zich mee. Zo kan zo'n partij bijvoorbeeld failliet gaan waardoor we nu op zoek moeten naar een andere oplossing. Welke oplossing gebruiken jullie?

Heb je voor je eigen in kaart wat je wilt zien/filteren?

Wellicht kun je dan beter in 1 keer investeren om het inhouse te hebben ipv externe partijen hiervoor te trekken.

Ik heb redelijk goed in kaart wat ik wil filteren. Alles waarop ik wil filteren staat al apart in de database (lengte, prijs, levertijd, enz.). Ik denk dat ik op zo'n 4 a 5 zaken wil filteren.

In house zou kunnen. Er zijn ook wel plugins voor beschikbaar. Nadeel is dat zoiets ook resources van onze servers trekt.

Niet om lullig te doen, maar daar heb je ook het succes voor uiteraard om dergelijek resources te verstoken

Mits je goed laat programmeren, met een cache erin moet dat echt niet teveel resources kosten. Zeker niet in combinatie met memcache en apc Wij bouwen het zelfs default in zulke zaken.

Zoekfunctie kost meeste resources van alles. Mijn webshop cached daar niets aan, omdat mensen allemaal andere zoek opdrachten geven. Daar is geen pijl op te trekken. Zoekfunctie die ik heb, is zelf geschreven. Het is een combinatie van een vrij lange SQL query met relevantie formules en dan nog met PHP wat correcties. Het enige wat mist is eigenlijk een synoniemen lijst erbij.

Zoekfunctie bij mij doet ze werk. Klanten vinden via de zoekfunctie vrijwel altijd wat ze zoeken. Daar gaat het dan om.

Voordeel van deze manier is, dat je makkelijk in resultaten kunt filteren, omdat je de SQL query natuurlijk makkelijk filters aan toevoegt.

NOP Webdesign schreef:Zoekfunctie kost meeste resources van alles. Mijn webshop cached daar niets aan, omdat mensen allemaal andere zoek opdrachten geven.

Dat is dan een ontwerpfout die je nog eens moet overdenken

Je kunt de opcode van het PHP-script cachen.
Je kunt de doorzochte tabellen cachen.
Je kunt de templates voor zoekresultaten cachen.

Met een plugin die functioneel doet wat jij wilt zou ik het resource ongemak maar voor lief nemen want het lijkt mij veruit de goedkoopste oplossing.
Ik heb zelf een pakket om websites en webshops te maken geschreven en daarbij heb ik gebruik gemaakt van Javascript – ajax – php – mysql.
Aan iedere implementatie kleven voor en nadelen maar een groot voordeel van deze implementatie is dat het resource gebruik mooi wordt verdeelt tussen de frontend en de backend en het verkeer tussen de frontend en de backend tot een minimum beperkt wordt.
En dat werkt in de praktijk razendsnel.
Kijk maar eens op Esheets naar de website en webwinkel voorbeelden "mijn videotheek" en "mijn kantoor".
Bij "mijn videotheek" kun je o.a. zoeken en sorteren op iedere kolom in de database en in het smoelenboek van "mijn kantoor" wordt voor iedere zoekterm de gehele database doorzocht.

Je huidige plugin werkt volgens mij nog niet helemaal lekker van als ik bijvoorbeeld zoek op 121 dan krijg ik allerlei artikelen te zien zonder dat 121 daarbij aanwezig is.

Esheets schreef:Je huidige plugin werkt volgens mij nog niet helemaal lekker van als ik bijvoorbeeld zoek op 121 dan krijg ik allerlei artikelen te zien zonder dat 121 daarbij aanwezig is.

Ik zou niet uitsluiten dat dit "by design" is. Ik heb zelf wel eens een zoeksysteem gebouwd dat bij getallen zoekt op prijzen (óók vergelijkbare, zoals 119,95 bij 121) én op gedeelten van EAN- en UPC-codes (die niet op webpagina's werden getoond).

Als er géén exacte match wordt gevonden op de zoekterm, schakel je over op een andere zoekstrategie: zoeken naar iets dat dicht in de buurt komt. Dat kan bijvoorbeeld met de Levenshtein-afstand — iets dat incidenteel tot "hilarische" zoekresultaten kan leiden.

Bedankt Ward, ik ben al jaren niet meer bij de HEMA geweest maar zo te zien is het assortiment een stuk aantrekkelijker geworden.

Ward schreef:

NOP Webdesign schreef:Zoekfunctie kost meeste resources van alles. Mijn webshop cached daar niets aan, omdat mensen allemaal andere zoek opdrachten geven.

Dat is dan een ontwerpfout die je nog eens moet overdenken

Je kunt de opcode van het PHP-script cachen.
Je kunt de doorzochte tabellen cachen.
Je kunt de templates voor zoekresultaten cachen.

+1 Ward! Binnen een webwinkel zijn 4 pagina's over het algemeen "het zwaarste":
- categoriepagina (met/zonder filters)
- productpagina
- vergelijkpagina
- zoekpagina

Als je slim gebruik maakt van caching verlaag je de laadtijd (in ieder geval van het 'gegenereerde' via de server, dus data ophalen uit database) tot 90%. Dat is iets wat Magento bijvoorbeeld verkeerd doet naar mijn idee.

Hoewel mensen verschillend zoeken, is de kans realistisch dat van de 1000 bezoekers, een aantal mensen exact hetzelfde zoeken. Of dat de bezoeker terugkomt op een zoekpagina na het bezoeken van een productpagina. Als er in de tussentijd niets is besteld (en dus geen wijzigingen zijn in voorraad/status/info van de producten) is het onzin om de volledige pagina geheel opnieuw op te halen uit de database; slim cachen.

Zeker niet verkeerd opvatten Wouter, maar hier lijkt kabeltje.com op een categoriepagina heel erg traag (gemiddeld 1-3 seconden puur voor de PHP/MySQL om alles te genereren). Zoekpagina is wel stabieler met gemiddeld 1 seconde. Lijkt er alleen niet op dat hij de resultaten cached; je zou dit nog kunnen overwegen om de snelheid te verhogen.

Pantastic, jij hebt wel een goede suggestie en die was ik inderdaad mee bezig. Die suggesties van Ward gaan hier niet op. Het is bij mij niet zo, dat de zoekfunctie zo slecht is, meer dat de rest zo soepel is. Zoals reeds eerder gezegd, is elke page request bij mij 1 SQL query. Heel veel gaat niet vanuit de database.

Wel ben ik sinds een week of 3 begonnen met zoekresultaten opslaan. Dan was het idee om dit te gebruiken om mensen aan te vullen als ze de eerste paar letter in toetsen aan de hand van meest ingetoetste zoek opdrachten. Daarbij was inderdaad ook het idee de meest gebruikte zoek opdrachten te cachen.

En zo blijft de website op een eenvoudige VPS toch razendsnel