Social networking sites traag en slecht bereikbaar

11 januari 2008, 05:42

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.

Marco Derksen
Partner bij Upstream

Oprichter/partner Upstream, Marketingfacts, Arnhem Direct, SportNext, TravelNext, RvT VPRO, Bestuur Luxor Live, social business, onderwijs, fotografie en vader!

Categorie
Tags

13 Reacties

    Frank Roor

    “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?


    11 januari 2008 om 06:31
    Lex

    @ 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!


    11 januari 2008 om 08:43
    Gerard van Enk

    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?


    11 januari 2008 om 08:54
    Peter Bonjernoor

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


    11 januari 2008 om 09:25
    Peter Bonjernoor

    PS – bij het plaatsen van een reaktie op MF zit ik ook 15 seconden te wachten totdat de pagina ververst…


    11 januari 2008 om 09:26
    bram12

    @Marco

    Mijn ervaring met onze site (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


    11 januari 2008 om 09:41
    Rick

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


    11 januari 2008 om 10:21
    T.R.Wijbenga

    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.


    11 januari 2008 om 10:38
    media

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


    11 januari 2008 om 12:39
    Peter Bonjernoor

    @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… 😉


    11 januari 2008 om 19:39
    Bèr Kessels

    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.


    14 januari 2008 om 08:15
    CB

    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.


    14 januari 2008 om 10:42

Marketingfacts. Elke dag vers. Mis niks!