Paul Butler hos Facebook har laget et fantastisk kart (se det i full størrelse her!) som viser vennskap verden over. Her er ingen kontinenter, grenser, hav eller elver tegnet inn, men vi kan allikevel tydelig se konturene av verden slik vi kjenner den.

Kartet forteller mye om sosiale og politiske forhold forskjellige steder i verden. Her er noen av tingene jeg finner mest interessant:

• Observer forskjellen mellom mellom Øst- og Vest-Tyskland. Det er gått 20 år siden gjenforeningen, men det er ingen tvil om hvor grensen gikk. Vest-Tyskland skinner like lyst som Danmark, Nederland og England. Øst-Tyskland, med unntak av Berlin, ligner mer på Polen eller Tyrkia.
• Se på grensen mellom USA og Canada mellom de store innsjøene og vestkysten. Det er mange vennskap internt i USA og i Canada, men nesten ingen mellom de to landene. Du kan se det samme mellom Tsjekkia og Tyskland og langs den greske grensen mot Albania, Makedonia og Bulgaria.
• Russland og Kina mangler nesten fullstendig. I Russland bruker folk heller VKontakte. I Kina bruker de QQ. I tillegg til at Facebook er blokkert av Den Store Brannmuren, selvsagt. Unntaket er Hong Kong.
• Facebook-bruk er et fullstendig urbant fenomen i Vietnam og Kambodsja. Hanoi, Ho Chi Minh-byen og Phnom Penh er godt synlige, mens resten av landet er tomt. I nabolandet Thailand er bruken jevnere fordelt.
• I Afrika syd for Sahara finner vi noen spredte øyer med lys i et ellers mørklagt kontinent. Sør-Afrika, Nigeria, Ghana, Kenya og Uganda er tilsynelatende langt foran resten.
• Det er like stor kontakt mellom kurderne i østlige Tyrkia og nordlige Irak som mellom Nord-Irak og Baghdad. De fleste av nabolandene, med unntak av Kuwait og Emiratene, er mørklagte.

Har du fått øye på noe annet interessant?

Denne uken har det vært mange avisoppslag og blogginnlegg om Firesheep – en Firefox-utvidelse som gjør det svært lett å bryte seg inn i andres kontoer til sosiale nettverk og epost. Det er ikke noe nytt sikkerhetshull Firesheep utnytter. Å stjele andres informasjonskapsler for å få tilgang til deres konto har vært mulig siden 1994. Men med Firesheep har det plutselig blitt veldig mye enklere for spammere, ekskjærester, kikkere og ungdomsskoleelever å ta over Facebook-profilen din.

Prinsippet bak angrepet er veldig enkelt. Hver gang du laster en side fra Facebook – eller et hvilket som helst annet nettsted du er logget inn på – sender nettleseren din med en hemmelig nøkkel som viser at du er logget inn med din konto. Nøkkelen gjør i praksis samme jobb som et brukernavn og passord i ett, og består av en serie tall og bokstaver – for eksempel df872ef3ae1c836667eb5b59eded8f0a. Hvis noen andre oppgir din nøkkel når de laster Facebook, vil Facebook tro at de er deg. Ikke bare kan de snoke i din private informasjon. De kan også sende meldinger eller kvitre i ditt navn.

Å få tilgang til noen andres hemmelige nøkkel er dessverre latterlig enkelt, spesielt på åpne trådløse nettverk. Din datamaskin og det trådløse tilgangspunktet snakker med hverandre ved hjelp av radiobølger med en gitt frekvens. Om noen andre lytter på den samme frekvensen, vil de kunne plukke opp alle data som sendes mellom deg og tilgangspunktet. Dermed kan uvedkommede se hvilke tvilsomme nettsider du besøker, lese epost du sender og mottar, se hva du søker etter, og – viktigst av alt – de kan se den hemmelige nøkkelen du sender til Facebook og andre nettsteder. Å avlytte trafikk på denne måten er såpass enkelt at Googles Street View-biler «ved en feil» snappet opp en mengde passord og annen privat informasjon fra folks åpne trådløse nettverk.

