[js/ajax] Hoe weet je wanneer request volledig geladen is?

[xilent_xage]

Hoi,

Ik heb een webpagina met daarin een aantal menu-tabs. Vroeger laadde ik die allemaal in 1x in waarna ik met een javascriptje de boel kon showhiden. Probleem was dat sommige pagina's erg zwaar en dus traag werden. Daarom laadt ik nu de inhoud van de tabbladen in met AJAX-calls. Ik gebruik daarbij de volgende logica:

1. Indien de URL een anchor bevat, laadt die eerst en toon die als actieve tab (handig voor formulieren die weer op dezelfde tab moeten uitkomen, linkjes uit de zoekmachine etc), zoniet laadt het eerste tabblad.
2. Indien de muiscursor idle is, laadt na 2 seconden het volgende tabje, daarna het 3e enz.
3. Als een user op een tabje klikt dat nog niet geladen is dan haalt ie de inhoud daarvan op alvorens de rest van de tabbladen op volgorde af te werken.

Werkt best geinig zo! Maar hoewel de pagina nu een stuk sneller 'voelt' is ie in werkelijkheid een stuk trager geworden. Dat komt deels door overhead qua queries (soms moet je dezelfde query voor elk tabblad gebruiken, ga ik nog wel eens ergens cachen oid), maar vooral door de 2 seconden tussen het laden van elk tabblad.

Waarom heb ik die erin zitten? Omdat de HTML die middels de ajax-calls wordt aangeroepen vaak ook images bevat, die ook even tijd moeten krijgen om te laden. Het zou natuurlijk veel mooier zijn als mijn script zelf kon meten wanneer een tabblad (inclusief images!) geladen is. Een soort onload-event voor ajax-calls INCLUSIEF resources etc dus.

So far heb ik nog niks kunnen vinden, iemand enig idee?

PS ik gebruik geen libraries! (en sta daar ook niet voor open, is een andere discussie)

[Styxxy]

window.onload gebruiken? Ik weet niet 100% zeker of dit event ook afgevuurd wordt bij insertion van nodes in de DOM. Dat kon ik niet direct vinden.

EDIT: window.onload event wordt niet opnieuw afgevuurd.

[ Voor 18% gewijzigd door Styxxy op 18-08-2011 17:19 ]

[BtM909]

Je houdt hier een hele academische discussie, heb je niet toevallig een kleine testcase online? Ik zou toch verwachten dat je gewoon al je content in je dom neerkwakt en dat dat door de browser wordt gerendered?

Oftewel, als je plaatjes langer duren, dan zie je in ieder je textuele content in beeld. Dit hangt uiteraard wel af van hoe je de informatie ophaalt (je AJAX call geloof ik wel), maar met name hoe je het in je DOM stopt

[xilent_xage]

Uh die academische discussie was me even ontgaan?

Anyway - het klopt natuurlijk wat je zegt: Als de plaatjes nog niet zijn geladen dan toont ie de tekst alvast. Maar wat ik dus wil voorkomen is dat tijdens het laden van de plaatjes van call1 call2 wordt uitgevoerd. Omdat dan de plaatjes ook weer trager laden en het nut van mijn ajax-model verloren gaat: Het idee is juist dat je alvast het huidige tabblad kan bekijken terwij de rest wordt opgehaald. Ik wil dus dat een tab volledig laadt inclusief alle bijbehorende afbeeldingen, en dat daarna pas de volgende tab wordt opgehaald.

Nu doe ik dat dus door ieder tabblad 2 seconden te geven om te laden voor de volgende ajax-call wordt uitgevoerd. Maar dat is natuurlijk een beetje een suffe oplossing - mooier zou het zijn om op een of andere manier te weten of een tabblad volledig geladen is.

[Edwinboss]

Enige manier is denk ik dat als de Ajax-call succesvol is en de inhoud ervan is geplaatst, een functie om de seconde (ofzo) aanroepen die controleert of alle elementen "loaded" zijn.

Zo kan het bijvoorbeeld met jQuery:

code:

