Sidans laddningstid handlar inte bara om bildkomprimering och cachning. Ibland är alla <img>-taggar på en webbplats redan lazy-loadade med loading="lazy", men PageSpeed Insights klagar fortfarande på bakgrundsbilder i Elementor-sektioner. Det beror på att background-image i CSS inte stöder lazy loading som standard, webbläsaren hämtar troget varje bakgrundsbild när den tolkar stilarna, även om sektionen är långt under mitten av skärmen.

Detta drabbar särskilt långa landningssidor: den första skärmen kan renderas på 1,2 sekunder, men det tar 4 sekunder eftersom webbläsaren laddar ner 8 bakgrundsbilder från sidfoten som användaren inte kommer att scrolla till på en minut. Det finns en lösning, och under de senaste åren har alternativ dykt upp för alla kunskapsnivåer, från "kryssa i en ruta" till anpassad JavaScript.

💡 Snabb översikt:

• Aktivera inbyggd lazy loading för bakgrunder i Elementors inställningar.
• Konfigurera IntersectionObserver API för anpassade CSS-bakgrunder och äldre pluginversioner.
• Använd jQuery med data-attribut för webbplatser där detta ramverk redan används.

Inbyggd lazy loading i Elementor

Sedan version 3.9 lade Elementor till en experimentell funktion för Lazy Load Background Images, och från version 3.15+ blev den stabil och aktiverad som standard på nya installationer. Under huven är det samma IntersectionObserver API som inbyggda webbläsarlösningar, men paketerat i en bekväm växelknapp.

Så här aktiverar du: gå till Elementor → Inställningar → Funktioner (eller Inställningar → Experiment i det ryska gränssnittet), leta upp raden Lazy Load Background Images och slå om växelknappen till Aktiv. Spara ändringarna, så börjar alla bakgrundsbilder för sektioner, containrar och kolumner som satts via standardgränssnittet i Elementor laddas först när användaren scrollar till dem.

Vad denna metod INTE täcker: anpassade bakgrunder som skrivits manuellt via Elementors CSS-flik (selector { background-image: url(...); }), och bakgrunder som lagts till via widget-plugins från tredje part. För dessa, använd metoderna nedan.

Fördelar: ingen kod, underhålls av Elementor-teamet, automatiskt kompatibel med cachningsplugins. Nackdelar: endast för standardbakgrunder i Elementor, kräver version 3.9+.

Separat är det värt att nämna bakgrundsbildsformatet. Google PageSpeed Insights straffar bakgrunder i JPEG när WebP eller AVIF finns tillgängligt, och detta straff är oberoende av vilken metod du använde för att skjuta upp laddningen. Konvertera alla bakgrundsbilder till WebP (kvalitetsförlusten är osynlig för ögat, och filstorleken är 25-35% mindre än JPEG) eller AVIF (50% mindre än JPEG, men kräver en fallback <picture> för Safari äldre än 16.0). Plugins som Converter for Media eller Imagify gör detta automatiskt vid uppladdning till mediebiblioteket, inklusive bakgrunder som laddas upp via Elementors gränssnitt.

IntersectionObserver: modern JavaScript utan jQuery

Om din Elementor-version är under 3.9, eller bakgrunder sätts med anpassad CSS, eller om du helt enkelt vill ha full kontroll, löser IntersectionObserver API uppgiften rent utan overhead från scroll-händelser.

Varför inte en scroll-hanterare? scroll-händelsen avfyras dussintals gånger per sekund och utför positionsberäkningar för element i huvudtråden vid varje tick. Även med throttle märks detta på svaga enheter. IntersectionObserver arbetar asynkront i webbläsarens kompositortråd, den rapporterar helt enkelt när ett element har passerat synlighetströskeln, utan konstanta beräkningar.

Steg 1. Märkning och CSS. Lägg till CSS-klassen lazy-bg-section till sektioner som behöver lazy loading:

1
.lazy-bg-section {
2
  background-color: #f0f0f0; /* placeholder until background loads */
3
  background-repeat: no-repeat;
4
  background-position: center;
5
  background-size: cover;
6
}
7
 
8
.lazy-bg-section.loaded {
9
  background-color: transparent;
10
}