Flere avisartikler får det til å høres ut som at så lenge du er på et kryptert trådløst nettverk, er problemet løst. Det stemmer ikke helt. Mange trådløse nettverk benytter den antikke WEP-protokollen, der alle legitime brukere bruker den samme nøkkelen. Selv om du med WEP stenger ute tilfeldig forbipasserende, kan alle som har passordet fremdeles like enkelt snoke i din trafikk. Ikke så mye bedre enn å låse ytterdøren og la alle vinduene stå åpne når du reiser på ferie, altså.

Med WPA og WPA2-protokollene er trafikken sikrere, men ikke bombesikker. Andre legitime brukere av nettverket kan fremdeles skaffe seg tilgang til din trafikk, men det kreves en del mer arbeid og god timing.

Selv ikke et kablet nettverk er noen helgardering. Det er mye vanskeligere for uvedkommede å skaffe seg tilgang til dine data på et kablet nettverk, men det er fremdeles fullt mulig. Og angrepsmulighetene stopper ikke der.

Mellom din datamaskin og Facebook er det et dusin forskjellige mellomtjenere alle dine data går gjennom, uten noen form for kryptering. Om det finnes en utro tjener et hvilket som helst sted underveis kan vedkommede lett overvåke din trafikk. Den underbetalte og nysgjerrige ITK-lærlingen som administrerer det lokale nettverket eller offentlige myndigheter er få tastetrykk unna dine hemmeligheter. Å koble til nettsteder via VPN eller SSH-tunneller er gode tiltak for å begrense angrepsflaten, men heller ikke det er fullstendig sikkert.

Den eneste måten du kan være sikker på at ingen kan avlytte trafikken underveis er om den er kryptert hele veien fra din maskin til tjenesteleverandøren. Dette er ikke noe du kan sette opp på egenhånd. Tjenesteleverandøren selv må legge til rette for dette. Nettbanken din lar all trafikk gå over den sikre HTTPS-protokollen. Gmail gjør det samme. Og E-tjenestens egne tjenester, selvfølgelig.

Om det er en gul eller grønn hengelås i adressefeltet er du trygg.

Om den mangler bør du være forsiktig.

Dersom tjenesteleverandørene du benytter ikke tilbyr å la trafikken gå kryptert over HTTPS bør du mase på dem, eller bytte til en annen leverandør for å beskytte dine kontoer og dine data.

Når det er sagt – kryptering av trafikken beskytter deg kun mot uvedkommede som lytter på trafikken mellom deg og dine tjenesteleverandører. Om tjenesteleverandøren selv har et avslappet forhold til personvern og privatliv er det mulig du har et større problem.

Fotografiapparatet

Et kamera er grunnleggende sett en lystett boks med et hull i. Lys reflektert fra objekter utenfor boksen (A) går gjennom blenderåpningen (B) og treffer et lysfølsomt materiale (C).

I tidligere tider var det som regel fotografisk film som fanget lyset. I dag er det mer vanlig at det er en digital bildebrikke som registrerer hvor lyset treffer.

Jo større den lysfølsomme overflaten er, jo større detaljrikdom eller oppløsning kan den gi.

Det seksti år gamle mellomformatkameraet til venstre på bildet gir omtrent seks ganger så høy oppløsning som det moderne digitale speilreflekskameraet til høyre.

Objektiver

Utenfor hullet i kamerahuset kan man plassere et objektiv som bøyer lysstrålene på forskjellige måter. Et objektiv består av en eller flere linseelementer og kan utvide eller krympe synsfeltet avhengig av hvordan linseelementene er plassert i forhold til hverandre. Objektivet kan også fokusere på et spesifikt område. Nyere kameraer gjør dette automatisk for deg med mindre du ber dem la vær.

Objektiver med kort brennvidde (10-35mm) kaller vi vidvinkelobjektiver. Disse kan brukes for eksempel til landskapsfotografier.

18mm

Objektiver med middels brennvidde (35-60mm) kaller vi normalobjektiver. Disse er utmerket til for eksempel portretter.

50mm

Objektiver med lang brennvidde (60mm og høyere) kaller vi teleobjektiver. Disse bringer det som er langt borte nærmere, og er en paparazzis beste venn.

200mm

Speilreflekskameraer og andre systemkameraer er laget for å fungere med et bredt spekter av forskjellige objektiver. Man kan benytte både objektiver med en fast brennvidde og zoom-objektiver man kan skru på for å endre brennvidde.

