• Usability & design
    wordt gesponsord door

Social networking sites traag en slecht bereikbaar

Social networking sites traag en slecht bereikbaar

Social networking sites traag en slecht bereikbaar Populaire social networking sites leveren volgens WatchMouse geen goede service aan hun gebruikers. Uit onderzoek van het website monitoring-bedrijf blijkt dat Web 2.0 sites vaak te langzaam en soms helemaal niet laden. WatchMouse heeft bijgehouden hoe lang social networking sites nodig hebben om te laden. Als basislijst werd een overzicht van Wikipedia aangehouden. Uit de resultaten blijkt dat het enorm populaire Facebook het slechtst scoort op het gebied van beschikbaarheid.

Andere bekende sites die slecht presteren zijn Twitter, last.fm, Windows Live Spaces, Friendster en del.icio.us. Van de 104 sites in dit onderzoek hebben er 51 een Site Performance Index (SPI) van 1000 of hoger, wat betekent dat ze erg langzaam laden. Een verrassend resultaat aangezien de meeste sites Ajax-technologie gebruiken. Dit zou moeten zorgen voor betere laadtijd, interactiviteit, snelheid, functionaliteit en gebruiksvriendelijkheid doordat er maar kleine hoeveelheden gegevens worden uitgewisseld met de server. Hierdoor hoeft niet iedere keer dat een gebruiker iets doet op een pagina de hele webpagina geladen te worden. Van de onderzochte netwerksites presteert Faceparty het best met een gemiddelde SPI van 303. Emerce kopt vanmorgen dat Hyves één van de snelste profielensites is volgens het onderzoek.

Een compleet overzicht van alle resultaten van de WatchMouse beschikbaarheidsindex, met daarin alle gecontroleerde sites, is te vinden op watchmouse.com.


Delen

0
0


