[HTML] Andere pagina in pagina

[BoomSmurf]

M'n clanleider heeft me gevraagd naar de clan website te kijken hoe we bandwidth kunnen besparen. De FP daaro is bv 175kb. Nu heb ik ondertussen gzip compressie erin gebouwd maar nu zit ik verder te kijken naar caching. Omdat er bv een PHP blok inzit met 'who is online' en nog wat van die dingen, gaan die paginas natuurlijk nooit fatsoenlijk gecached worden. Heel veel dingen zijn nogal static dus zouden in weze perfect gecached kunnen worden als het losse pagina's waren. Nu weet ik ontzettend veel van de server side kant en hoe het HTTP protocol precies in elkaar zit, maar HTML zelf is niet m'n sterkste kant

Wat ik nu eigenlijk wil weten is de verschillende manieren om een andere HTML pagina te embedden in een HTML pagina. Het enige wat ik tot nog toe gevonden heb zijn frames en iframes. Normale frames worden te moeilijk daarvoor zou de complete site opnieuw geschreven moeten worden. Met iframes heb ik het probleem dat de hoogte en breedte opgegeven moet worden, ipv dat de frame gewoon de 'scrollHeight' is. Hier kunnen we natuurlijk met een javascriptje wel omheen maar echt handig is het niet Is er geen HTML tag waarmee je gewoon een andere pagina kan 'includen' of zo? Dat het in feite hetzelfde zou zijn als die inhoud van die pagina gewoon op de plek van die tag zou staan?

[coubertin119]

Een FP van 175kB, is dat images inclusief? Of enkel de (X)HTML-code? If so, gooi die WYSIWYG-editor weg . En gooi zoveel mogelijk in de CSS, CSS cached erg gemakkelijk. En als echt iedere kilobyte telt, kan je met Javascript gaan werken.

En pagina's includen kan niet in HTML. Met JS kan het dan weer wel, als je veel werk levert.

[BoomSmurf]

Dat is ex images natuurlijk. Het HTML bestanden wat we de FP noemen is 175kb Het is verder een PHPnuke pagina, niet wysiwyg of zo. Gewoon PHP uitpoepsel. Ik zou de link wel geven maar dan gaan jullie allemaal kijken en zitten we meteen over de bandwidth limit heen

Jammer dat er idd niet zo'n tag is. Waar ik nu even aan zit te denken is het volgende:

In plaats van de losse PHP bloks HTML uit te laten poepen, ze een javascript uit te laten gooien (ofwel, 'function WriteXXXX { document.write(<normal php uitvoer>) }'). Deze kunnen dan als externe javascripts aangeroepen worden in de 'main' HTML pagina's. Op de plek waar het PHP blok dan normalite zou staan zou er gewoon iets als '<SCRIPT>WriteXXXX();</SCRIPT>' komen te staan. De bloks die niet veranderen zouden dan gecached worden (als de goeie headers erbij gegooid worden).

.plan?

[TafkaT]

coubertin119 schreef op 17 juli 2004 @ 14:26:
En pagina's includen kan niet in HTML. Met JS kan het dan weer wel, als je veel werk levert.

Het zou eventueel kunnen met iframes, toch?

[Verwijderd]

175 KB voor alleen de HTML lijkt me vrij onmogelijk veel. Ik denk dat je je plaatjes hierin hebt meegenomen, en dat is dan ook de plaats waar je bandwidth kan besparen. Dat kan bijvoorbeeld door ze als een ander formaat op te slaan (JPEG/PNG), minder kleuren te gebruiken of slechtere kwaliteit in te stellen.

Edit: argh. Toch geen plaatjes.

[ Voor 6% gewijzigd door Verwijderd op 17-07-2004 14:37 ]

[BoomSmurf]

@TafkaT: ja het KAN idd wel, maar lijkt me niet de makkelijkste manier

@Sjord: De plaatjes zijn allemaal heel erg klein. Eén clan banner en voor de rest zijn ze allemaal max 32x32, meer icons dus. Deze worden ook perfect gecached. Het is echt de HTML zelf die bandbreedte freet.

Maar ik wil dus eik wel effe jullie mening weten over m'n idee in m'n post hiervoor?

[flat]

Een html-pagina van 175 kilobyte is of een vreselijke tagsoup die in nette xhtml een stuk kleiner kan, of hij bevat veel meer informatie dan voor de gebruiker nodig is. Dat lijkt mij tenminste

Ik neem aan dat je frontpage nieuwsitems bevat. Je zou bijvoorbeeld het aantal daarvan terug kunnen brengen naar 3 of 5, met daaronder links naar de vorige 5 entries of de archieven. Dat scheelt niet alleen bandbreedte, maar het is ook nog eens overzichtelijker voor de gebruiker.