Eksponering

Din fremste jobb som fotograf er å sørge for at bildebrikken får akkurat passe mengde lys. Som en bleik skandinav i Syden skal den bli brun, ikke solbrent.

Om du slipper inn for lite lys vil bildet ditt bli mørkt og undereksponert, slik som dette:

50mm, 1/200 sekund, f/11

Om du slipper inn for mye lys blir bildet ditt overeksponert. Store flater vil være helt hvite og «utbrente», slik som dette:

50mm, 1/200 sekund, f/2.2

Om du slipper inn akkurat passe mengde lys vil bildet ditt se mer riktig ut.

50mm, 1/200 sekund, f/7.1

De fleste digitale kameraer lar deg se et histogram med en graf som viser fordelingen av lyse og mørke piksler. Om bildet er undereksponert vil grafen være høyest til venstre i histogrammet, ved overeksponering vil den være høyest til høyre.

Overeksponering
Undereksponering
Riktig eksponering

Som oftest vil du at histogrammet skal være feitest på midten, og nå null rett før den når høyre kant. Om kameraet får bestemme eksponeringen selv er det dette det vil prøve å få til. For å la kameraet eksponere automatisk, velger du P-programmet på ditt speilreflekskamera.

Dette er vel og bra for de aller fleste motiver. Men om du tar to bilder – ett av en helt hvit vegg, og ett av en helt svart vegg – kan du ende opp med to helt like, grå bilder. Histogrammet vil se fint ut og kameraet vil tro det har gjort en god jobb, men bildene vil ikke samsvare med virkeligheten. Noen ganger er det derfor hensiktsmessig å eksponere mer enn kameraet ville gjort på egenhånd, og andre ganger mindre.

For å anpasse hvor mye lys som slipper inn har du et par forskjellige innstillinger du kan skru på. Hvis du vil sette alle eksponeringsinnstillingene selv, velg M-programmet på kameraet.

Lukkertid

Den første variabelen du kan endre er lukkertiden. Kameraet slipper inn lys kun en kort periode. Jo lengre luken er åpen, jo mer lys slipper inn. Lukkertid uttrykkes i brøkdeler av et sekund eller hele sekunder. Hvis du vil sette lukkertiden selv men la kameraet sette de andre variablene, velg S-programmet på Nikon-kameraer og Tv på Canon-kameraer.

Husk at forskjellige eksterne lysforhold kan gjøre at samme kamerainnstillinger kan gi radikalt forskjellige resultater. Om du tar bilder i strålende sol får du mye mer lys per millisekund enn om du tar bilder i et dårlig belyst rom.

Å la luken stå åpent lenge har dog bieffekter. Om det tar et helt sekund å få riktig eksponering, og motivet flytter på seg underveis kan du bevegelsesuskarphet og et grøtete bilde.

Her har jeg for eksempel tatt et bilde av en bilvei om kvelden:

50mm, 5 sekunder, f/16

Lukkertiden er fem sekunder, og i løpet av den tiden kjører bilene mange meter og etterlater seg bare et spor av lys. Det kan være en fin effekt om du vil fremheve bevegelse, men det er det ikke alltid du vil.

Her er samme motiv med langt kortere lukkertid:

50mm, 1/15 sekund, f/2.2

Selv om motivet ikke flytter på seg, kan du også få bevegelsesuskarphet om du ikke klarer å holde kameraet helt i ro under eksponeringen. Å holde kameraet i ro et helt sekund er umulig for oss vanlige dødelige, så ved lange eksponeringstider vil du trenge et stativ for å holde kameraet på plass.

Jo lengre brennvidde objektivet ditt har, jo vanskeligere er det å holde det i ro lenge nok. Med et 50mm objektiv kan du forvente å kunne ta klare bilder med lukkertider opp til ca. 1/50 sekund. Med et 200mm objektiv kan du forvente uskarphet ved lukkertider over 1/200 sekund.

Her er et mislykket bilde av en elefant:

86mm, 1/30 sekund, f/4.5

Jeg klarte ikke å holde kameraet i ro lenge nok, så hele bildet er uklart. Med kortere lukkertid kunne resultatet vært bedre.

Blenderåpning

Den andre variabelen du kan skru på for å regulere lysmengden er blenderåpningen til objektivet.

