Görsel Ağırlıklı Sitelerde Hosting ve WebP/AVIF Stratejisi

Fotoğrafçı portfolyoları, ajans siteleri, online dergiler ve magazin projeleri aynı ortak problemle boğuşur: Görseller çok güzeldir ama teknik tarafta maliyet, hız ve depolama yönetimi sürekli bir baskı oluşturur. Örnek bir proje hedefi şöyle olabilir: “Sitede 50.000 fotoğraf olacak, 4K çözünürlük istiyoruz, dünya çapında hızlı açılsın ama maliyet de makul olsun.” İşte bu üçgeni dengeleyen şey, doğru hosting, disk, CDN ve WebP/AVIF stratejisidir.

Görsel ağırlıklı sitelerde yavaş açılan sayfalar, boşa giden bant genişliği ve dakikalar süren yedekleme süreçleri kader değil. Doğru mimari, fotoğraf kalitesini korurken yükleme sürelerini azaltmaya yardımcı olur; sonuç, sayfa ağırlığına, kullanıcı bağlantısına ve önbellek durumuna bağlıdır. Bu yazıda fotoğrafçı, portfolyo ve magazin siteleri için pratik yaklaşımları ele alacağız: Hangi disk yapısını tercih etmeli, CDN’i nasıl konumlandırmalı, WebP/AVIF dönüşümünü nerede ve nasıl yapmalı, hangi dosyayı nerede saklamalısınız?

Amacımız, teoride güzel ama pratikte işlemesi zor çözümler değil; gerçek dünyada çalışan, yönetilebilir ve ölçeklenebilir bir yol haritası sunmak. Yazının sonunda, kendi görsel ağırlıklı siteniz için net bir mimari taslak ve uygulanabilir bir aksiyon listesine sahip olacaksınız.

Görsel Ağırlıklı Sitelerde Asıl Darboğaz Nerede?

Hazır görsellerin sunumunda CPU her zaman asıl darboğaz değildir; yoğun WebP/AVIF dönüşümünde ise CPU yükü belirleyici olabilir. Depolama ve dağıtım sorunları üç başlıkta toplanabilir:

• Disk alanı: Binlerce yüksek çözünürlüklü fotoğraf, farklı boyutlar ve formatlarla katlanarak artar.
• Disk I/O (okuma/yazma): Aynı anda çok sayıda görsel istenince disk üzerindeki rastgele okuma yoğunluğu artar.
• Bant genişliği ve CDN maliyeti: Trafiğin büyük kısmı görsellerden gelir; iyi yönetilmezse maliyetler hızla yükselir.

Örneğin, 2 MB ortalama boyuta sahip 10.000 fotoğrafınız olduğunu düşünelim. Yalnızca orijinalleri tuttuğunuzu varsayarsak yaklaşık 20 GB depolama alanı yeterli gibi görünebilir. Ancak:

• Her fotoğraf için 3–4 farklı boyut (thumbnail, orta boy, büyük, tam ekran),
• Hem JPEG/PNG hem de WebP/AVIF kopyaları,
• Önbellek, geçici dosyalar, yedekler ve log’lar

devreye girdiğinde toplam ihtiyaç artar; 150–200 GB gibi bir bütçe ancak türev boyutları ve yedek saklama planı hesaplanarak gerekçelendirilebilir. Eşzamanlı galeri istekleri de önbellekten karşılanmıyorsa disk I/O darboğazı oluşturabilir.

Bu nedenle görsel ağırlıklı sitelerde başarı formülü, yalnızca “büyük disk” almak değil; doğru disk türü + akıllı CDN kullanımı + WebP/AVIF ile görüntü optimizasyonu üçlüsünü birlikte kurgulamaktır.

Fotoğrafçı, Portfolyo ve Magazin Siteleri İçin Doğru Hosting Mimarisi

Görsel ağırlıklı projeleri barındırırken mimariyi kabaca üç katmanlı düşünmek gerekir:

