Volledige page loads vermijden via xhr/fetch

[gnoe93]

ik heb een traditionele website (server side rendered) die over de jaren heen uitgegroeid is tot wat je een webapplicatie zou kunnen noemen. Dit zorgt momenteel voor performanceproblemen (voornamelijk mobiel), omdat bij elke page load een grote hoeveelheid JavaScript telkens weer geinterpreteerd moet worden. Ik zou natuurlijk een volledige rewrite kunnen doen en gebruik maken van een modern front end framework, maar aangezien dat lang gaat duren, zoek ik ondertussen naar een soort van tussenweg.

Ik stel me de vraag of het een grote impact zou maken, moest ik bij elke interne link een xhr/fetch doen achter de schermen om de hoofddelen van de pagina te vervangen i.p.v. de pagina's volledig te laden. Zolang de delen die vervangen worden geen script tags bevatten, zou de JavaScript enkel en alleen maar bij de initiele page load geladen en geinterpreteerd worden, juist? Is er iemand die hier ervaring mee heeft?

[RobIII]

Zonder héél veel meer informatie en diepgaande kennis van je site is hier verdomd weinig zinnigs over te zeggen. Ja, het zou (bakken) kunnen schelen en het zou ook een complete verspilling van moeite kunnen zijn en alles er tussenin. Ik zou als ik jou was eens een proof-of-conceptje doen, een testje. Kijken waar 't heen gaat. Meten == weten.

[gnoe93]

Ik bedoel specifiek performance op vlak van initiele page load; eens een pagina geladen is, loopt alles vlot. Het is gewoon zeer irritant dat bij elke nieuwe pagina je een paar seconden moet wachten tegen dat de UI interactief wordt.

[Room42]

Is je site/UI dan niet gewoon veel te log? Zijn het allemaal effecten? Kun je op mobiel niet een beetje bezuinigen op alle scripts?

Ik bedoel, je zegt dat je site server-side rendered is. Wat moet er allemaal aan de client-side nog gebeuren met alle Javascript?

[ Voor 33% gewijzigd door Room42 op 08-01-2020 00:09 ]

[gnoe93]

Room42 schreef op woensdag 8 januari 2020 @ 00:07:
Is je site/UI dan niet gewoon veel te log? Zijn het allemaal effecten? Kun je op mobiel niet een beetje bezuinigen op alle scripts?

De UI zelf is vlot te gebruiken, en de weinige effecten gebeuren met CSS; het gaat hier specifiek over page loads. Ik heb in essentie de nadelen van SSR en CSR gecombineerd: lange initiele page load (door veel JS, zie je bij elke SPA praktisch), maar dit dan nog eens bij elke pagina.

Ik bedoel, je zegt dat je site server-side rendered is. Wat moet er allemaal aan de client-side nog gebeuren met alle Javascript?

Redelijk wat niet DOM-gerelateerde berekeningen, verwerken van forms, templates genereren... Of die code nu gebruikt wordt bij het laden van een pagina of niet, het blijft een grote hoeveelheid dat de browser moet interpreten. De mate waarin browsers dit optimaliseren tussen page loads weet ik niet, maar blijkbaar niet voldoende.

[ Voor 31% gewijzigd door gnoe93 op 08-01-2020 00:15 ]

[Gropah]

Maar heb je dan niet gewoon te veel javascript draaien waardoor de intial load zo lang duurt? Ik bedoel, hell, ik heb een volledige webcam image analyzer zien draaien zonder noemenswaardige slowdown.

[gnoe93]

Gropah schreef op woensdag 8 januari 2020 @ 00:15:
Maar heb je dan niet gewoon te veel javascript draaien waardoor de intial load zo lang duurt? Ik bedoel, hell, ik heb een volledige webcam image analyzer zien draaien zonder noemenswaardige slowdown.

Het enige noemenswaardige dat er gebeurt is het registreren van event listeners. Hangt er van af wat je noemenswaardig vindt, op mobiel moeten gebruikers makkelijk 1-3 seconden wachten tegen een knop interactief wordt. Misschien was performance niet de juiste woordkeuze; het probleem dat ik heb is dat de ervaring totaal niet vlot aanvoelt, en dat is inherent aan page reloads denk ik.

[Room42]

@gnoe93 ik vind je informatie weinig concreet, tot nu toe. Heb je wat cijfers? Hoeveel megabyte aan Javascript laadt je per page load? Hoeveel libraries gebruik je en welke? Wat zijn de laadtijden precies en hoe verhoudt de CPU zich op dat moment?

Je blijft wat vaag met 'redelijk wat dit' en 'aardig wat dat'. Dus dat helpt niet echt om gefundeerde antwoorden te geven.

[ Voor 34% gewijzigd door Room42 op 08-01-2020 01:10 ]

[DJMaze]

Wat is 1-3 seconden?
Html 1s + 1s javascript + 1s uitvoeren?
Je moet meten om het te weten.