Blenderen kan være helt åpen eller nesten helt lukket. En stor åpning gir mer lys enn en liten. Blenderåpningens innstilling uttrykkes i forholdstallet mellom brennvidden og åpningen. f/16 er en liten åpning, og f/1.4 er en veldig stor åpning. For å stille blenderåpningen selv og la kameraet sette lukkertiden, velg A-programmet på Nikon-kameraer og Av-programmet på Canon-kameraer.

Med en stor blenderåpning kan du ha lav lukkertid og allikevel få inn nok lys. Hvor stor blenderåpning du kan ha varierer veldig fra objektiv til objektiv. Objektiver med en fast brennvidde har typisk mulighet for langt større blenderåpning enn zoom-objektiver.

Å bruke en stor blenderåpning har også sine bieffekter. Jo større blenderåpning du bruker, jo mindre dybdeskarphet blir det i bildet.

Dette bildet er tatt med en blenderåpning på f/16. Det meste av teksten er fint leselig.

50mm, 4 sekunder, f/16

Dette bildet er tatt med en blenderåpning på f/1.4. Kun et par centimeter av siden er i fokus, og resten blir en uklar grøt.

50mm, 1/25 sekund, f/1.4

Fra hvert eneste punkt på motivet reflekteres lys i alle mulige retninger. Med en stor blenderåpning vil lyset fra ett og samme punkt kunne prege bildebrikken på flere forskjellige steder. Dette gjør at et gitt punkt på bildebrikken vil bombarderes med lys reflektert fra flere forskjellige deler av motivet.

Selektiv bruk av fokus med stor blenderåpning kan være veldig fint på portrettbilder. Hovedpersonen i bildet kan være helt i fokus, mens den mindre viktige bakgrunnen kan dempes med uskarphet.

50mm, 1/500 sekund, f/2

Stopp

Hver gang du skal fotografere noe av må du vurdere hva som er den riktige balansen mellom lukkertid og blenderåpning for det aktuelle motivet. Ofte vil det være greit å ofre dybdeskarphet i bytte mot lavere lukkertid.

For å angi ønsket blenderåpning eller lukkertid skrur du på hjulene på kameraet. Tallene du kan velge mellom er i utgangspunktet standardiserte stopp. Hvert stopp opp eller ned medfører en dobling eller halvvering av mengden lys. Vanligvis lar kameraet ditt deg gå et tredjedels stopp om gangen. Tabellen under viser hele stopp.

Om du øker lukkertiden fra 1/8 sekund til 1/4 sekund får du dobbelt så mye lys. Om reduserer blenderåpningen fra f/2.8 til f/4 halvverer du mengden lys. Endrer du begge disse variablene samtidig – lengre lukkertid og mindre blenderåpning – holdes mengden lys konstant. Slik kan du beholde samme eksponering, og bytte en bieffekt mot en annen.

Lysfølsomhet (ISO)

Om du tar bilder under dårlige lysforhold, har prøvd alt annet og fremdeles ikke får nok lys til riktig eksponering er det en siste variabel du kan skru på. Du kan øke lysfølsomheten – ISO-verdien – til bildebrikken.

Den ekstra lysfølsomheten kommer dog til en meget høy pris. Jo høyere ISO-verdi, jo mer støy vil du få i bildene dine. De tre bildene under er et lite utsnitt av tre bilder tatt av samme motiv med forskjellige ISO-verdier på min D80.

ISO 100 er den laveste verdien i mitt kamera, og den jeg vanligvis bruker.

ISO 100

ISO 800

ISO 1600

Ved ISO 1600 er bildene praktisk talt ubrukelige. Nyere og dyrere kameraer gir mindre støy på høyere verdier, men vær allikevel forsiktig.

Hvilket utstyr trenger jeg?

Hvilket kamera du har er ikke egentlig så veldig viktig. Alle speilreflekskameraer fra de siste fem årene er veldig gode. Kjøp heller fine objektiver enn et dyrt kamerahus. Om du skal kjøpe noe nytt, kjøp samme merke som vennene dine har. Da kan dere låne objektiver av hverandre.

Hvilke objektiver du trenger avhenger av hva du har tenkt å ta bilder av. Hvis jeg bare kunne hatt ett objektiv, ville jeg valgt et lyssterkt normalobjektiv.

