[HTML]Bandbreedte besparen *

[RwD]

Ik moet een nieuw (voor de zoveelste keer) beheersysteem voor een websites admin schrijven. Alleen moet ik zoveel mogelijk de bandbreedte sparen...

Welke opties heb ik?

Ik dacht sowieso dus
+ Geen of heel weinig, en dan kleine, plaatjes
+ Zo effiecient mogelijke output (onleesbaar eigenlijk) met alle extra whitespaces er uit.
+ Zo weinig mogelijk het scherm moeten refreshen...
- Frames?
- Gegevens ophalen/aanpassen doormiddel van een IFRAME + JavaScript??

Heeft iemand hier nog ideeen voor, en wellicht alternatieven/argumenten voor/tegen FRAMES en IFRAME. Zelf probeer ik normaal JavaScript zoveel mogelijk te vermijden waar het ook met PHP gedaan kan worden.

[gorgi_19]

HttpCompression
oa GZip compression kan veel bandbreedte besparen; zijn aparte modules voor voor Apache, IIS, asp.net,etc.
Clientside caching
Wat er op de client bewaard wordt aan pagina en plaatjes, hoeft niet ververst te worden.
Anti-leeching scripts
Per definitie uitsluiten dat iemand anders 'jouw' bandbreedte kan 'stelen'

Over jouw puntjes:
1. Cache eens, bespaard ook een hoop.
2. Mja, httpcompression maakt meer uit en de verschillen zijn dan marginaal
3. Kan, maar moet je niet tig javascripts gaan maken die enorm lang zijn. Alleen elementen die veel postbacks vereisen, kan je als zodanig aanpassen, mits je dan niet te veel data 'extra' moet oversturen
4. Maakt weinig uit, HTTPCompression moet eea ook kunnen compenseren en de doorzoekbaarheid voor zoekmachines verminderd

Verder is Javascript niet eng, mits je het goed gebruikt.

[ Voor 116% gewijzigd door gorgi_19 op 29-07-2004 09:12 ]

[DeadMetal]

Interessant topic! Vooral dat Clientside caching zou voor mijn website erg van pas komen. Een groot deel wordt namelijk bij iedere pagina geladen (het menu bijvoorbeeld, die vreet enorm veel bandbreedte omdat hij op iedere pagina opnieuw geladen wordt).

Zijn er voor de eerste twee punten makkelijke handleidingen beschikbaar? (ik heb er nog helemaal geen ervaring mee)

[SchizoDuckie]

Een van de belangrijkste punten mis ik nog

Genereer VALID xhtml en bouw je site ZONDER tables voor je layouts!!!!
Weet je niet waar ik het over heb, zoek dan ff op google.

Het scheelt zo veel om je opmaak echt PUUR in CSS te doen, en voor een menu bijv. een <ul> met <li>'s te gebruiken ipv 20 geneste tables

En CSS wordt natuurlijk ook gewoon gecached

[ Voor 6% gewijzigd door SchizoDuckie op 29-07-2004 09:23 ]

[DeadMetal]

Valid XHTML heb ik gisteren ook gehoord van een vriend. Maar waarom scheelt dat bandbreedte? Want bij XHTML moet je voor elke tag een sluittag plaatsen, terwijl je normaal gesproken bijvoorbeeld </p> mag weglaten. En <br> wordt <br /> in XHTML. Ik dacht dus juist dat de code met XHTML alleen maar groter wordt. Kan je dat eens uitleggen?

Zonder tables scheelt inderdaad veel code. Maar ik gebruik van die ronde hoeken (kleine plaatjes als achtergrond) in de hoeken van m'n table, is zoiets mogelijk zonder tables?

[pietje63]

Ja, zoiets is mogelijk en zelfs een stuk netter met css (maar daarvoor moet je eigenlijk bij de buren zijn).
Ik geef toe dat ik zelf ook vrijwel alles met tables doen, maar ik heb de laatste tijd een paar keer een topic in W&G over css (2) doorgelezen en dat biedt toch veel mogelijkheden, vooral als je dezelfde opbouw meerdere keren gebruikt.

[RwD]

