Helpmij.nl
Helpmij.nl
Helpmij.nl
Steun Helpmij.nl! Klik hier     Computerprobleem? Klik hier!

Quote

Weergeven resultaten 1 tot 16 van 16

Onderwerp: Hoe zwaar is de ideale website maximaal ?

  1. #1

    Hoe zwaar is de ideale website maximaal ?

    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

    met vriendelijke groet, janyep

  2. #2
    Senior Member Berkery's avatar
    Geregistreerd
    7 juni 2010
    Locatie
    Meppel
    Afstand tot server
    ±54 km
    2,5 MB? Wat heb je allemaal op die pagina staan?
    Go ahead, make my day.

  3. #3

  4. #4
    Senior Member Berkery's avatar
    Geregistreerd
    7 juni 2010
    Locatie
    Meppel
    Afstand tot server
    ±54 km
    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.
    Go ahead, make my day.

  5. #5
    Hallo Berkery

    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.

    http://onzeautovakantiesinnoorwegen.nl/TEST/TEST.html


    http://onzeautovakantiesinnoorwegen....-uk/index.html


    maar eh ... heel voorzichtig natuurlijk ...

    weet je hoe zwaar de ideale website maximaal is ??

  6. #6
    Senior Member Berkery's avatar
    Geregistreerd
    7 juni 2010
    Locatie
    Meppel
    Afstand tot server
    ±54 km
    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.
    Go ahead, make my day.

  7. #7
    yep.

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

    toch vriendelijk dank voor alle moeite,
    gr. janyep

  8. #8
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009

    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.
    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

  9. #9
    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-comp...s-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...._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! 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 Dat kan toch niet? Zou ook niet weten wat er wel en niet door de zeef zou moeten

    Nou, zal het eens laten bezinken .

    Met vriendelijke groet,
    janyep

    ps. mag ik heel voorzichtig vragen:
    Hoe zwaar vind je dat de ideale website maximaal is ?
    Laatst aangepast door janyep : 11 mei 2012 om 22:19

  10. #10
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    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

  11. #11
    Goedenavond csshunter

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

    bedankt weer,
    ww?
    janyep

  12. #12
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    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:


    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

  13. #13
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    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è?

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


    =======
    ww?
    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 aangepast door csshunter : 14 mei 2012 om 21:32

  14. #14
    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

  15. #15
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    ... 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 aangepast door csshunter : 14 mei 2012 om 22:43

  16. #16
    Hoi!

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

    Naam: info.gif
Bekeken: 27
Grootte: 70 Bytes Naam: driehoek.gif
Bekeken: 26
Grootte: 109 Bytes Naam: bnafc.gif
Bekeken: 26
Grootte: 919 Bytes

    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

  17. Dit topic is automatisch gesloten omdat er sinds vier maanden niet meer op gereageerd is.

    Indien gewenst kan de topicstarter een verzoek tot heropening indienen.

Berichtenregels

  • U mag geen nieuwe vragen starten.
  • U mag niet reageren op berichten.
  • U mag geen bijlagen versturen.
  • U mag uw berichten niet bewerken.
  •  
Helpmij.nl
Helpmij.nl

Helpmij.nl en business

Partners
Sponsoren
Linkpartners
Aanbiedingen