Web İçin Görsel Boyutu Nasıl Küçültülür? og:image Rehberi

Web için görsel hazırlamanın üç adımı var: doğru piksel ölçüsüne kırpmak (paylaşım görselleri için 1200 × 630), fotoğrafik içeriği %80-85 kalitede JPEG'e çevirmek ve yükledikten sonra dosyanın gerçekten sunulduğunu doğrulamak. Bu üç adım altı görselimizi 6 MB'dan 940 KB'a indirdi.

Blog yazılarımız için altı kapak görseli hazırladık. Yapay zeka ile üretildiler, güzel görünüyorlardı ve toplam boyutları 6 MB'ydı.

Bu haliyle yayına alınabilirdi. Alınmamalıydı.

İşlem sonrası aynı altı görsel 940 KB — dosya başına %78 ile %91 arasında küçülme, gözle görülür kalite kaybı olmadan.

Bu yazı ne yaptığımızı ve neden her adımın gerektiğini anlatıyor.

Neden ham çıktı doğrudan yüklenmemeli

Görsel üreticileri size kaynak dosya verir, web için hazır dosya değil. Tipik çıktı 1600-2000 piksel genişlikte ve PNG formatında.

Üç ayrı sorun var:

Boyut yanlış. Blog kartında görsel 400 piksel genişlikte gösteriliyorsa 1731 piksellik dosya göndermenin anlamı yok.

Format yanlış. PNG kayıpsız sıkıştırma yapar. Ekran görüntüsü, logo, şeffaflık gereken grafik için doğrudur. Fotoğraf için israftır — fotoğrafta kayıpsız sıkıştırmanın getirdiği kalite farkını göz zaten ayırt edemez.

Oran yanlış olabilir. Sosyal paylaşım kartları belirli bir oran bekler; farklı oranda gönderirseniz kenarlardan kırpılır.

Dördüncü bir sorun daha var ve kimse konuşmuyor: fotoğraf makinesinden gelen görsellerde EXIF verisi. Konum bilgisi, cihaz modeli, çekim tarihi. Müşteri fotoğrafı, ürün fotoğrafı ya da ofis fotoğrafı yüklüyorsanız bu veri dosyayla birlikte internete çıkar. Aşağıdaki dönüştürme adımları EXIF'i genelde temizler, ama emin olmak için kontrol edin:

# macOS / Linux, exiftool kuruluysa
exiftool -GPS:all -Model gorsel.jpg

Çıktı boşsa temiz.

Adım 1: doğru ölçü

Her görselin tek bir doğru ölçüsü yok; kullanım yerine göre değişir.

Kullanım	Önerilen ölçü	Neden
og:image / paylaşım kartı	1200 × 630	Platformların beklediği standart
Blog kapak (sayfa içi)	1600 px genişlik	Retina ekranda net, dosya makul
Yazı içi görsel	1200 px genişlik	İçerik kolonundan geniş, fazlası israf
Liste kartı küçük resmi	800 px genişlik	Kartta 400 px gösteriliyorsa 2× yeter
Logo / ikon	SVG	Ölçekten bağımsız, kilobayt seviyesinde

Sosyal paylaşım görselinin (og:image) standardı 1200 × 630 piksel. Facebook, LinkedIn, X, WhatsApp — hepsi bu ölçüyü bekler.

Oranı 1.905. Kaynak görselleriniz farklı orandaysa kırpın, esnetmeyin. Esnetilmiş görsel amatör durur ve içindeki yazı bozulur.

macOS'ta yerleşik sips ile:

# Önce ortadan kırp (1672x941 → 1672x878)
sips -c 878 1672 kapak.png

# Sonra hedef ölçüye küçült
sips -z 630 1200 kapak.png

sips -c ortadan kırpar; kırpma noktasını seçemezsiniz. Ana özne ortada değilse ImageMagick ile konum belirtin:

magick kapak.png -gravity north -crop 1672x878+0+0 +repage -resize 1200x630 kapak-og.jpg

