Lange lijst sneller maken

[havana]

Mijn vraag

Ik heb samen met 2 andere gasten een website. Het is een wereldwijde kalender (zoekmachine) voor fietstochten. Er staan op dit moment ruim 2000 tochten in de lijst. Het probleem is dat de lijst nu deze steeds langer wordt, trager laadt. Op zich is dat logisch. Maar toch zou ik willen onderzoeken hoe de lijst sneller kunnen maken zonder dat het nodig is niet de hele lijst te tonen. Nee is ook een antwoord, uiteraard.

Hierbij de direct link naar de kalender:
*snip irrelevant/spam* Maak even een testcase of een screenshot (ontdaan van (merk)namen etc)

Relevante software en hardware die ik gebruik

Het onderliggende CMS is grotendeels zelf gebouwd in PHP door één van ons (niet door mij). Het is een soort hobbyproject geweest. Degene die het geprogrammeerd heeft is wel professioneel IT'er, maar geen webdeveloper.

Wat ik al gevonden of geprobeerd heb

We hebben wel diverse dingen bedacht

- pagination
- of slechts een deel van de kalender tonen (bijv. 500 tochten) > knop "toon meer tochten"
- gebruiker eerst laten filteren en dan op "ZOEK" laten drukken en dan pas tonen

... Maar misschien is er een betere oplossing zonder dat het nodig is de dat we slechts een deel van de lijst tonen. Benieuwd naar jullie ideeën.

Ik realiseer me dat dit misschien een beetje op het snijvlak van UX design en programmeren zit.

[ Voor 8% gewijzigd door RobIII op 17-11-2020 15:09 ]

[Verwijderd]

Andersom: wat is de added value van alles laten zien? Het is nu al onmogelijk om januari 2021 fatsoenlijk in beeld te krijgen met zo'n klein scrollbalkje.

Je moet je bedenken wat mensen eigenlijk willen. De hele lijst in deze vorm is denk ik voor 0 mensen handig.

Maar concreet. Waarom niet: "Januari 2021. 15 tochten. Klik hier om ze te zien"

Edit. Nu ik verder scroll.

- Ik kan alleen in het weekend. Ik scroll me een ongeluk om dat in beeld te krijgen voor augustus 2021.
- Ik ben vergeten wat het verschil is tussen groen en geel. Nu moet ik helemaal terug naar de top.

[ Voor 25% gewijzigd door Verwijderd op 17-11-2020 15:08 ]

[RM-rf]

eerste idee zou gewoon asynchroon loaden zijn, dus eerst de eerste 10 laden en weergeven en vervolgens bij scrollakties meer laden...


echter, zeker als het gaat om een wereldwijde opsomming van routes die vermoedelijk vooral epr regio interssant zijn, is het volgens mij een betere optie om iig één pre-selectie altijd af te dwingen, dus pas bv de lijst te laden, als je minimaal een bepaalde regio (land, continent hebt) of locatie met omtrek hebt...

volgens mij is het weinig zinvol fietsroutes in australie, spanje, venerenigd koninkrijk, colombia en China in dezelfde lijst altijd weer te geven.

Overigens, ik zou ook naar die sortering op datum kijken.... volgens mij moeten die drie fietstochten in januari (ik vermoed januari 2021) niet afgebeeld worden voor de fietstochten in november 2020

[ Voor 14% gewijzigd door RM-rf op 17-11-2020 15:10 ]

[FoOnEeN]

De meest standaardoplossing is inderdaad paginering toepassen in een vorm, waarbij je het ophalen en pagineren door je database laat doen. Dat is het snelst. Moet vast wel een standaardoplossing voor php voor zijn.

Alternatief is caching toepassen in een van de lagen.

[havana]

Overigens, ik zou ook naar die sortering op datum kijken.... volgens mij moeten die drie fietstochten in januari (ik vermoed januari 2021) niet afgebeeld worden voor de fietstochten in november 2020

