Lovdata har vært en digital pioner siden 1981, da stiftelsen ble opprettet av Justisdepartementet og Det juridiske fakultet i Oslo.
Som det første landet i Europa kunne Norge i 2001 gjøre elektroniske kunngjøringer av regelverk til offisiell kunngjøring gjennom Lovdata.
I dag inneholder systemet nærmere 200 informasjonsbaser med alt fra lover og forskrifter til rettsavgjørelser og juridiske artikler.
I de fleste webapplikasjoner er ytelsesoptimalisering en "nice-to-have". Men i "Lovdata Pro", hvor jurister og andre profesjonelle brukere er avhengige av rask tilgang til kompleks rettslig informasjon, er det en absolutt nødvendighet.
Mulig med Elm
Med dokumenter som Skatte-ABC som per dags dato produserer over 120.000 DOM-noder(!), og brukere som forventer lynraske interaksjoner med komplekse juridiske dokumenter, må man til de grader pushe grensene for hva som er mulig i en nettleser.
Som en relativt ny konsulent hos Lovdata (startet mars 2025) har jeg blitt imponert over hvor langt teamet har gått i ytelsesoptimalisering. Det er fascinerende å se hvordan en organisasjon som har vært i fronten for digitalisering av rettslig informasjon siden 1981, fortsetter å pushe grensene for hva som er mulig i webapplikasjonsutvikling.
Eks-vippser bytter beite: «Viktigst av alt er Jesus»
Joda, jeg har sett mange av triksene før, men bare som pynt på toppen av kaka, ikke som "dette må på plass, ellers går det for treigt på iPhone 12".
Elm har vært en kritisk og essensiell del av ytelsesstrategien. Språkets funksjonelle natur og sterke typer gir flere fordeler:
- Null runtime-feil - Når koden kompilerer, krasjer den ikke
- Optimalisert rendering - Elms virtual DOM er ekstremt effektiv, selv uten optimalisering slår vi greit ut det meste React har å by på
- Forutsigbar arkitektur - The Elm Architecture gir oss et solid fundament som oppfordrer og inspirerer til å skrive god kode
- Les mer om Elms relevanse i 2025 her.
Men selv med Elms innebygde optimaliseringer, må man gå lenger. Mye lenger.
Ekstrem DOM-optimalisering
Når man plutselig har 126.160 DOM-noder i et enkelt dokument, blir selv små optimaliseringer kritiske:
- CSS-optimalisering - Selv lengden på CSS-klassenavn kan ha betydning, og ikke minst hvilke CSS-properties man bruker.
- Så liten og ukomplisert DOM som mulig – Kan vi erstatte disse to ikonene (et for dark mode, et for light mode) med ett ikon, og heller sette background programatisk? Ubetytelig forbedring for de fleste, men merkbar forskjell hos oss.
- Ingen virtualisering - Hele dokumentet er i DOM for umiddelbar tilgang. Ambisiøst, men nødvendig for å få sanntidssøk og navigering mellom markeringer til å funke som det skal.
- On-the-fly optimalisering - Dynamisk påføring av Elm.lazy der det er gagnlig – dette er det nærmeste rocket science jeg har kommet i frontendutvikling: med en så kompleks, gigantisk og dynamisk payload man får for hver av disse lovdokumentene fra backend, er det nærmest et mirakel at man klarer å lage kjørbar kode av det. Men ikke bare virker det; sluttresultatet er skremmende raskt!
Robin lager eget språk: «Handler om å fjerne muligheter»
Pionerarbeid i ytelses-optimalisering
I tillegg til "det vanlige", har Lovdata et par nokså unike løsninger for å håndtere ekstreme krav:
- Elm Optimize Level 2 - Bruker avansert optimalisering av Elm-kompileringen, og transformerer generert JavaScript til raskere JavaScript. Les mer om dette her.
- Mikrooptimalisering "by default", og uvanlig terping på små detaljer - Selv valget mellom cons og concat har betydning, og man slipper ikke unna med slurv på ytelseskritiske deler av koden. Lesbar kode er fint, men performance kommer først!
- Varslinger ved høy INP (Interaction to Next Paint) latency – DataDog sier ifra hvis brukerne våre må vente lenge på synlig respons.
Skatte-ABC: Et case study i ekstrem ytelse
Skatte-ABC er et perfekt eksempel på våre utfordringer:
- 230+ kapitler
- Brukerens markeringer og notater (i teorien omtrent uendelige i både antall og fasonger...)
- Haugevis av historiske versjoner
- Over 126 000 DOM-noder per nå (men stadig færre!)
- Ingen virtualisering eller paginering(!🤯)
Ruby, Elm, Kotlin - se flaskesangen generert med 6 språk
For å håndtere denne ekstreme størrelsen har vi implementert:
- Intelligent DOM-forbehandling - Dokumenter pre-prosesseres til en optimalisert struktur før rendering
- Attributt-deduplisering - Reduserer minneforbruket drastisk gjennom smart gjenbruk
- Strategisk content-visibility - Utsetter rendering av ikke-synlige seksjoner (i browsere som støtter dette)
- Prekomputerte komponenter - Statiske elementer beregnes én gang og gjenbrukes
Spennende? ✅
Enkelt? ❌
Fremtiden for webapplikasjon-ytelse
Arbeidet med ytelsesoptimalisering har ført til flere interessante innsikter:
- DOM-rendering er fortsatt en flaskehals - Selv med moderne nettlesere kan DOM-manipulasjon begrense ytelsen når alt annet er optimalisert
- CSS-optimalisering er undervurdert - Spesielt i store applikasjoner. Se f.eks. på bruken av content-visibility: auto, og hva den kan gjøre med lange lister eller stort innhold
- Attributt-deduplisering gir overraskende gevinster - Reduserer minnebruk og øker ytelsen merkbart
- Elm kombinert med avanserte optimaliseringsverktøy - Elm Optimize Level 2 med manuell fine-tuning gir ekstrem ytelse
- Intelligent lazy-evaluering er avgjørende - Strategisk implementering av lazy-rendering på nøkkelpunkter i applikasjonen
Elm er dritkult
Jeg er både starstruck, lykkelig og gira på jobben jeg får være med å gjøre her.
Lovdata har måttet utvikle unike løsninger for å håndtere ekstreme ytelseskrav. Arbeidet viser at selv med radikale valg av verktøy som Elm, er det fortsatt rom for innovasjon og optimalisering i webapplikasjonsutvikling.
Som en organisasjon som har vært i fronten for digitalisering av rettslig informasjon siden 1981, fortsetter de å pushe grensene for hva som er mulig i webapplikasjonsutvikling.
Og så syns jeg, mer en noen gang, at Elm er dritkult.