Bakgrundsfärgen #f0f0f0 fungerar som en visuell platshållare, sektionen ser inte tom ut medan användaren scrollar. Klassen .loaded kommer att läggas till från JavaScript när sektionen kommer in i vyporten.

Steg 2. JavaScript, initiering av Observer. Placera koden i ditt temas skriptfil eller via ett plugin som Code Snippets:

1
document.addEventListener('DOMContentLoaded', () => {
2
  const sections = document.querySelectorAll('.lazy-bg-section');
3
 
4
  if (!sections.length || !('IntersectionObserver' in window)) return;
5
 
6
  const observer = new IntersectionObserver(
7
    (entries) => {
8
      entries.forEach((entry) => {
9
        if (entry.isIntersecting) {
10
          const bgUrl = entry.target.dataset.bg;
11
          if (bgUrl) {
12
            entry.target.style.backgroundImage = `url(${bgUrl})`;
13
          }
14
          entry.target.classList.add('loaded');
15
          observer.unobserve(entry.target);
16
        }
17
      });
18
    },
19
    { rootMargin: '200px 0px' }
20
  );
21
 
22
  sections.forEach((section) => observer.observe(section));
23
});

Viktig detalj: rootMargin: '200px 0px' innebär att Observern avfyras 200 pixlar innan sektionen faktiskt visas på skärmen. Användaren ser inte laddningsögonblicket, bilden är redan på plats.

Steg 3. Märkning i Elementor. Öppna den önskade sektionen → fliken Avancerat → fältet CSS-klasser, ange lazy-bg-section. På samma ställe, under Anpassade attribut, lägg till ett data-bg-attribut med värdet som den fullständiga URL:en till bakgrundsbilden.

Detta tillvägagångssätt fungerar i alla moderna webbläsare (Chrome 51+, Firefox 55+, Safari 12.1+, Edge 15+), det vill säga överallt sedan 2016. För Internet Explorer behöver du en polyfill, men sådana projekt är numera sällsynta.

JQuery och data-attribut: den klassiska metoden

På riktigt gamla webbplatser där jQuery redan laddas på varje sida och det inte är ett alternativ att skriva om stacken, fungerar en metod med data-attribut och en scroll-hanterare. Den är mindre prestandaeffektiv än IntersectionObserver, men beprövad genom åren och kräver inte moderna webbläsar-API:er.

Steg 1. Sektionsklass. I Elementors sektionsinställningar, fliken Avancerat → CSS-klasser, ange lazy-background:

Steg 2. CSS-stilar för bakgrund. För att bakgrundsbilden ska sträckas ut korrekt över hela sektionen efter laddning, sätt stilar. I Elementor görs detta via fliken Avancerat → Anpassad CSS för den specifika sektionen:

Grundläggande stilar för en helskärmsbakgrund:

1
#OO2 .lazy-bg {
2
  background-repeat: no-repeat;
3
  background-position: center;
4
  background-size: cover;
5
  position: absolute;
6
  top: 0;
7
  right: 0;
8
  bottom: 0;
9
  left: 0;
10
  z-index: -1;
11
  background-attachment: fixed;
12
}

Notera selektorn #OO2, detta är sektionens CSS-identifierare som du sätter i samma flik Avancerat → CSS-ID. För varje sektion med sin egen bakgrund måste identifieraren vara unik så att stilarna inte överlappar.

Alternativ för små bilder (inte hel sektion). Om du behöver placera en liten bild i sektionen snarare än en helskärmsbakgrund, till exempel en logotyp eller ett dekorativt element i sidfoten, justera stilarna för den specifika storleken och positionen:

1
section#SDStudio-Footer .lazy-bg {
2
  background-repeat: no-repeat;
3
  background-position: right bottom;
4
  background-size: 350px;
5
  position: absolute;
6
  top: 0;
7
  right: 0;
8
  bottom: 0;
9
  left: 0;
10
  z-index: 0;
11
  background-attachment: fixed;
12
}
13
 
14
section#SDStudio-Footer .elementor-column.elementor-col-25,
15
.elementor-column[data-col="25"] {
16
  width: 25%;
17
  z-index: 2;
18
}

Här är bakgrunden placerad i det nedre högra hörnet av sidfotssektionen med en fast bredd på 350px, och kolumner ges z-index: 2 så att innehållet inte täcks av bakgrundslagret.

