Sådan gør Grundfos sin webside hurtig i hele verden

Slut med load-tider på et halvt minut. Grundfos fokuserede på performance, da den nye webside skulle kodes og fik forbedret oplevelsen markant.

Pumpefirmaet Grundfos' gamle webside var måske hurtig nok i Danmark, men ude i den store verden var den lidt af en prøvelse.

Flash-elementer, der tog 15 sekunder at indlæse, og sider, som brugte et halvt minut på at blive klar, var dagens orden.

Det var ikke sjovt for Grundfos-ansatte i for eksempel Kina, så da firmaet skulle i gang med at udvikle en ny webside, blev performance et hovedfokus, fortæller Michael Lindencrone Konrad, frontend-udvikler hos Grundfos.

Websiden www.grundfos.com blev lanceret i november, men arbejdet med at optimere siderne er ikke færdigt.

»Vi har brugt værktøjet Yslow, og her ligger vi til karakteren C (efter den amerikanske karakterskala, red.) lige nu. Det er rimeligt godt, men vi regner med at komme højere op i løbet af nogle måneder,« siger Michael Lindencrone Konrad.

Yslow er et gratis værktøj til Firefox-tilføjelsen Firebug, og det har været udviklernes vigtigste våben mod lange svartider. Men værktøjet er ikke ufejlbart, og derfor er målet heller ikke at få topkarakterer over hele linjen.

Pointgivningen i Yslow sker nemlig ud fra, hvad der er godt for en gennemsnitlig webside og tager ikke højde for individuelle forskelle, så nogle af rådene fra Yslow kan faktisk virke mod hensigten, forklarer udvikleren.

Opskrift: Sund fornuft

Udover hjælpen fra Yslow-værktøjet er det mest af alt sund fornuft, der skal til, når målet er hurtige svartider, lyder meldingen.

»Det handler om ikke at lægge for meget på hver side, komprimere alle scripts og gøre filerne så små som mulige. Det er helt almindelige guidelines, vi har brugt,« supplerer Mads Pedersen, der er appplikationskonsulent hos Grundfos.

Øvelsen med at få hurtige svartider har kostet mellem 10 og 20 procent ekstra udviklingstimer, vurderer Michael Lindencrone Konrad, og resultatet har været den ekstra tid værd, mener han.

Væk er nu de enormt lange ventetider i udlandet.

»Jeg kan ikke sige, hvor meget hurtigere vores webside er blevet af det. Men det var åbenlyst, at vi skulle fokusere på performance. Meget af det ekstra arbejde har også været læring, så fremover vil det ekstra tidsforbrug være skåret kraftigt ned,« forklarer han.

Lige nu arbejder webfolkene på at få gzippet indholdet på siderne og indføre expire headers, der forhindrer unødige html-requests. Og så skulle alle de vigtigste tekniske tricks være opbrugt, ifølge point-tavlen i Yslow-værktøjet.

Bedste trick: Lokal hosting

Men meget af hemmeligheden bag hurtige websider ligger også uden for it-afdelingen.

Den fysiske afstand mellem serverne i Bjerringbro og kunderne i for eksempel Kina kan selv ikke den hurtigste hjemmeside lave om på.

Derfor tester Grundfos nu et såkaldt content delivery network, der giver store hastighedsforbedringer for besøgende i lande uden for Europa.

»Det koster en formue, men så får man også hosted siderne lokalt i nærheden af brugerne i de forskellige lande,« siger Michael Lindencrone Konrad.

En anden udfordring, der kræver andre evner end kodeoptimering, er at opdrage alle dem i Grundfos, der har redigerings-rettigheder.

»Det er afgørende, at redaktørerne ikke lægger noget ind, som fylder for meget. Så man kan sige, at der er tusind årsager til, at en webside kan tage lang tid og hente, og kun en lille delmængde handler om teknik,« siger Mads Pedersen.

Grundlæggende har it-folkene hos Grundfos ikke gjort andet end at følge alle de gængse råd på området, og hele tiden analysere websiderne med Yslow.

Og så har øvelsen også handlet om at se websiden med kinesiske øjne. Grundfos har afdelinger i over 50 lande, og hastigheden falder naturligt nok, jo længere væk fra en server, man kommer.

Læs også: Top 10: Her er de mest populære CMS'er

»Forskellen på Danmark og Kina kan være faktor fem. Og så betyder det meget, hvor lang tid det tager, selvom load-tiden måske er acceptabel i Danmark,« siger Mads Pedersen.

