Danske websider loader med sneglefart i udlandet

Besøgende fra udlandet skal bruge helt op på 25 sekunder på at indlæse forsiden fra store danske firmaer og Udenrigsministeriet. Det er 47 procent langsommere end for et år siden.

Mange store danske virksomheder henter en stor del af omsætningen i udlandet. Men der er tilsyneladende ikke samme fokus på at få den internationale webside til at fungere tilfredsstillende uden for Danmarks grænser.

Det viser en ny undersøgelse, som firmaet Digicure står bag, hvor websider for Udenrigsministeriet og 32 danske firmaer med internationalt marked blev målt fra Irland og Californien. På flere af siderne skulle de besøgende nemlig være meget tålmodige, med Haldor Topsøes webside som bundskraber med 25 sekunders ventetid fra Californien, før hele siden er loadet.

Fra den amerikanske vestkyst tog det også over ti sekunder i gennemsnit at hente forsiden på Bestseller.com, Flysas.com, UM.dk (Udenrigsministeriet) og Flsmidth.com, viser målingerne, som blev gennemført hvert tiende minut i en uge.

Den hurtigste webside var Lego.com, som blev indlæst på 0,69 sekunder i gennemsnit fra Irland og 1,08 sekunder fra Californien.

Digicure kørte samme undersøgelse i marts 2013, og siden da er det gået ned ad bakke for de danske websider med internationalt publikum. Ventetiden er steget med 47 procent for besøgende fra Californien, oplyser firmaet. Dengang klarede Haldor Topsøe sig i øvrigt fint og lå i toppen, mens Udenrigsministeriet klarede sig værst med over 16 sekunders load-tid fra USA.

Der findes flere måder at forbedre svartiderne fra fjerne lande på. Den klassiske er at få siden duplikeret og cachet i flere verdensdele gennem et content delivery network (CDN), mens generelt lange svartider er et tegn på en for tung side, der trænger til oprydning og optimering.

Målingerne skete fra Amazons serverpark i Irland og Californien, og indholdet blev i sagens natur ikke cachet fra gang til gang. Det vil en browser normalt gøre, så gentagne besøg på en side vil normalt føre til væsentligt hurtigere load-tider.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads N. Vestergaard

Tager man andre test værktøjer i brug, får jeg nogle mere acceptable resultater på både topsoe.com og um.dk, jeg ved ikke om amazon er helt retvisende.

Mere interessant ville det også være, hvor det går galt. Hvor lang tider tager f.eks. et connect attempt til webserveren ? Hvis der går lang tid, kan det være en dårlig peering, den del kan så både lægge hos amazon, og hos hjemmesiden.

Jeg har tidligere målt svar tider fra DK, til forskellige internationale hosting centre, og det var ikke ligefrem Amazon der svarede hurtigst.

Og i sidste ende afhænger det jo ikke af Amazon, men af den forbindelse slutbrugeren sidder på.

  • 3
  • 0
Peter Müller

Og i sidste ende afhænger det jo ikke af Amazon, men af den forbindelse slutbrugeren sidder på.

Det afhænger i meget høj grad af latenstid og hvorvidt siden er optimeret til færrste mulige overførsler. Den største flaskehals er frontend filer. Jo flere du har, jo flere roundtrips bliver du nødt til at have før du har hentet alle. Ydermere vil en ikke-optimeret side måske endda blokere for hentning af yderligere filer indtil bestemte filer er hentet. Alt dette forsinker sidens visning. de to yderligere roundtrips et SSL handshake tager tilføjer så yderligere 4x latenstid for hver af disse http-requests.

Det er højest anbefalelsesværdigt at reducere antallet af roundtrips ved bundling eller helt at eleminere filerne ved at undlade dem eller inline dem. Derudover vil et CDN med geografisk tættere cachet indhold reducere latenstiden på statiske filer. SPDY kan reducere antallet af SSL handshakes og server push kan yderliger reducere antallet af roundtrips der er krævet for at starte en overførsel.

Båndbredde tæller i denne sammenhæng ganske lidt. Det er lysets hastighed og tcp/http vi arbejder imod når frontend skal leveres over nettet

  • 10
  • 0
Jens loggo

Jeg synes mange danske firmasider er alt for langsomme om at reagere.

Jeg støder jævnligt på en hjemmeside for et professionelt etableret firma, og undrer mig over hvordan de kan være bekendte, at deres server kan være flere sekunder om at svare.

Nogle gange går der så enda ekstra tid før de forskellige dele af siden loader, og hvis siden så er så dårligt designet, at alt skal loades før man kan se/bruge den, så holder det ikke.

  • 2
  • 0
Niels Henrik Sodemann

Oplevede dog en lille detalje, nemlig at der er noget med dns, så topsoe.com reagerede ikke, mens www.topsoe.com reagerede prompte (her i DK).

Godt spottet...
Zone apex A record (topsoe.com) peger på 12.24.167.45 og 195.41.214.4, mens www.topsoe.com alene peger på 195.41.214.4. Den første svarer ikke, mens den anden gør. Det er vist bare en simpel dns opsætningsfejl.

  • 4
  • 0
Tue Skaarup