gorgi_19 schreef op 29 juli 2004 @ 09:06:
HttpCompression
oa GZip compression kan veel bandbreedte besparen; zijn aparte modules voor voor Apache, IIS, asp.net,etc.
Clientside caching
Wat er op de client bewaard wordt aan pagina en plaatjes, hoeft niet ververst te worden.
Anti-leeching scripts
Per definitie uitsluiten dat iemand anders 'jouw' bandbreedte kan 'stelen'

Over jouw puntjes:
1. Cache eens, bespaard ook een hoop.
2. Mja, httpcompression maakt meer uit en de verschillen zijn dan marginaal
3. Kan, maar moet je niet tig javascripts gaan maken die enorm lang zijn. Alleen elementen die veel postbacks vereisen, kan je als zodanig aanpassen, mits je dan niet te veel data 'extra' moet oversturen
4. Maakt weinig uit, HTTPCompression moet eea ook kunnen compenseren en de doorzoekbaarheid voor zoekmachines verminderd

Verder is Javascript niet eng, mits je het goed gebruikt.

Die compressie is een goed idee, die zal ik er sowieso bij doen. Alleen nog info er over zoeken hoe het precies gebeurd -> nog nooit gebruikt

Caching op een admin pagina? ik weet niet hoor, volgens mij moet ik data actueel houden, maar voor client side kan het wel uitmaken, en gebruik ik het al.

Leechen is geen probleem, admin gedeelte is voldoende beveiligd...

Javascript is ook niet eng, ik vermijd het alleen het liefst waar dit kan omdat het gewoon vaak om domme redenen of niet werkt op *een* browser, of gewoonweg uitgeschakeld is

[RwD]

Papa Eend schreef op 29 juli 2004 @ 09:22:
Een van de belangrijkste punten mis ik nog

Genereer VALID xhtml en bouw je site ZONDER tables voor je layouts!!!!
Weet je niet waar ik het over heb, zoek dan ff op google.

Het scheelt zo veel om je opmaak echt PUUR in CSS te doen, en voor een menu bijv. een <ul> met <li>'s te gebruiken ipv 20 geneste tables

En CSS wordt natuurlijk ook gewoon gecached

Je bedoeld zoals www.csszengarden.com ??

Zo heb ik al een site gemaakt, maar ja, als je 20 geneste tables nodig hebt, dan is er wat mis in je weergave denk ik...

[faabman]

voor de mensen die het over valid xhtml hebben icm bandbreedte besparing hebben, lees dan even

http://annevankesteren.nl/archives/2004/07/bandwidth

[gorgi_19]

Het wordt me nu allemaal iets te veel clientside, dus

>> Webdesign & Graphics

[André]

Dan wil ik nog even noemen dan een HTML pagina minder kb's gebruikt dan een XHTML pagina

Edit:
Was dus al genoemd door faabman

[ Voor 23% gewijzigd door André op 29-07-2004 10:04 ]

[Verwijderd]

Die clientside caching kun je wel vergeten, in een administration interface wil je juist niet dat zaken als informatie gecached terugkomen.

Voor de rest haal je enorm veel besparingen uit het gebruik van Javascript, hergebruik van code, dynamisch aanspreken van componenten. Dat is echter niet voor iedereen weggelegd omdat er een enorme tijd aan studie en ervaring op javascript vlak in moet zitten wil je het een beetje voor elkaar krijgen.

[ Voor 24% gewijzigd door Verwijderd op 29-07-2004 10:07 ]

[Croga]

faabman schreef op 29 juli 2004 @ 09:43:
voor de mensen die het over valid xhtml hebben icm bandbreedte besparing hebben, lees dan even

http://annevankesteren.nl/archives/2004/07/bandwidth

Tsja... jammer alleen dat Anne geen verstand heeft van layout..... in IE5.5 komt het menu over de text heen te staan, waardoor alle tekst onleesbaar wordt.

[X-Lars]

Croga schreef op 29 juli 2004 @ 10:11:
[...]

Tsja... jammer alleen dat Anne geen verstand heeft van layout..... in IE5.5 komt het menu over de text heen te staan, waardoor alle tekst onleesbaar wordt.

offtopic:
Wablief? Je zou ook de nuttige en bruikbare informatie van het artikel kunnen gebruiken en Anne op de hoogte stellen van deze fout of bug in plaats van zo'n bewering op dit forum te plaatsen.

[ Voor 3% gewijzigd door X-Lars op 29-07-2004 10:18 ]

[Verwijderd]

offtopic:
Of IE wordt niet ondersteund. En mail me aub op [e-mail] oid als je daar verder op in wilt gaan.

[ Voor 3% gewijzigd door Verwijderd op 29-07-2004 10:18 ]

[RwD]

Verwijderd schreef op 29 juli 2004 @ 10:04:
Die clientside caching kun je wel vergeten, in een administration interface wil je juist niet dat zaken als informatie gecached terugkomen.

Voor de rest haal je enorm veel besparingen uit het gebruik van Javascript, hergebruik van code, dynamisch aanspreken van componenten. Dat is echter niet voor iedereen weggelegd omdat er een enorme tijd aan studie en ervaring op javascript vlak in moet zitten wil je het een beetje voor elkaar krijgen.

Maar wat zeg jij dan van het gebruik van IFrames in combinatie met een beetje JavaScript? Ik kom genoeg uit de voeten met JavaScript om dit voor elkaar te krijgen. Ik vergeet alleen soms even te kijken of ik niet "IE only" bezig ben. (Maar van de andere kant ben ik tot nu toe er altijd mee weg gekomen om voor de admin zijde een specifieke browser of beter te eisen.)

Je kunt trouwens veel scripting door PHP laten doen, dat vereist ook vrij weinig bandbreedte als je precies weet welke resultaten je gaat krijgen? Je zult vroeg of laat toch gegevens uit de database gaan halen, want logischerwijs kun je in (bijna) geen enkel geval steeds de gehele db inhoud mee sturen en dan alles clientside aanpakken.


----
Waarom is trouwens in godsnaam PHP uit de titel gehaald moderators alhier? Ik ben wel degelijk op zoek naar PHP dingen die de bandbreedte kunnen besparen voor zover aanwezig, en zeker niet ASP of iets dergelijks!!

[Verwijderd]

RwD schreef op 29 juli 2004 @ 14:27:
[...]
Maar wat zeg jij dan van het gebruik van IFrames in combinatie met een beetje JavaScript? Ik kom genoeg uit de voeten met JavaScript om dit voor elkaar te krijgen. Ik vergeet alleen soms even te kijken of ik niet "IE only" bezig ben. (Maar van de andere kant ben ik tot nu toe er altijd mee weg gekomen om voor de admin zijde een specifieke browser of beter te eisen.)

Je kunt trouwens veel scripting door PHP laten doen, dat vereist ook vrij weinig bandbreedte als je precies weet welke resultaten je gaat krijgen? Je zult vroeg of laat toch gegevens uit de database gaan halen, want logischerwijs kun je in (bijna) geen enkel geval steeds de gehele db inhoud mee sturen en dan alles clientside aanpakken.


----
Waarom is trouwens in godsnaam PHP uit de titel gehaald moderators alhier? Ik ben wel degelijk op zoek naar PHP dingen die de bandbreedte kunnen besparen voor zover aanwezig, en zeker niet ASP of iets dergelijks!!

Waarom een iframe, waarom niet xmlHttp (kan icm responseText, wat je wil), of remote procedure calls. Bij een iframe moet je alsnog een pagina gaan parsen, inladen, versturen, uitlezen, etc.

Met PHP ga je echt geen bandbreedte besparen. Met een juiste aanpak van je applicaties wel. PHP is daar alleen een middel toe.

[RwD]

Verwijderd schreef op 29 juli 2004 @ 14:57:
[...]


Waarom een iframe, waarom niet xmlHttp (kan icm responseText, wat je wil), of remote procedure calls. Bij een iframe moet je alsnog een pagina gaan parsen, inladen, versturen, uitlezen, etc.

Met PHP ga je echt geen bandbreedte besparen. Met een juiste aanpak van je applicaties wel. PHP is daar alleen een middel toe.

Ow, ik zie wat je bedoelt, stom genoeg heb ik zoiets al eens in het klein gedaan, en vergeten

Na ja, bedankt voor de tip

[Verwijderd]

Maak goed gebruik van CSS.
Het wordt hier al wel genoemd, maar een beetje tussen de regels door, alsof het heel vanzelfsprekend is dat je dat zou doen.

