Hoe zwaar is de ideale website maximaal ?

Status
Niet open voor verdere reacties.

janyep

Gebruiker
Lid geworden
7 mei 2008
Berichten
261
Hallo allemaal

mijn website heeft pagina's van 2,5 MB

Voorheen was dit wellicht aan de zware kant.
Maar nu er steeds snellere verbindingen komen (glasvezel + Tele2 start 4G-dienst):
weet iemand wat gangbaar / geschikt zou zijn voor de toekomst?

Voor de toekomst: omdat ik nog wel een paar maanden bezig ben voordat de "verbouwing" af is :thumb:

met vriendelijke groet, janyep
 
Oh ik dacht bij een paagina van 2.5 MB meer aan een Flash site of ongecomprimeerde foto's, maar je hebt gewoon heel veel tekst en heel veel plaatjes op elke pagina.

Ik zou de pagina's wat meer opknippen in kleinere delen, en misschien met een menu in de vorm van routekaart of iets dergelijks gaan werken. Zulke lappen tekst nodigen niet uit tot lezen, en dat is zonde, want het is wel duidelijk dat je er met plezier erg veel tijd in hebt gestoken.
 
Ik kan daar geen antwoord op geven, het is meer wat jezelf nog acceptabel vind. 2.5 MB zou ik zelf niet acceptabel vinden.

Ik probeerde alleen aan te geven, wannneer je de extreem lange pagina's op je site opknipt in kleinere brokken je over laadtijd niet zo'n zorgen hoeft te maken.
 
yep.

jammer dat ik nu nog niet weet wat je zelf wel acceptabel zou vinden ...

toch vriendelijk dank voor alle moeite,
gr. janyep
 
Bezuinigen, maar niet voor de MB's ...

Hoi janyep,
Nog steeds ben ik beduusd over enorme hoeveelheid aan aangeboden informatie op de site.

De pagina-zwaarte wordt hier in belangrijke mate bepaald (en de paginasnelheid vertraagd) door de grote hoeveelheid (vaak: mini-)images; op de homepage zo'n 148 stuks.
Elk image moet apart door de browser opgevraagd worden met een http-request, en behalve extra overhead is dat uploaden van de bezoeker naar de server, en dat gaat veel langzamer dan downloaden!
  • Zie hier: waarom http requests verminderen?.
  • Voor image-optimalisatie kunnen een aantal technieken gebruikt worden, zie bv. hier: Images optimaliseren.
    En YSlow zegt: "Do not scale images in HTML - There are 90 images that are scaled down.", dus hier valt eer aan te behalen.
  • Ook voor handig en besparend gebruik van stylesheets en javascripts zijn een aantal technieken. En wat overblijft aan pure html-code is niet zo groot (voor de homepage nu wel pittig, maar niet exorbitant: 80kB).

Maar ... het knelpunt bij de site is mijns inziens niet zozeer hoe zwaar een pagina maximaal in kB/MB mag zijn, maar hoe alle info overzichtelijk gepresenteerd kan worden.
Dat wordt worstelen! :)

Want duidelijk is dat de site gemaakt is door perfectionisto's, die alles tot in de details aan boord willen hebben en alles uniform willen structureren om er grip op te blijven houden. Ik ken dat, ik ben er ook zo eentje... ;)

De kunst is om ongeoorloofde "wildgroei" in de aangeboden info te vermijden.
Een paar signalen.

Niet alleen toegankelijk voor de bedreven surfer
Nu heb ik in de loop der jaren heel wat sites gezien, en ik durf mezelf wel een "gevorderd surfer" te noemen die weet welk soort navigatie-mogelijkheden er allemaal zijn en hoe die gebruikt kunnen worden: "webpagina's bekijk ik met de muis".
Toch kom ik er door de overdaad aan mogelijkheden niet achter hoe de site in elkaar zit, waar ik moet beginnen, waar ik dan op zal uitkomen, en hoe ik niets mis van wat ik wil weten.
  • Een heldere sitemap zou zeker niet mogen ontbreken.