• Uygulama katmanı: WordPress, Laravel, özel geliştirilen portfolyo uygulaması vb.
• Medya katmanı: Görsellerin saklandığı disk veya nesne (object) depolama altyapısı.
• Dağıtım katmanı: CDN, cache ve tarayıcıya sunum kuralları.

Planlamaya şu sorularla başlayabilirsiniz:

• Aylık tahmini sayfa görüntüleme sayısı nedir?
• Ortalama görsel boyutu ve toplam fotoğraf adedi ne kadar?
• Kullanıcı kitlesi belirli bir ülkeye mi, yoksa global mi dağılmış?
• Site tek dilli basit bir portfolyo mu, yoksa yüksek trafikli magazin mi?

Bu cevaplara ve ölçülen kaynak ihtiyacına göre değerlendirilebilecek seçenekler:

• Paylaşımlı hosting: Kaynak ve dosya sayısı sınırları yeterli olan portfolyolarda değerlendirilebilir; disk türünü ve dönüşüm araçlarının desteklenmesini seçilecek plandan doğrulayın.
• VPS: İşletim sistemi yönetimi ve özel sunucu ayarları gerekiyorsa bir seçenektir; yönetim sorumluluğunu ve gerçek kaynak tahsisini hesaba katın.
• Dedicated sunucu veya colocation: Ölçülen yük ve yönetim kapasitesi özel donanımı gerekçelendiriyorsa genel mimari seçenekleridir; herhangi bir sağlayıcıda sunulduklarını varsaymayın. Medyayı nesne depolamaya ayırmak da alternatif olabilir.

Yüksek trafikli senaryolarda, veritabanı ve uygulama sunucusunu ayırmaya yönelik stratejileri ayrıntılı olarak ele aldığımız yüksek trafikli haber ve blog siteleri için hosting rehberi görsel ağırlıklı magazin projeleri için de çok faydalıdır.

Paylaşımlı Hosting Ne Zaman Yeterli, Ne Zaman VPS/Dedicated Gerekir?

Aşağıdaki trafik ve arşiv büyüklükleri kesin geçiş eşikleri değil, değerlendirme örnekleridir:

• Aylık 50–100 bin sayfa görüntülemenin altında, görseller ortalama 500–800 KB seviyesinde ise, iyi yapılandırılmış paylaşımlı hosting bir adaydır; yeterlilik, sayfa başına görsel sayısı, önbellek isabeti ve paketin CPU/RAM, I/O, inode ve trafik sınırlarına bağlıdır.
• Günlük binlerce tekil ziyaretçi, yoğun kategori ve galeri dolaşımı varsa, özellikle magazin/haber sitelerinde VPS, özel Nginx/Apache ve PHP-FPM ayarları üzerinde daha fazla kontrol sağlayabilir; önbellek ve CDN ile birlikte değerlendirilmelidir.
• Hem yüksek trafik hem de çok büyük medya arşivi (örneğin 2–5 TB fotoğraf) söz konusuysa, dedicated sunucu veya colocation ile özel disk mimarisi tasarlamak bir seçenektir; medya arşivini nesne depolamaya ayırmak da değerlendirilmelidir.

CPU/RAM boyutlandırması konusunda daha detaylı hesaplama yapmak isterseniz, yeni web sitesi için CPU, RAM ve trafik nasıl hesaplanır rehberindeki yaklaşımı fotoğraf/medya ağırlıklı sitenize uyarlayabilirsiniz.

Disk Stratejisi: NVMe, Kapasite Planlama ve Soğuk Arşiv

Görsel ağırlıklı sitelerde diski üç boyutta değerlendirmelisiniz:

• Disk türü (NVMe, SATA SSD, HDD)
• Kapasite (şu anki kullanım + büyüme hızı)
• Performans (IOPS ve throughput)

Uygulama ve aktif olarak sunulan görseller için NVMe SSD, disk I/O darboğazı varsa yararlı olabilir; her proje için zorunlu değildir. SATA SSD’ye göre daha yüksek IOPS potansiyeli, tek başına belirli sayıda eşzamanlı isteğin karşılanacağını garanti etmez; önbellek, disk paylaşımı ve ağ kapasitesi de sonucu etkiler. Özellikle galeri veya masonry listelemelerde, sayfa açılırken onlarca küçük görsel çağrıldığını unutmayın.

