iFrames of jQuery

[frumper]

Ik zit met een kleine discussie...
Op onze homepage maak ik gebruik van een drietal iFrames om dynamische content in te laden. Dit moet helaas via een externe site omdat de hoofdsite dit niet kan.
hoofdsite is op .net en kunnen wij (bijna) niet aankomen. We hebben dus extern een omgeving gemaakt in php die de juiste output levert, en die laden we via iFrames in. Niet ideaal (verre van) maar helaas de enige manier.
Nu krijgen wij de opmerking dat de site 'traag' is vanwege de iFrames.
Ik was altijd in de veronderstelling dat dit onzin was, aangezien een iFrame parrallel geladen wordt naast de hoofdsite, maar blijkbaar heeft het toch een kleine impact.
Nu lees ik dat ik evt een pagina ook dmv jQuery kan inladen als alternatief van een iFrame.

code:

<script type='text/javascript'>

      $('#include-from-outside').load('http://example.com/included.html');

    </script>

wat zou beter/sneller/netter zijn? via bovenstaande jQuery of toch met de iFrames. Het is op zich weinig data die ingeladen wordt, maar toch...

[skate master]

Persoonlijk denk ik dat het qua performance niet zo gek veel zal schelen, tenzij je het jQuery script pas laat uitvoeren nadat de pagina is geladen. Het initeel laden van de pagina gaat hierdoor wel iets sneller, maar het duurt weer langer voordat je content volledig zichtbaar is.

Feit blijft dat je qua snelheid afhankelijk blijft van je externe omgeving. Wanneer je externe omgeving niet beschikt over een snelle verbinding zal het geheel ook niet snel geladen kunnen worden. De grootste winst zou je dus kunnen behalen wanneer je alles op dezelfde server zou kunnen uitvoeren.

[frumper]

skate master schreef op donderdag 21 december 2017 @ 11:40:
Feit blijft dat je qua snelheid afhankelijk blijft van je externe omgeving. Wanneer je externe omgeving niet beschikt over een snelle verbinding zal het geheel ook niet snel geladen kunnen worden. De grootste winst zou je dus kunnen behalen wanneer je alles op dezelfde server zou kunnen uitvoeren.

De iframes worden vanaf een server geladen die sneller is dan de hoofdsite. Sowieso een verschil dat de hoofdserver niet in NL staat en de externe wel. Bezoekers komen uit NL.

"men" zoekt een uitkomst waarom de site traag zou zijn, en leggen het op de iFrames. En dat zou ik graag willen bestrijden

[André]

frumper schreef op donderdag 21 december 2017 @ 11:46:
[...]

"men" zoekt een uitkomst waarom de site traag zou zijn, en leggen het op de iFrames. En dat zou ik graag willen bestrijden

Je browser gebruikt een maximaal aantal connecties bij het inladen van een pagina. Alle iframes op die pagina tellen mee voor dat aantal. Die hebben niet een nieuwe eigen limiet. Als daar dus trage zaken in staan zullen die ook zeker invloed hebben op de hoofdsite.

[Dark Blue]

Als je jQuery gebruikt, kun je nog wat schuiven met de plek waar je het inlaadt.
Met het iframe kan dat niet, tenzij je het iframe weer laat genereren in Javascript en met die snippet weer wat schuift.

Ik zou het nog niet aan de grote klok hangen, maar gewoon eens wat experimenten doen.
Kijk goed in je dev console naar de laadtijden en leg je bevindingen naast elkaar.

[emnich]

Je kan het toch gewoon meten en kijken waar de vertraging in zit?

Zou je de iframe content niet vanaf de hoofdserver parallel kunnen laden met de hoofdpagina?

[DJMaze]

frumper schreef op donderdag 21 december 2017 @ 11:05:
Dit moet helaas via een externe site omdat de hoofdsite dit niet kan.
hoofdsite is op .net en kunnen wij (bijna) niet aankomen. We hebben dus extern een omgeving gemaakt in php die de juiste output levert, en die laden we via iFrames in. Niet ideaal (verre van) maar helaas de enige manier.

Er is ook een andere manier hoor: de hoofdsite vervangen voor iets dat je wel kan aanpassen.

[frumper]

DJMaze schreef op donderdag 21 december 2017 @ 14:47:
[...]

Er is ook een andere manier hoor: de hoofdsite vervangen voor iets dat je wel kan aanpassen.

In het kort: nee, dat kan niet. Niet binnen nu en drie jaar in ieder geval.

Ik zal eens gaan meten met pagina's waarin wel en waarin geen iframes zitten met verder dezelfde content erin. Voor mijn gevoel gaat het weinig uitmaken.

Je browser gebruikt een maximaal aantal connecties bij het inladen van een pagina.

Als ik de broncode uit elkaar trek van de hoofdsite, worden er sowieso al flink wat connecties gemaakt, als daar die van mij dan nog overheen komen kan het wel vertragen wellicht. Maar goed, meten is weten!

[Dark Blue]

frumper schreef op donderdag 21 december 2017 @ 15:16:
[...]

In het kort: nee, dat kan niet. Niet binnen nu en drie jaar in ieder geval.

Hoewel ik het sneu voor je vind dat je zo weinig speelruimte hebt, snap ik je positie uitermate goed.
Roei met de riemen die je hebt, en zorg in ieder geval dat jullie project een voorbeeld wordt voor nog volgende projecten die tegen die homepage aan moeten schurken.

Ik zal eens gaan meten met pagina's waarin wel en waarin geen iframes zitten met verder dezelfde content erin. Voor mijn gevoel gaat het weinig uitmaken.

Zeg nooit nooit, he! Voor hetzelfde geld heb je volgende maand een stagiair naast je zitten die het 'even uitprobeert' en je verschillen laat zien waar je steil van achterover slaat. Daarom zei ik 'niet aan de grote klok hangen'. Als het niet zo is, is het niet zo. Maar de technologie waarmee je dit allemaal uitpoept staat ook niet stil.

Als ik de broncode uit elkaar trek van de hoofdsite, worden er sowieso al flink wat connecties gemaakt, als daar die van mij dan nog overheen komen kan het wel vertragen wellicht. Maar goed, meten is weten!

Ja, daarom... probeer het dus ook even met die jQuery, en laad die code op verschillende plekken in. Aan het begin van je body, na je body, enzovoorts. Het kan zijn dat het elkaar in de weg zit, en sneller zijn juist als je ze in volgorde omdraait. Testen kost je amper wat!

'Stijf' blijven beweren dat het niet zo kan zijn kan je meer kosten... al wil ik hiermee niet zeggen dat je dat zo doet.

[reshi]

Je kan toch met developer tools en het Network tabblad perfect zien waar de vertraging vandaan komt?

[q-enf0rcer.1]

Afhankelijk van hoe belangrijk deze frames zijn, zou je er ook voor kunnen kiezen deze pas te laden zodra je pagina volledig geladen is. Dat zou in ieder geval de initiële page load versnellen.

[Hiroj]

reshi schreef op dinsdag 2 januari 2018 @ 13:38:
Je kan toch met developer tools en het Network tabblad perfect zien waar de vertraging vandaan komt?

Dit is dus het juiste begin. Eerst kijken waar de vertraging echt vandaan komt...

Een simpel HTML/CSS/JS document zou normaliter niet al te groot mogen zijn (400kb en/of kleiner).
Overigens kan jouw PHP script ook wel iets voor vertraging zorgen, maar wederom is de vraag dan "waardoor is het zo traag?". Indien het hier ligt, wat kun jij dan zelf nog doen om jouw script te optimaliseren?