Relanceringen af www.grundfos.com er sket med CMS'et Adobe Day CQ5, og der er brugt HTML5-tricks og Jquery på siderne. Senere følger en relancering af websiderne for de nationale salgskanaler rundt omkring i verden, og derefter får extranet og intranet en omgang.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mikkel Høgh

Jeg håber sandelig ikke på at budgettet har været ret stort. gzip og expire-headers tager ikke ret meget mere end 20 min. at sætte op, hvis man ellers bare har en rimelig fornuftig webserver, og CSS/JavaScript komprimering kan jo fås ud af boksen fra ethvert CMS med respekt for sig selv :)

  • 0
  • 0
#2 Emil Moe

Læs og hør nogle af de bøger og foredrag af Steve Souders, det er ikke småting loadetiderne har af at sige. Amazon tabte 2% af omsætningen ved at tvinge loadetiden op med 0.2 sekunder

  • 0
  • 0
#6 Morten Borg

»Det koster en formue, men så får man også hosted siderne lokalt i nærheden af brugerne i de forskellige lande,«

Huh? Vi bruger den CDN funktionalitet som Amazon S3 (CloudFront) og Azure tilbyder - det er stort set gratis, set i forhold til hvad man ellers alligevel skal betale for trafikken.

Mvh. Morten, www.arto.com

  • 0
  • 0
#8 Allan Ebdrup Blogger

»Det koster en formue, men så får man også hosted siderne lokalt i nærheden af brugerne i de forskellige lande,«

Huh? Vi bruger den CDN funktionalitet som Amazon S3 (CloudFront) og Azure tilbyder - det er stort set gratis, set i forhold til hvad man ellers alligevel skal betale for trafikken.

Jeg bruger Google App Engine som CDN. Med 20.000 unikke besøgende om måneden er jeg stadig MEGET langt fra at ramme det punkt hvor jeg skal betale noget som helst. Det er altså gratis.

Priserne er:

Outgoing Bandwidth $0.12/GByte Første 10,33 GB gratis

Incoming Bandwidth $0.10/GByte Første 3,8 GB gratis

Total Stored Data $0.005/GByte-day Første 81 GB gratis

Jeg tror Grundfos skal vælge en anden leverandør hvis deres CDN koster en bondegård.

MVh Allan Ebdrup http://obsurvey.com

  • 0
  • 0
#9 Mads Pedersen

Nu er "en formue" jo et relativt begreb. Og der er vel ingen som ønsker at betale mere end højst nødvendig :-D

