Görselleri web için iyileştirmek
Bir görseli iyileştirmek üç iştir ve önem sırası şudur: gerçekten gösterilen boyuta küçültmek, modern bir formatta göndermek ve ölçülerini HTML'de açıkça bildirmek. Hiçbir şey kazandırmayan bir görseli ise hiç göndermemek daha iyidir; o, üçünden de önce gelir.
- Ders 5 / 10
- Başlangıç
- Ücretsiz, kayıt yok
Aynı görsel, kamera dosyasından ziyaretçiye ulaşana kadar
Bel, kararların alındığı yerdir; bir kez doğru yapılırsa sonraki her ziyaretçi kazanır.
Elinizdeki
- kamera dosyası ya da tasarım çıktısı, birkaç megabayt
- gösterileceği yerin birkaç katı genişlik
- fazladan kamera verisi ve konum koordinatları
Ziyaretçiye ulaşan
- gerçekten gösterildiği genişlikte bir dosya
- gözün ayırt edemeyeceği bir kalitede modern format
- HTML'de açık ölçüler, dolayısıyla düzen kayması yok
- ilki hariç her görsel için tembel yükleme
Bu şekil işin sırasını gösterir, tasarrufun büyüklüğünü değil. O, görselin kendisine bağlıdır: düz gökyüzü olan bir fotoğraf çok daha iyi, küçük yazılarla dolu bir ekran görüntüsü çok daha kötü sıkışır.
Son kontrol: Bu dersteki bilgiler ve araç adları bu tarihte kaynaklarıyla yeniden doğrulanır.
Herhangi bir araçtan önce görselin kendisine sorun
En hafif görsel, hiç gönderilmeyendir. Bu bir slogan değil, her sıkıştırmadan önce işleyen bir çalışma kuralıdır ve uygulaması basittir: sayfadaki her görsele bakın ve o olmasaydı okurun ne kaybedeceğini sorun.
Üç görsel ailesi bu testte genelde kalır. Birincisi dekoratif olanlar: toplantı masasında gülümseyen insanların fotoğrafı, süs ikonlar, yalnızca başlığı tekrarlayan yazı üstü afiş. İkincisi görsel olmayıp görsel olarak kaydedilenler: grafikler, tablolar, infografikler, ikonlar. Üçüncüsü yalnızca metnin zaten söylediğini kanıtlamak için var olan ekran görüntüleri.
İkinci aile en önemlisidir, çünkü en çok baytı yer ve en kolay karşılığı vardır. PNG olarak kaydedilmiş bir çubuk grafik ağırdır, telefonda okunmaz ve metnini hiçbir arama motoru okumaz. Aynı grafik HTML ve CSS ile birkaç yüz bayttır, her boyutta okunur kalır ve metni seçilebilir ve çevrilebilir. İkonlar da aynı hikâye: satır içi bir SVG küçük bir PNG'den daha hafif çıkar ve rengini temadan alır.
Burada sert bir duruşumuz var ve bedelini de ödüyoruz: bu sitenin ana sayfasının tamamında sıfır img etiketi bulunuyor. Burada infografik gibi görünen her şey HTML ve CSS ile çizilmiştir. Kısıtı da kabul ediyoruz, çünkü bu şekillerin hiçbiri gerçek bir ürünün fotoğrafı olamaz. Bir mağazanız varsa ürün fotoğrafı silinemez ve bu dersin geri kalanı tam olarak onun içindir.
Herhangi bir sıkıştırma aracını açmadan önce yanıtlanacak soru
Bu görselin görsel olması gerekiyor mu?
HTML ve CSS ile çizin
- grafikler, tablolar ve infografikler; metni de okunur
- ikonlar; satır içi bir SVG küçük bir PNG'den hafiftir
- dekoratif bir fotoğraf; silin, hiçbir şey kaybolmaz
O hâlde düzgün gönderin
- orijinal boyutta değil, gösterildiği boyutta
- modern bir formatta, kendi denediğiniz bir kalitede
- HTML'de açık ölçülerle ve aşağıdaki her şey için tembel yüklemeyle
Sağdaki dal her şeyi silmez. Bir ürün fotoğrafı, tamamlanmış bir işin gerçek fotoğrafı ve bir ölçümün ekran görüntüsü gerçek içeriktir ve kalır.
Yüklediğiniz boyut değil, gerçek boyut
Site görsellerinde en yaygın hata, kamera dosyasını ya da Photoshop çıktısını doğrudan yükleyip sonra CSS ile küçük göstermektir. Tarayıcı dosyanın tamamını indirir ve sonra küçültür. Yani ziyaretçi hiç görmeyeceği her bayta para ödemiştir.
Doğru iş iki adımdır. Önce görselin gerçekte hangi boyutta gösterildiğini bulun: sayfayı tarayıcıda açın, görsele sağ tıklayıp inceleyin ve öğenin gerçek genişliğini okuyun. Sonra dosyayı o boyutta üretin, yüksek yoğunluklu ekranlar için genelde iki katında. Temanızda bir görsel her zaman 400 piksel genişlikte gösteriliyorsa 800 piksellik bir dosya yeterlidir; 3000 piksellik dosya yalnızca ziyaretçinin veri kotasını yakar.
WordPress'te bu epeyce otomatiktir: her yükleme birkaç boyut üretir ve tema en uygununu srcset ile tarayıcıya verir. Ancak zincirin kırıldığı iki yer var ve ikisi de yaygın. Birincisi, metnin içine orijinal dosyanın adresiyle bırakılan ve mekanizmanın tamamını atlayan bir görsel. İkincisi, ölçüleri üretilen bütün boyutları aşan bir görsel; örneğin hiç ara boyut üretilmemiş 4000 piksellik bir fotoğraf.
Format ve sıkıştırma, gerçek sayılarla
Bu tartışmayı zevk alanından çıkarmak için bu sunucudan gerçek bir dosya alıp iki genişlikte ve üç formatta ürettik. Orijinal, yüklendiği hâliyle 57,8 kilobayt ağırlığında 1200 x 630 bir paylaşım kapağı. ImageMagick ile, JPEG ve WebP için kalite 78 ve AVIF için kalite 55 kullanıldığında tablo şu:
| Format | 1200 genişlikte | 800 genişlikte |
|---|---|---|
| JPEG | 47,2 KB | 23,5 KB |
| WebP | 20,9 KB | 11,7 KB |
| AVIF | 14,6 KB | 8,3 KB |
Buradan iki şey çıkar. Birincisi, iki hamle de işe yarar ve biri diğerinin yerini tutmaz: aynı genişlikte format değiştirmek ağırlığı kabaca yarıya indirir, genişliği yarıya indirmek ise onu bir kez daha kabaca yarıya indirir. İkincisi, ikisini birlikte yapmak o 57,8 kilobaytlık dosyayı 11,7 kilobayta, yani yaklaşık beşte birine indirdi ve gözle görülür bir fark kalmadı.
Gerekli bir uyarı: bu sayılar tek bir görsele ait. Düz gökyüzü olan bir fotoğraf çok daha iyi sıkışır, küçük yazılarla dolu bir ekran görüntüsü çok daha kötü; kayıplı sıkıştırmada ilk dağılan şey küçük yazıdır. Formatların kendi karşılaştırması ve hangisinin nereye uyduğu görsel formatları dersinde açıldı; burada yalnızca ağırlığa etkileri önemli.
Bu çıktıları üreten komut tek satırdır ve bir klasörün tamamında da çalışır:
for f in *.jpg; do convert "$f" -resize '800x>' -strip -quality 78 "${f%.jpg}.webp"; doneBu komutta üç şey bilinçlidir. Genişlikten sonraki büyüktür işareti, yalnızca daha büyük görsellerin küçültülmesi, küçük olanın büyütülmemesi demektir; o olmazsa komut küçük dosyalarınızı şişirir. strip, kamera modeli ve GPS koordinatları gibi fazladan veriyi siler; bu hem bayttır hem de bazen yayımlamayı düşünmediğiniz bilgidir. Kalite 78 ise bir kanun değil başlangıç noktasıdır; kendi görsellerinizde birkaç değer deneyin.
Hangi görsel tembel yüklenmemeli
Tembel yükleme, tarayıcının henüz görüntü alanına yakın olmayan bir görseli indirmemesi demektir. Tek bir HTML özniteliğiyle açılır ve onlarca görseli olan bir sayfada büyük bir kazançtır.
Ve en yaygın hız hatası tam burada olur: biri her şeyi tembel yükleyen bir eklenti kurar, sayfanın tepesindeki büyük görsel dahil. Şimdi tarayıcı, ilk gelmesi gereken görseli bilerek geciktirir ve LCP iyileşmek yerine kötüleşir. Google belgeleri açıktır: sayfa yüklenirken görüntü alanında olması muhtemel görselleri, özellikle de LCP görsellerini tembel yüklemeyin.
Bundan çıkan kural basittir. Kullanıcının kaydırmadan gördüğü hiçbir görsel tembel olmaz. Onun altındaki her şey olur. O üstteki görsel için fazladan bir adım daha var: bir getirme önceliği özniteliğiyle tarayıcıya bunun diğerlerinden önemli olduğunu söyleyebilirsiniz. Tembeli yüksek öncelikle birleştirmek ise işe yaramaz; Google belgeleri, böyle bir görselin ekran dışındayken yine geciktirileceğini ve sonra yüksek öncelikle getirileceğini söyler ki istediğiniz bu değildi.
Kontrolü elle yapılır ve bir dakika sürer: sayfayı açın, kaynağı görüntüleyin ve ilk büyük görselde tembel özniteliğini arayın. Oradaysa bulmuşsunuz demektir.
Açık ölçüler ve bizim düştüğümüz tuzak
Son kural en basiti ve en çok göz ardı edileni: her görsel etiketinin kendi gerçek width ve height değerleri olmalı. Bunlar olmadan tarayıcı ne kadar yer bırakacağını bilmez, metni dizer ve görsel geldiğinde her şeyi aşağı iter. CLS'de sayılan kayma budur.
Bu iki öznitelikle tarayıcı en boy oranını onlardan hesaplar ve yeri önceden ayırır. Yani CSS'iniz görseli akışkan yapsa bile ayrılan yer doğrudur ve kayma olmaz. Bir sitenin hem CLS'sinin sıfır olmasını hem de duyarlı görseller taşımasını sağlayan şey budur.
Ve şimdi bizim düştüğümüz tuzak, çünkü hiçbir eğitim bunu yazmıyor. Neredeyse her duyarlı site, görsel yüksekliğini otomatik yapan genel bir kural taşır; bu sitenin ana stil dosyası da tam olarak o kuralı taşıyor. Kaymayı önlemek açısından bu doğru ve sorunsuzdur. Ama yanlış anda pahalıya patlayan başka bir anlamı daha var: bir yerde genişliği CSS'ten verir ve yüksekliği HTML özniteliğine bırakırsanız, o genel kural kazanır ve kutu dosyanın kendi doğal oranına çöker. Bizde bu, serbest çalışanlar sayfasındaki avatarlarda oldu: daire olması gereken kutular oval çıktı ve en kötüsü aslında uzun bir telefon ekran görüntüsü olan bir fotoğraftı. Doğru çözüm, şekli CSS'in sahiplenmesidir: genişliği de yüksekliği de kendisi verir ve kırpmayı object-fit ile belirler. HTML öznitelikleri yer ayırmak içindir, kutu şekillendirmek için değil.
Olması gereken dört şey ve olmaması gereken dört şey
Olmalı
- dosya genişliği gerçekte gösterilen genişliğe yakın
- kendi denediğiniz bir kalitede modern format
- her görsel etiketinde açık width ve height
- sayfanın üstündeki ilk görsel, tembel yükleme olmadan
Olmamalı
- olduğu gibi yüklenip CSS ile küçültülen kamera dosyası
- resim olarak kaydedilmiş bir grafik ya da tablo
- istisnasız her görseli tembel yükleyen bir eklenti
- HTML özniteliğine bırakılıp sonra CSS'in kazandığı bir yükseklik
Üstteki sütunun son satırı, hiçbir otomatik aracın sizin yerinize yapamayacağı tek maddedir, çünkü hangi görselin önce görüldüğünü yalnızca siz bilirsiniz.
Yapay zekayla hızlı yol
Alışılmış yol, görselleri tek tek bir çevrimiçi hizmete yükleyip çıktıyı indirmektir. Bu beş görsel için işe yarar, iki yüz için yaramaz. Hızlı yol, çoğu kişinin yapmadığı zihinsel bir kayma gerektirir: modelden görsellerinizi iyileştirmesini istemeyin, bunu yapan komutu yazmasını isteyin. Model araç değil, araç yapıcısıdır. Ortaya çıkan şey, aynı gün iki yüz görsel üzerinde çalışan ve bir dahaki sefere de işe yarayan bir betiktir.
- Önce tahmin etmek yerine klasörün gerçeğini öğrenin. Kaç dosyanız olduğunu, hangilerinin en büyük olduğunu ve ölçülerini bir kez listeleyin. Klasör ağırlığının yarısının beş dosyada olduğu çıkarsa, işin tamamı o beş dosyadır ve gerisi zaman kaybıdır.
- Komutu modelden isteyin ve koşulları kendiniz koyun. Burada hızlı ve ucuz sınıf yeter; bir kabuk döngüsü yazmak yargı işi değildir. Ama ucuz bir model bile parametre uydurur, o yüzden koşullar isteğin içinde olmalı: büyütme, orijinalleri silme ve her bayrağın ne yaptığını söyle. Her sınıftaki güncel tercih yapay zekâ referansımızda tutulur.
- Gerçek klasörde çalıştırmadan önce üç dosyada deneyin ve çıktıya gözünüzle bakın. Yalnızca daha küçük bir sayı başarı değildir; görselin içindeki küçük yazı bulaşmışsa ya da kenarlar yumuşamışsa kaliteyi yükseltip yeniden alın. Bu, hiçbir otomatik aracın yerini alamayacağı tek adımdır.
- Dönüştürmeden sonra kalan kısmı unutmayın: sitedeki adresler yeni dosyaları göstermeli ve her görsel etiketinin kendi açık ölçüleri olmalı. Adresleri güncellemeden dosyaları dönüştürmek, kimsenin görmediği hafif dosyalarla dolu bir klasör demektir.
Kopyalamaya hazır şablon
Bana bir görsel klasörünü web için hazırlayan bir komut satırı yaz. Komutu ben çalıştıracağım, yani işin onu yazmak, yapmak değil.
Durumum:
İşletim sistemi: {Linux | Mac | Windows}
Kurulu araçlarım: {ImageMagick | ffmpeg | hiçbiri, neyin gerektiğini söyle}
Klasör: {yol}, yaklaşık {sayı} dosya, uzantı {jpg | png | ikisi}
Bu görsellerin sitede gösterildiği en büyük genişlik: {sayı} piksel
Koşullar, hepsi zorunlu:
1. Bu genişlikten küçük bir görsel büyütülmemeli.
2. Orijinal dosyalar silinmemeli ya da üzerine yazılmamalı; çıktı ayrı bir klasöre.
3. Kamera modeli ve konum koordinatları gibi fazladan veri silinmeli.
4. Çıktı dosya adları girdi adlarından üretilmeli; boşluklar ve Latin olmayan karakterler onları bozmamalı.
5. Bir dosya bozuksa döngü durmamalı; adını yazdır.
Komuttan sonra şu üç şeyi yaz:
1. Her bayrağın yanına tam olarak ne yaptığını söyleyen bir satır.
2. Yalnızca ilk üç dosyada çalışan bir deneme sürümü.
3. Dönüştürmeden sonra önceki ve sonraki boyutları yan yana yazdıran ayrı bir komut.
Kurallar: aracın o sürümünde var olduğundan emin olmadığın hiçbir bayrağı yazma; emin değilsen bunu söyle ve güvenli alternatifi ver. Hiçbir tasarruf rakamı vaat etme, çünkü bu görsellerin kendisine bağlıdır. Adını verdiğim araç bu iş için uygun değilse bunu söyle ve gerçekten gerekmedikçe bende olmayan bir şeyi kurmamı isteme.Çıktıya güvenmeden önce: Buradaki asıl tehlike uydurulmuş bayraklardır. Model bu araçların komut örüntüsünü görmüştür ve var olmayan ya da sizin sürümünüzde başka bir şey yapan bir bayrak yazabilir; komut ya hata verir ya da sessizce sandığınızdan başka bir şey yapar. Bu yüzden gerçek klasörde çalıştırmadan önce deneme sürümünü üç dosyada çalıştırın ve çıktıya gözünüzle bakın; tanımadığınız bir bayrak varsa aracın kendi kılavuzunda arayın. Ve asla atlanmaması gereken bir adım: her çalıştırmadan önce orijinal klasörün bir yedeği.
Bu işte yapay zeka
Buradaki duruşumuz beklenenin tersi: görsel iyileştirmede yapay zekânın en iyi kullanımı, görsellere hiç dokunmamasıdır. Gerçekten iyi yaptığı şey komutu yazmak, bayrakları açıklamak ve site şablonunu incelemektir. Zayıf olduğu şey, görselin kendisini web için üretmek ya da yeniden kurmaktır; orada kalite öngörülemez ve ayrıca bir iz bırakır, bir sonraki bölüm de onunla ilgili.
Gerçekten işe yarayan araçlar
- Claude Buradaki hızlı yol işine uygundur: toplu komutu yazar, bayrakları açıklar ve üç dosyalık deneme sürümünü de kurar. İran, Anthropic'in desteklenen ülkeler listesinde değil; dolayısıyla resmi kayıt da yok, İran kartı da kabul edilmiyor.
- Gemini Sayfanın kendisine bakmak için işe yarar: bir ekran görüntüsü verip hangi görselin önce görüldüğünü ve hangilerinin katlama çizgisinin altında kaldığını sorun. Bu tek yanıt, hangi görselin tembel yüklenmemesi gerektiğini çözer. Google'ın kendi sayfası, Gemini web uygulamasının 230'dan fazla ülke ve bölgede çalıştığını söylüyor ve İran o listede yok.
- ChatGPT Komutu yazmak ve açıklamak için yeterli. İran'dan erişim konusunda bir iddiada bulunmuyoruz, çünkü OpenAI'nin desteklenen ülkeler sayfası, o alan adının geri kalanı gibi, bu sunucuya 403 döndürüyor.
Nerede geri teper
İki risk var ve ikincisi özellikle bu derse ait. Birincisi uydurulmuş bayraklar: model ImageMagick ve ffmpeg komutlarının örüntüsünü görmüştür ve var olmayan ya da sizin sürümünüzde başka anlama gelen bir bayrak yazabilir. Bir görsel klasöründe, orijinallerin üzerine yazdıysanız bu hata geri alınamaz; yani yedek son adım değil ilk adımdır. İkinci risk aynı işin başka bir köşesinde durur: iyileştirdiğiniz görseller kendileri yapay zekâyla üretilmişse, onlarla birlikte göremediğiniz bir şey yolculuk ediyor olabilir. Google DeepMind'ın SynthID adlı bir aracı, Google görsel modellerinin çıktısına algılanamayan bir dijital filigran gömer ve Google bunu sonradan tespit edebilir. Yani çok sayıda üretilmiş görsel yayımlayan bir site, o modelin sahibi için tanınabilir hâle gelir ve sıkıştırma ile yeniden boyutlandırma bunu kaldırmak için tasarlanmamıştır. Duruşumuz basit: komutu model yazsın, siz çalıştırın ve çıktıya bakın. Görselin kendisinin yapay zekâyla üretilmesini istiyorsanız o başka bir tartışmadır ve yapay zekâ görsellerindeki gizli işaretler dersinde açılmıştır.
Kaynaklar: Google DeepMind: SynthID Anthropic: supported countries Google: where Gemini Apps are available
Bu tavsiyenin sınırı
Bu ders görselleri göndermekle ilgilidir, onları yapmakla değil; renk seçimi, kompozisyon ve hangi fotoğrafın doğru olduğu bu sayfanın işi değil. Üç sınırı daha var. Birincisi, tablodaki sayılar tek bir gerçek görselden geliyor ve sizinkilerde farklı olacak; güvenilecek tek sayı, kendi dosyalarınızda kendinizin ölçtüğüdür. İkincisi, modern format tavsiyesinin bir istisnası var: kitleniz çok eski tarayıcılardaysa bir yedek de göndermeniz gerekir ve o zaman tek dosya değil iki dosya tutuyorsunuz demektir. Üçüncüsü, deneyimimiz orta ölçekli İran kurumsal ve mağaza sitelerinden geliyor; on binlerce fotoğrafı olan galerilerde görsel yönetimi bir komut değil bir sistemdir ve o ölçekte birinci elden deneyimimiz yok.
Kendi işimizden
Açık ölçüler hakkında öğrendiğimiz en önemli şeyi kendi hatamızdan öğrendik ve bunu hiçbir eğitimde görmedik. Bu sitenin ana stil dosyasının 68. satırı, her görsel ve videoya en fazla yüzde yüz genişlik ve otomatik yükseklik söyleyen genel bir kural taşır. O kural doğrudur ve yer ayırmayı da bozmaz, çünkü tarayıcı oranı width ve height özniteliklerinden hesaplar. Ama ikinci bir anlamı vardır: CSS'in yalnızca genişlik verdiği ve yüksekliği HTML özniteliğine bıraktığı her yerde o genel kural kazanır ve kutu dosyanın kendi doğal oranına çöker. 28 Ağustos 2026'da tam olarak bu, serbest çalışanlar sayfasındaki avatarlarda oldu: daire olması gereken kutular oval çıktı ve en kötüsü aslında uzun bir telefon ekran görüntüsü olan bir görseldi. Doğru çözüm HTML'e daha fazla öznitelik eklemek de değildi; şekli CSS'in sahiplenmesiydi, yani avatar sınıfı kendi genişliğini ve yüksekliğini verir ve kırpmayı object-fit ile belirler. Bu deneyimin bize maliyeti şu: sabit şekilli bir görsel kutusu kurduğumuz her seferde CSS'te aynı genel kuralı aramamız gerekiyor; bu da iyi bir kuralın iyi olduğu için aldığı bedeldir.
Gerçek devam soruları
Her görseli WebP'ye çevirmeli miyim?
Fotoğraflar için evet ve kazanç kayda değer. Ama formattan önce boyutu düzeltin: bizim ölçümümüzde genişliği yarıya indirmek, format değiştirmek kadar iş gördü. Dosyalarınız en baştan doğru boyutta üretilmişse WebP bir kurtarma değil ek bir kazançtır.
Görsel iyileştirme eklentisi mi kurmalıyım, kendim mi yapmalıyım?
Düzenli içerik yayımlıyorsanız, işi yükleme anında yapan bir eklenti size zaman kazandırır. Ama hiçbir eklentinin sizin yerinize karar vermediği iki şey var: hangi görselin hiç var olmaması gerektiği ve hangi görselin tembel yüklenmemesi gerektiği. Bu ikisi hep size aittir.
Kalite değerini kaç yapmalıyım?
Doğru evrensel bir sayı yok, çünkü görsele bağlı. Bu ders için JPEG ve WebP'de 78'i denedik ve sıradan bir fotoğraf için sonuç iyiydi. Doğru yöntem, kendi gerçek görsellerinizden birkaçında üç değer alıp gözünüzle karşılaştırmaktır; özellikle küçük yazı içeren görsellerde.