Favorittobjektivet mitt er Nikons 50mm f/1.4. Det har så stor blenderåpning at jeg kan ta fine bilder i hvilket som helst lys. Om jeg vil ha litt mer eller litt mindre med i bildet, kan jeg flytte på meg. Zoom trenger jeg ikke.

Alle som liker å fotografere burde ha et liknende objektiv. Overnevnte får du for 2500 kroner. Den litt billigere varianten – 50mm f/1.8 – koster tusen kroner, og er verdt hvert øre.

Alle produktfoto er lånt av Nikon. Programhjulet er laget av Althepal og er lisensiert under Creative Commons Attribution-ShareAlike 2.5-lisensen. Hasselblad-bildet er tatt av Eugene Ilchenko og lisensiert under GNU fri dokumentasjonslisens, versjon 1.2 eller senere. Tegningene er modifiserte skisser fra Cyclopaedia fra 1728. Portrettfotografiet er tatt av Andreas Tolf Tolfsen i E-tjenesten SA. Resten har jeg tatt selv.

Forrige uke studerte vi hvordan mange HTTP-forespørsler etter hverandre kan gjøre ditt nettsted tregere enn det behøver å være, og hva du kan gjøre for å unngå dette.

Minst like viktig er det å holde det totale antallet bilder, skript og stilsett på nettstedet nede.

HTTP

Du skjønner, både nettleseren din og tjenermaskinen i den andre enden har en begrensning på hvor mange forskjellige filer de vil overføre samtidig. Vanligvis ligger denne grensen på 16 filer.

Dette betyr at om du har en side med 17 like store bilder, kan denne siden på en dårlig dag ta dobbelt så lang tid å laste som dersom den bare hadde 16. For om alle de 16 sporene på stasjonen allerede er i bruk, må det syttende toget finne seg i å vente til ett av de andre togene har reist videre.

Ikke bare stiller forespørslene seg i kø når det blir for mange av dem. Både nettleseren og tjeneren er glade i å fortelle alt mulig om seg selv hver gang de utveksler en fil. Uansett hvor liten filen er går de samme høflighetsfrasene igjen. Nettleseren pleier å begynne med noe sånt som dette:

GET /eksperimenter/data-uri/img/application_add.png HTTP/1.1
User-Agent: Opera/9.80 (X11; Linux i686; U; nb) Presto/2.5.24 Version/10.52
Host: e-tjenesten.org
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png,
image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: nb-NO,nb;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://e-tjenesten.org/eksperimenter/data-uri/img/
Cache-Control: no-cache
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers

Tjeneren kan ikke være noe dårligere, så den svarer omtrent som følger:

HTTP/1.1 200 OK
Date: Mon, 10 May 2010 22:36:07 GMT
Server: Apache/2.2.9 (Debian) mod_auth_kerb/5.3 DAV/2 PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Wed, 31 Mar 2010 17:10:48 GMT
ETag: "688cca9-26b-4831bd3d2b600"
Accept-Ranges: bytes
Content-Length: 619
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/png

Deretter kommer selve filen. Underveis har altså det lille ikonet på bare 619 byte i praksis blitt tre ganger så stort, alle høflighetsfrasene inkludert. Det samme skjer for hver eneste lille fil.

Løsninger for å redusere antall forespørsler

Det er som du kanskje ser flere gode grunner til å holde antallet stilsett, skript og bilder så lavt som mulig. For skript og stilsett er ikke dette så komplisert. Å slå mange små skript eller stilsett sammen til ett stort er en enkel oppgave.

Men hva så med bilder?

Vi er stolte over at webapplikasjonene vi utvikler og drifter har et meget enkelt design, uten unødvendig dill som tar stor plass. Men vi har mange små ikoner på menyelementer, knapper og lister, og flere forskjellige bakgrunnsbilder. Det kan være flere titalls slike små elementer på en enkelt side, og selv om hver enkelt fil er veldig liten går sidelastingen tregere enn vi liker.

Er det mulig å redusere antallet forespørsler på noe vis, uten å måtte fjerne ikonene?