Verder lijkt het me toch wel handig om die pagina ergens te kunnen zijn. Als je wilt kan je me de link mailen, dan sla ik 't ding op en zet ergens online.

[ Voor 45% gewijzigd door flat op 17-07-2004 14:55 ]

[BoomSmurf]

't is idd wel een aardige tagsoup, mn clanleider heeft nogal ruzie met PHPnuke geloof ik Verder staat er idd ook een hele berg informatie op. Maar het is niet m'n taak om de inhoud te veranderen, maar om de bandwidth terug te dringen zonder inhoudelijke veranderingen. Met compressie is ie al terug gedrongen naar 20kb maar ik denk dat het dmv die JS nog kleiner kan...

[curry684]

BoomSmurf schreef op 17 juli 2004 @ 14:34:
Dat is ex images natuurlijk. Het HTML bestanden wat we de FP noemen is 175kb

Dat is volstrekt absurd veel. De T.net Frontpage is op dit moment 33Kb... ik zou a) eens naar de HTML kijken en b) eens of er wel zoveel troep op de FP moet.

[Paters]

Wat je kunt doen is link in een cel openen in een andere cel (in dezelfde tabel of in een andere tabel.

Dan zet je in de lege cel waar de link in moet worden geopend:

code:

<?php  

$actionfile = "$action";  

if (file_exists($actionfile))  
{  
include("$actionfile");  
}  
else  
{  
include("leeg.htm");  
}  

?>

leeg.htm staat er dan standaard in die cel. Wanneer je de link als volgt schrijft:

code:

<a href="naamvanjepagina.php?action=ditkomtindelegeceltestaan.htm">

Tis echter geen html oplossing maar een php oplossing. Het kan zijn dat ik je compleet verkeerd heb begrepen (ben nog maar een beginner).

[TafkaT]

Ik kwam net nog een interessant artikel tegen:
http://www.theukwebdesign.../articles/php-caching.php
en dan vooral het kopje "Regenerate only When Necessary"

Wellicht heb je hier iets aan.

[BoomSmurf]

@curry: ... zoals ik al zei, het is niet aan mij de content te veranderen. Bovendien wordt er voor de rest niets external gelinkt momenteel. De php schrijft alles naar 1 bestand, dus inclusief alle javascript en css. Dit haal ik er nu dus wel uit.

@Paters: Dat is zoals het nu is. Ik wil het echter client side ipv server side hebben, omdat er dan veel beter gecached kan worden

@TafkaT: Ik heb het zojuist gelezen. Lijkt wel een beetje op m'n oplossing nu.

Zoals ik het nu gedaan heb (voor een paar bestanden - nog lang niet alles) lijkt goed te werken. Ik laat de afzonderlijke php bloks javascript ipv html uitpoepen. Deze komen met een <script src...> in de hoofdpagina. Deze lossen bestandjes kunnen dus wel gecached worden dmv een etag.php die ik zelf in elkaar gedraaid heb die etags maakt op basis van md5. Deze worden bij een request vergeleken en eventueel een 304 teruggestuurd. Verder nog effe een compress.php in elkaar gedraaid die het hele zooitje met gzip terugstuurd. Al met al vrij weinig werk en een hoop bandbreedte besparing.

[Blaise]

Kan je de source van een pagina opslaan en ergens anders uploaden? dan kunnen er waarschijnlijk nog betere tips worden gegeven.

[Marijn_S]

curry684 schreef op 17 juli 2004 @ 15:21:
[...]

Dat is volstrekt absurd veel. De T.net Frontpage is op dit moment 33Kb... ik zou a) eens naar de HTML kijken en b) eens of er wel zoveel troep op de FP moet.

De source zelf is inderdaad 33kb. De gzip versie is zelfs 9.14 KB (als Firefox dat correct weergeeft tenminste).

Verder is die 20 KB wat je er aan overhoudt niet echt veel vind ik (in grootte, aardige winst namelijk!). Daar is wel mee te leven, al zou met caching en vooral wat opschoonwerk er veel bandbreedte bespaard kunnen worden ja.

En wat Blaise zegt is wel handig ja

[BoomSmurf]

@Blaise: zoals eerder gezegd is het niet de bedoeling dat ik er veel in ga veranderen. Het huidige kan ik doen door aan een aantal bestanden 1 regel toe te voegen.

@Cerberus: Firefox geeft idd de verzonden grootte weer (zojuist getest), dus die 9.14kb is idd de grootte van de gegzipte file.... Die 20kb is idd respectabel, maar grote delen van de gegevens zie je over meerde pagina's hetzelfde, dus waarom die meer dan één keer versturen....

[crisp]

De Tnet frontpage is niet te vergelijken; die wordt vnl mbv javascript opgebouwd wat ook weer z'n nadelen heeft. Hier op het forum wordt enkel gebruik gemaakt van gzip compressie, dus dat zou een betere vergelijking zijn.