Dat klopt, de eerste 3 tochten zijn niet op datum, dat zijn de tochten die ons kwaliteitslabel hebben. Beetje zelfde als de eerste drie hits bij Google

[edit] Een link mag schijnbaar niet wegens spam, dus meer dan een screenshot kan ik niet posten. Website is vinden in handtekening en profiel.

[ Voor 24% gewijzigd door havana op 17-11-2020 15:28 ]

[Standeman]

Misschien ook even kijken naar waar de lijst precies uit bestaat. Zijn het alleen de genoemde waarden die hier in de filters te zien krijg (met daarbij een omschrijving) of zitten daar ook kaarten, filmpjes, PDF bestanden, foto's, etc bij? M.a.w. hoeveel data zit er per item in de lijst?

[Tsjilp]

2000 records mag toch geen probleem zijn?
Waar zit de traagheid? In de db query? In het http request? In de frontend?

[BramV]

Tsjilp schreef op woensdag 18 november 2020 @ 13:36:
2000 records mag toch geen probleem zijn?
Waar zit de traagheid? In de db query? In het http request? In de frontend?

Ja dat denk ik ook, ik zie wel een console foutmelding. Die zou ik sowieso proberen te verwijderen.

[Tsjilp]

er zit sowieso wel meer fout, in de html zie ik tig keer

code:

<style>.lef-edit {
  position: relative;
  float: left;
  color: #35A7D7 ;
  background-color: #333333 ;
  font-size: 20px;
}
.lef-edit a:hover{
    text-decoration: none;
}
</style>

staan.
Ik zou dus sowieso ff met de stofkam door je code gaan.

[ThomasG]

De traagheid zit hem in dat er een tabel wordt gebruikt voor de weergaven. Tabellen worden op een andere manier gerenderd, en gebeurd pas nadat de gehele tabel is ingeladen. Dit is bijvoorbeeld de reden waarom je geen tabellen moet gebruiken voor de layout (wat vroeger vaak gebeurde). Scrollen in pagina's met grote tabellen kan soms langzaam/laggy zijn.

In dig geval is het een tabel met slechts 1 kolom, en den 4 "kolommen" die je ziet met bootstrap gedaan. Een eerste oplossing zou dus zijn om de tabel om te schrijven naar bootstrap rows.

[RM-rf]

havana schreef op dinsdag 17 november 2020 @ 15:15:
[...]

Dat klopt, de eerste 3 tochten zijn niet op datum, dat zijn de tochten die ons kwaliteitslabel hebben. Beetje zelfde als de eerste drie hits bij Google

bij google geven ze dat aan, op je website worden die links echter exact hetzelfde weergegeven als de rest (dat groene labeltje rechts in het item zie ik verder ook terugkomen, dus dat lijkt het niet te zijn)..

het is erg verwarrend als er 'opeens' iets bovenaan verschijnt, zonder dat je daar als gebruiker ook een visuele aanwijzing bij krijgt waarom dat gebeurt... ik zou er dan minimaal een labeltje 'Speciaal aanbevolen routes door [website]' en misschien nog wat verschil in de weergave van de boxen... netste is natuurlijk gewoon 'Ad' of 'Adv' erbij te plaatsen.


wat betreft de traagheid... ik vind de website niet overdreven traag, maar wel blijft hij lang doorladen, wat eigenlijk nutteloos is, als enorme hoeveelheden data wel ingeladen worden, maar de kans eerder klein is dat de gebruiker daar nog iets mee doet.

Nog sterker, het kan gebruikers juist 'afschrikken'...
Als gebruikers uit enorm veel items moet 'kiezen' is er een grote kans dat ze helemaal geen keuze willen maken...
Om die reden bieden veel grote Interfaces graag 'speciale picks' aan voor hun gebruikers, waarbij standaard al de gepresenteerde items voorgeselecteerd worden (vaak door algorithmes, die gestuurd worden door gegevens die je al hebt van de gebruiker, zie bv Netflix, Youtube e.d.).