Mange jobber seg rundt problemet ved å legge bildene sine på ett subdomene, stilsettene på et andre og skriptene på et tredje. Da vil nettleseren åpne 16 tilkoblinger til hver av disse subdomenene, og laste ned langt flere filer samtidig. Dette er vel og bra når det gjør nettstedet raskere, men er ofte ikke nok.

Google setter sammen alle de grafiske elementene på sin søkeside til ett eneste bilde:

Riktig del av bildet vises så på riktig element ved hjelp av nøyaktig posisjonering av bakgrunnsbildet, slik at kun den relevante delen av bildet blir synlig for brukeren:

<span class="csb ch" style="background-position:-76px 0; margin-right:34px;width:66px">

Dette reduserer antallet HTTP-forespørsler betraktelig, men et slikt puslespill er kronglete å vedlikeholde og oppdatere. Kildekoden blir heller ikke spesielt leselig.

Finnes det flere måter å løse dette problemet på?

data URI

Ja, heldigvis. Si hei til data URI.

En data URI er en adresse som inneholder en fil. Det høres unektelig litt snodig ut, men er egentlig ganske enkelt. Se for eksempel på denne her:

data:text/plain;charset=utf-8,Jeg%20er%20en%20liten%20tekstfil.%20Kopier%20meg%20til%20adressefeltet%20ditt!

Slike adresser med filer i kan du bruke alle steder på en nettside der du kan henvise til eksterne ressurser – i lenker, stilsett eller bilder. Det betyr at du for eksempel kan bytte ut denne koden:

.ikon { background-image: url(ikon.png); }

… med denne:

.ikon { background-image: url(data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAAK/ INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwA
AAFiSURBVBgZpcEhbpRRGIXh99x7IU0asGBJWEIdCLaAqcFiCArFCkjA0KRJF0EF
26kkFbVVdEj6/985zJ0wBjfp8ygJD6G3n358fP3m5NvtJscJYBObchEHx6QKJ6SK
snn6eLm7urr5/PP76cU4eXVy/ujouD074hDHd5s6By7GZknb3P7mU+WNLZGKn
x595JDvf96zTQSM92vRYA4lMEEO5RNraHWUDH3FV48f0K5mAYJk5pQQpqIgixa
E1JDKtRDd2OsYfJaTKNcTA2IBIIesMAOPdDUGYJSqGYml5lGHHYkSGhAJBBIkAo
WREAT3Z3JLqZhF3uS2EloQCQ8xLBxoAEWO7aZxros7EgISIIkwlZCY6s1OlAJT
WFal5VppMzUgbAlQcIkiT0DXSI2U2ymYZs9AWJL4n+df3pncsI0bn5dX344W
05dhctUFbapZcE2ToiLVHBMbGymS7aUhIdoPNBf7Jjw/gQ77u4AAAAASUVORK
5CYII=); }

Det ser kanskje ikke så pent ut, men for hver eksterne referanse du bytter ut på denne måten sparer du en HTTP-forespørsel. Om stilsettet refererer mange bilder kan dette utgjøre en stor forskjell.

For å omgjøre en fil til en data URI kan du bruke data URI kitchen eller en base64_encode()-funksjon i skriptspråket du benytter.

Blir det noe raskere, da?

For å teste om denne fremgangsmåten faktisk er noe raskere enn alternativet, har jeg laget en håndfull forskjellige tester. Disse finner du her.

I testene laster jeg henholdsvis 10, 20 og 100 forskjellige ikoner på to forskjellige måter. I det ene tilfellet på gamlemåten, der alle ikonene er eksterne filer. I det andre tilfellet er samtlige inkludert i stilsettet ved hjelp av data URI.

Hver av testene er kjørt ti ganger, og gjennomsnittlig lastetid fremgår i tabellen under. Testene er kjørt både på min noenlunde raske nettlinje hjemme, og via en tregere 3G-tilkobling.

På den raskere linjen gir dette trikset en hastighetsøkning på mellom 46% og 102%. På den tregere linjen er forskjellen enda større: mellom 130% og 330%!

Jeg må innrømme at dette var langt over hva jeg hadde forventet.

Vil dette fungere på mitt nettsted?

Testene over er syntetiske og tester kun et veldig smalt bruksområde, så det finnes ingen garantier for at du kan få en like stor hastighetsøkning på ditt nettsted. Kanskje er det helt andre flaskehalser  som gjør seg gjeldende der. Jeg vil anbefale deg å kjøre dine egne tester og se hvor stor forskjell dette utgjør hos deg.