Maar dan nog:
  • "De grote groep gebruikers zijn matige gebruikers die twee tot drie jaar achterlopen met de frequente gebruikers. Web-ontwerp dient de massa te bedienen. Slechts zelden kan een site succesvol zijn wanneer het zich richt op de 10% gevorderde gebruikers."
    Usability-expert Jakob Nielsen, 2000, maar nog steeds van kracht!
    (vertaald op: bens-web.tripod.com/usability.htm)

Zuinig met beslismomenten voor de bezoeker.
Ik heb ze even laten tellen door Yellowpipe: het aantal links = klikmogelijkheden op de pagina deel_1.html.
Dit blijkt uit te komen op ruim 900 (ne-gen-hon-derd !) stuks.

Ik zie er een paar dubbele tussen zitten, dus ik zal er ruimhartig ruim 100 stuks van af halen. :p
Dat betekent: de argeloze bezoeker van deze pagina moet 800 keer beslissen "To Click, or Not To Click?".
Dat is wat veel gevraagd...
  • Op de homepage is het een stuk rustiger: daar worden maar 200 keuzemomenten aan de bezoeker voorgelegd.
    Maar waar moet de arme eerste-keer-bezoeker nu naar toe?

Leesvoer:

Zo, nu heb ik even de tijd ;) voor m'n:

Wordt vervolgd!
CSShunter
 
Hoi csshunter
wat ben je er weer druk mee
en wat zijn wij daar weer blij mee !


http requests
Snap ik het nu of niet: foto's kunnen beter verdeeld worden over meerdere folders?
http://www.karelgeenen.nl/23/de-complete-gids-voor-een-snelle-website-3-waarom-http-requests-verminderen/
En het aantal folders = het aantal verbindingen per server? (bijv. IE9 = 6 verbindingen)

De pagina-zwaarte wordt hier in belangrijke mate bepaald door de hoeveelheid (vaak: mini-)images
148 st., maar ca. 10 verschillende .gif's: zijn er dan 148 verzoeken of 10 ?
ik weet het: sprites = http://guistuff.com/css/css_imagetech1.html
Proudly present in het nieuwe nav-menu = http://onzeautovakantiesinnoorwegen.nl/TEST/menu/kaart_noorwegen.png :)

toegankelijkheid / waar ben ik op de site?
dat verbetert hopelijk met http://onzeautovakantiesinnoorwegen.nl/TEST/TEST.html

tegelijkertijd zou de site worden opgedeeld, wellicht per provincie
1.1 t/m 1.11 en 2.1 t/m 2.16 = 27 pagina's ...
maar waar ik zelf ook al eerder over zat te dubben: http://www.useit.com/alertbox/scrolling-attention.html :
Wie het weet mag het zeggen ...
"In fact, if you have a long article, it's better to present it as one scrolling canvas than to split it across multiple pageviews.
Scrolling beats paging because it's easier for users to simply keep going down the page than it is to decide whether or not to click through for the next page of a fragmented article."
Te veel beslismomenten / Bezuinigen, maar niet voor de MB's ...
Ach neeee! :eek: Daarmee ben ik voorlopig nog niet overtuigd hoor.
Vind zelf dat de site zich hiermee zo onderscheidt: direct is relevante info voorhanden.

Best veel foto's (natuurlijk ook om de bezoekers nieuwsgierig te maken),
maar ook dat ze hierdoor in 1 oogopslag kunnen beslissen: lezen of doorscrollen.

Ach man :eek: Dat kan toch niet? Zou ook niet weten wat er wel en niet door de zeef zou moeten

Nou, zal het eens laten bezinken :eek:.

Met vriendelijke groet,
janyep

ps. mag ik heel voorzichtig vragen:
Hoe zwaar vind je dat de ideale website maximaal is ?
 
Laatst bewerkt:
Hoi janyep,
http requests: Snap ik het nu of niet: foto's kunnen beter verdeeld worden over meerdere folders?
"Folders" is bij mij = mappen / directories binnen een site op één bepaalde server.