Ne Kadar Disk Alanına İhtiyacınız Var?

Bunu kabaca hesaplamak için şu formülü kullanabilirsiniz:

• Ortalama orijinal görsel boyutu x görsel sayısı = Orijinal arşiv
• Örnek bir bütçe varsayımı: Orijinal arşivin 2–3 katı = Orijinaller + türevler (farklı boyutlar ve formatlar). Gerçek çarpanı örnek görsellerden üretilen türevleri ölçerek belirleyin.
• Bu toplamın üzerine örneğin %20–30 = Log ve geçici dosyalar için pay; yedek alanını saklama süresi, kopya sayısı ve yedekleme yöntemine göre ayrıca hesaplayın.

Örneğin:

• Ortalama 1.5 MB’lık 30.000 fotoğrafınız var: ~45 GB orijinal.
• Orijinaller ve tüm türevlerin toplamını bu örnekte orijinal arşivin 2,5 katı varsayalım: ~112,5 GB.
• Log ve geçici dosyalar için %30 ekleyelim: ~146 GB; yedek alanı buna dahil değildir.

Bu varsayımlarla, büyüme ve yedekler hariç yaklaşık 146 GB gerekir; 150–200 GB başlangıç bütçesi değerlendirilebilir. Diskin NVMe olması gerekip gerekmediği ise kapasiteden ayrı bir performans kararıdır. Büyüme hızınız yüksekse (örneğin her ay 2–3 bin yeni fotoğraf ekleniyorsa), 12–18 aylık projeksiyonla planlamak daha sağlıklı olur.

Sıcak ve Soğuk Depolamayı Ayırmak

Tüm fotoğrafları aynı hızlı NVMe disk üzerinde tutmak zorunda değilsiniz. Özellikle eski çekimler veya nadir görüntülenen arşivler için soğuk depolama stratejisi işinizi oldukça kolaylaştırır:

• Sıcak depolama: Sitede aktif olarak kullanılan, sık görüntülenen görseller. Son 6–12 aylık içerik bir başlangıç örneği olabilir; ayrımı dosya yaşından çok erişim sıklığına göre yapın.
• Soğuk depolama: Nadir gereken eski çekimler, ham (RAW) dosyalar ve arşiv kopyaları. Geri yükleme gerektiren bir katmandaki dosyalar doğrudan web sunumuna uygun değildir; yayındaki görsellerin sunum kopyalarını çevrimiçi tutun. Soğuk arşiv, ayrı yedeklerin yerini almaz.

Sıcak depolama için bir VPS veya dedicated sunucu değerlendirirken seçilen planın disk türünü, kapasitesini, I/O sınırlarını ve yönetim kapsamını doğrulayın. NVMe bir performans seçeneğidir; tüm DCHost ürünlerinde bulunduğu veya her iş yükünü hızlandırdığı varsayılmamalıdır. Seyrek erişilen arşivler için farklı disk ya da nesne depolama katmanı seçilebilir. Erişim ücretlerini, minimum saklama süresini ve geri yükleme gecikmesini hesaba katın; aktif sunum kopyaları çevrimiçi kalmalı, arşivden bağımsız yedek korunmalıdır.

WordPress kullanıyorsanız, medya dosyalarını ayrı bir depolama katmanına taşımanın artılarını ve eksilerini ayrıntılı anlattığımız WordPress medyanı S3’e taşıma rehberi görsel ağırlıklı sitenizi ölçeklerken çok işinize yarayacaktır.

CDN Stratejisi: Medya Trafiğini Edge’e Taşımak

Görsel ağırlıklı sitelerde aktarılan veri hacminin büyük kısmı görsellerden gelebilir; oranı erişim kayıtları veya analiz araçlarıyla ölçmek gerekir. Özellikle yüksek trafikli veya farklı bölgelerden ziyaretçi alan sitelerde CDN, mimarinin önemli bir bileşeni olabilir.

CDN kullanmanın başlıca faydaları:

