Spideren van een op JavaScript-gebaseerde website

[Verwijderd]

Ik heb een website die voor het grootste deel wordt opgebouwd door JavaScript (maakt gebruik van DOM etc.).
Dit is lekker snel en het scheelt in de belasting aan de server-kant.
Er zijn natuurlijk ook bezoekers die JavaScript uit hebben staan. Ik wil dat deze mensen ook gebruik kunnen maken van mijn site.
Ik heb er een tijd over zitten denken en ben met twee mogelijke oplossingen gekomen.

Oplossing 1
Beschr.: Een noscript-tag met daarin de hele pagina.
Voorbeeld: <noscript>Hier komt de inhoud</noscript>
Het nadeel hiervan is dat de pagina alsnog moet worden opgebouwd door de server, waardoor het voordeel van snelheid en belasting volledig wegvalt. Het heeft dan uiteraard ook geen zin meer om de pagina uberhaupt door JavaScript te laten bouwen.

Oplossing 2
Beschr.: Een iframe na de noscript-tag
Voorbeeld: <noscript><iframe src=....pagina.php></iframe></noscript>
De pagina in de iframe is dus een php-script wat hetzelfde doet als het JavaScript binnen de script-tags.
Het voordeel hiervan is dat de pagina alleen aan de kant van de server wordt gemaakt wanneer de browser geen JavaScript ondersteunt.
Deze oplossing heeft dan ook de voorkeur.

Wat erg belangrijk is, is dat zoekmachines mijn site goed kunnen spideren. Wanneer ik oplossing 2 toepas, is dit dan het geval? Oftwel, kan een zoekmachine een (de inhoud afkomstig van) een iframe goed spideren?

Sorry voor het lange verhaal, maar ik ben bang dat het anders niet duidelijk is.

[crisp]

Hoezo is het genereren van javascript sneller en minder belastend op je server?
Gewoon HTML over de lijn gooien, daar los je al je problemen mee op...

[Verwijderd]

Het probleem is dat de inhoud van de pagina afhankelijk is van de bezoeker.
Dit moet dus dynamisch gebeuren. Dat zou betekenen dat php aan het werk moet worden gezet. Dit is op zich geen probleem, maar JavaScript heeft mijn voorkeur omdat er dan alleen statische content over de lijn hoeft. Het opbouwen gebeurt dan aan de kant van de bezoeker. Dit scheelt erg voor mijn eenvoudige servertje.

[Blaise]

Het probleem is dat de inhoud van de pagina afhankelijk is van de bezoeker.

Dus dan kunnen bezoekers zonder javascript de site alsnog niet normaal bekijken, anders kon je javascript net zo goed achterwege laten.

Voorbeeld: <noscript><iframe src=....pagina.php></iframe></noscript>

Dat is ongeschikt voor zoekmachines en andere bezoekers die frames niet of slecht ondersteunen.

Ik denk dat je beter javascript helemaal achterwege kan laten. Je javascript-idee klinkt als een vreemde oplossing voor een dynamische website. PHP is hier heel geschikt voor, en is ook niet zo zwaar voor je server omdat het hier waarschijnlijk om eenvoudige handelingen gaat.

[Erkens]

Verwijderd schreef op woensdag 12 september 2007 @ 20:07:
Het probleem is dat de inhoud van de pagina afhankelijk is van de bezoeker.
Dit moet dus dynamisch gebeuren. Dat zou betekenen dat php aan het werk moet worden gezet. Dit is op zich geen probleem, maar JavaScript heeft mijn voorkeur omdat er dan alleen statische content over de lijn hoeft. Het opbouwen gebeurt dan aan de kant van de bezoeker. Dit scheelt erg voor mijn eenvoudige servertje.

Als je echt denkt dat dat beter is, waarom gooi je dan niet een "standaard" HTML pagina over de lijn en dan zodra die bij de client is het ding verbouwen met javascript zoals je hem wilt hebben?

[Gomez12]

Wat doe jij met javascript dat je niet de hele pagina moet opbouwen??? Want bij mij zijn in 99% van de gevallen de dbase calls en berekeningen duurder dan het daadwerkelijke opbouwen van de html ( ter indicatie, in een onderzoekje van mij een op mijn eigen websites bleek dat het pagina opbouwen in html 0,1% van de tijd koste, de rest was het verzamelen van alle gegevens nodig voor het opbouwen ( dus ik vermoed dat je ook bij JS dezelfde gegevens gebruikt ), voor verkeer over de lijn scheelde het wel een hoop, maar dat voordeel is weer grotendeels gecompenseerd door gewoon gzip aan te zetten. Met JS en gzip combinatie kon ik wel een redelijke verkeershoeveelheid besparen, maar qua onderhoudbaarheid koste me dit zoveel dat ik het toch gewoon op html +css hield met JS voor de fancy touches ).

En als jij wilt dat mensen zonder javascript iets kunnen doen hebben die toch op de een of andere de html nodig. Alleen een iframe op je pagina betekent voor google imhe gewoon dat google je pagina als zijnde leeg indexeert.

Plus dat ik sterke twijfels heb over het persoonlijke inhoud gedeelte afhankelijk van de bezoeker als je het met JS oplost. Dat klinkt mij meer in de oren als dat je dingen uithaalt die je beter met css kan doen, of gewoon met php.
JS heeft alle gegevens nodig en verbergt er dan een aantal, ditzelfde kan je bereiken met css. Bezoeker kan het net zo makkelijk uitzetten. PHP kan je het netjes regelen en de bezoeker alleen maar sturen wat hij nodig heeft, niets hoeft verborgen te worden. Want de bezoeker krijgt gewoon niet wat hij niet hoeft te krijgen...

Btw voor dat javascript heb je daar een bestaand framework voor gebruikt of is het allemaal homemade, want ik zou me erge zorgen maken over hoe onderhoudbaar het is als het homemade is, en anders gewoon afvragen waarom er geen non-JS fallback in het framework zit...

Erkens schreef op donderdag 13 september 2007 @ 00:46:
[...]

Als je echt denkt dat dat beter is, waarom gooi je dan niet een "standaard" HTML pagina over de lijn en dan zodra die bij de client is het ding verbouwen met javascript zoals je hem wilt hebben?

Omdat als hij dat deed dan had hij dit probleem niet gehad, ik vermoed meer dat hij gewoon een gigantische brok JS over de lijn heenstuurt en dan on the fly uit het stuk JS een html pagina maakt. Opzich werkt dit als je redelijk veel html hebt en geen css, waardoor je een JS library kunt bouwen die alle html genereert, maar als je over css gaat gebruiken kan je html al omlaag, je caching wordt beter. En als het goed is dan is je content toch nog steeds groter dan je html...

[ Voor 17% gewijzigd door Gomez12 op 13-09-2007 01:12 ]

[Erkens]

Gomez12 schreef op donderdag 13 september 2007 @ 01:08:
Want bij mij zijn in 99% van de gevallen de dbase calls en berekeningen duurder dan het daadwerkelijke opbouwen van de html ( ter indicatie, in een onderzoekje van mij een op mijn eigen websites bleek dat het pagina opbouwen in html 0,1% van de tijd koste, de rest was het verzamelen van alle gegevens nodig voor het opbouwen ( dus ik vermoed dat je ook bij JS dezelfde gegevens gebruikt ), voor verkeer over de lijn scheelde het wel een hoop, maar dat voordeel is weer grotendeels gecompenseerd door gewoon gzip aan te zetten.

1 woord: caching

Als je al je data op je server al cached, hoef je die dure DB calls niet meer te doen, zeker als je toch weet dat de data niet veel veranderd. Voor de gebruikerspeciefieke representatie kan het dus handig zijn om op de client het een en ander vorm te geven (css+js).
Owja, vergeet ook niet dat juist het gebruik van gzip een extra load op je server veroorzaakt, hoewel ik van mening ben dat je beter kan investeren in een krachtigere server, dan dat je "teveel" probeert te optimaliseren, want doorgaands leidt dat niet tot duidelijkere code.

Omdat als hij dat deed dan had hij dit probleem niet gehad,

maw het zou een oplossing kunnen zijn voor zijn "probleem"

[Stamgastje]

crisp schreef op woensdag 12 september 2007 @ 19:55:
Hoezo is het genereren van javascript sneller en minder belastend op je server?

Inderdaad, dit ontgaat mij ook even.

Dus TS: doe je met javascript calls naar een database server voor het ophalen van dynamische content? Of genereer je alleen voorgedefinieerde blokken HTML m.b.v. javascript? In dat laatste geval gaan er dus heel veel (wellicht onnodige) blokken HTML over de lijn, dit is ook weer een belasting voor je web server.

Hoe dan ook, ik zou gewoon PHP (of een andere script taal) op je server gebruiken, in de meeste gevallen is dat het minst belastend voor je server en het is hoe dan ook de beste oplossing aangezien je niet (of minder) afhankelijk bent van de browser van de gebruiker.

[moozzuzz]

Stamgastje schreef op donderdag 13 september 2007 @ 08:13:
[...]

Inderdaad, dit ontgaat mij ook even.

Neen, zover ik begrijp is het te vergelijken met een template en ruwe data die template-matig (door JS) tot een HTML-doc worden opgebouwd (vergelijkbaar idee van RSS).

Een (lange) lijst van events bijvoorbeeld, waar je dan enkel de title, datum en content in een JS-array gooit (via PHP) en dan client-side ombouwt tot een mooie lijst met veel repeterende toeters en bellen.

Uiteindelijk verlaagt dit de "load" op de server nauwelijks maar de upload-bandbreedte kan er misschien wel van genieten (we hebben dit ooit es geprobeerd voor een lijst van events, maar eerder als "uitdaging" dan noodzaak).