- Nee, het artikel zegt dat je sneller kunt werken als je de pagina-bestanddelen laat weghalen bij verschillende servers.
Dus je hebt bv. een index.html staan op mijnsite.nl.
Daarnaast heb je een server op een ander domein, bv. mijnextraserver.nl.

In de index.nl worden bv. 12 images gebruikt, die voor het gemak allemaal even groot zijn.
  • Dan haal je bv. de eerste 6 op bij de gewone site:
    src="http://mijnsite.nl/images/img1.png" t/m src="http://mijnsite.nl/images/img6.png".
  • De tweede serie van 6 laat je sprokkelen bij de extra server:
    src="http://mijnextraserver.nl/images/img7.png" t/m src="http://mijnextraserver.nl/images/img12.png".

Als de browser 6 verbindingen per server aankan, en je ze alle 12 bij mijnsite.nl zou weghalen, moeten de tweede 6 wachten tot de eerste binnen zijn en de betreffende verbindingen vrijkomen.
Verdeel je de plaatjes over de twee servers, dan zijn er ook 6 verbindingen per server, maar omdat er aanvragen lopen naar 2 verschillende servers, kunnen er nu 12 verbindingen tegelijk zijn en hoeft de tweede serie niet te wachten. > Dus 2 keer zo snel.

Ergo: dit pleit ervoor om tzt het oude domein niet op te heffen, maar te gebruiken als extra stalling! :)
  • Per pagina moet je dan goed bekijken hoe je de lusten en lasten gaat verdelen.

wvv!
CSShunter
 
Goedenavond csshunter

sorry hoor, en best genant, maar ...
twee domeinen bij ééndezelfde webhoster = altijd twee servers?

bedankt weer,
ww?
janyep
 
CSShunter: De pagina-zwaarte wordt hier in belangrijke mate bepaald door de hoeveelheid (vaak: mini-)images: 148 stuks.
janyep: maar ca. 10 verschillende .gif's: zijn er dan 148 verzoeken of 10 ?
Ik heb de images op de homepage eerlijk geteld :) (via Chrome: Engelse sleutel-icoontje rechtsboven > menu Extra > optie Hulpprogramma voor ontwikkelaars > tabblad Network)(de Webdeveloper Toolbar in Firefox komt op hetzelfde aantal uit).
  • Er zijn 31 gif's die door de pagina zelf worden opgehaald, en nog 2 gif's vanuit het <iframe> met de schuif-foto's (die tellen ook mee!!!): samen 33 gif's.
  • Maar er zijn ook nog jpg-plaatjes en png-plaatjes. Op de homepage zelf: samen met de gif's 52 stuks. En in het iframe: samen 89 images. Maakt 141 stuks.
  • En er zijn ook een aantal afbeeldingen die elders vandaan komen (al dan niet via javascripts): van Google, addthisedge, uptrends, onestat en nog een paar. Geeft totaal images: 148 stuks.

Dus 148 verschillende images = 148 verschillende verzoeken om ze op te halen = 148 http-requests.
En 148 keer handjes schudden, overhead, enz.

=======
Behalve "overhead" ook nog: "overstaart"!
Wat in het artikeltje niet zo duidelijk naar voren komt, is dat er behalve de overhead door de header van elk te downloaden bestand(je) ook nog een "overstaart" is die bij de overhead van de header komt. Dat zit ongeveer als volgt:

data-pakketje.png