• Gecikme süresini azaltabilir: Önbellekteki görseller, CDN’in yönlendirdiği uygun edge noktasından sunulur.
• Sunucu yükünü düşürebilir: Önbellek isabetinde görsel origin’den değil, CDN cache’inden sunulur; kaçırma ve yeniden doğrulama durumlarında origin’e istek gidebilir.
• Origin bant genişliği kullanımını azaltabilir: Toplam maliyet için CDN trafik ve istek ücretleri ile origin’den CDN’e aktarım ücretleri birlikte hesaplanmalıdır.

Buradaki kritik nokta, CDN’i sadece “tak kullan” şeklinde değil, doğru cache-control ve varyasyon kurallarıyla yapılandırmaktır. Örneğin:

• Herkese açık, sürümlenmiş görseller için uzun süreli (örneğin 30 gün veya daha uzun) cache-control başlıkları,
• Versiyonlama (dosya adında hash kullanma) ile güncelleme geldiğinde yeni URL kullanma,
• Aynı URL’den “Accept” başlığına göre WebP/AVIF veya JPEG/PNG sunuluyorsa, CDN cache-key içinde seçilen formatı ayırma ve JPEG/PNG dahil tüm ilgili yanıtlarda Vary: Accept gönderme. CDN’e özel anahtar, tarayıcıya ve diğer ara önbelleklere bu bağımlılığı tek başına bildirmez; Vary başlığının CDN üzerinden istemciye ulaştığını da doğrulayın.

CDN tarafında cache-control ve edge kurallarını nasıl kurgulamanız gerektiğini detaylı olarak anlattığımız CDN önbellekleme ve edge kuralları rehberi, görsel ağırlıklı siteler için adeta bir kontrol listesi gibi kullanılabilir.

CDN’in temellerine daha genel bir bakış atmak isterseniz de, CDN nedir ve avantajları nelerdir yazımızdan başlayıp, ardından bu makaledeki daha ileri seviye önerilere dönebilirsiniz.

WebP/AVIF Stratejisi: Boyutu Küçült, Kaliteyi Koru

WebP ve AVIF uygun görsellerde aktarım boyutunu azaltabilir. Temsili fotoğraflarda dosya boyutunu, renkleri, ince detayları ve sıkıştırma izlerini hedef ekran boyutlarında karşılaştırın. Seçilen kodlayıcı ve kalite ayarlarına göre:

• JPEG’e göre görsele ve kodlayıcı ayarlarına bağlı olarak daha küçük dosya boyutları,
• Hedeflenen görsel kaliteyi koruyarak daha verimli sıkıştırma,
• Görsel aktarım yükü azaldığında mobilde daha hızlı açılan sayfalar

elde etmenizi sağlayabilir. Ancak yanlış kurgulanan WebP/AVIF stratejisi; kırık görseller, SEO sorunları veya aşırı CPU tüketimi olarak geri dönebilir.

Orijinaller ve WebP/AVIF Varyantları Nasıl Saklanmalı?

Burada üç temel model var:

1. Orijinali tut, istek geldiğinde anlık dönüştür
   JPEG/PNG orijinaller saklanır; gelen isteğe göre Nginx/Apache arkasında çalışan bir servis WebP/AVIF üretip cache’ler. Tüm varyasyonları önceden üretmeye göre disk tasarrufu sağlayabilir; ancak üretilen varyasyonların önbelleği de alan kullanır. Dezavantajı ise dönüşüm sırasında CPU yükü ve ilk istekte gecikmedir.
2. Upload anında tüm format ve boyutları üret
   Kullanıcı görsel yüklediğinde arka planda WebP/AVIF ve farklı boyutlar üretilir. Disk kullanımı artar; iş kuyruğu ve eşzamanlılık sınırıyla CPU yükü zamana yayılabilir. Varyasyonlar hazır olduğunda ilk görüntülemede dönüşüm beklenmez.
3. Hibrit model
   En çok kullanılan boyutlar ve formatlar önceden üretilir, nadir kullanılan varyasyonlar için anlık dönüşüm yapılır.