I vårt tilfelle har vi et digert stilsett som refererer over hundre forskjellige ikoner, men kun en brøkdel av disse er i bruk på hver enkelt side. For å teste dette scenariet laget jeg en test som refererer til 150 forskjellige ikoner i stilsettet, men kun bruker henholdsvis 10, 20 og 30 av dem.

Nettlesere er såpass intelligente at de ikke laster ned eksterne ressurser de ikke behøver, så her har eksterne bilder et fortrinn. Når du legger alt sammen til én pakke med data URI må du laste ned ned alt eller ingenting.

Som du ser av tabellen over lønner ikke data URI-trikset seg om du bruker en for liten andel av bildene du refererer i stilsettet. Bruker du kun 20 av 150 refererte ikoner går den optimaliserte versjonen tregere ved første sidelasting, mens ved 30 av 150 ikoner er resultatet positivt. Ved andre sidelasting, når stilsett og ikoner ligger mellomlagret i nettleseren, vil dog den optimaliserte versjonen alltid ha et fortrinn. Uansett bør vi nok rydde godt i stilsettet vårt.

Hvilke nettlesere fungerer dette i?

Data URI fungerer fint i alle moderne nettlesere, men ikke i Internet Explorer 6 og 7. Så lenge merkbar andel av våre potensielle kunder bruker disse eldre nettleserne kan vi selvsagt ikke ignorere dette.

Heldigvis kan vi gi et ekstra stilsett eldre versjoner av Internet Explorer ved hjelp av såkalte «conditional comments»:

<link rel='stylesheet' href='style.css'>
<!--[if lte IE 7]>
<link rel='stylesheet' href='iesucks.css'>
<![endif]-->

I style.css har vi vårt ordinære stilsett med data URI. Dette brukes av alle nettlesere. De eldre nettleserne vil ikke forstå noe av data URI-referansene og vil ignorere disse. I iesucks.css, som kun vil lastes av Internet Explorer 6 og 7, overstyrer vi de opprinnelige deklarasjonene. Slik:

.ikon { background-image: url(ikon.png); }

Sidelasting vil gå noe tregere for brukere av disse antikke nettleserne, men det kan vi leve med. Det viktigste er at alt fungerer som normalt også for dem.

Fotografiet øverst er tatt av vitelone. Ikonene er fra famfamfam og Gnome-prosjektet.

Dette er vel og bra når det gjør nettstedet raskere og enklere å bruke. Men det er dessverre ikke alltid tilfelle. Blendet av fordelene med dette verktøyet er det mange utviklere som benytter det også i tilfeller der en statisk side hadde fungert like fint. Ofte fører dette til at nettsider og webapplikasjoner blir tregere enn de behøver å være.

Test #1: Uten asynkrone JavaScript

La oss bruke følgende enkle side som et eksempel:

Denne siden består av en statisk HTML-side og to statiske bilder – totalt 1.5kB med data. Å laste denne siden på min datamaskin tar i gjennomsnitt 75 millisekunder, fordelt omtrent som følger:

Tid

Nettleseren laster først ned HTML-dokumentet og tolker dette. Underveis oppdager nettleseren at det refereres til to forskjellige bilder, og laster ned disse også. Svoosj. Lynraskt.

Test #2: Med asynkrone JavaScript

La oss prøve én gang til, men la et JavaScript hente inn kommentarene på egenhånd når siden først er lastet. Hvor lang tid vil det ta?

Tid

På min datamaskin tar dette i gjennomsnitt 131 millisekunder. Det er fremdeles ganske raskt, men er allikevel hele 75% lengre tid enn i det første eksempelet!

Hva er det egentlig som foregår?

Men hvordan kan forskjellen bli så stor av et så lite skript? Burde ikke den raske og fine nettlinjen min klare å laste ned denne lille siden like raskt som den andre?

Nei, det er dessverre ikke slik det fungerer. Selv om du kan overføre store mengder data per sekund over en rask nettlinje, behøver signalene fremdeles en gitt mengde tid for å fysisk komme seg fra A til B. Å sende et signal via Internett fra Oslo til Bergen og tilbake tar minst 15 millisekunder, uansett hvor lite data som følger med. Signalet skal jo fysisk forflytte seg gjennom tusen kilometer med kobber- og fiberkabel, og enn så lenge vi er begrenset av lysets hastighet må vi belage oss på litt venting.

