HTTP Requests verlagen voor dynamische content

[Zakkenwasser]

Beste mede webbuilders.

Ik hou ervan om mijn website op alle vlakken te testen, of het nou gaat om css/html validatie of om contrast / laadsnelheid tests.

Ik test ook graag op http requests.
Deze probeer ik tot een minima te houden.

Ik wil zoveel mogenlijk snelheids winst boeken met mijn site, zodat deze ook later op mobiele browsers makkenlijk en snel te bereiken is.

Nu heb ik gisteren mijn film pagina uitgebreid met 12 thumbnailtjes die ieder max 1,4kb weegt.
Opgeteld is het 12x 1,4kb = 16,8kb, wat ik al vrij netjes vindt.

Iedere thumbnail is een link naar een filmpje, dus vrij uniek.
Daardoor genereer ik wel enorm veel http requests !
(12 pakketjes + 2x CSS + header) = 15 requests.

De 12 thumbnails veranderen vaak ook van gezicht.
Deze zijn gekoppeld aan mijn zelf gebouwde CMS.

Ik ben al wezen zoeken op het internet en kwam CSS sprites tegen.
Een prachtige techniek die ik helaas op uniek thumbnails niet kan toepassen,

Wat ik me dus afvraag:
Welke techniek zal voor mijn situatie veel effectiever mijn http requests verminderen?
Zonder de uniekheid van mijn preview thumbnails te verliezen.

Ik hoor het graag

[ Voor 17% gewijzigd door Zakkenwasser op 13-12-2008 21:10 ]

[RobIII]

Met CSS sprites beperk je je HTTP requests tot een minimum; ik zou niet weten hoe je dat nog verder kunt beperken. Wel kun je nog gzip gaan gebruiken om wat compressie op de http verbinding te krijgen en HTTP keepalives gebruiken mocht je dat nog niet doen. Personally denk ik dat je misschien een beetje ver door slaat; met elke ingreep die je loslaat op je project om dit soort 'problemen' op te lossen lever je een stuk compatibility, leesbaarheid en onderhoudbaarheid in.

MrJey schreef op zaterdag 13 december 2008 @ 20:49:
Een prachtige techniek die ik helaas op uniek thumbnails niet kan toepassen,

Want Als dat is omdat ze vaak 'wijzigen' ofzo dan kun je natuurlijk ook dynamisch die sprites aanmaken (en cachen) aan de server-zijde.

[ Voor 34% gewijzigd door RobIII op 13-12-2008 21:14 ]

[Zakkenwasser]

RobIII schreef op zaterdag 13 december 2008 @ 21:10:
Personally denk ik dat je misschien een beetje ver door slaat; met elke ingreep die je loslaat op je project om dit soort 'problemen' op te lossen lever je een stuk compatibility, leesbaarheid en onderhoudbaarheid in.

Als ik het op de juiste manier aanpak, zal ik juist niet op deze punten inleveren.
Ik test vrij veel.

En als ik ook maar merk dat ik moet inleveren op leesbaarheid, dan kies ik liever voor de effectievere techniek.

Php lijkt inderdaad met dynamische thumbs waarschijnlijk de beste optie, tenzij er ook andere manieren zijn.

Hoe dan ook, ik wil dit probleem vermijden en dit op professionele manier oplossen.

[alx]

Thumbs in 1 plaatje samenvoegen en op de client met pixel offsets tonen? Als de optimalisaties erg ransig worden, is dat vaak een teken dat je te ver in de gekozen richting doorslaat.

[BCC]

Volgens mij is alleen google zo groot dat het aantal HTTP requests misschien een keer zin heeft. Waarom wil je dit? Uit puristisch oogpunt?

[RobIII]

alx schreef op zaterdag 13 december 2008 @ 21:46:
Thumbs in 1 plaatje samenvoegen en op de client met pixel offsets tonen?

Dat zijn CSS sprites, zoals in de topicstart reeds aangehaald

[ Voor 10% gewijzigd door RobIII op 13-12-2008 21:52 ]

[Zakkenwasser]

BCC schreef op zaterdag 13 december 2008 @ 21:48:
Volgens mij is alleen google zo groot dat het aantal HTTP requests misschien een keer zin heeft. Waarom wil je dit? Uit puristisch oogpunt?

Juist, ik wil een perfect website maken, waar iedereen blij mee is
De juiste balans tussen design, user interface en snelheid.

Ik ben paar keer de fout ingegaan door 1 jaar geleden een table deisgned website met extreem veel image slices te maken, en heb daar veel kritiek over me heen gekregen.

Ik ben leergierig en leer graag van mijn fouten in het verleden.
Ik heb een developers knobbel, en hou van perfectie, dit keer moet alles tot in de puntjes perfect wezen.

Ik lees mezelf nu in over Gzip, net op mijn css toegepast voor wat snelheids winst.
Dit zal ook wel mogenlijk moeten zijn voor plaatjes lijkt mij.

Maar dan zitten we weer in het verkeerde subforum

[ Voor 27% gewijzigd door Zakkenwasser op 13-12-2008 21:59 ]

[crisp]

Als die thumbnails niet puur een stilistische functie hebben maar ook content vertegenwoordigen (wat meestal wel zo is bij thumbnails) dan is het gebruik van een background-image sowieso al incorrect.
Het gebruik van bijvoorbeeld clipping of andere manieren om een deel van een (gecombineerde grotere) <img> te verbergen zou ik ook niet willen aanraden omdat je daarmee te sterk afhankelijk bent van de CSS-support van een client.

Ergo: 12 thumbnails zijn gewoon 12 <img>-elementen.