-gravity north üstten kırpar — yazı üstteyse doğru seçim. +repage unutulmasın; kırpma sonrası kalan sanal tuvali temizler, yoksa bazı araçlar orijinal ölçüyü okumaya devam eder.

Kırpma sırasında dikkat: yazı ya da ana özne kenara yakınsa kesilebilir. Kırpmadan önce görsele bakın.

Adım 2: doğru format

Fotoğrafik içerik için JPEG. Kalite %80-85 aralığı, gözle ayırt edilemeyen kayıpla en iyi dengeyi verir.

sips -s format jpeg -s formatOptions 82 kapak.png --out kapak.jpg

Bizim sonuçlarımız:

Dosya	PNG	JPEG	Kazanç
Çakışan yapısal veri	852 KB	96 KB	%88
ChatGPT okumuyor	788 KB	68 KB	%91
CDN önbellek	1088 KB	192 KB	%82
Paylaşımlı hosting	1248 KB	272 KB	%78

Küçülme oranı görselin içeriğine göre değişiyor: düz renkli, az detaylı görseller daha çok küçülüyor.

Format seçimini basit bir kurala indirgeyebilirsiniz:

İçerik	Format	Sebep
Fotoğraf, illüstrasyon	JPEG (veya sayfa içinde WebP)	Kayıplı sıkıştırma fotoğrafta görünmez
Ekran görüntüsü, arayüz	PNG veya WebP	Keskin kenarlar JPEG'de bulanır
Logo, ikon, diyagram	SVG	Vektör, her ölçüde net, çok küçük
Şeffaflık gerekiyor	PNG veya WebP	JPEG şeffaflık desteklemez
Animasyon	Video (mp4/webm)	GIF'ten onlarca kat küçük

Son satır sık atlanıyor: bir GIF genelde aynı içeriğin mp4 halinden 5-10 kat büyüktür. Animasyonlu bir ekran kaydını GIF olarak yüklemek, sayfanıza megabaytlarca yük bindirmenin en kolay yolu.

WebP daha da küçük olurdu ama og:image için JPEG daha güvenli. Sebebi bir sonraki bölümde.

Toplu dönüştürme yapıyorsanız tek satırda halledin:

for f in *.png; do
  sips -s format jpeg -s formatOptions 82 "$f" --out "${f%.png}.jpg"
done
ls -lh *.jpg | awk '{print $5, $9}'

Son satır sonuçları listeler — 200 KB'ı geçen dosya varsa tekrar bakın.

Dosya adı ve alt metin

Optimizasyon sadece bayt meselesi değil. İki alan, arama görünürlüğüne doğrudan etki ediyor ve ikisi de bedava.

Dosya adı açıklayıcı olsun. IMG_4821.jpg hiçbir şey söylemez; cdn-onbellek-eski-icerik.jpg söyler. Türkçe karakter ve boşluk kullanmayın — ö, ç, ı bazı sunucularda kodlama sorunu çıkarır, boşluk %20'ye dönüşür.

Alt metin görselin içeriğini anlatsın, anahtar kelime listesi olmasın. İki işi birden yapar: ekran okuyucu kullanan ziyaretçiye görseli tarif eder, arama motoruna bağlam verir.

![CDN düğümlerinin farklı sürümleri sunmasını gösteren üç gazete kutusu](/images/blog/cdn-eski-icerik-inline-1.jpg)

Yanlış kullanım şöyle görünür: ![cdn önbellek temizleme, cdn cache, hosting, seo](...). Bu, kimseye fayda sağlamayan ve spam olarak okunabilen bir alan doldurmadır.

Süs amaçlı, bilgi taşımayan görsellerde alt metni boş bırakmak (alt="") doğru davranıştır — ekran okuyucu o görseli atlar. Ama markdown'da yazdığınız her görselin bir anlamı olmalı zaten; boş alt metne ihtiyaç duyuyorsanız o görsel içerikte ne arıyor sorusunu sorun.

Adım 3: og:image doğrudan çekilir

Bu, en sık atlanan nokta.