Når nettleseren min må gjøre fire slike rundturer (HTML, JS, data, bilder) for å få tak i dataene den behøver for å kunne vise siden over, tar det naturligvis lengre tid enn når den bare må gjøre to (HTML, bilder).

Effekten blir gradvis større jo lenger unna du er fra datamaskinen du vil kommunisere med. Mens det bare tar 15 millisekunder å komme seg fra Oslo til Bergen og tilbake, tar tur-retur Tromsø 30 millisekunder, og skal du kommunisere med noen i California tar det hele 200 millisekunder! Så det som ser fint og raskt ut for deg kan være smertelig tregt for brukerne dine andre steder i verden.

Konklusjon

Hvor mange rundturer gjør brukerens nettleser når din nettside lastes? Om du gjør alt riktig bør det aldri være mer enn tre når siden først lastes, og to når du gjør asynkrone oppdateringer underveis. Om du kan redusere antall rundturer ytterligere vil det glede både brukerne dine og tjenermaskinen din.

Om en side inneholder data som skal oppdateres dynamisk og ofte, sørg for å laste ned en statisk versjon først. Så kan du oppdatere den dynamisk noen sekunder senere.

Kartet over er basert på dette, og kan fritt brukes av andre under en Creative Commons-lisens.

De blir runde og fine i Opera, Firefox, Chrome og Safari. I Internet Explorer forblir de firkantede, men de går like fint an å trykke på. Skyggen fungerer foreløpig bare i Opera og Firefox, men brukere av andre nettlesere klarer seg sikkert fint uten akkurat den kosmetiske detaljen.

En fungerende demonstrasjon av knappene med og uten ikoner finner du her:

http://e-tjenesten.org/eksperimenter/knapp/

Lån gjerne deler av CSSen vår.

Artikkelen er sannsynligvis spredd utover dobbelt så mange sider som nødvendig, fulle av menyer, lenker og reklame som vanskelig kan klikkes på når de henger på veggen.

Det finnes flere måter å løse dette problemet på. Den vanligste er å plassere en lenke til en «utskriftsvennlig versjon» på et tilsynelatende tilfeldig valgt sted på siden. Det er dog ikke en spesielt god løsning. Den er tungvindt for vedkommende som lager nettsiden, forvirrende for søkemotorer som kan ende opp med å indeksere to nesten identiske sider. Og, viktigst av alt, irriterende for brukerne som ikke lenger kan bruke «Utskrift»-knappen i nettleseren sin.

Heldigvis finnes der en løsning som både er enklere og mer elegant. Fem linjer CSS er alt som skal til:

@media print {
   .reklame, .meny {
      display: none;
   }
}

CSS-spesifikasjonen definerer en rekke forskjellige medietyper, hvorav «print» er én. Med deklarasjonen @media print {} angir vi at den aktuelle blokken med kode skal ignoreres når dokumentet vises på skjerm, og kun ta effekt ved utskrift. I eksempelet over skjuler vi alle menyer og reklamebannere fra vårt hypotetiske dokument, slik at alt som gjenstår er selve artikkelteksten.

Dersom du ønsker det kan du selvsagt også angi mer leselige skriftstørrelser, farger med bedre kontrast, hensiktsmessige sidemarger eller gjøre andre justeringer for å gjøre utskriften mer leselig:

@media print {

   ...

   #artikkel {
      font-size: 14pt;
      color: black;
      background-color: white;
      width: auto;
      margin: 1% 2%;
      padding: 0;
      float: none;
   }
}

Du kan også putte utskrifts-reglene i et separat stilsett:

<link href='utskrift.css' rel='stylesheet' media='print'>

En demonstrasjon av hvordan disse tingene fungerer i praksis finner du her:

http://e-tjenesten.org/eksperimenter/utskrift/

Mer informasjon om relevant CSS-magi finner du i spesifikasjonen:

• CSS2, chapter 7: Media types
• CSS2, chapter 13: Paged media
• CSS3 Module: Paged Media (fremdeles eksperimentelt, med varierende nettleserstøtte)