CSS Scroll Snap-ytelse: En dybdeanalyse av optimalisering for beregning av snappunkter

Når brukeren scroller, kjøres en liten mengde JavaScript for å beregne hvilke elementer *burde* være synlige nå. Den gjenbruker deretter den eksisterende poolen av 10-20 DOM-noder, fjerner dataen fra elementene som har scrollet ut av syne, og fyller dem med dataen til de nye elementene som scroller inn i syne.

Anvende virtualisering på Scroll Snap

Dette utgjør en utfordring. CSS Scroll Snap er deklarativt og avhenger av at ekte DOM-elementer er til stede for å beregne deres posisjoner. Hvis elementene ikke eksisterer, kan ikke nettleseren lage snappunkter for dem.

Løsningen er en hybridtilnærming. Du opprettholder et lite antall ekte DOM-elementer i din scroll-container. Disse elementene har `scroll-snap-align`-egenskapen og vil snappe korrekt. Virtualiseringslogikken, håndtert av JavaScript, er ansvarlig for å bytte ut innholdet i disse få DOM-nodene etter hvert som brukeren scroller gjennom det større, virtuelle datasettet.

Fordeler med virtualisering:

• Enorm ytelsesgevinst: Nettleseren trenger bare å beregne layouten og snappunktene for en håndfull elementer, uavhengig av om datasettet ditt har 1 000 eller 1 000 000 elementer. Dette eliminerer nesten den innledende beregningskostnaden og nyberegningskostnaden under scrolling.
• Redusert minnebruk: Færre DOM-noder betyr mindre minne brukt av nettleseren, noe som er kritisk for ytelsen på enklere mobile enheter.

Ulemper og hensyn:

• Økt kompleksitet: Du bytter ut enkelheten i ren CSS med kompleksiteten i en JavaScript-drevet løsning. Du er nå ansvarlig for å administrere tilstand, beregne synlige elementer og oppdatere DOM-en effektivt.
• Tilgjengelighet: Å implementere virtualisering korrekt fra et tilgjengelighetsperspektiv er ikke-trivielt. Du må håndtere fokus, sikre at skjermlesere kan navigere i innholdet, og vedlikeholde korrekte ARIA-attributter.
• Finn-på-siden (Ctrl/Cmd+F): Nettleserens innebygde finn-funksjonalitet vil ikke fungere for innhold som ikke er rendret i DOM-en for øyeblikket.

For de fleste storskalaapplikasjoner veier ytelsesfordelene langt tyngre enn kompleksiteten. Du trenger ikke bygge dette fra bunnen av. Utmerkede åpen kildekode-biblioteker som TanStack Virtual (tidligere React Virtual), `react-window` og `vue-virtual-scroller` gir robuste, produksjonsklare løsninger for implementering av virtualisering.

Optimaliseringsstrategi 2: Egenskapen `content-visibility`

Hvis full virtualisering føles som for mye for ditt bruksområde, finnes det en mer moderne, CSS-innebygd tilnærming som kan gi en betydelig ytelsesboost: egenskapen `content-visibility`.

Hvordan det fungerer

Egenskapen `content-visibility` er et kraftig hint til nettleserens renderingsmotor. Når du setter `content-visibility: auto;` på et element, forteller du nettleseren:

"Du har min tillatelse til å hoppe over det meste av renderingsarbeidet for dette elementet (inkludert layout og paint) hvis du fastslår at det for øyeblikket ikke er relevant for brukeren – det vil si at det er utenfor skjermen."

Når elementet scroller inn i viewporten, begynner nettleseren automatisk å rendere det akkurat i tide. Denne on-demand renderingen kan dramatisk redusere den innledende lastetiden for en side med en lang liste med elementer.

Følgeegenskapen `contain-intrinsic-size`

Det er en hake. Hvis nettleseren ikke renderer et elements innhold, vet den ikke størrelsen. Dette ville føre til at scrollbaren hopper og endrer størrelse etter hvert som brukeren scroller og nye elementer renderes, noe som skaper en forferdelig brukeropplevelse. For å løse dette, bruker vi egenskapen `contain-intrinsic-size`.

contain-intrinsic-size: 300px 500px; (høyde og bredde) gir en plassholderstørrelse for elementet før det renderes. Nettleseren bruker denne verdien til å beregne layouten for scroll-containeren og dens scrollbar, og forhindrer dermed brå hopp.

Slik ville du brukt det på en liste med scroll-snap-elementer:

            
.scroll-snap-container {
  scroll-snap-type: y mandatory;
  height: 100vh;
  overflow-y: scroll;
}

.snap-item {
  scroll-snap-align: start;
  /* The magic happens here */
  content-visibility: auto;
  contain-intrinsic-size: 100vh; /* Assuming full-height sections */
}

            

              
                Copy
              
            
          

`content-visibility` og beregning av snappunkter

Denne teknikken hjelper betydelig med den innledende renderingskostnaden. Nettleseren kan utføre det første layout-passet mye raskere fordi den bare trenger å bruke plassholderen `contain-intrinsic-size` for elementene utenfor skjermen, i stedet for å beregne den komplekse layouten av innholdet deres. Dette betyr en raskere Time to Interactive.

