Batch-komprimering av bilder för webbutvecklare | Bulk Image Compressor

Published December 18, 2025

Bilder är de tyngsta tillgångarna på de flesta webbplatser. På en genomsnittlig sida står de för 40 till 60% av den totala vikten. Om du är webbutvecklare och inte komprimerar bilder skickar du ut svullna sidor oavsett hur ren din kod är.

Frågan är inte om du ska komprimera. Det är var i ditt arbetsflöde komprimeringen ska ske och vilket verktyg som passar varje situation.

Var bildkomprimering passar in i ett utvecklingsflöde

Det finns tre huvudsakliga punkter där du kan komprimera bilder under utveckling:

Fre commit. Du optimerar bilder lokalt innan de någonsin hamnar i versionshantering. Detta håller ditt repository smalt och innebär att varje miljö (staging, produktion, andra utvecklares datorer) får de optimerade versionerna automatiskt.

Under bygge. Byggverktyg som Vite eller webpack hanterar komprimering som en del av tillgångspipelinen. Källbilderna ligger kvar i full kvalitet i repot, och byggprocessen genererar optimerade versioner för driftsättning.

På CDN-nivån. Tjänster som Cloudflare, Imgix eller Cloudinary transformerar och komprimerar bilder i farten baserat på den anropande enheten och webbläsaren.

Varje tillvägagångssätt har avvägningar, och du kan kombinera dem.

Online-verktyg vs byggplugin

För en snabb engångsuppgift, som att komprimera en batch skärmbilder för ett blogginlägg eller optimera en uppsättning ikoner, är ett online-verktyg det snabbaste alternativet. Öppna Bulk Image Compressor, släpp dina filer, justera kvaliteten och ladda ner. Klart på under en minut.

Byggplugin hanterar löpande optimering automatiskt. Så här ser det ut i praktiken.

Vite

Vite-användare kan använda vite-plugin-imagemin eller liknande plugin:

// vite.config.js
import imagemin from 'vite-plugin-imagemin';

export default {
  plugins: [
    imagemin({
      mozjpeg: { quality: 80 },
      webp: { quality: 80 },
      pngquant: { quality: [0.7, 0.8] },
    }),
  ],
};

Detta komprimerar bilder under vite build. Källfilerna förblir orörda. Utmatningskatalogen får de optimerade versionerna.

webpack

Med webpack gör image-minimizer-webpack-plugin samma jobb:

const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        minimizer: {
          implementation: ImageMinimizerPlugin.sharpMinify,
          options: {
            encodeOptions: {
              jpeg: { quality: 80 },
              webp: { quality: 80 },
            },
          },
        },
      }),
    ],
  },
};

När du ska använda vilket

Använd ett online-verktyg när:

Du lägger till en handfull bilder i ett projekt och vill ha dem optimerade direkt
Du arbetar med innehåll från en kund eller designer som skickat ooptimerade filer
Ditt projekt inte har ett byggsteg (statisk HTML, enkla webbplatser)
Du vill granska komprimeringsresultat visuellt innan du committar

Använd byggplugin när:

Ditt projekt redan har en byggpipeline
Flera utvecklare bidrar med bilder och du vill ha konsekvent optimering
Du behöver formatkonvertering (t.ex. generera WebP-versioner automatiskt)
Du vill ha källbilder i full kvalitet i repot för eventuell framtida ombearbetning

CI/CD-bildoptimering

Byggplugin körs under lokala byggen, men du kan också lägga till bildoptimering i din CI/CD-pipeline. Det fångar ooptimerade bilder som slinker igenom, oavsett vem som committade dem.

Ett enkelt tillvägagångssätt är att köra ett skript i din CI-pipeline som kontrollerar bildfilernas storlekar:

# Misslyckas med bygget om någon bild är större än 500KB
find public/images -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +500k | tee oversized.txt
if [ -s oversized.txt ]; then
  echo "Hittade för stora bilder. Komprimera innan driftsättning."
  exit 1
fi

För automatiserad komprimering i CI kan verktyg som sharp-cli eller imagemin-cli bearbeta bilder som ett byggsteg. Detta garanterar att inget går till produktion okomprimerat.