Dönüşüm modelini CPU/RAM ihtiyacına, yükleme yoğunluğuna ve türevlerin disk kullanımına göre seçin. İş kuyruğunda eşzamanlılık ve yeniden deneme sınırları belirleyin; dönüşüm bitmeden hazır olmayan URL’leri ziyaretçiye sunmayın. NVMe disk tek başına kodlama için işlemci kapasitesi sağlamaz. DCHost planı seçerken disk türünü, kaynak sınırlarını ve arka plan işlerinin çalıştırılabildiğini ayrıca doğrulayın.

WebP/AVIF sunumu sırasında tarayıcı uyumluluğu, SEO ve CDN cache’ini bozmadan dönüşüm yapmak için ayrıntılı teknik örnekler görmek isterseniz, WebP/AVIF’i kırmadan sunmak rehberimizde Nginx/Apache rewrite kuralları, varyant yönetimi ve SEO uyumluluğunu tüm detaylarıyla anlattık.

Tarayıcıya Göre Doğru Formatı Sunmak

WebP ve AVIF güncel tarayıcılarda yaygın olarak desteklenir; yine de hedef kitlenizin eski cihazlarını, uygulama içi tarayıcılarını ve kullandığınız görüntü işleme araçlarını kontrol edin. Bu yüzden:

• Aynı URL’de içerik pazarlığı yapılıyorsa tarayıcının “Accept” başlığına göre desteklenen WebP/AVIF formatını seçmek, uygun destek yoksa JPEG/PNG sunmak,
• Bu URL’nin JPEG/PNG dahil tüm ilgili yanıtlarında Vary: Accept göndermek; mevcut diğer Vary alanlarını korumak, CDN cache-key’inde format varyantlarını ayırmak ve başlığın istemciye ulaştığını kontrol etmek. Vary başlığı tek başına CDN’in özel anahtar yapılandırmasının yerini almaz. Her format ayrı bir URL’den sunuluyor ve yanıt Accept’e göre değişmiyorsa, yalnızca format ayrımı için Vary: Accept gerekmez.
• İlk ekranda görünmeyen görsellerde lazy-load (gecikmeli yükleme), uygun boyutu sunmak için responsive görüntü (srcset, sizes) kullanmak ve yerleşimde görsele boyut ayırmak; LCP görselini gecikmeli yüklememek

görsel ağırlıklı sitelerde yararlı olabilir. Ayrı format URL’leriyle picture yaklaşımını kullanıyorsanız, img öğesinde çalışan JPEG/PNG yedeği ve anlamlı görseller için doğru alt metin bulundurun. Content-Type başlığı gerçek dosya türüyle eşleşmeli; bozuk AVIF dosyasının her durumda kendiliğinden JPEG’e düşeceğini varsaymayın. Önemli fotoğrafları taranabilir HTML içinde sunun, mevcut URL’leri geçişte çalışır tutun; aynı adrese farklı içerik yazmak yerine değişen görsele yeni sürümlü URL verin. Bu optimizasyonlar, görsel yüklemesi darboğaz olduğunda Google’ın Core Web Vitals metriklerinden özellikle LCP’yi (Largest Contentful Paint) iyileştirebilir; etkileri ölçülmelidir. Sunucu tarafındaki optimizasyonların bu metriklere etkisini ayrıntılı olarak anlattığımız Core Web Vitals ve hosting altyapısı rehberi de mutlaka göz atmanız gereken bir diğer kaynak.

Görüntü Optimizasyon Boru Hattı ve Otomasyon

İş gerçekten büyüdüğünde, “Ben fotoğraf yükleyeyim, gerisini sistem halletsin” demek istersiniz. İşte burada görüntü optimizasyon boru hattı (image pipeline) devreye girer.

Tipik bir boru hattı şöyle işler:

