Rette hoppende layout: De vanligste årsakene
Et hoppende layout er feilen besøkende merker sterkest og utviklere ser sjeldnest – fordi ingenting hopper på en rask maskin med fylt mellomlager. Seks årsaker dekker nesten alle tilfeller.
Det viktigste kort
- Seks årsaker dekker nesten alle tilfeller – bilder uten mål, skrifter som lastes etterpå, innebygd fremmedinnhold, merknader som vises i etterkant, sent lastet CSS og dynamisk innsatt innhold.
- Verdien måles jevnlig for godt på egen maskin: rask forbindelse, fylt mellomlager, annen skjermstørrelse.
- Det mest virkningsfulle enkelttiltaket er å gi hvert bilde og hvert innebygde element faste mål eller et sideforhold.
- En merknadsbjelke som dukker opp etter lastingen og skyver innhold nedover, er den nest vanligste årsaken – og den enkleste å rette.
De seks årsakene
1. Bilder uten målangivelser
Uten width og height vet ikke nettleseren hvor mye plass som skal settes av – teksten sklir så snart bildet kommer.
Retting: Sett begge attributtene og legg til height: auto i CSS, slik at skaleringen beholdes.
2. Skrifter som lastes etterpå
Teksten vises først i erstatningsskriften og hopper ved byttet, fordi de to har ulik bredde.
Retting: Last skriften på forhånd, bruk font-display: swap, og tilpass erstatningsskriftens mål til målskriften.
3. Innebygd fremmedinnhold
Videoer, kart og vurderingselementer kommer uten kjent høyde og skyver alt nedover når de ankommer.
Retting: Angi en plassholder med fast sideforhold som innholdet lastes inn i.
4. Merknader som vises i etterkant
Et samtykkebanner eller en kampanjebjelke som dukker opp øverst etter lastingen og skyver hele siden nedover.
Retting: Sett av plass fra begynnelsen, eller vis den overlappende i stedet for innskyvende.
5. Sent lastet CSS
Blir stilarket først virksomt etter den første oppbyggingen, vises siden én gang uformet og deretter formet.
Retting: Lever reglene som trengs for det synlige området, tidlig – fullstendig, ikke stykkevis.
6. Dynamisk innsatt innhold
En merknad, en liste eller et område som JavaScript setter inn over bestående innhold etter lastingen.
Retting: Sett det inn under det synlige området, eller sett av plass.
Visste du at …?
Årsak fem er den lumskeste, fordi den nesten aldri opptrer lokalt: på en rask forbindelse kommer stilarket før den første oppbyggingen, og ingenting hopper. På en treg forbindelse kommer det etterpå – og hele siden bygges opp to ganger.
Å levere en del av CSS-en tidlig holder ikke: mangler det der en regel som gjelder det synlige området, hopper nettopp det elementet. Enten fullstendig for det synlige området eller ikke i det hele tatt – halve løsninger er her dårligere enn ingen.
Å måle riktig
| Målemåte | Hva den viser | Fallgruve |
|---|---|---|
| Egen maskin, utviklerverktøy | grove holdepunkter | for rask, mellomlageret fylt |
| Laboratorietest i et testverktøy | en verdi som lar seg gjenta | én betingelse, ikke virkeligheten |
| Feltdata fra ekte besøkende | hva som faktisk skjer | trenger nok trafikk |
| Mobil med strupet forbindelse | den ærligste enkelttesten | må stilles inn bevisst |
Et tilfelle som fester seg: en side hadde en feilfri verdi lokalt og en svært dårlig i testverktøyet. Årsaken var et stilark som delvis ble levert på forhånd – tre regler for områder i den synlige delen manglet i det.
Lokalt ble det aldri oppdaget, fordi den fullstendige filen kom raskere enn den første oppbyggingen. Under struping kom den etterpå, og tre områder hoppet. Lærdommen: ved hoppende layout er det lokale inntrykket ikke et motbevis, men bare et annet scenario – og som regel det mest urealistiske.
Rekkefølgen når det rettes
- Kontroller alle bilder.
widthogheightsatt,height: autoi CSS. Som regel halve problemet. - Ramm inn innebygd fremmedinnhold. Plassholder med fast sideforhold.
- Kontroller merknader som vises. Overlappende i stedet for innskyvende.
- Kontroller skriftlastingen. Last på forhånd, tilpass erstatningsskriften.
- Kontroller CSS-leveringen. Fullstendig for det synlige området.
- Mål på nytt – strupet. Og det etter hvert enkelt trinn, ellers vet man ikke hva som virket.
Hjelp meg å finne og rette hoppende layout på siden vår. Opplysninger: - Målt verdi for layoutforskyvning: [verdi, verktøy, mobil eller skrivebord] - Elementer som ifølge målingen forskyver seg: [liste, hvis kjent] - Bilder med width/height-attributter? [ja / nei / delvis] - Hvordan leveres CSS? [ekstern fil / innebygd på forhånd / delvis på forhånd] - Innebygd fremmedinnhold: [videoer, kart, vurderinger, chat] - Blir noe vist etter lastingen? [banner, merknad, kampanjebjelke] - Hvordan lastes skriftene? [angivelse] Oppgaver: 1. Plasser hvert forskyvende element under en av de seks årsakene: bilder uten mål, skrifter som lastes etterpå, innebygd fremmedinnhold, merknader som vises i etterkant, sent lastet CSS, dynamisk innsatt innhold. 2. Nevn per årsak den konkrete rettingen med kodeeksempel. 3. Hvis CSS bare leveres delvis på forhånd: forklar hvorfor det kan være dårligere enn ikke i det hele tatt, og hva som må kontrolleres. 4. Gi meg en rekkefølge etter virkning per innsats. 5. Si meg hvordan jeg bør måle etter hvert trinn, slik at jeg vet hva som virket. Ikke finn på måleverdier.
Konklusjon
Seks årsaker, og den første – bilder uten målangivelser – utgjør som regel halvparten. Den er rettet på en halvtime og virker med en gang.
Den vanskeligere delen er målingen: den som tester lokalt, måler et scenario knapt noen besøkende opplever. Mål strupet, enkeltvis etter hvert trinn – ellers retter man tre ting og vet ikke hvilken av dem som virket.
Vanlige spørsmål
Hvorfor hopper innholdet når en side lastes?
Som regel av én av seks årsaker: bilder uten målangivelser, skrifter som lastes etterpå og har annen bredde, innebygd fremmedinnhold uten kjent høyde, merknadsbjelker som vises i etterkant, CSS som blir virksomt sent, og innhold som JavaScript setter inn over det synlige området.
Hva er det mest virkningsfulle enkelttiltaket?
Å gi hvert bilde width og height og legge til height: auto i CSS. Nettleseren setter da av riktig plass fra begynnelsen, mens skaleringen beholdes. Dette tiltaket utgjør i praksis ofte halve problemet.
Hvorfor er verdien bedre lokalt enn i testverktøyet?
Fordi forbindelsen på egen maskin er rask og mellomlageret fylt: stilark, skrifter og bilder kommer før den første sideoppbyggingen, og ingenting hopper. Under realistiske forhold kommer de etterpå – derfor må det måles strupet.
Kan CSS som bare delvis leveres på forhånd, skade?
Ja. Mangler det i den forhåndsleverte delen en regel som gjelder et område i den synlige delen, hopper nettopp det elementet så snart det fullstendige stilarket kommer. Enten fullstendig for det synlige området eller ikke i det hele tatt – halve løsninger er her dårligere enn ingen.
Hvordan retter man hoppende samtykkebannere?
Ved å vise dem overlappende i stedet for innskyvende – altså at de ligger over innholdet uten å skyve det nedover. Alternativt lar plassen seg sette av fra begynnelsen. Denne årsaken er en av de vanligste og samtidig den enkleste å rette.
Markedsføring som setter seg opp selv
Betaen for Studio Engine er åpen. Sikre deg en plass og bidra fra starten.
Bli med i betaen →