Lat laddning och responsiva bilder

Komprimering ensam räcker inte. Hur du laddar bilder spelar lika stor roll.

Lat laddning skjuter upp bilder utanför skärmen tills användaren scrollar till dem. Lägg till loading="lazy" på varje bild som är nedanför mitten. Ladda inte lat din hero-bild eller något innehåll som är synligt vid första sidladdningen, eftersom det kommer att skada din Largest Contentful Paint-poäng.

Responsiva bilder levererar olika storlekar baserat på skärmbredd. En telefon behöver inte en 2400px-bild avsedd för en datorskärm. Använd attributen srcset och sizes för att låta webbläsaren välja rätt version:

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
  sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
  alt="Produktfoto"
  width="1600"
  height="1067"
  loading="lazy"
>

Generera dessa storleksvarianter som en del av din byggprocess eller med ett batchverktyg innan uppladdning.

CDN-leverans

Ett CDN (Content Delivery Network) levererar bilder från servrar som är geografiskt nära dina besökare. Detta minskar latensen, men vissa CDN:er går längre med bildoptimering i farten.

Cloudflare Image Resizing kan ändra storlek och konvertera bilder till WebP eller AVIF automatiskt baserat på besökarens webbläsare. Du behöver inte generera varianter själv.

Imgix och Cloudinary är dedikerade bild-CDN:er. Du laddar upp en högkvalitativ källa, och de genererar vilken storlek, format och kvalitet du begär via URL-parametrar. Detta är kraftfullt men tillkommer en kostnad per bild.

För de flesta projekt räcker det att komprimera bilder före uppladdning och leverera dem via ett standard-CDN (Cloudflare, Fastly, AWS CloudFront). Dedikerade bild-CDN:er är vettiga när du har tusentals användaruppladdade bilder och behöver dynamisk storleksändring. För bakgrund om varför komprimering överhuvudtaget är viktigt för webben täcker vår guide om varför webbbilder behöver komprimering grunderna.

Vanliga misstag utvecklare gör

Committa ooptimerade bilder. En 5MB JPEG i ditt repo stannar där i git-historiken för alltid, även om du ersätter den senare. Komprimera innan du committar.

Använda PNG för fotografier. PNG är avsett för grafik, skärmbilder och bilder med genomskinlighet. Ett fotografi sparat som PNG är typiskt 3 till 5 gånger större än samma bild som JPEG eller WebP. Använd rätt format för innehållstypen. Kolla vår formatjämförelseguide för specifikationer.

Hoppa över bredd- och höjdattribut. Utan explicita dimensioner vet webbläsaren inte hur mycket utrymme som ska reserveras för en bild förrän den laddas. Detta orsakar layoutförskjutningar, vilket skadar din CLS-poäng och irriterar användare.

Överkomprimering. Att pressa kvaliteten till 30 eller 40% för att få små filer ger synliga artefakter. För webbilder ger 75 till 82% kvalitet rätt balans mellan storlek och utseende.

Ignorera bilddimensioner. Att komprimera ett 4000px-foto till 80% kvalitet är bra, men om det visas i 600px bredd på din sida skickar du fortfarande mycket fler pixlar än nödvändigt. Ändra storlek till dina visningsdimensioner först, komprimera sedan.

Använda inte WebP. Webbläsarstöd för WebP är universellt nu. Om du fortfarande bara använder JPEG och PNG går du miste om 25 till 35% filstorleksbesparingar.

Ett praktiskt tillvägagångssätt

För de flesta webbprojekt fungerar följande bra:

Ändra storlek och komprimera bilder innan du committar, med ett online-verktyg som Bulk Image Compressor eller ett lokalt skript.
Lägg till ett byggplugin som ett säkerhetsnät för att fånga upp sådant som slank igenom.
Använd lat laddning och responsiva bilder i din HTML.
Leverera via ett CDN.

Du behöver inte göra alla fyra från dag ett. Börja med det första steget. Redan det kommer att göra en märkbar skillnad i dina sidladdningstider.

Ready to compress your images?

Bulk compress JPEG, PNG, WebP, and AVIF images right in your browser. No uploads, no sign-ups.

Try Bulk Image Compressor