Steg 3. Responsiva bilder. För att undvika att ladda en bild på 2 megabyte på en mobilskärm med 400px bredd, förbered 6 bildvarianter för olika upplösningar:

Steg 4. Data-attribut. Ladda upp bilder till WordPress mediebibliotek och ange sökvägar till dem i sektionens data-attribut. I Elementor: Avancerat → Anpassade attribut:

Format för varje attribut:

1
data-bg-min-1701 | /wp-content/uploads/2020/03/Background-min-width-1701px.jpg
2
data-bg-max-1700 | /wp-content/uploads/2020/03/Background-max-width-1700px.jpg
3
data-bg-max-1200 | /wp-content/uploads/2020/03/Background-max-width-1200px.jpg
4
data-bg-max-1024 | /wp-content/uploads/2020/03/Background-max-width-1024px.jpg
5
data-bg-max-768  | /wp-content/uploads/2020/03/Background-max-width-768px.jpg
6
data-bg-max-400  | /wp-content/uploads/2020/03/Background-max-width-400px.jpg

Skriptet (se nedan) läser dessa attribut, bestämmer den aktuella skärmbredden via window.matchMedia och infogar URL:en för den behövda storleken.

Steg 5. jQuery-skript. Lägg till koden i ditt temas skriptfil eller via ett plugin:

1
jQuery(document).ready(function ($) {
2
  var $window = $(window),
3
    lazyBgArr = [];
4
 
5
  $window.on('load resize scroll', function () {
6
    for (var i = 0; i < lazyBgArr.length; i++) {
7
      var func = lazyBgArr[i];
8
      if (func !== undefined) {
9
        func();
10
      }
11
    }
12
  });
13
 
14
  function lazyBg(strEl, intPos) {
15
    return function () {
16
      var intCheckVal = $window.scrollTop() + $window.height() + 100;
17
      if (intCheckVal > strEl.offset().top) {
18
        var data_bg;
19
 
20
        if (window.matchMedia('(min-width: 1701px)').matches) {
21
          data_bg = 'data-bg-min-1701';
22
        } else if (
23
          window.matchMedia('(min-width: 1201px) and (max-width: 1700px)').matches
24
        ) {
25
          data_bg = 'data-bg-max-1700';
26
        } else if (
27
          window.matchMedia('(min-width: 1025px) and (max-width: 1200px)').matches
28
        ) {
29
          data_bg = 'data-bg-max-1200';
30
        } else if (
31
          window.matchMedia('(min-width: 769px) and (max-width: 1024px)').matches
32
        ) {
33
          data_bg = 'data-bg-max-1024';
34
        } else if (
35
          window.matchMedia('(min-width: 401px) and (max-width: 768px)').matches
36
        ) {
37
          data_bg = 'data-bg-max-768';
38
        } else if (window.matchMedia('(max-width: 400px)').matches) {
39
          data_bg = 'data-bg-max-400';
40
        }
41
 
42
        if (!data_bg) return;
43
 
44
        var tmpImg = new Image(),
45
          strSrc = strEl.attr(data_bg);
46
        tmpImg.src = strSrc;
47
        delete lazyBgArr[intPos];
48
 
49
        $(tmpImg).on('load', function () {
50
          strEl.append('<div class="lazy-bg"></div>').css('opacity', 1);
51
          strEl.addClass('loaded');
52
        });
53
      }
54
    };
55
  }
56
 
57
  $('.lazy-background').each(function (i) {
58
    lazyBgArr.push(lazyBg($(this), i));
59
  });
60
});

Hur det fungerar: vid sidladdning och varje scroll-händelse kontrollerar skriptet positionen för varje sektion med klassen .lazy-background. Om sektionen kommer in i zonen "skärm + 100px buffert", bestäms den aktuella vyportens bredd via matchMedia, det nödvändiga data-attributet väljs, ett temporärt Image-objekt skapas för förladdning, och efter framgångsrik laddning läggs en <div class="lazy-bg"> med bakgrundsbilden till i sektionen. Den bearbetade sektionen tas bort från bevakningsarrayen, det sker inga upprepade laddningar.

Vilken metod ska man välja: jämförelse