$('.img_class').load(function() {
  doe iets
}

[Styxxy]

Edwinboss schreef op donderdag 18 augustus 2011 @ 17:53:
Enige manier is denk ik dat als de Ajax-call succesvol is en de inhoud ervan is geplaatst, een functie om de seconde (ofzo) aanroepen die controleert of alle elementen "loaded" zijn.

Zo kan het bijvoorbeeld met jQuery: [...]

Wat op zich gewoon het load event is van een element.

[Bosmonster]

Je wilt je tabs asynchroon laden, maar vervolgens ga je ze nog gewoon achter elkaar automatisch volproppen?

Het idee lijkt me juist dat je de tab-content laadt op het moment dat een user een tab opent, ipv dat je op de achtergrond allemaal tabs gaat preloaden die misschien helemaal nooit geopend gaan worden.

[_Thanatos_]

Je weet toch wat je allemaal in die tabbladen giet? De images die je erin zet, geef je dus een onload-handler. Hoewel dat event niet altijd wordt aangeroepen (door IE als de image uit de browsercache komt, afaik) kun je wel weer checken op de completed property, desnoods met een interval.

Het is een beetje vies, maarja, zeg nou zelf, content laden met ajax is ook niet echt netjes. Zonder javascript heb je nml mooie lege tabs die je never nooit gevuld gaat krijgen.

dat je op de achtergrond allemaal tabs gaat preloaden die misschien helemaal nooit geopend gaan worden

Bij dergelijke tijdrovende oplossingen mag je wel een klein beetje verwachten dat daar wel onderzoek naar gedaan is. Naar hoe de gebruiker de pagina "gebruikt", dus welke tabs worden geopend, hoelang na het laden van de pagina, en hoe vaak men dit doet.

[Bosmonster]

_Thanatos_ schreef op vrijdag 19 augustus 2011 @ 00:06:

Het is een beetje vies, maarja, zeg nou zelf, content laden met ajax is ook niet echt netjes. Zonder javascript heb je nml mooie lege tabs die je never nooit gevuld gaat krijgen.

Ajax-tabs toegankelijk maken (dus ook laten werken zonder javascript) is helemaal niet zo heel lastig.

Het is vooral zorgen voor een degelijke implementatie van je template-generatie, waarin je naast volledige pagina's, ook delen op kunt vragen. Dan werkt het zonder JS gewoon met een page refresh, en kun je dit middels progressive enhancement ombouwen tot een systeem dat alleen de juiste stukjes dynamisch ophaalt.

[Naranya]

Zet iig altijd even een loading image in elke lege tab dan ziet een gebruiker nooit een witte tab tijdens het laden.

[xilent_xage]

Helaas - de content van de tabs is dynamisch. Het betreft hier overigens een CMS. Preloaden van andere tabs vind ik in dit geval uist prima werken; dataverkeer is sowieso niet zo'n issue hier en het zorgt ervoor dat de overige tabs lekker vlot laden als ze al gepreload zijn. Het geheel werkt ook zonder javascript.

Elke x seconden pollen of het werkt is opzich niet zo'n ramp. Ik zou bijvoorbeeld na het laden van de HTML een getElementsByTagName kunnen geven om alle images te pakken en vervolgens gaan pollen of ze geladen zijn. Maar ik denk dat de performancewinst daarmee een beetje wegvalt (dat pollen zou ik ook niet elke0,1 seconde willen doen, eerder elke seconde oid).

[OkkE]

xilent_xage schreef op vrijdag 19 augustus 2011 @ 10:06:
Helaas - de content van de tabs is dynamisch. Het betreft hier overigens een CMS. Preloaden van andere tabs vind ik in dit geval uist prima werken; dataverkeer is sowieso niet zo'n issue hier en het zorgt ervoor dat de overige tabs lekker vlot laden als ze al gepreload zijn. Het geheel werkt ook zonder javascript.

Je bekijkt het, in mijn ogen, van de verkeerde kant: de server. Bekijk het vanuit de bezoeker.

Het voordeel van content laden via ajax-calls is dat de bezoeker pas die data hoeft binnen te halen wanneer hij er om vraagt. Een bezoeker die maar één tab bekijkt haalt dus ook maar één tab aan data op. Veel fijner, zeker met langzame verbinding.
De data van een tweede tab ophalen zou sowieso niet lang moeten duren, daar is pre-loaden niet voor nodig lijkt me. Duurt het wel lang zou ik me daar eerder mee bezig houden.

[BtM909]

xilent_xage schreef op donderdag 18 augustus 2011 @ 17:29:
Uh die academische discussie was me even ontgaan?

Met academische discussie bedoelde ik het feit dat je geen enkele letter code hebt neergeplempt

[Bosmonster]

xilent_xage schreef op vrijdag 19 augustus 2011 @ 10:06:
Helaas - de content van de tabs is dynamisch. Het betreft hier overigens een CMS. Preloaden van andere tabs vind ik in dit geval uist prima werken; dataverkeer is sowieso niet zo'n issue hier en het zorgt ervoor dat de overige tabs lekker vlot laden als ze al gepreload zijn. Het geheel werkt ook zonder javascript.

Maar de vraag is dan waarom je uberhaupt nog AJAX gebruikt. Als je de content al direct in de tabs zet heb je hetzelfde zonder al die extra calls namelijk.

Het hele nut van de tabs dynamisch inladen gaat verloren als je ze gaat preloaden.

[xilent_xage]

Bosmonster schreef op vrijdag 19 augustus 2011 @ 13:13:
[...]


Maar de vraag is dan waarom je uberhaupt nog AJAX gebruikt. Als je de content al direct in de tabs zet heb je hetzelfde zonder al die extra calls namelijk.

Het hele nut van de tabs dynamisch inladen gaat verloren als je ze gaat preloaden.

Gedeeltelijk mee eens: De totale laadtijd van de pagina wordt langer dan eerst het geval was. Maar qua gebruikerservaring werkt het een stuk prettiger: je kunt alvast de content in tab1 lezen, een formulier invullen enz terwijl op de achtergrond de andere tabs worden geladen.

[xilent_xage]

BtM909 schreef op vrijdag 19 augustus 2011 @ 10:50:
[...]

Met academische discussie bedoelde ik het feit dat je geen enkele letter code hebt neergeplempt

leek me in dit geval niet nodig. al denk ik wel dat er hier mensen zijn die 100 regels code sneller snappen dan 10 regels tekst

[Bosmonster]

xilent_xage schreef op vrijdag 19 augustus 2011 @ 13:33:
[...]


Gedeeltelijk mee eens: De totale laadtijd van de pagina wordt langer dan eerst het geval was. Maar qua gebruikerservaring werkt het een stuk prettiger: je kunt alvast de content in tab1 lezen, een formulier invullen enz terwijl op de achtergrond de andere tabs worden geladen.

Want dat kan niet als je alles gewoon in 1 pagina zet? Sterker nog, dan kan dat nog sneller.

Dat beetje extra HTML is de overhead niet namelijk.

[xilent_xage]

Bosmonster schreef op vrijdag 19 augustus 2011 @ 13:59:
[...]


Want dat kan niet als je alles gewoon in 1 pagina zet? Sterker nog, dan kan dat nog sneller.

Dat beetje extra HTML is de overhead niet namelijk.

nee maar het javascript om van tabs te wisselen werkt pas na de onload van de pagina. maar ook de inhoud van de tabs maakt veel gebruik van javascript. bedenk dat sommige tabs zo zwaar zijn dat ze 10-20 seconden nodig hebben om te laden, en dat er op een pagina al gauw 10 tabs staan.

[Hipska]

Dan doe je dat niet pas op onload maar op onDOMready of iets dergelijks.. ?

Of je laad een tab pas in bij het klikken er op.

[ Voor 25% gewijzigd door Hipska op 19-08-2011 14:50 ]

[Naranya]

xilent_xage schreef op vrijdag 19 augustus 2011 @ 14:47:
[...]
bedenk dat sommige tabs zo zwaar zijn dat ze 10-20 seconden nodig hebben om te laden, en dat er op een pagina al gauw 10 tabs staan.

Dan zit je volgens mij op de verkeerde plek te optimaliseren.

[Bosmonster]

Naranya schreef op vrijdag 19 augustus 2011 @ 14:59:
[...]

Dan zit je volgens mij op de verkeerde plek te optimaliseren.

Dat...

Blijkbaar is er iets serieus mis met je backend als het 10-20 seconden duurt om een stukje html te genereren

Om het dan maar niet te hebben over het feit dat als jij gaat preloaden, je met meer dan 3 bezoekers tegelijkertijd je server plattrekt als het zo goed fout zit.

[ Voor 21% gewijzigd door Bosmonster op 19-08-2011 15:04 ]

[xilent_xage]

Mensen het gaat hier om een CMS, niet om een publieke site. Er zijn goede redenen waarom sommige tabs zo traag zijn - dat is een bewuste keuze en geen kwestie van brakke code ofzo. Wil het best allemaal gaan uitleggen, maar dan gaan we heel erg offtopic.

Hipska schreef op vrijdag 19 augustus 2011 @ 14:50:
Dan doe je dat niet pas op onload maar op onDOMready of iets dergelijks.. ?

Het probleem is dat het genereren van de HTML ook veel tijd kost.

Hipska schreef op vrijdag 19 augustus 2011 @ 14:50:
Of je laad een tab pas in bij het klikken er op.

Waarom heeft iedereen toch zoveel bezwaar tegen preloaden? Als dataverbruik geen issue is: wat is het nadeel? Voor de gebruiker is het in elk geval een stuk prettiger?

[noes]

Je zou het kunnen combineren. Als je een event/functie maakt die de data inlaadt met extra parameters kan je ervoor zorgen dat de functie/event wordt gedraaid zodra ofwel de gebruiker er om vraagt ofwel als de pagina idle is. (en laden terwijl de gebruiker toch even niets doet, is alleen maar goed: maakt de site meer responsive: alles kan uit cache komen).

Op basis van de extra parameter kan je in de succes callback bepalen of je al dan niet de data weer gaat geven. Ook moet je een extra variabele maken waarin je aangeeft of je al een load aan het doen bent, zodat je niet op basis van idle en op basis van user input de ajax call tegelijkertijd gaat doen.

Over het 'klaar' zijn van images zou ik me geen zorgen maken. Een browser laadt meerdere dingen tegelijkertijd en als je goed geoptimaliseerde & compressed plaatjes hebt staan die er binnen korte tijd. In het geval van een CMS of ander beheersysteem wil je snel kunnen doorklikken, als je een pagina ergens diep in de tree wil aanpassen moet je daar in korte tijd naar toe kunnen klikken. Kortom: als je links etc er staan is de pagina in veel gevallen klaar genoeg.

[BtM909]

Dus als je het perse zo wilt oplossen, dan ben je eigenlijk op zoek naar een Ajax queue

---

Mensen het gaat hier om een CMS, niet om een publieke site. Er zijn goede redenen waarom sommige tabs zo traag zijn - dat is een bewuste keuze en geen kwestie van brakke code ofzo. Wil het best allemaal gaan uitleggen, maar dan gaan we heel erg offtopic.

Als je kan uitleggen waarom het zo traag kan zijn en wij mee kunnen denken naar een structurele oplossing, is het niet offtopic

[xilent_xage]

noes schreef op zaterdag 20 augustus 2011 @ 00:00:
Je zou het kunnen combineren. Als je een event/functie maakt die de data inlaadt met extra parameters kan je ervoor zorgen dat de functie/event wordt gedraaid zodra ofwel de gebruiker er om vraagt ofwel als de pagina idle is. (en laden terwijl de gebruiker toch even niets doet, is alleen maar goed: maakt de site meer responsive: alles kan uit cache komen).

Op basis van de extra parameter kan je in de succes callback bepalen of je al dan niet de data weer gaat geven. Ook moet je een extra variabele maken waarin je aangeeft of je al een load aan het doen bent, zodat je niet op basis van idle en op basis van user input de ajax call tegelijkertijd gaat doen.

En dit is precies de manier waarop het nu werkt. Probeerde ik te omschrijven in de openingspost

noes schreef op zaterdag 20 augustus 2011 @ 00:00:
Over het 'klaar' zijn van images zou ik me geen zorgen maken. Een browser laadt meerdere dingen tegelijkertijd en als je goed geoptimaliseerde & compressed plaatjes hebt staan die er binnen korte tijd. In het geval van een CMS of ander beheersysteem wil je snel kunnen doorklikken, als je een pagina ergens diep in de tree wil aanpassen moet je daar in korte tijd naar toe kunnen klikken. Kortom: als je links etc er staan is de pagina in veel gevallen klaar genoeg.

Normaal gesproken ben ik het met je eens. Maar in dit geval niet. In het CMS kun je plaatjes toewijzen aan bepaalde pagina-elementen. Dat betekent dat je de media-library moet laden. En dat zijn een heleboel plaatjes

BtM909 schreef op zaterdag 20 augustus 2011 @ 01:04:
Als je kan uitleggen waarom het zo traag kan zijn en wij mee kunnen denken naar een structurele oplossing, is het niet offtopic

Ok, ik noem even een paar voorbeelden van trage tabs.

• Een tab doet een keyword-analyse voor de pagina die je bewerkt. Dat wil zeggen dat ie de html van de pagina ophaalt en parset, en daarna vergelijkt met de keywords van concurrenten en hun posities op de betreffende keywords in Google.
• Een andere tab haalt bezoekersstatistieken van de betreffende pagina op en stelt daarmee een aanal profiel en clickpaden op.
• Een derde tab scant inkomende links naar de betreffende pagina op andere sites en social media.

Voor al deze dingen zijn nogal wat queies en wgets nodig. Er valt vast nog wel wat aan te optimaliseren hoor,maar als je bezoekersstatistieken van de laatste 1000 visitors ophaalt en daarmee gaat goochelen wordt t nooit snel. En idem voor het opvragen van tientallen externe sites. Natuurlijk wordt er hier en daar wat gecached, maar een aantal gegevens wil ik realtime aanbieden.

Ik ben nog steeds van menng dat in deze omstandigheden de gekozen insteek prima is, het systeem werkt gewoon best goed nu. Ik zit dus alleen met dit kleine schoonheidsfoutje dat de preloader niet helemaal netjes werkt..

Maar volgens mij kan ik inmiddels wel de conclusie trekken dat wat ik zoek gewoon niet mogelijk is, en dat ik moet leven met de huidige opzet.

[SilentStorm]

Waar je het over hebt, is het synchroniseren van ajax requests (die per definitie asynchroon zijn). Hier worden terecht vraagtekens bij gezet, omdat het vrijwel nooit echt nodig is. In jou geval bijvoorbeeld:
Je browser kan meerdere ajax requests tegelijk doen. Als bandbreedte toch geen probleem is, kun je ook zeggen dat je, bv wanneer de pagina geladen is, meteen voor alle andere tabs een request afvuurt.

---
Als je om wat voor reden toch echt een gesynchroniseerd ajax request wilt doen,
vond ik de gedachtes aan het begin van dit topic niet zo slecht, waarom ga je daar niet mee verder?

* wachten op een event
* wachten tot een element geladen is via jquery
* je eigen pollmethode gebruiken

Ik heb iets.. soortgelijks ooit eens zo opgelost (code wat .. uitgerekt voor leesbaarheid):

JavaScript:

function waitFor(pollMethod, whenDone) {
    var done = pollMethod();

    if (!done) {
        //keep waiting, by calling this method again in 100ms
        window.setTimeout(
            function() {
                waitFor(pollMethod, whenDone);
            }
            , 100
        );
    } else {
        whenDone();
    }
}

aanroepen met:

JavaScript:

waitFor(
    pollMethod, function() {
        alert('blah');
    }
);

_{Let er wel op dat je op deze manier je context verliest bij het aanroepen van de whenDone functie. Je kunt de code aanpassen, zodanig dat je die ook bewaard, argumenten mee kan geven, etc, of je maakt het jezelf makkelijker en gebruikt jquery, die dat al voor je gedaan heeft.}

[Naranya]

Als je weet dat elke tab ongeveer 20 seconden nodig heeft om zijn content te laden zou je ook voor de simpele oplossing kunnen gaan en een setInterval kunnen doen die om de 20 seconden een nieuwe tab inlaadt.

[Bosmonster]

Het probleem is ook dat je bij moet gaan houden welke pagina's al geladen worden. Als de gebruiker een tab aan klikt die op dat moment al opgevraagd is, wil je dat proces niet herstarten.

Ten tweede heb je het dan nog steeds over enkele minuten die het duurt om de hele pagina synchroon in te laden, wat gewoon absurd is in _alle_ gevallen, aangezien dit gewoon killing wordt voor je server, hoe je het ook went of keert. Ik kan me in geen geval voorstellen dat hier niks geoptimaliseerd of gecached kan worden.

Als je dan toch al tijdswinst wilt boeken, laad de tabs dan asynchroon tegelijkertijd op de achtergrond. Dan hoef je ook verder niks bij te houden of te queue'en.

[ Voor 6% gewijzigd door Bosmonster op 20-08-2011 13:02 ]

[Bozozo]

Je wilt dus complexe queries enzo preloaden terwijl de gebruiker al de eerste content in beeld krijgt? Waarom pak je dat niet serverside aan? AJAX heeft er mi niet zoveel mee te maken.

In index.php serveer je de snelle HTML en genereer je vervolgens alle andere pagina's. Volgens mij kan dat met flush(), maar ik kan ernaast zitten. Zodra een subpagina klaar is schrijf je hem weg naar een cache. In de betreffende tabs serveer je de laatst gecachete versie, en middels AJAX polling update je zo'n subpagina secondes nadat de main thread klaar is met je ingewikkelde queries.