1. Fotoğrafçı/ajans panelden orijinal görseli yükler.
2. Görsel, biçim ve boyut kontrolleriyle geçici alana kaydedilir; dosya boyutu, piksel sayısı ve işlem süresi sınırları belirlenir.
3. Arka planda çalışan bir iş kuyruğu (queue) şu adımları uygular:
   • Orijinali kalıcı arşivde koruyup web sunumu için fazla büyükse bir kopyasını yeniden boyutlandırma (örneğin 8000 px’den 3000 px’e düşürme),
   • Farklı boyutlar (thumbnail, orta, büyük) oluşturma,
   • WebP ve/veya AVIF üretme,
   • Sonuçları kalıcı depolama alanına (NVMe veya nesne depolama) taşıma,
   • Sunum URL’lerini üretme; CDN’in desteklediği bir önbellek ısıtma mekanizması varsa gerekli varyasyonlar için bunu kullanma. Yalnızca URL üretmek önbelleği ısıtmaz.

Bu mimariyi adım adım anlattığımız görüntü optimizasyonu boru hattı rehberinde, AVIF/WebP dönüşümü, origin shield ve akıllı cache-key stratejilerinin CDN faturası ve performans üzerindeki etkilerini detaylı olarak ele aldık.

Bu tür bir boru hattında uygulama, dönüşüm işleri ve medya depolaması ayrı katmanlara yerleştirilebilir. DCHost üzerinde sunucu seçerken disk türünü ve kaynak sınırlarını, nesne depolama için de kullanılacak sağlayıcının hizmet kapsamını ayrıca doğrulayın. Örnek görev dağılımı:

• Bir VPS’i uygulama + API sunucusu,
• İhtiyaç varsa ayrı bir VPS’i arka plan işçisi (worker) ve kuyruk sistemi,
• Seçilen sağlayıcıdaki nesne depolamayı kalıcı medya arşivi

Bu ayrım, uygulama ile dönüşüm işlerinin kaynaklarını ayrı büyütmeyi kolaylaştırabilir; kuyruk takibi, yeniden denemeler ve erişim yönetimi ek işletim yükü getirir. RAW/TIFF ana arşivini ve yüksek çözünürlüklü müşteri indirmelerini herkese açık web kopyalarından ayırın. Özel dosyada her erişim yetkili olmalı; imzalı URL kullanılıyorsa denetim önbellek isabetinde de çalışmalı ve herkese açık origin bu kontrolü atlatmamalıdır. Geçerli imzalı adresi bilen kişi süre dolana kadar kullanabilir. Sıcak/soğuk arşiv veya CDN bağımsız yedek sayılmaz. Orijinallerin, gerekli türevlerin, veritabanının ve yapılandırmanın tutarlı yedeğini ayrı ortamda tutun; çözme anahtarlarıyla birlikte izole geri yükleme testi yapın.

Farklı Site Türleri İçin Örnek Mimariler

Tek Fotoğrafçı veya Portfolyo Sitesi

Varsayımsal senaryo: Portre fotoğrafçısı, düğün fotoğrafçısı veya kreatif ajans portfolyosu. Aylık 10–50 bin ziyaret, toplamda 2–5 bin görsel.

Önerilen mimari:

• Paketin CPU/RAM, I/O, inode ve trafik sınırları uygunsa paylaşımlı hosting veya küçük bir VPS; disk türünü iş yüküne ve seçilen planın özelliklerine göre değerlendirin.
• Görseller için yükleme sonrasında arka planda WebP üretimi; JPEG/PNG orijinallerin yeniden işleme ve gerektiğinde uyumlu sunum için korunması, ayrıca yedeklenmesi. Paylaşımlı hosting’de dönüşüm araçlarının ve arka plan işlerinin desteklendiğini doğrulayın; desteklenmiyorsa dönüşümü ayrı bir ortamda yapın.
• Basit bir CDN entegrasyonu ile herkese açık görsellerin önbellek isabetlerinde edge üzerinden sunulması.
• WordPress kullanılıyorsa, media library yönetimini sadeleştiren ve temayla uyumlu çalışan bir galeri eklentisi.

Bu segmentte en kritik nokta, sayfa açılış hızları ve mobil deneyimdir. Core Web Vitals metriklerini düzenli takip ederek, gerektiğinde sunucu tarafı ayarlarını optimize edebilirsiniz.

Yüksek Trafikli Magazin veya Haber Sitesi