Det praktiska urvalskriteriet är enkelt: om din Elementor är version 3.9 eller nyare och bakgrunder sätts på standardvägen, aktivera den inbyggda funktionen och stäng ärendet. Om bakgrunder är anpassade (CSS-flik, widgets från tredje part), använd IntersectionObserver i vanilla JavaScript, utan jQuery. Spara jQuery-metoden för projekt där jQuery redan finns och det inte finns budget för omskrivning, eller där stöd för Internet Explorer behövs.

Oavsett vald metod förblir bakgrundsbilden fysiskt samma fil på servern. Om den väger 800 kilobyte kommer lazy loading inte att göra den lättare, den kommer bara att skjuta upp ögonblicket då webbläsaren börjar ladda ner dessa 800 kilobyte. Därför gäller regeln "optimera först, lazy loada sedan" även här: komprimera först till WebP eller AVIF och ändra storlek till målgruppens maximala skärmbredd, och tillämpa först därefter någon av de tre lazy loading-metoderna. Cachningsplugins (WP Rocket, LiteSpeed Cache, Flying Press) står inte i konflikt med någon av de tre metoderna, eftersom en bakgrund som laddas via CSS background-image cachas av webbläsaren på samma sätt som en vanlig <img>.

⁉️🤔 Vanliga frågor

Varför inte bara använda loading="lazy" för bakgrundsbilder?

Attributet loading="lazy" fungerar bara med <img>- och <iframe>-taggar, men inte med CSS-egenskapen background-image. Webbläsaren vet inte att din CSS innehåller en bild-URL som skulle kunna skjutas upp förrän den tolkar stilmallen, och vid det laget har begäran redan gått till nätverket. Det är precis därför bakgrunder behöver en separat mekanism.

Vilken metod ska jag välja om webbplatsen är 3 år gammal och Elementor är version 3.12?

Inbyggd lazy loading från Elementor. Version 3.12 inkluderar redan denna funktion i stabil status, gå bara till Inställningar, Funktioner och aktivera den. Ingen kod behöver skrivas.

Saktar jQuery-metoden ner märkbart på mobilen?

På budget Android-enheter från 2019-2020, märkbart. scroll-händelsen i kombination med offset().top belastar huvudtråden vid varje bildruta av scrollningen. Om webbplatsens publik övervägande är mobil, byt till IntersectionObserver eller uppdatera Elementor till 3.9+ och aktivera den inbyggda funktionen.

Kan jag kombinera metoder på en webbplats?

Ja, och det är normal praxis. De flesta bakgrundssektioner som konfigurerats via standardgränssnittet i Elementor hanteras av inbyggd lazy loading. De återstående anpassade sektionerna med manuell CSS kopplar du till IntersectionObserver. Det finns ingen konflikt: Observer avfyras endast på element med den angivna klassen, och Elementors inbyggda mekanism ignorerar dem.

Är det obligatoriskt att förbereda 6 bildstorlekar, eller räcker det med en?

Sex storlekar är maximum för meningsfull detaljrikedom. I praktiken räcker tre för de flesta webbplatser: 1920px för desktop, 1024px för surfplatta och 768px för mobil. Fyra brytpunkter, med tillägg av 400px för små skärmar, är redan en bra balans mellan kvalitet och ansträngning. En bild för alla upplösningar fungerar, men laddar extra kilobyte på mobilen, Google PageSpeed Insights kommer att notera detta.

Är det värt att bry sig om anpassad kod år 2026?

Om du har Elementor 3.9 eller nyare, nästan definitivt inte. Den inbyggda funktionen täcker behoven hos den stora majoriteten av webbplatser: aktivera den, kontrollera i PageSpeed Insights, glöm bort den. Anpassade metoder (IntersectionObserver och särskilt jQuery) är motiverade i exakt två fall: Elementor-versionen är låst under 3.9 av giltiga skäl, eller bakgrunder läggs till på ett icke-standardiserat sätt och standardväxeln ser dem inte.

För ett nytt projekt på färsk Elementor är den korrekta åtgärdsordningen: aktivera inbyggd lazy loading, kör webbplatsen genom PageSpeed Insights, och endast om specifika bakgrundsbilder fortfarande flaggas som problematiska, hantera dem individuellt via IntersectionObserver. Skriv inte anpassad kod i förväg "för säkerhets skull", varje extra rad JavaScript som du kan undvika att skriva sparar dig underhållstid.