og det gør det til et interesant område, hastighed og hastighedsoptimering. Interessant fordi det er så nemt at gøre noget ved, og fordi så få alligevel gør det.

Man behøver ikke at måle hastighed af danske websites fra Irland eller Californien for at konstatere, at de fleste er meget langsomme, for det er de også for herboende brugere. Og som Digicure helt rigtigt påpeger, problemet bliver større.

Jeg kan ikke komme i tanke om noget andet område indenfor onlinetilstedeværelsen, hvor det er så nemt at opnå store forbedringer med en meget lille indsats. Måske med undtagelse af at rette DNS fejl, som med topsoe.com. Ofte kan der nås 30-50% hastighedsforbedring for nogle få timers arbejde.

Der kan ikke være mange, der ved deres fulde 5 vil vælge at poste f.eks. 100.000 kr om måneden mere i Google AdWords for at få 5% flere kunder, frem for at bruge nogle få timers arbejde på at opnå samme resultat med hastighedsoptimering. Forklaringen må være, at man simpelthen ikke er bevidst om hastighed og dens betydning for brugeroplevelsen, og dermed for konverteringsraterne.

I de sidste 5-6 år er der ellers publiceret store mængder information om hastighedsoptimering på ressourcesites for markedsføringsfolk og udviklere. Dokumentation for sammenhæng mellem hastighed og brugeroplevelse/konverteringsrater/bundlinie. Guides til hastighedsoptimering i helt ned til 5 enkle trin, som en udvikler vil kunne sætte sig ind i på 5 minutter. Selv nyhedsmedierne er begyndt at tage fat i emnet indenfor de sidste par år.

Det virker bare alligevel ikke som om det er gået op for broderparten af virksomhederne endnu. Ærgerligt for dem og ærgerligt for deres besøgende. Godt for det mindretal som forstår vigtigheden, for de får en nem konkurrencefordel.

Der går nok nogle år endnu inden de fleste indtænker slutbrugerhastighed i kravspecifikationer, design, kode, platform, CMS'er og webindhold. Men de bliver nødt til det, øget båndbredde vil - som Peter Müller rigtigt peger på - ikke fikse hastighedsproblemet for dem.

  • 3
  • 0
Jens Jönsson

Der kan ikke være mange, der ved deres fulde 5 vil vælge at poste f.eks. 100.000 kr om måneden mere i Google AdWords for at få 5% flere kunder, frem for at bruge nogle få timers arbejde på at opnå samme resultat med hastighedsoptimering. Forklaringen må være, at man simpelthen ikke er bevidst om hastighed og dens betydning for brugeroplevelsen, og dermed for konverteringsraterne.

Hej Tue, du har sådan set ret, men der er mange firmaer, hvis side mere fungerer som et visitkort og produktkatalog, som ikke tænker på den måde, mht. konvertering. De skal bare have folk ind på siden.

Og de glemmer så mht. søgemaskine optimering (SEO), der vægter Google bla. på loadtiden.

  • 1
  • 0
Tue Skaarup

Jeg kan anbefale webpagetest.org. Det er et onlineværktøj, hvor du kan måle sideloadtid med Document Complete og Speed Index som de vigtigste målepunkter.

Målingerne kan foretages fra mange forskellige steder i verden og med forskellige Internethastigheder. Desuden kan måles den sideloadtid mobilenheder oplever og der kan checkes for SPOF (Single Point Of Failure) for 3. part scripts.

  • 1
  • 0
Tue Skaarup

Jep det er min pointe. Der er mange virksomheder, der ikke tænker på den måde og som ikke har hastighed på radaren. Det undrer mig at det er så mange, for hastighedsproblemer og metoder til at gøre noget ved det, har været kendt og meget omtalt i mange år.

Det er helt fint at de virksomheder får folk ind fra siden til at hjælpe dem, men de skal jo ligesom først være klar over, at de har et problem.

SEO gevinsten er en fordel mere ja. Desuden kan der spares ganske betydeligt på hostingudgifter og servere, når websites optimeres.

  • 1
  • 0
Niels Henrik Sodemann

Det afhænger i meget høj grad af latenstid og hvorvidt siden er optimeret til færrste mulige overførsler. Den største flaskehals er frontend filer.

Det er ikke frontend filer alene. På f.eks. flsmidth.com går der knap 4s inden initiale html fil er loaded. Det må alene skyldes uhensigtsmæssig kode og manglende side cache. Rimelig kode på en Microsoft IIS (som det ser ud til ligger under), vil kunne levere en sådan initiel html-side på mindre end 200ms.

  • 1
  • 0
Mogens Bluhme

De nyere browsere understøtter allerede SPDY (som er i DRAFT på HTTP 2.0) og alle nye versioner af webserversoftware som NGINX, IIS og Apache. Ifølge Wiki er antallet af sites, som understøtter SPDY FALDET til 0,6 % januar 2014 fra 1 % i april 2013. Der kan være mange årsager men det tyder helt klart på, at andre end webdesignere burde interessere sig for web. Men man kunne fokusere på brugeroplevelsen: tekst og CSS kommer først, derefter komme billeder og mere eller mindre buggy javascript, som sagtens kan undværes.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize