Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

Volledige page loads vermijden via xhr/fetch

Pagina: 1
Acties:

Vraag


  • gnoe93
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
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?

Alle reacties


  • RobIII
  • Registratie: december 2001
  • Laatst online: 23:08

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

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.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • gnoe93
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
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.

  • Evanescent
  • Registratie: september 2001
  • Niet online

Evanescent

Helemaal klaar voor de zomer!

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?

Evanescent wijzigde deze reactie 08-01-2020 00:09 (33%)

I'm thankful for the Foo Fighters because I've never felt threatened by a foo
so that means they're doing a hell of a job on the frontlines!


  • gnoe93
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
Evanescent 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.

gnoe93 wijzigde deze reactie 08-01-2020 00:15 (31%)


  • Gropah
  • Registratie: december 2007
  • Laatst online: 23:31

Gropah

Moderator Spielerij

Oompa-Loompa 💩

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
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
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.

  • Evanescent
  • Registratie: september 2001
  • Niet online

Evanescent

Helemaal klaar voor de zomer!

@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.

Evanescent wijzigde deze reactie 08-01-2020 01:10 (34%)

I'm thankful for the Foo Fighters because I've never felt threatened by a foo
so that means they're doing a hell of a job on the frontlines!


  • DJMaze
  • Registratie: juni 2002
  • Niet online
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.

Maak je niet druk, dat doet de compressor maar


  • Ramon
  • Registratie: juli 2000
  • Laatst online: 22:10
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.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/


  • Tsjilp
  • Registratie: november 2002
  • Niet online

Tsjilp

RS[I]ds

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...

Raar... Is zo gek nog niet


  • dev10
  • Registratie: april 2005
  • Laatst online: 24-01 15:24
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.

dev10 wijzigde deze reactie 09-01-2020 10:34 (17%)

Heb jij HBO werk- en denkniveau en ben je op zoek naar een baan als developer? DM mij voor meer info.


  • gnoe93
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
Evanescent 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!

gnoe93 wijzigde deze reactie 09-01-2020 21:36 (4%)


  • RobIII
  • Registratie: december 2001
  • Laatst online: 23:08

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

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?

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Catch22
  • Registratie: november 2001
  • Laatst online: 23:18
En test zulke dingen in incognito modus om extensies te vermijden. Check verder je waterfall en caching

AMD Ryzen 2700x - Asus Strix 2080 - 32Gb Corsair Vengeance RGB Pro - 27" 1440p


  • gnoe93
  • Registratie: september 2016
  • Laatst online: 19-01 19:24
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.

gnoe93 wijzigde deze reactie 09-01-2020 21:53 (42%)


  • DJMaze
  • Registratie: juni 2002
  • Niet online
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.

Maak je niet druk, dat doet de compressor maar


  • Gomez12
  • Registratie: maart 2001
  • Nu online
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
  • Registratie: juli 2000
  • Laatst online: 22:10
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?

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

Pagina: 1


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True