Als je alle style-elementen in de CSS-file stopt en echt alleen maar semantische dingen in je (X)html, dan zijn de html-bestanden verrassend klein.
De CSS-file hoeft ook maar 1 keer opgehaald te worden.

Ook handig is het om je pagina's af en toe door http://www.websiteoptimization.com/services/analyze te halen. Ze geven puntsgewijs aan waar je snelheids/bandbreedtewinst kunt halen door de code van je pagina aan te passen.

Alle maatregelen zoals gzip en caching zijn ook mooi, maar hoe beter je code en opzet hoe minder je dat nodig hebt.

Wat is trouwens de reden dat de bandbreedte zo belangrijk is?

[Verwijderd]

Verwijderd schreef op 29 juli 2004 @ 15:42:
Wat is trouwens de reden dat de bandbreedte zo belangrijk is?

Responsesnelheid Het scheelt heel veel als je in een complexe web interface bij acties en events niet complete documenten hoeft in te laden zoals listview en grids, maar dynamisch data kan aanpassen in het component zonder opnieuw alle data op te halen terwijl je maar één ding wijzigt.

[Eskimootje]

Javascript gewoon laten wijzigen en bij de onunload event alles bijwerken lijkt me hier prima geschikt voor. En bandbreedte besparing is iets anders als response snelheid.

[RwD]

Gordijnstok is een goeie . Samen met die compressie zijn dat mogelijkheden die veel kunnen doen denk ik.

Als iemand anders nog suggesties heeft...

[Verwijderd]

Eskimootje schreef op 29 juli 2004 @ 16:37:
En bandbreedte besparing is iets anders als response snelheid.

Dat weet iedereen, wat ik alleen aangeef is dat het in bepaalde gevallen bijkomende voordelen oplevert voor je algehele responssnelheden in je applicaties als je bandbreedte weet te minimaliseren.

Niet gerelateerd aan HTML, maar hoe vaak zie je niet mensen nog steeds recursieve database calls bij de applicatieserver neerleggen, waardoor je niet alleen factor aanroep aan template calls hebt, maar ook nog eens factor aanroep aan database connecties. Resultaat is een retetrage constructie, die een torenhoge cpu hit veroorzaakt en ook nog eens per recursieve aanroep data verzend aan de applicatieserver. Leg dan die business logic bij het rdbms in een stored procedure en voer een enkele sql call uit, die ook maar eenmaal data terugverzend. Zo krijg je als snel factor 500% of meer performance increases die uiteraard de clientside kant heel snel gaat merken in de responsesnelheid van pageloads.

[Verwijderd]

Waarom hoor ik hier nou niemand keyword: SOAP roepen? Okey, de xmlHTTP opmerking van Gordijnstok komt aardig in de buurt...
SOAP is gewoon geniaal. Als je dan toch wil gaan klooien met xmlHTTP en je wil het compatibel houden met Gecko, dan is het Sarissa project misschien wel handig.

[Verwijderd]

Verwijderd schreef op 30 juli 2004 @ 11:05:
Waarom hoor ik hier nou niemand keyword: SOAP roepen? Okey, de xmlHTTP opmerking van Gordijnstok komt aardig in de buurt...
SOAP is gewoon geniaal. Als je dan toch wil gaan klooien met xmlHTTP en je wil het compatibel houden met Gecko, dan is het Sarissa project misschien wel handig.

Dan mag jij mij, die toch best veel met SOAP heeft gewerkt, gaan uitleggen wat het voordeel is van SOAP gebruik op het web via xmlHTTP, tov XML Documents Wat zijn volgens jij de voordelen?

Voor de rest zie ik die compatibiliteits voor Gecko ook niet zo, enige wat je hoeft te doen is het object via xmlHttpRequest() creeren, je hoeft geen null value te sturen op send, en onreadystatechange moet gepatched worden voor vroegere beta versies. Voor de rest...

[ Voor 19% gewijzigd door Verwijderd op 30-07-2004 11:21 ]

[Verwijderd]

Verwijderd schreef op 30 juli 2004 @ 11:13:
[...]