Bij google pagespeed kom ik ook niet onder de 1.8s voor mobiel, terwijl die voor desktop wel 0.6s aan geeft.
Pak een trage/goedkope mobiel en test daar mee.

[Ramon]

Wat we regelmatig hebben gedaan hier op t werk is met Django in de views kijken of iets een xhr request is en dan enkel de content terugsturen. Zo kan je inderdaad wellicht wat snelheid winnen. Je verliest daardoor alleen wel navigatie dmv de back-button (die je dan wel weer kan toevoegen met de history API) maar je maakt het er allemaal niet makkelijker op.

Al met al zou ik zeggen; voordat je dit gaat doen, kijk eerst of je al die JavaScript wel nodig hebt en optimaliseer daar eerst.

[Tsjilp]

Heb je je caching ook goed ingericht? Als je de jsfiles eenmaal hebt geladen zouden opvolgende pageloads niet veel vertraging mogen geven. Als ik het zo lees is de initialisatie van je pagina (dus *na* het inladen van de files) te zwaar

En wat Ramon zegt: je haalt je wel wat op de hals als je deze route in gaat...

[dev10]

gnoe93 schreef op dinsdag 7 januari 2020 @ 23:51:
Ik stel me de vraag of het een grote impact zou maken, moest ik bij elke interne link een xhr/fetch doen achter de schermen om de hoofddelen van de pagina te vervangen i.p.v. de pagina's volledig te laden. Zolang de delen die vervangen worden geen script tags bevatten, zou de JavaScript enkel en alleen maar bij de initiele page load geladen en geinterpreteerd worden, juist? Is er iemand die hier ervaring mee heeft?

Ik heb in een heel ver verleden wel eens iets gedaan met Turbolinks. (https://github.com/turbolinks/turbolinks) Deze library zorgt voor het gedrag dat jij beschrijft. Belangrijkste waar je op moet letten is dat je de complete javascript bundle van de applicatie in eerste instantie moet laden, maar dat gaat in het algemeen wel goed. Mijn ervaring waren toentertijd wel positief, maar wat de huidige staat is durf ik je echt niet te zeggen omdat ik er al jaren niet meer mee gewerkt heb.

Ramon schreef op woensdag 8 januari 2020 @ 07:53:
Je verliest daardoor alleen wel navigatie dmv de back-button (die je dan wel weer kan toevoegen met de history API) maar je maakt het er allemaal niet makkelijker op.

Daar heb je dus wel libraries voor die dat doen. Zoals hierboven staat werkte dat een aantal jaar geleden prima en dat was toen redelijk plug-and-play.

[ Voor 17% gewijzigd door dev10 op 09-01-2020 10:34 ]

[gnoe93]

Room42 schreef op woensdag 8 januari 2020 @ 01:06:
@gnoe93 ik vind je informatie weinig concreet, tot nu toe. Heb je wat cijfers? Hoeveel megabyte aan Javascript laadt je per page load? Hoeveel libraries gebruik je en welke? Wat zijn de laadtijden precies en hoe verhoudt de CPU zich op dat moment?

Je blijft wat vaag met 'redelijk wat dit' en 'aardig wat dat'. Dus dat helpt niet echt om gefundeerde antwoorden te geven.

Ik had inderdaad beter wat profiling qua performance gedaan op voorhand; ik maakte direct de assumptie dat de hoeveelheid JS de oorzaak van het probleem was. Ik verwachte een makkelijk antwoord op een moeilijke vraag.

Dit zijn de resultaten:

http://i.imgur.com/fk9ODxo.png
http://i.imgur.com/Jps1Eka.png
http://i.imgur.com/txGlt7b.png
http://i.imgur.com/Mc9LrOz.png
http://i.imgur.com/5TYpoKi.png

Ik denk dat ik hier uit kan afleiden dat het grootste probleem de grootte van de DOM is. Als ik de pagina beperkt tot een klein aantal resultaten, is de pagina inderdaad stukken sneller interactief. Het interpreteren/evalueren van JS neemt (slechts?) 23% + 7.7% van de tijd in beslag als ik het goed begrijp.

Het enige dat gedaan wordt bij de page load qua JS, is een hele boel event listeners registreren (hoofdzakelijk jQuery plugins), en een aantal noodzakelijke berekeningen qua window size/breakpoints om bepaalde classes te zetten. Ik gebruik zo weinig mogelijk externe dependencies: jQuery 3.4 en nouislider zijn mijn enige dependencies. De JS bundel is 39.5KB (69.9KB met jQuery er bij totaal). De function call van 15.5% kan genegeerd worden omdat die afkomstig is van LastPass.

Het probleem is dat de meeste HTML absoluut noodzakelijk is. Misschien kan ik gewoonweg de lijst resultaten korter maken en desnoods de resultaten bijhouden in memory om extra roundtrips naar de server te vermijden?

Tsjilp schreef op donderdag 9 januari 2020 @ 10:17:
Heb je je caching ook goed ingericht? Als je de jsfiles eenmaal hebt geladen zouden opvolgende pageloads niet veel vertraging mogen geven. Als ik het zo lees is de initialisatie van je pagina (dus *na* het inladen van de files) te zwaar

En wat Ramon zegt: je haalt je wel wat op de hals als je deze route in gaat...

Alles wordt 1 jaar gecached (max-age=31536000), behalve de gegenereerde HTML (no-store).

dev10 schreef op donderdag 9 januari 2020 @ 10:32:
[...]


Ik heb in een heel ver verleden wel eens iets gedaan met Turbolinks. (https://github.com/turbolinks/turbolinks) Deze library zorgt voor het gedrag dat jij beschrijft. Belangrijkste waar je op moet letten is dat je de complete javascript bundle van de applicatie in eerste instantie moet laden, maar dat gaat in het algemeen wel goed. Mijn ervaring waren toentertijd wel positief, maar wat de huidige staat is durf ik je echt niet te zeggen omdat ik er al jaren niet meer mee gewerkt heb.


[...]


Daar heb je dus wel libraries voor die dat doen. Zoals hierboven staat werkte dat een aantal jaar geleden prima en dat was toen redelijk plug-and-play.

Turbolinks is exact wat ik in gedachte had!

[ Voor 4% gewijzigd door gnoe93 op 09-01-2020 21:36 ]

[RobIII]

gnoe93 schreef op donderdag 9 januari 2020 @ 21:31:
Het enige dat gedaan wordt bij de page load qua JS, is een hele boel event listeners registreren

Even voor mijn beeld: als je een lijst hebt met, zeg, 1000 items, dan registreer je toch niet 1000 van die event listeners he? Je kunt dan ook gewoon 1 event listener op 't parent element zetten namelijk... Misschien moet je 't in die richting zoeken?

[418O2]

En test zulke dingen in incognito modus om extensies te vermijden. Check verder je waterfall en caching

[gnoe93]

Nieuw resulaat met alle extensions disabled, simulated 4x slowdown (mobile):

http://i.imgur.com/eZgJIeS.png
http://i.imgur.com/5d6Erwe.png
http://i.imgur.com/fFmMhDk.png
http://i.imgur.com/o8UKT4O.png
http://i.imgur.com/Dvpu7PL.png
http://i.imgur.com/1fPjWMY.png

en caching/waterfall:

http://i.imgur.com/mct30V5.png

RobIII schreef op donderdag 9 januari 2020 @ 21:37:
[...]

Even voor mijn beeld: als je een lijst hebt met, zeg, 1000 items, dan registreer je toch niet 1000 van die event listeners he? Je kunt dan ook gewoon 1 event listener op 't parent element zetten namelijk... Misschien moet je 't in die richting zoeken?

Even gekeken in Chrome: +- 50 listeners geregistreerd. En neen, altijd op de parent met event bubbling.

[ Voor 42% gewijzigd door gnoe93 op 09-01-2020 21:53 ]

[DJMaze]

gnoe93 schreef op donderdag 9 januari 2020 @ 21:52:
Nieuw resulaat met alle extensions disabled, simulated 4x slowdown (mobile):

Maar daar zie je toch duidelijk je bulk aan CSS.
Zet die eens uit of repareer dat eens.

[Gomez12]

gnoe93 schreef op donderdag 9 januari 2020 @ 21:31:
[...]
Ik denk dat ik hier uit kan afleiden dat het grootste probleem de grootte van de DOM is. Als ik de pagina beperkt tot een klein aantal resultaten, is de pagina inderdaad stukken sneller interactief. Het interpreteren/evalueren van JS neemt (slechts?) 23% + 7.7% van de tijd in beslag als ik het goed begrijp.

Niet echt, het voornaamste probleem is het volgende :

en een aantal noodzakelijke berekeningen qua window size/breakpoints om bepaalde classes te zetten.

Hierdoor genereer je een shitload aan repaints / reflows en ja, daarbij gaat de grootte van je DOM opeens wel meetellen, want hij moet de complete DOM opnieuw repainten na een windows size berekening etc.

Turbolinks is exact wat ik in gedachte had!

Ik verwacht dat deze het alleen maar erger maakt, want je dom wordt er alleen maar groter van en er moet alleen maar meer verplaatst / gerepaint / gereflowed etc worden.

Je moet gewoon minder met javascript doen...

[Ramon]

Misschien kan je wat meer van je code delen? Want het blijft een beetje gissen zo natuurlijk. We weten niet wat je allemaal doet dus kunnen we ook geen specifieke tips geven anders dan "minder html/css/js is meestal sneller'. Heb je echt 11 niveas nodig in je HTML? Kan ik me haast niet voorstellen... Misschien kan je ergens de pagina saven zodat wij hem kunnen bekijken?