For at nuancere en smule, har vi et ønske om at optimere performance for alle vores brugere. Ikke blot dem som befinder sig i nærheden af en Amazon Cloudfront server (der er pt. kun 7 udenfor USA iflg. http://aws.amazon.com/cloudfront/). Derfor er global tilstedeværelse et af vores krav til en CDN leverandør.

Desuden er en del af vores websites mere at betragte som web-applikationer (indrømmet, det er pt. ikke tilfældet for grundfos.com). Derfor er det et andet krav, at det CDN vi vælger også understøtter optimering af dynamisk indhold - og ikke blot cacher statisk indhold.

Vi har ikke valgt leverandør endnu, så hvad siger I? Hvilken leverandør ville I vælge givet ovennævnte to basale krav?

Mads Pedersen Grundfos

PS. @Rasmus: Yderste lag i vores eget set-up er Apache.

  • 0
  • 0
#10 Brian Jacobsen

En interessant detalje er at IE8 (og muligvis andre IE'er) kun kan klare en lille mængde flash på én side.

Jeg har endnu ikke regnet ud hvor problemet præcist ligger, men i et forsøg med 5 flash filer (10-200KB) på den samme side var load-tiden omkring 2-3 sekunder og med 6 flash-filer var load-tiden 30-60 sekunder. Tilbage til 5 filer og tiden igen 2-3 sekunder. Det var (næsten) ligegyldigt hvor mange png'er der var på siden.

Om det er antallet af filer eller mængden af hukommelse der er afgørende er endnu uvist.

Problemet findes ikke i de andre browsere.

  • 0
  • 0
#11 Morten Borg

Vi har ingen erfaringer med CDN på dynamisk indhold, men benytter det til ALT billed- og grafisk materiale, og har kørt vellykkede tests med videostreaming fra S3.

Jeg vil også vove den påstand at det er relativt ligegyldigt hvor selve PHP/ASP/whatever siderne hostes fra hvis blot alle billeder, alt Flash, alt CSS etc. ligger på CDN.

Men Akamai er naturligvis lige til højrebenet hvis man vil have det største netværk. Mig bekendt er de verdens største udbyder. Dem har vi også kørt test med i koncernen. De er endnu nemmere at implementere end S3 og Azure og har også yderst rimelige priser.

  • 0
  • 0
#12 Allan Ebdrup Blogger

Desuden er en del af vores websites mere at betragte som web-applikationer (indrømmet, det er pt. ikke tilfældet for grundfos.com). Derfor er det et andet krav, at det CDN vi vælger også understøtter optimering af dynamisk indhold - og ikke blot cacher statisk indhold.

Jeg synes i skulle teste om det er nødvendigt at cache dynamisk indhold. Umiddelbart lyder caching af dynamisk indhold som en kompliceret affære, alle udviklere kan nok fortælle historier om problemer der skyldtes en cache der ikke var opdateret. En cache skal virkeligt kun indføres som en sidste mulighed hvis alt andet ikke virker. Og med en cache foran en cache, har du virkelig opskriften på problemer for dig selv.

Hvad er det for noget dynamisk indhold i vil cache?

Hvis jeres test viser at det vitterligt er nødvendigt med en cache for dynamisk indhold, kunne i måske kigge på http://www.edgecast.com/ Dem har jeg selv snakket en del med, og deres løsning virker teknisk ret solid. Men jeg har ikke implementeret med dem (endnu).

Sidst jeg fik et quote fra dem var deres priser:

500 GB @ $0.60 pr. GB pr mnd. 1 TB @ $0.40 pr. GB pr mnd. 5 TB @ $0.30 pr. GB pr mnd. 10 TB @ $0.20 pr. GB pr mnd. 25 TB @ $0.15 pr. GB pr mnd. 50 TB @ $0.12 pr. GB pr mnd.

Ang. YSlow. I skulle også tage et kig på Googles pagespeed http://code.google.com/speed/page-speed/ Den fanger nogle lidt andre ting end YSlow, og kan med fordel bruges sammen med YSlow.

  • 0
  • 0
#15 Kenneth Darling Sørensen

Jeg vil også vove den påstand at det er relativt ligegyldigt hvor selve PHP/ASP/whatever siderne hostes fra hvis blot alle billeder, alt Flash, alt CSS etc. ligger på CDN.

Det afhænger af dine sider. Antallet af objekter og dermed antallet af requests har stor betydning når latency stiger.

  • 0
  • 0
#16 Torben Espersen

Hej Mads, Hvis du med caching af dynamisk indhold også mener reelt at køre mange instanser af jeres web-applikationer, kunne Akamai's EdgeComputing være en mulighed. Så vidt jeg ved er det dog fortsat primært JEE (eller dvs. JVM baserede) applikationer. De dækker ihvertfald også Kina solidt.

  • 0
  • 0
#17 Oscar Gensmann

Måske det var værd at kigge på leverandøren af jeres grafiske billeder (eller den motor i bruger til at komprimere billeder til websites).

Følgende billede klokker ind på omkring 217 KB (221 KB on disk) og ser ud til allerede at være kørt igennem en resize engine på URL'en og ud fra JPG artifakter ligner det også noget der er komprimeret maskinelt:

http://www.grundfos.com/content/g0/en/service-support/_jcr_content/banne...

Tager man billedet og åbner det i photoshop og gemmer i jpg via save for web med 80%'s kvalitet, får man godt nok minimal forvrængning da det allerede er jpg-komprimmeret i forvejen (kan undgåes ved at bruge originalbilledet), men tilgengæld er filstørrelsen ca 49 KB (53 KB on disk):

http://gensmann.dk/examples/1290500173575.jpg

Bare et fif. ;-)

  • 0
  • 0
#18 Mads Pedersen

@Torben: Acceleration af dynamisk indhold handler for os i første omgang om at optimere netværksdelen (transporttid/latency). At flytte selve applikationen (eller dele heraf) ud "på kanten" er også et interessant perspektiv, men der er ikke i spil i denne omgang.

@Oscar: Tak for tippet. Vil se om dét er noget vi kan skrue på. Vi benytter Day CQs indbyggede renderingsengine. Nu hvor Adobe har købt Day kunne man håbe på at noget af logikken fra Photoshop kunne webificeres :-D

  • 0
  • 0
Log ind eller Opret konto for at kommentere