Fordeler med `content-visibility`:

• Enkelhet: Det er bare to linjer med CSS. Dette er langt enklere å implementere enn et fullt JavaScript-virtualiseringsbibliotek.
• Progressiv forbedring: Nettlesere som ikke støtter det, vil enkelt og greit ignorere det, og siden vil fungere som den gjorde før.
• Bevarer DOM-strukturen: Alle elementene forblir i DOM-en, så innebygde nettleserfunksjoner som Finn-på-siden fortsetter å virke.

Begrensninger:

• Ingen universalmiddel: Selv om det utsetter renderingsarbeid, anerkjenner nettleseren fortsatt eksistensen av alle DOM-nodene. For lister med titusenvis av elementer, kan det store antallet noder fortsatt forbruke betydelig minne og noe CPU for stil- og trehåndtering. I disse ekstreme tilfellene er virtualisering fortsatt overlegen.
• Nøyaktig størrelse: Effektiviteten av `contain-intrinsic-size` avhenger av at du gir en rimelig nøyaktig plassholderstørrelse. Hvis elementene dine har veldig varierende innholdshøyder, kan det være utfordrende å velge en enkelt verdi som ikke forårsaker noe innholdsforskyvning.
• Nettleserstøtte: Selv om støtten i moderne Chromium-baserte nettlesere og Firefox er god, er den ennå ikke universell. Sjekk alltid en kilde som CanIUse.com før du implementerer det som en kritisk funksjon.

Optimaliseringsstrategi 3: JavaScript-debounced DOM-manipulering

Denne strategien retter seg mot ytelseskostnaden ved nyberegning i dynamiske applikasjoner der elementer ofte legges til eller fjernes fra scroll-containeren.

Problemet: Død av tusen kutt

Se for deg en live-feed der nye elementer ankommer via en WebSocket-tilkobling. En naiv implementering kan legge til hvert nye element i DOM-en etter hvert som det kommer:

            
// ANTIMØNSTER: Dette utløser en ny layout-beregning for hvert eneste element!
socket.on('newItem', (itemData) => {
  const newItemElement = document.createElement('div');
  newItemElement.className = 'snap-item';
  newItemElement.textContent = itemData.text;
  container.prepend(newItemElement);
});

            

              
                Copy
              
            
          

Hvis ti elementer ankommer i rask rekkefølge, utløser denne koden ti separate DOM-manipuleringer. Hver `prepend()`-operasjon ugyldiggjør layouten, og tvinger nettleseren til å beregne posisjonene til alle snappunktene i containeren på nytt. Dette er en klassisk årsak til Layout Thrashing og vil få grensesnittet til å føles ekstremt hakkete.

Løsningen: Gruppér oppdateringene dine

Nøkkelen er å gruppere disse oppdateringene i én enkelt operasjon. I stedet for å endre den aktive DOM-en ti ganger, kan du bygge opp de nye elementene i et `DocumentFragment` i minnet og deretter legge til fragmentet i DOM-en på én gang. Dette resulterer i bare én ny layout-beregning.

Vi kan forbedre dette ytterligere ved å bruke `requestAnimationFrame` for å sikre at vår DOM-manipulering skjer på det mest optimale tidspunktet, rett før nettleseren skal tegne neste bilderute.

            
// GODT MØNSTER: Gruppering av DOM-oppdateringer
let itemBatch = [];
let updateScheduled = false;

socket.on('newItem', (itemData) => {
  itemBatch.push(itemData);

  if (!updateScheduled) {
    updateScheduled = true;
    requestAnimationFrame(updateDOM);
  }
});

function updateDOM() {
  const fragment = document.createDocumentFragment();

  itemBatch.forEach(itemData => {
    const newItemElement = document.createElement('div');
    newItemElement.className = 'snap-item';
    newItemElement.textContent = itemData.text;
    fragment.appendChild(newItemElement);
  });

  container.prepend(fragment);

  // Tilbakestill for neste gruppe
  itemBatch = [];
  updateScheduled = false;
}

            

              
                Copy
              
            
          

Denne debounced/grupperte tilnærmingen forvandler en serie kostbare, individuelle oppdateringer til én enkelt, effektiv operasjon, og bevarer responsiviteten til ditt scroll snap-grensesnitt.

Avanserte hensyn og beste praksis for et globalt publikum

Å optimalisere ytelse handler ikke bare om å gjøre ting raskt på en kraftig utviklermaskin. Det handler om å sikre en jevn og tilgjengelig opplevelse for alle brukere, uavhengig av deres enhet, nettverkshastighet eller sted. En ytende side er en inkluderende side.

Lazy Loading av media

Dine snap-elementer inneholder sannsynligvis bilder eller videoer. Selv om du virtualiserer DOM-nodene, ville det å laste inn alle medieelementer for en liste med 5000 elementer på forhånd være katastrofalt for nettverks- og minnebruk. Kombiner alltid ytelsesoptimaliseringer for scrolling med 'lazy loading' av media. Den innebygde `loading="lazy"`-attributten på ``- og `