Er zijn 14 reacties op dit artikel

  • In aansluiting op dit onderzoek merk ik voor zowel marketingfacts, maar ook andere sites waar ik (mede) eigenaar van ben zoals boomr.nl, dat het erg moeilijk is om op te schalen. Het is simpel bijplaatsen van servers is namelijk niet de oplossing, grootste probleem is de exponentiele toename van het aantal keer dat de database moet worden geraadpleegd. Optimalisatie van de database, gebruik van cachingtechnieken, en dat soort zaken worden steeds belangrijker.

    Iemand enig idee welke partijen daarin gespecialiseerd zijn in Nederland?

    geplaatst op
  • "De home page van een site wordt opgehaald door een van de teststations in het WatchMouse wereldwijde netwerk, met een vaste frequentie, zonder afbeeldingen, frames etc."

    Dit betekend dat dus een gehele pagina geladen wordt om de snelheid te meten. Als er vervolgens een deel van de pagina vernieuwd wordt d.m.v. AJAX technologie (wat de meeste sites uit het onderzoek gebruiken), wordt dit niet meegenomen in de meting. Zoals in het bericht ook al geschetst wordt, moet dat in theorie sneller zijn dan een gehele pagina te vernieuwen. Is dit onderzoek op basis hiervan wel representatief?

    geplaatst op
  • @ Marco

    Ik wint niet dat je (mede)eigenaar van Boomr bent. Kan je een lijstje maken van alle sites waar je betrokken bij bent! Het lijkt me erg leuk om dat eens te zien!

    geplaatst op
  • Toch wel een beetje vaag onderzoek dit. Als de kale pagina geladen wordt zonder afbeeldingen, frames, etc wat wordt er dan wel geladen? Wordt dan de javascript wel geladen en de output daarvan? En de CSS, hoe zit 't daarmee? Wordt er ingelogd op de homepage of gaat 't om de homepage die niet ingelogde gebruikers te zien krijgen?

    En waarom zonder plaatjes? Als je wilt weten hoe 't op de gebruiker over komt, zal je dat de hele pagina moet meten zoals deze in je browser te zien is?

    geplaatst op
  • Dat de meeste sites AJAX gebruiken levert vaak zelfs een nog groter gevoel van traagheid op.

    Mijn dochter zit sinds een paar weken op Hyves, en wil dan natuurlijk berichtjes aan papa schrijven, dus ik heb me ook ingeschreven. Wat me opvalt is dat, los van het feit dat de pagina's inderdaad erg traag laden, je daarna nog steeds zit te wachten totdat de AJAX functionaliteit de benodigde gegevens heeft opgehaald en eindelijk jou in staat stelt om ergens te klikken.

    Dit houdt in dat, als de pagina er voor jouw gevoel staat, je alsnog een paar seconden zit te wachten voordat je uberhaupt ergens kunt klikken, en dat is behoorlijk irritant (=vette understatement).

    geplaatst op
  • PS - bij het plaatsen van een reaktie op MF zit ik ook 15 seconden te wachten totdat de pagina ververst...

    geplaatst op
  • @Marco

    Mijn ervaring met onze site (http://www.jijbent.nl) is inderdaad dat meer servers bijplaatsen niet helpt, maar vooral:
    - caching (wij werken met blokcaching zodat aparte blokken content op pagina's voor verschillende tijdsduren worden gecached).
    - verbeteren van indexen op tabellen.
    - herschrijven van queries zodat de juiste indexen worden gebruikt. Meeste voordeel kan hieruit worden gehaald, zeker met MySQL.


    Door deze optimalisatie kunnen we nog steeds met 1 database server toe als er 800 mensen online zijn en persen we circa 40.000 queries per minuut uit 1 machine

    geplaatst op
  • @marco: De mensen die echt verstand hebben van dit soort zaken werken over het algemeen al bij bedrijven die deze kennis voor zichtzelf inzetten, Marktplaats, Hyves, Ilse etc. Webburos lopen in Nederland te zelden tegen het probleem aan om zich hierin te verdiepen, en hosters kennen over het algemeen alleen de botte bijl oplossingen als meer ijzer, caching proxies e.d.

    Maar afgezien daarvan, op het moment dat met de botte bijl schalen niet meer werkt moet de software worden aangepast aan de schaal en loop je tegen het probleem aan dat het meerendeel van de sites, zelfs al zijn gemaakt door gerenommeerde webburos, technisch belabberd in elkaar zitten, en zich nauwelijks meer laten aanpassen. Typisch probleem van bedrijven die graag on-line spelers willen zijn maar technologie als commodity beschouwen.

    geplaatst op
  • Ik las dit gister al op nu.nl en ik heb me behoorlijk verbaasd over hoe goed Hyves er nogvanaf komt in het onderzoek. Zo erg als twee jaar geleden is het niet, maar nog steeds is de traagheid van Hyves één van de grootste ergernissen die ik over de site heb (en met mij veel anderen) .

    @ rick: Wat betreft dat de sites moeilijk aan te passen zijn lijk je een goed punt te hebben. Ik denk dat een technisch redesign om de snelheid van de site te optimaliseren vaak behoorlijk zou lonen. Met dit soort sites zie je, net als met bepaalde softwareapplicaties, dat ze in de loop der jaren zijn gegroeid en dat er zowel functionaliteit is bijgekomen als weggehaald, waardoor het ontwerp in essentie niet meer efficiënt is. Qua functionaliteit zitten social networking sites niet ingewikkeld inelkaar, zeker niet als je het vergelijkt met 'normale' software. Gewoon de site vanaf scratch opnieuw opbouwen, testen en optimaliseren. De gegevens zelf heb je toch wel in de database staan.

    geplaatst op
  • @Marco : "grootste probleem is de exponentiele toename van het aantal keer dat de database moet worden geraadpleegd".

    Performance problemen met een database kun je natuurlijk oplossen door er meer hardware tegen aan te gooien. Of een redesign van de database met een aantal performance tabellen. Maar op een bepaald moment houdt het op. Ik heb daarom zelf ervoor gekozen om bepaalde performance gevoelige queries buiten de database te houden. Ik gebruik hiervoor Lucene (http://lucene.apache.org/). Het werkt bijzonder snel en is goedkoop... De queries op grote hoeveelheden data doe ik dus op documenten die met Lucene geindexeerd zijn... Met de resutaten van de query ga ik naar de database toe...

    @ Peter Bonjernoor. Ik deel je mening over Ajax... Ik zit stevig te balen als ik met Google Analytics zit te werken tegenwoordig..Ik zit binnen Analytics nog steeds te vroeg op buttons te clicken die nog niet actief zijn... De usability guru Jakob Nielsen hanteert als regel dat de maximale wachtijd 1,5 tot 2 seconden maximaal mag zijn.. Bij 'Ajax' sites moet je geregeld meer dan 10 seconden wachten...

    geplaatst op
  • @Allen: Dank voor alle suggesties zover; zeer bruikbaar!

    @Peter: mee eens, duurt veel te lang bij reageren op marketingfacts. Maar zoals gezegd, wij hebben ook problemen met de performance. Al geruime tijd en het lijkt er op dat we er niet goed uitkomen. Aan de server ligt het niet (daar heeft een expert reeds naar gekeken). Het lijkt dus te liggen aan de performance van EE en dan met name de manier waarop het omgaat met MySQL. Nu hebben maken wij hier op Marketingfacts ook wel heel intensief gebruik van die database (denk bijv. aan de stats bij ieder bericht, ie aantal keer opgevraagd, aantal keer doorgeklikt). Die gegevens worden telkens opnieuw uit de database gehaald.

    geplaatst op
  • @Marco - dat is allemaal op zich niet heel spannend voor een database, en met al die queries mag 1 enkele insert-query extra geen probleem opleveren.

    Uit de stress-tests die we destijds voor eBanner hebben gedaan weet ik dat een heel modale webserver alleszins indrukwekkende hoeveelheden queries en pagerequests kan verwerken, dus aan het ijzer ligt het in ieder geval niet.

    Ik ga weer even timen... ;-)

    geplaatst op
  • en verrassend resultaat aangezien de meeste sites Ajax-technologie gebruiken. Dit zou moeten zorgen voor betere laadtijd, interactiviteit, snelheid, functionaliteit en gebruiksvriendelijkheid doordat er maar kleine hoeveelheden gegevens worden uitgewisseld met de server.


    Wat een onzin! Het klopt dat er "slechts kleine hoeveelheden worden uitgewisseld", maar iedereen die ook maar iets van database en/of webapplicaties afweet, weet ook dat daar de bottleneck niet zit.
    Ten eerste is het aggregeren van data uit een database voor een hele pagina nauwelijks meer werk dan het aggregeren van een "kleine hoeveelheid".

    Ten tweede is mijn devies altijd "Als je AJAX gebruikt omdat een full pageload te lang duurt, dan heb een veel groter probleem. Los dat eerst op." AJAX is momenteel het meest gebruikte symptoombestrijdingsmiddel.

    Ten derde, en dat is het belangrijkste, is het vaak /juist/ die AJAX die zaken zo traag maakt. In plaats van eenmaal informatie van en naar de server te sturen, deze te verwerken en in of uit de database te duwen, gebeurt dit nu veel, veel vaker. Tag-uitvul widgets (zoals die op de-licious) doen vaak 5 queries *per tag*. Dus in plaats van eenmaal de tags te valideren en in te voeren, op het moment dat je je bokomark savet, wordt er nu telkens gekeken "hebben we nog een suggestie in de database?".

    En als laatste: een groot deel van de webapplicaties die ni en om social sites hangen zijn zolderkamer-projecten. Wat bijelkaar geharkte, onsamenhangende scriptjes. Gebouwd voor een proof of concept, of om snel een idee vast te leggen. Zelden of nooit is een goede DBA hierbij betrokken. Nog minder zijn goede, visionaire software architecten hierbij betrokken. Dat is ergens een goede ontwikkeling (agile devlopment, extreme programming etc.) maar ook een slechte. De kwaliteit gaat snel achteruit. Waardoor vaak dingen als goede normalisatie, caching, of eenvoudige indexes ontbreken.

    geplaatst op
  • Ik heb het idee dat er voor sites als hyves e.d. veel te weinig wordt getest (functioneel en performance) voordat de boel live gaat. Als ik kijk waar mijn werkgever (Computest) zijn klanten heeft, dan is dit voor het grootste deel de financiele wereld. Zij hebben wel door dat een goede performance essentieel is. En hoewel er nog regelmatig dingen fout gaan (nieuwe ABN-Amro site, mijnpostbank.nl) zou het aantal incidenten vele malen hoger liggen als er niet getest zou worden.

    geplaatst op

Plaats zelf een reactie

Log in zodat je (in het vervolg) nóg sneller kunt reageren

Vul jouw naam in.
Vul jouw e-mailadres in. Vul een geldig e-mailadres in.
Vul jouw reactie in.

Herhaal de tekens die je ziet in de afbeelding hieronder


Let op: je reactie blijft voor altijd staan. We verwijderen deze dus later niet als je op zoek bent naar een nieuwe werkgever (of schoonmoeder). Reacties die beledigend zijn of zelfpromotioneel daarentegen, verwijderen we maar al te graag. Door te reageren ga je akkoord met onze voorwaarden.