Dan mag jij mij, die toch best veel met SOAP heeft gewerkt, gaan uitleggen wat het voordeel is van SOAP gebruik op het web via xmlHTTP, tov XML Documents Wat zijn volgens jij de voordelen?

Voor de rest zie ik die compatibiliteits voor Gecko ook niet zo, enige wat je hoeft te doen is het object via xmlHttpRequest() creeren, je hoeft geen null value te sturen op send, en onreadystatechange moet gepatched worden voor vroegere beta versies. Voor de rest...

SOAP heeft wel degelijk voordelen ten opzichte van xmlHTTP. SOAP is het meest krachtig bij grote projecten. Wanneer je een simpel project hebt, heeft SOAP geen voordelen ten opzichte van xmlHTTP.
Wanneer er echter veel communicatie tussen server en client af moet spelen, is SOAP handig. Er moet dan wel sprake zijn van interactie. Als je simpelweg alleen rauwe data naar de client wil stouwen is xmlHTPP voldoende. Wanneer je ook wil dat de gebruiker een verzoek naar de server kan sturen en afhankelijk van dat verzoek de juiste data terugkrijgt, is SOAP dé oplossing.
Je kan nu wel zeggen dat je wat parameters aan de URL zou kunnen meegeven die dan weer door een server-side taal uitgelezen worden, maar een protocol als SOAP is daar veel geschikter voor.

Maar hoe wou je xmlHTTP gebruiken als je bijvoorbeeld een zoekopdracht moet uitvoeren? De gebruiker heeft een aantal zoek-criteria ingevuld en klikt op zoeken. Ik werk dan liever met SOAP dan met xmlHTTP.

[Verwijderd]

Je doet nu net of je een Catterpillar vrachtwagen nodig hebt om een aanhangertje met 2 wielen met wat grindtegels (btw gratis grindtegels af te halen bij mij, stuk of 100) te trekken.

Je kunt gewoon een document samenstellen met de XML functionaliteit in je browser, daar heb je geen soap envelopes voor nodig SOAP is vooral bedoeld als een eenduidige vorm van data uitwisseling tussen diverse systemen, voor het web is dit imo dikke overkill daar de communicatie plaatsvind tussen client en browser tenzij je aan de gang gaat met webservices. Je kunt gewoon je data als url variable versturen

[ Voor 4% gewijzigd door Verwijderd op 30-07-2004 12:12 ]

[Verwijderd]

Verwijderd schreef op 30 juli 2004 @ 12:12:
Je doet nu net of je een Catterpillar vrachtwagen nodig hebt om een aanhangertje met 2 wielen met wat grindtegels (btw gratis grindtegels af te halen bij mij, stuk of 100) te trekken.

Je kunt gewoon een document samenstellen met de XML functionaliteit in je browser, daar heb je geen soap envelopes voor nodig SOAP is vooral bedoeld als een eenduidige vorm van data uitwisseling tussen diverse systemen, voor het web is dit imo dikke overkill daar de communicatie plaatsvind tussen client en browser tenzij je aan de gang gaat met webservices. Je kunt gewoon je data als url variable versturen

Hoewel ik dubbel heb gelegen om je analogie, ben ik het er toch niet helemaal mee eens. In sommige gevallen kan je niet alles meegeven aan de URL. Neem bijvoorbeeld een admin pagina. Stel je wil om één of andere vage reden dat je geen formulier gebruikt om de data traditioneel te posten. Om dan de complete content van je tekstveld als url variabele mee te geven lijkt me ook niet zo handig.

offtopic:
Ik denk eigenlijk dat dit veschil van mening uit gaat lopen op een wellus-nietus spelletje...

Ik geef je gelijk, dat in dit voorbeeld SOAP niet persé nodig is. SOAP hoeft geen overkill te zijn. 't Hoeft helemaal niet veel tijd te kosten om een SOAP server op te zetten... Als je wat 'templates' heb, gaat alles redelijk vlot.

[Verwijderd]

Verwijderd schreef op 30 juli 2004 @ 12:21:

In dat geval zijn url variables inderdaad niet zo handig, maar dat je bandbreedte gaat besparen wil niet meteen betekenen dat alles persistant moet zijn. Zaken als text editors etc. wil je ook weer unloaden uit je browser memory, dus zodra jij een lap tekst hebt ingevoerd is het zowiezo wenselijk om in ieder geval die pagina daarna te verlaten om zo de garbage collector van je browser aan de gang te zetten.

[Croga]

Verwijderd schreef op 30 juli 2004 @ 12:12:
Je kunt gewoon je data als url variable versturen

Ja, totdat je er achter komt dat IE slechts 255 karakters ondersteund in de URL. En als de base URL van je formulier dan al een stapel karakters groot is, blijft er nog maar weinig over om de data in te stoppen....

[Verwijderd]

Croga schreef op 30 juli 2004 @ 14:10:
[...]


Ja, totdat je er achter komt dat IE slechts 255 karakters ondersteund in de URL. En als de base URL van je formulier dan al een stapel karakters groot is, blijft er nog maar weinig over om de data in te stoppen....

Lees mijn verhaal nog eens... je gaat toch geen enorme lappen tekst of uberhaupt al lappen tekst versturen per url variabele

Zaken als url parameters met booleans, integers of korte varchars gaan perfect. Maar je moet inderdaad niet zulke zaken gaan versturen.

Een goed voorbeeld van xmlHttp vind je bijvoorbeeld op gmail van google, die maken er ook veel gebruik van.

[RwD]

Verwijderd schreef op 30 juli 2004 @ 20:31:
[...]

...

Een goed voorbeeld van xmlHttp vind je bijvoorbeeld op gmail van google, die maken er ook veel gebruik van.

Weet je misschien ook andere goede voorbeelden? Gmail kan ik me nog niet voor aanmelden

[ Voor 30% gewijzigd door RwD op 31-07-2004 15:25 ]

[Verwijderd]

Neem dit pruts0r script maar als voorbeeld:

Java:

// performs HTML encoding of some given string
htmlEncode = function(s) {
    s = s.replace(/&/ig, "&");
    s = s.replace(/</ig, "&lt;");
    s = s.replace(/>/ig, "&gt;");
    s = s.replace(/\x22/ig, "&quot;");
    // \x22 means '"' use hex reprezentation so that we don't disturb
    // JS compressors
    return s;
};

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP.3.0");
xmlhttp.open("GET","http://www.nextavenue.com/development/Configuration/Menus/menus.xml", false);
xmlhttp.send();
var oDomMenus = xmlhttp.responseXML;
document.write(htmlEncode(xmlhttp.responseText));

[ Voor 12% gewijzigd door Verwijderd op 31-07-2004 15:47 ]

[RwD]

Hmm, dan moet ik alleen nog uitzoeken hoe ik dit op FireFox ga laten werken, waarop ik meestal als eerste check of het werkt. Maar daar kom ik wel uit. (Tenzij iemand me nu al kan vertellen dat dit niet werkt voor FireFox)

[ Voor 39% gewijzigd door RwD op 31-07-2004 20:46 ]

[Verwijderd]

RwD schreef op 31 juli 2004 @ 20:46:
Hmm, dan moet ik alleen nog uitzoeken hoe ik dit op FireFox ga laten werken, waarop ik meestal als eerste check of het werkt. Maar daar kom ik wel uit. (Tenzij iemand me nu al kan vertellen dat dit niet werkt voor FireFox)

Jawel,

code:

var req;

function loadXMLDoc(url) {
    // branch for native XMLHttpRequest object
    if (window.XMLHttpRequest) {
        req = new XMLHttpRequest();
        req.onreadystatechange = processReqChange;
        req.open("GET", url, true);
        req.send(null);
    // branch for IE/Windows ActiveX version
    } else if (window.ActiveXObject) {
        req = new ActiveXObject("Microsoft.XMLHTTP");
        if (req) {
            req.onreadystatechange = processReqChange;
            req.open("GET", url, true);
            req.send();
        }
    }
}

code:

function processReqChange() {
    // only if req shows "loaded"
    if (req.readyState == 4) {
        // only if "OK"
        if (req.status == 200) {
            // ...processing statements go here...
        } else {
            alert("There was a problem retrieving the XML data:\n" +
                req.statusText);
        }
    }
}

[RwD]

http://developer.apple.co...ebcontent/xmlhttpreq.html

[ Voor 8% gewijzigd door RwD op 01-08-2004 09:14 ]