Bijkomend voordeel is dat juist zoiets het kunnen positioneren van een item in een speciale plaats extra veel zin heeft voor de aanbieders, aangezien ze daarmee die algorithmes kunnen 'overrullen'


wat me wel opvalt is dat dat forumiler waarmee je subselecties kunt maken enorm traag en on-responsief lijkt te zijn, het reageert vrijwel niet op gemaakte selecties... kan dat misschien zijn omdat daarover dan weer veel javascripts gaan die daarna informatie poogt te 'verbergen' die eerst wel ingeladen is?
Ik denk dat dat gewoon niet zo goed werkt, wel eerst _alle_ data van de server inladen en alle verdere selecties in de client frontend laten doen door javascripts

[R4gnax]

ThomasG schreef op woensdag 18 november 2020 @ 13:48:
De traagheid zit hem in dat er een tabel wordt gebruikt voor de weergaven. Tabellen worden op een andere manier gerenderd, en gebeurd pas nadat de gehele tabel is ingeladen.

Tenzij je table-layout:fixed gebruikt, dan heb je met gefixeerde kolombreedtes te maken en kan de layout van de table gestreamd worden zonder dat alles vantevoren bekend moet zijn.

[NMe]

Ik zou de hele interface zo op de schop gooien dat je pre-selecteert op regio of iets dergelijks en je daardoor met veel minder resultaten in die dropdown zit. Eventueel kan dat zelfs dynamisch, maar in elk geval zo dat er geen selectie mogelijk is waarin je de hele lijst in een dropdown gaat lopen renderen. Een hele lijst maken van alle items zou je op een eigen lijstpagina met paginering kunnen doen, daar moet je het formulier niet voor misbruiken.

ThomasG schreef op woensdag 18 november 2020 @ 13:48:
De traagheid zit hem in dat er een tabel wordt gebruikt voor de weergaven. Tabellen worden op een andere manier gerenderd, en gebeurd pas nadat de gehele tabel is ingeladen.

HTML wordt sowieso lineair ingeladen en gerenderd dus of je nou een tabel hebt of een stel divs maakt weinig uit, zolang die select nog gerenderd wordt heb je rare verspringende dingen.

[havana]

BramV schreef op woensdag 18 november 2020 @ 13:39:
[...]

Ja dat denk ik ook, ik zie wel een console foutmelding. Die zou ik sowieso proberen te verwijderen.

Sorry voor de domme vraag, maar wat is een console foutmelding?

[havana]

Tsjilp schreef op woensdag 18 november 2020 @ 13:42:
er zit sowieso wel meer fout, in de html zie ik tig keer

code:

<style>.lef-edit {
  position: relative;
  float: left;
  color: #35A7D7 ;
  background-color: #333333 ;
  font-size: 20px;
}
.lef-edit a:hover{
    text-decoration: none;
}
</style>

staan.
Ik zou dus sowieso ff met de stofkam door je code gaan.

Is aangepast, dank! Is enorm veel sneller geworden!

[BramV]

havana schreef op donderdag 19 november 2020 @ 16:20:
[...]
Sorry voor de domme vraag, maar wat is een console foutmelding?

In chrome / rechtermuis / onder : inspect, kun je alles over je webpagina vinden... oa tab console daar zie je evt foutmeldingen

[R4gnax]

NMe schreef op woensdag 18 november 2020 @ 22:48:
HTML wordt sowieso lineair ingeladen en gerenderd dus of je nou een tabel hebt of een stel divs maakt weinig uit, zolang die select nog gerenderd wordt heb je rare verspringende dingen.

Kom je wel achter als je ooit een echt grote tabel met display:table gaat renderen, versus een kunstmatige 'tabel' met display:grid of display:flex. Ik kan je vertellen dat een jaartje geleden bij 500 regels in 8 koloms zelfs Chrome nog peentjes stond te zweten.