Varsayımsal senaryo: Günlük binlerce yeni ziyaretçi, sürekli güncellenen içerik, bol slider’lı ana sayfa ve liste sayfaları, on binlerce görsel.

Önerilen mimari:

• Ölçülen yük için uygun disk ve kaynaklara sahip VPS veya dedicated sunucu üzerinde uygulama (örneğin WordPress veya özel CMS).
• Kaynak veya işletim ihtiyacı gerekçelendiriyorsa ayrı sunucu ya da yönetilen servis olarak veritabanı; ağ gecikmesi ve ek işletim yükünü ölçün.
• Nesne depolama veya ayrı disk alanında medya arşivi.
• Herkese açık, sürümlenmiş görseller için uzun süreli cache-control ile yapılandırılmış CDN ve versiyonlu URL’ler; özel veya kişiselleştirilmiş içerik için ayrı önbellek kuralları.
• WebP/AVIF dönüşümünü arka plan işlerinde yapan, kırılma riskini minimize eden bir pipeline.

Bu tip sitelerde tam sayfa önbellekleme (full-page cache) ve veritabanı yükünü azaltma stratejileri de kritik önem taşıyor. Nginx FastCGI cache, Varnish veya LiteSpeed Cache gibi çözümlerle tam sayfa önbellekleme kurulumunu anlattığımız WordPress tam sayfa önbellekleme rehberi, magazin sitelerinde de kullanılan CMS, sunucu yazılımı ve kişiselleştirilmiş içeriklere göre uyarlanabilir.

Ajans, Stock Foto veya Büyük Arşiv Siteleri

Varsayımsal senaryo: On binlerce hatta yüz binlerce görsel, çok sayıda içerik üreticisi, yoğun upload trafiği, detaylı filtreleme ve arama.

Önerilen mimari:

• Ölçülen yük ve yönetim kapasitesine göre dedicated sunucu, uygun sağlayıcıda colocation veya nesne depolama seçenekleri. RAID ve depolama katmanları bağımsız yedeklerin yerini almaz.
• Arka planda güçlü bir görüntü optimizasyon boru hattı ve iş kuyruğu.
• Geniş edge ağı olan bir CDN, region bazlı cache stratejileri.
• Arama ve filtreleme için optimize edilmiş veritabanı veya ek arama altyapıları (Elasticsearch vb.).

Arşivin erişilebilirliği kadar kurtarılabilirliğini de ölçün. Kabul edilebilir veri kaybı ve geri dönüş süresi hedeflerini belirleyip yedek sıklığını, saklama süresini ve testleri bunlara göre seçin. Türevleri yeniden üretmek mümkün olsa bile büyük arşivlerde bu işlem günler sürebilir; dönüşüm ayarları ve uygulama kayıtları da kurtarma planına dahil olmalıdır. Deneme geri yüklemesi gerçek müşteri e-postası veya ödeme işlemi üretmemelidir.

Kapasite Planlama: Disk, Trafik ve CDN Maliyeti Nasıl Hesaplanır?

Görsel ağırlıklı projelerde yanlış kapasite planı iki türlü can yakar: Ya sürekli “disk doldu” uyarıları alırsınız ya da gereğinden fazla kaynak için gereksiz ödeme yaparsınız. Basit ama etkili bir yaklaşım şu adımlarla kurulabilir:

1. Mevcut durumun fotoğrafını çekin
   Toplam görsel sayısı, ortalama dosya boyutu, günlük/aylık sayfa görüntüleme sayısı… Bunları gerçek verilerle veya makul tahminlerle ortaya koyun.
2. 1 yıllık büyüme hedefini belirleyin
   Örneğin, her ay 1000 yeni fotoğraf veya trafik tarafında ayda %10 artış gibi.
3. Disk ve trafik projeksiyonu yapın
   Mevcut arşive 12 aylık yeni yüklemeleri ekleyin; orijinallerin yanı sıra üretilen boyut/format varyantlarını ve saklanan yedekleri de disk hesabına katın. Aylık sayfa görüntüleme sayısını, görüntüleme başına ortalama aktarılan veri boyutuyla çarparak yaklaşık trafik hacmini hesaplayın; tarayıcı önbelleği ve gerçekte yüklenen görseller bu ortalamayı etkiler.