Next.js kullanıyorsanız <Image> bileşeni görselleri otomatik optimize eder: boyutlandırır, WebP'ye çevirir, tarayıcıya uygun sürümü gönderir. Bizim 92 KB'lık dosyamız sayfada 33 KB olarak sunuluyor.

Ama og:image bu yoldan geçmez.

LinkedIn, WhatsApp ya da X bir bağlantıyı önizlerken sizin sayfanızı ziyaret eder, og:image etiketindeki adresi okur ve o dosyayı doğrudan indirir. Next'in optimizasyon katmanına uğramaz.

Yani sayfada 33 KB olarak görünen görsel, sosyal önizlemede 92 KB'lık ham dosya olarak iner. Kaynak dosya 2 MB olsaydı, her paylaşımda 2 MB inecekti.

Bu yüzden kaynak dosyanın kendisi de optimize olmalı — sadece framework'ün optimizasyonuna güvenmek yetmez.

WebP'yi og:image için önermememizin sebebi de bu: bazı eski önizleme botları WebP'yi çözemez ve görselsiz kart gösterir. JPEG her yerde çalışır.

Bir de mutlak URL kuralı var: og:image göreli yol kabul etmez.

<!-- Yanlış -->
<meta property="og:image" content="/images/blog/kapak.jpg">
<!-- Doğru -->
<meta property="og:image" content="https://siteniz.com/images/blog/kapak.jpg">

Göreli yol yazdığınızda bazı platformlar görseli hiç bulamaz, bazıları kendi alan adında arar. İkisi de boş kart demek.

Adım 4: yükledikten sonra doğrulayın

Görselin gerçekten sunulduğunu kontrol edin:

curl -s -o /dev/null -w '%{http_code} %{size_download} bayt\n' \
  https://siteniz.com/images/blog/kapak.jpg

Sonra og:image etiketinin doğru adresi gösterdiğini ve o adresin çalıştığını:

og=$(curl -s https://siteniz.com/blog/yazi \
     | grep -oE 'property="og:image" content="[^"]*' | sed 's/.*content="//')
echo "$og"
curl -s -o /dev/null -w '%{http_code}\n' "$og"

404 alıyorsanız sosyal paylaşımlarınız görselsiz çıkıyor demektir — ve bunu kimse size söylemez.

Sitenizdeki tüm blog yazılarını tek seferde tarayın:

curl -s https://siteniz.com/sitemap.xml \
  | grep -oE 'https://[^<]*/blog/[^<]+' \
  | while read u; do
      og=$(curl -s "$u" | grep -oE 'og:image" content="[^"]*' | sed 's/.*content="//')
      kod=$(curl -s -o /dev/null -w '%{http_code}' "$og")
      [ "$kod" != "200" ] && echo "$kod  $u"
    done

Çıktı boşsa hepsi çalışıyor. Bir de içerik türünü kontrol edin — sunucu görseli text/html olarak veriyorsa (404 sayfası dönüyor olabilir) durum kodu 200 çıkar ama görsel yine görünmez:

curl -sI "$og" | grep -i content-type
# beklenen: image/jpeg

Bizim düştüğümüz tuzak

Görselleri sunucuya yükledik, veritabanını güncelledik, uygulamayı yeniden başlattık. Görseller hâlâ 404 veriyordu.

Sebep: Next'in standalone çıktısı kendi public/ kopyasını taşır. Biz dosyaları kaynak klasördeki public/ içine koymuştuk, ama uygulama .next/standalone/public/ altından sunuyordu.