Waar je qua clientside performance wel op kan winnen is zorgen dat deze van een andere host kunnen worden geladen - dat scheelt eventuele overbodig cookies in de client requestheaders, en het blocked niet de requests naar je mainhost.

Verder natuurlijk gewoon zorgdragen voor goede cacheability.

Gzip heeft niet of zelfs een negatief effect overigens op binaire files...

[ Voor 5% gewijzigd door crisp op 13-12-2008 22:01 ]

[Zakkenwasser]

crisp schreef op zaterdag 13 december 2008 @ 21:59:
Als die thumbnails niet puur een stilistische functie hebben maar ook content vertegenwoordigen (wat meestal wel zo is bij thumbnails) dan is het gebruik van een background-image sowieso al incorrect.

Background-image? de enige die ik gebruik is 2px . 314px en die zijn gecompressed en stretched over een volledige div.
Dat zou niet slecht moeten wezen voor een 459bytes "zwaar" wegend "plaatje"

Waar je qua clientside performance wel op kan winnen is zorgen dat deze van een andere host kunnen worden geladen - dat scheelt eventuele overbodig cookies in de client requestheaders, en het blocked niet de requests naar je mainhost.

Naja, nog een host erbij nemen, ik zit momenteel nog bij mijndomein.nl, en ga volgend jaar overstappen naar leaseweb.
Het hoeft denk ik niet zo omslachtig met een 2de host erbij.

[ Voor 22% gewijzigd door Zakkenwasser op 13-12-2008 22:15 ]

[RobIII]

MrJey schreef op zaterdag 13 december 2008 @ 22:12:
Naja, nog een host erbij nemen, ik zit momenteel nog bij mijndomein.nl, en ga volgend jaar overstappen naar leaseweb.
Het hoeft denk ik niet zo omslachtig met een 2de host erbij.

Het gaat om een 'virtuele host' in dit geval; een tweede (sub?)domein vanwaar je de images serveert omdat browsers doorgaans 'netjes' niet meer dan 2 gelijktijdige HTTP requests naar 1 enkel domein doen. Fysiek kan dat prima dezelfde server en hetzelfde hostingaccount zijn; zolang je er maar een ander (sub)domein aan knoopt.

[ Voor 11% gewijzigd door RobIII op 13-12-2008 22:35 ]

[Zakkenwasser]

RobIII schreef op zaterdag 13 december 2008 @ 22:34:
[...]

Het gaat om een 'virtuele host' in dit geval; een tweede (sub?)domein vanwaar je de images serveert omdat browsers doorgaans 'netjes' niet meer dan 2 gelijktijdige HTTP requests naar 1 enkel domein doen. Fysiek kan dat prima dezelfde server en hetzelfde hostingaccount zijn; zolang je er maar een ander (sub)domein aan knoopt.

Daar zal wel wat scripting aan te pas komen van de CMS kant.

meer zoiets van, random over max 6 subdomeinen verspreiden waarvan max 2 thumbs per subdomein.


correct me if i'm wrong

[Joolee]

MrJey schreef op zaterdag 13 december 2008 @ 20:49:
2x CSS

Ik heb voor mijzelf een script gebouwd dat alle CSS en JS bestanden die nodig zijn voor de pagina gecomprimeerd (alle onnodige zooi eruit) met behulp van JSMin en CSSTidy, samenvoegt in één bestand en deze cached op de server.
Uiteindelijk heb je cache bestanden voor alle gebruikte combinaties van je JS en CSS files.

Natuurlijk moet je dat alleen doen als je veel verschillende JS en CSS bestanden aanroept op verschillende pagina's. Anders kun je beter zorgen dat de client je JS en CSS bestanden éénmaal in de cache kan plaatsen.

[RobIII]

MrJey schreef op zaterdag 13 december 2008 @ 22:45:
[...]

Daar zal wel wat scripting aan te pas komen van de CMS kant.

meer zoiets van, random over max 6 subdomeinen verspreiden waarvan max 2 thumbs per subdomein.


correct me if i'm wrong

Moeilijk doen als 't makkelijk kan
Gewoon een andere domeinnaam kiezen en die verwijzen naar dezelfde server (een 'alias' is dus al voldoende). De URL van de images dat domein geven (xxx.nl vervangen door yyy.nl) en klaar. Om daar nou een bak subdomeinen voor te gaan reserveren en max 2 thumbs per subdomein blabla is complete onzin (en kost je dan weer DNS requests) en is IMHO, again, veel te ver doorgeslagen.

Waarom zou dit 'perfectie' zijn volgens jou? In mijn ogen maak je er dan alleen maar een administratieve puinhoop van en dat alleen voor een paar HTTP requestjes die geen drol kosten. Zoals crisp al aangaf gewoon zorgen voor nette caching, zorgen dat je geen cookies op dat (sub)domein meestuurt etc. en dan ben je al een heel eind.

[ Voor 25% gewijzigd door RobIII op 13-12-2008 22:52 ]

[BCC]

Inderdaad.. door de dynamiek van webapplicaties is het veel belangrijker dat het onderhoudbaar en flexibel is dan enorm getweaked op performance. Meer servers zijn een stuk goedkoper dan meer developers.

[mcDavid]

Ik kwam toevallig een link tegen met veel interessante tips om je pagina's sneller te laten laden:
http://developer.yahoo.com/performance/rules.html

Onder andere wordt aangehaald dat je niet meer dan max. 2-4 domeinen moet gebruiken, omdat anders de winst niet meer opweegt tegen de vertraging door DNS-lookups.