4. CDN maliyetini ve origin trafiğindeki azalmayı hesaplayın
   Origin trafiğindeki azalma, içeriğin önbelleklenebilirliğine ve CDN’in önbellekten karşıladığı veri oranına bağlıdır; sabit bir tasarruf yüzdesi varsaymayın. Sağlayıcının tarifesine göre aylık CDN veri aktarımı ve istek ücretlerini, varsa sabit ve görsel dönüştürme ücretlerini, depolama erişim/geri yükleme ücretlerini ve origin çıkış maliyetini birlikte hesaplayın. Origin trafiğinin azalması, toplam faturanın aynı oranda düşeceği anlamına gelmez.

Bu hesabı yaparken, özellikle yeni projelerde belirsizlik çok fazlaysa, bir miktar esneklik payı bırakmak akıllıca olur. DCHost üzerinde küçük bir planla başlamayı düşünüyorsanız, büyüme için gereken kaynak artırımı ve taşıma seçeneklerini önceden netleştirin; yatay ölçekleme ayrıca uygulama mimarisinin buna uygun olmasını gerektirir.

DCHost Planını Seçerken Uygulanacak Kontrol Listesi

Buraya kadar anlattıklarımızı, uygulanabilir bir yol haritasına dönüştürelim. DCHost’ta görsel ağırlıklı bir siteyi planlarken şu adımları değerlendirebilirsiniz:

1. İş yükünü ölçün: Görsel sayısı, türevler, trafik, kullanıcı bölgeleri, CMS, bütçe ve bir yıllık büyümeyi kaydedin.
2. Plan ve sorumlulukları doğrulayın: Paylaşımlı hosting, VPS veya dedicated seçeneklerinin gerçek disk türünü, kapasitesini, inode ve trafik sınırlarını karşılaştırın. Dönüşüm araçları, arka plan işleri ve yönetim yetkisi ihtiyacını belirtin. Harici CDN, nesne depolama veya colocation gerekiyorsa sağlayıcı ve hizmet kapsamını ayrıca belirleyin.
3. Önbellek ve erişimi kurun: Herkese açık sürümlü görsellere uygun Cache-Control verin. Aynı URL Accept’e göre değişiyorsa JPEG/PNG dahil ilgili yanıtlarda Vary: Accept gönderin, diğer Vary alanlarını koruyun ve CDN’in formatları ayırdığını doğrulayın. Özel müşteri dosyaları için yetki kontrollerini koruyun.
4. Dönüşümü ve kaliteyi test edin: Kontrollü iş kuyruğuyla gerekli boyutları ve formatları üretin. Hazır dosyaları doğru Content-Type ile sunun; eski URL, uyumluluk, renk, detay ve mobil LCP kontrollerini yapın.
5. Yedek ve izlemeyi tamamlayın: Canlıya geçmeden bağımsız yedeklerden izole geri dönüşü doğrulayın. CPU/RAM, kuyruk yaşı, dönüşüm hataları, disk büyümesi, CDN isabetleri ve toplam maliyeti izleyin; yalnızca ölçülen darboğazı giderecek yükseltmeleri seçin.

DCHost ekibiyle görüşürken disk kullanımınızı, trafik beklentinizi, CDN verilerinizi ve WebP/AVIF dönüşüm ihtiyaçlarınızı paylaşın. Plan seçiminin yanı sıra mimari planlama, kapasite analizi ve optimizasyon desteğinin kapsamını da netleştirin.

Hosting kararını yalnızca fotoğraf adedine veya NVMe etiketine bağlamayın. Ölçülen depolama ve işlem ihtiyacını; doğru format sunumunu, erişim kurallarını, bağımsız yedekleri ve CDN’nin toplam maliyetini birlikte değerlendirin. Küçük bir görsel grubuyla başlayıp kalite ve performansı doğruladıktan sonra aynı iş akışını arşive uygulayın.