# Yanlış — çalışan uygulama burayı görmüyor
cp gorseller/*.jpg surum/public/images/blog/

# Doğru — standalone kopyasına da girmeli
cp gorseller/*.jpg surum/.next/standalone/public/images/blog/

Dağıtım betiğiniz cp -r public .next/standalone/ yapıyorsa bu sorun çıkmaz. Elle dosya kopyalarken çıkar.

İkinci bir tuzak daha yaşadık ve bu daha pahalıya mal oldu: bir seed betiği, dosyası olmayan yollara coverImage yazdı ve altı yazının kapağı bir anda kırıldı. Ders şu: veritabanına görsel yolu yazan her betik, dosyanın gerçekten var olduğunu kontrol etmeli. Bizim şimdiki betiklerimizde kapak alanı yalnızca elimizde gerçek dosya varsa yazılıyor; yoksa alan hiç gönderilmiyor ve mevcut değerin üstüne yazılmıyor.

Görsel yavaşlığı: bizim on kat farkımız

Görsel optimizasyonu yalnızca dosya boyutu değil, sunucu işlem yükü meselesi de.

Blog liste sayfamız sunucu tarafında 9-15 saniye sürüyordu. Sebep: dokuz adet 1024×1024 boyutunda, yaklaşık 1 MB'lık PNG'nin her istekte AVIF formatına dönüştürülmesi. AVIF kodlaması WebP'nin on ila yirmi katı işlem gücü istiyor.

AVIF'i kapatıp WebP'de bırakınca aynı sayfa 1,1-2 saniyeye indi. Yaklaşık on kat.

Buradan çıkan iki ders var:

Kaynak dosyayı küçültmek, framework'e iş bıraktığınızda bile önemli. 1 MB'lık PNG'yi dönüştürmek pahalı; 150 KB'lık bir JPEG'i dönüştürmek ucuz.

En yeni format her zaman en iyi seçim değil. AVIF gerçekten daha küçük dosya üretir, ama üretim maliyetini kim ödüyor sorusunu sormadan açmayın. Görselleri build sırasında bir kez dönüştürüyorsanız AVIF mantıklı; her istekte dönüştürüyorsanız değil.

Yavaş yanıt süresinin arama ve yapay zeka görünürlüğüne etkisini ChatGPT sitenizi neden okumuyor listesinin yedinci maddesinde ayrıca ele aldık.

Hangi görsel gecikmeli yüklenmeli

Modern tarayıcılarda loading="lazy" varsayılan gibi kullanılıyor ama bir istisnası var: ekranın ilk görünen alanındaki görsel asla lazy olmamalı.

Sayfanın en büyük görseli genelde LCP (Largest Contentful Paint) öğesidir — yani Core Web Vitals ölçümünde "sayfa yüklendi" sayılan an, o görselin gelmesiyle belirlenir. Onu geciktirirseniz kendi performans puanınızı kendiniz düşürürsünüz.

Kural basit: kapak görseli öncelikli, gerisi lazy. Next.js'te bu priority ile yapılıyor:

<Image src={post.coverImage} alt={post.title} fill priority />

Sayfada birden fazla görsele priority vermek de yanlış — o zaman hiçbiri öncelikli olmaz. Sayfa başına bir tane.

Bir de yer değişimini (CLS) engelleyin: görselin width ve height değerleri baştan belli olmalı ki tarayıcı yer ayırsın. Ölçü verilmediğinde görsel yüklenince metin aşağı kayar, ziyaretçi okuduğu satırı kaybeder.

Hangi araçla yapmalı

Dört seçenek var ve hepsinin yeri farklı.

sips (macOS'ta yerleşik). Kurulum gerektirmez, tek dosya ve küçük partiler için yeterli. Kırpma noktasını seçemezsiniz.

ImageMagick (magick). Her platformda çalışır, kırpma konumu, toplu işlem, kalite ayarı — hepsini verir. Sunucuda otomatik hat kuracaksanız doğru seçim.

magick kapak.png -resize 1200x630^ -gravity center -extent 1200x630 -quality 82 kapak.jpg

Bu tek satır oranı koruyarak ölçekler, ortadan kırpar ve kaliteyi ayarlar. ^ işareti önemli: onsuz ImageMagick görseli esnetir.

cwebp / avifenc. Sayfa içi görselleri elle WebP'ye çevirmek isterseniz. Framework'ünüz zaten yapıyorsa gereksiz.

Tarayıcı tabanlı araçlar. Tek seferlik işler için pratik; ama dosyayı bir üçüncü tarafa yüklediğinizi unutmayın. Müşteri fotoğrafı ya da henüz yayınlanmamış görsel için kullanmayın.

Otomatikleştirmenin doğru yeri yükleme anı: görsel sisteme girerken bir kez işlensin, her istekte değil. Bunu yaptığınızda hem sunucu yükü sabit kalır hem de kimsenin elle küçültmeyi unutma ihtimali kalmaz.

Görsel yoksa ne olmalı

Bir kapak görseli hazır değilse olmayan dosyaya işaret etmeyin. Bu iki sorun birden yaratır: sayfada kırık görsel ve 404 veren og:image.

Doğrusu alanı boş bırakmak ve arayüzde bir yer tutucu göstermek:

{post.coverImage ? (
  <Image src={post.coverImage} alt={post.title} fill />
) : (
  <div className="grid place-items-center bg-gradient-to-br from-slate-100 to-slate-200">
    <ImageIcon className="w-8 h-8 text-slate-300" />
  </div>
)}

og:image için de yedek verin — kapak yoksa sitenin genel paylaşım görseli kullanılsın. Görselsiz kart, kırık görselli karttan iyidir ama yedekli kart ikisinden de iyidir.

Sık yapılan altı hata

1. Ham üretici çıktısını doğrudan yüklemek. Yazının tamamı bu maddenin etrafında.

2. Ekran görüntüsünü JPEG yapmak. Keskin kenarlar ve yazılar bulanır. Ekran görüntüsü PNG ya da WebP olmalı.

3. Aynı görseli her yerde tek ölçüde kullanmak. Kart için 1600 px göndermek, mobilde boşuna indirilen bir megabayt demek.

4. og:image'i göreli yol yazmak. Kart boş çıkar.

5. Kapak görseline loading="lazy" vermek. LCP puanını düşürür.

6. Görselleri sürüm kontrolüne alıp CDN'e hiç koymamak. Küçük sitede sorun değil ama görsel sayısı arttıkça depo şişer ve dağıtım yavaşlar.

Kontrol listesi

• og:image 1200 × 630 ve JPEG
• og:image mutlak URL ile yazılmış
• Sayfa içi görseller kullanım genişliğinin en fazla iki katı
• Dosya adları açıklayıcı, Türkçe karakter ve boşluk içermiyor
• Her görselde anlamlı alt metin var
• Kapak görseli priority, diğerleri lazy
• Görsellerin width/height değerleri belli (CLS yok)
• EXIF konum verisi temizlenmiş
• Yüklenen her görsel 200 ve image/* içerik türüyle dönüyor
• Kapağı olmayan yazı için yer tutucu ve yedek og:image var

Özet

Üretilen görseli doğrudan yüklemeyin. Üç adım, toplam bir dakika:

1. 1200 × 630'a getirin — kırparak, esnetmeden
2. JPEG'e çevirin — %82 kalite, fotoğraf için yeterli
3. Yükleyip doğrulayın — hem dosya hem og:image adresi 200 dönmeli

Altı görselde 5 MB'lık fark, mobilde paylaşım önizlemesinin anında açılmasıyla iki saniye beklemek arasındaki fark demek.

Görsel ağırlığının en çok can yaktığı yer ilan ve ürün siteleri: yüzlerce fotoğrafın olduğu bir emlak portföyünde bu iş elle yapılamaz, yükleme sırasında otomatikleşmesi gerekir — emlak programı seçerken bakılacak maddelerden biri de bu. Aynısı ürün fotoğrafları için geçerli; e-ticaret sitesi kurulumunda görsel işleme hattı baştan kurulmalı.

Optimize edilmiş görsellerin dağıtımdan sonra da güncel gelmesi ayrı bir konu — CDN eski kopyayı sunuyorsa yaptığınız iş görünmez. Onu CDN önbelleği yazısında anlattık. Bu işlerin bir proje bütçesinde nereye düştüğünü ise web sitesi fiyatları yazısında ayırdık.