Elke over internet te versturen data-pakketje met bitjes heeft een bepaalde vaste bestandsgrootte (ca. 1.5kB). Wat er niet in past, gaat naar het volgende pakketje. Het zal toeval zijn, als het aantal bits van een bestand precies zo groot is als x maal de pakketgrootte. Wat niet nodig is voor het bestand, zijn dus loze bits in de staart van het laatste pakketje.
  • Hoe meer kleine bestandjes er zijn, des te meer zal er ook aan overstaart zijn!
    [*[Bij slechts een paar images zal dat het sop de kool niet waard zijn, wel bij een heleboel kleintjes.
  • Combineer je veel kleintjes tot één grote (sprite), dan worden de eerste pakketjes van die grote helemaal gevuld, en heeft alleen het laatste pakketje de overstaart. Dat is dus winst bij het downloaden!

wvv!
CSShunter
 
Ah, kruispost!
twee domeinen bij één dezelfde webhoster = altijd twee servers?
Twee domeinnamen = twee IP-adressen, dus lijkt me wel dat de browsers dat in dit verband als 2 servers beschouwen (ook al zitten ze wellicht fysiek op hetzelfde kastje bij de provider).
Maar ik moet bekennen dat ik dit ook niet 100% weet, gênant hè? :eek:

  • Weet iemand van de lezers van dit topic het juiste antwoord?

=======
Er staat eigenlijk "w v v" = wordt ver volgd.
Maar bij hoge resoluties zou dat wel eens kunnen versmelten tot ww. :)

Tot de volgende keer!
CSShunter
 
Laatst bewerkt:
kleine foto's in het iframe zijn geschaald, het zijn geen extra thumbnails

... eenzelfde foto in het iframe als in het tekst-gedeelte : wordt 'ie dan 1 of 2 keer binnengehaald?

... er is ook nog sprake van
Code:
<META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
... misschien niet zo handig als een foto twee keer wordt binnengehaald?

weer bedankt hoor,
groeten janyep
 
... eenzelfde foto in het iframe als in het tekst-gedeelte: wordt 'ie dan 1 of 2 keer binnengehaald?
Eén keer, want de src-locatie is hetzelfde.


  • Op de homepage, waar je meestal mee begint, zit via het iframe de hele bups al aan thumbs (= aan geschaalde grotere). Dus alle 89 grotere zijn http-requests bij opening van de homepage.
    Maar in het tekstgedeelte van de homepage staan ze niet, daarvoor zijn de grotere niet nodig (schalen is hier ballast).
  • Op de deel-1, deel-2 en deel-3 pagina's zijn ze er op deze manier al, ook in grote gedaante.
    Maar daar is telkens maar 1/3 van de images nodig (de rest zit bij de andere delen).

Ergo voor het spriten lijkt me:
  • 1 sprite voor alle kleintjes => snelle homepage (+ de thumbs zijn meteen ook beschikbaar voor de delen e.a. pagina's).
  • 3 sprites voor de grote, 1 per deel => snelle pagina's van de 3 delen (de thumbs zijn er al na bezoek van de homepage).
  • Als je in de nieuwe opzet de huidige indeling aanhoudt!

Over "Cache-control": heb ik op m'n ToDo-lijstje staan om me op in te lezen en er het fijne van te weten te komen. Op een of andere rare manier kom ik er steeds niet aan toe. ;)

wvv!
Met vriendelijke groet,
CSShunter
_______________
PS:
Hé, valt me opeens op dat in het menu de link "Home" altijd een <a href="#"> heeft, en dus altijd op dezelfde pagina blijft als waar je zit, ipv naar de echte homepage <a href="http://onzeautovakantiesinnoorwegen.nl/"> te gaan.
 
Laatst bewerkt:
Hoi!

Ik had in gedachten alleen de mini-mini-kleintjes in een sprite te zetten

info.gif driehoek.gif bnafc.gif

Al die foto's (thumbs en/of standaard) 'spriten' wordt een hele operatie! Ben er niet zo handig mee, maar dat zou dan kunnen veranderen ...

Dus aan het to-do-lijstje: nadenken :) over zulke grote sprites

valt me opeens op dat in het menu de link "Home" altijd een <a href="#"> heeft,
Hebben ze allemaal: Home | De reizen | Diversen | Topografie.
Weet niet waarom: het stond in het originele script http://www.cssplay.co.uk/menus/final_drop.html
heb er zelf nog een "cursor: default" bij gezet.

Home = niks
Submenu: "Voorpagina" |||| kon niets beters bedenken i.p.v. van 2xHome

In de nieuwe http://onzeautovakantiesinnoorwegen.nl/TEST/TEST.html is dat weer
hetzelfde liedje.
Suggesties van iedereen zijn welkkom!

Weer bedankt!
groeten janyep
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan