# SFCC Performans Optimizasyonu: Storefront Denetim Listesi

URL: https://www.ozanaltinbas.com/tr/makale/sfcc-performance-audit
Author: Ozan Altinbas (Ozan Altınbaş), SFCC Technical Architect
Published: 2026-11-12
Category: Performans ve SEO | Tags: SFCC, Performans, Önbellek, Kotalar, SFRA

---

Salesforce, B2C Commerce performansını ortak bir sorumluluk olarak tanımlar: platformun performansı Salesforce'a, customization'larınızın performansı size aittir ([Monitor Your Site](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/monitor-site.html)). Pratikte yavaş bir storefront genellikle birkaç somut soruna indirgenir: her varyantı yükleyen bir listeleme sayfası, makul bir timeout'u olmayan bir entegrasyon, hiç önbelleğe alınmamış bir controller, yüklendiği boyutta sunulan bir hero görseli.

Bu kontrol listesi, bir SFRA veya headless storefront'ta SFCC site hızı denetiminin hangi sırayla yapılacağını veriyor: ölçün, sunucuyu profilleyin, entegrasyonları, önbelleği ve kotaları kontrol edin, ardından front-end'e geçin ve son olarak bulguları sıralayın. Ayrıntılı rehberleri tekrar etmek yerine onlara bağlantı veriyor. Platformun genel resmi için [SFCC rehberiyle](https://www.ozanaltinbas.com/tr/sfcc) başlayın.

---

## Adım 0: Denetimin kapsamını belirleyin

- **Geliri taşıyan template'leri seçin.** Salesforce'un kodlama standartları, iyi performans göstermesi ve mümkün olduğunca önbelleğe alınması gereken en çok ziyaret edilen sayfaları sayar: arama ve kategori (`Search-Show`), ürün detay (`Product-Show`), ana sayfa (`Home-Show`), sepet (`Cart-Show`) ve checkout.
- **Gerçek giriş sayfalarını bulun.** [Site Performance rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-site-performance.html), en çok ziyaret edilen giriş sayfasının ana sayfa değil, bir e-posta veya iş ortağı landing page'i olabileceğini hatırlatır.
- **Bir baseline dondurun.** Kod versiyonunu, son replikasyonları, kampanyaları ve trafiği kaydedin; ne zaman yeniden ölçeceğinizi baştan belirleyin.

---

## Adım 1: Bir şeyi değiştirmeden önce ölçün

### Saha verisi karar verir, lab verisi açıklar

Salesforce'un [storefront izleme rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/perf-monitor.html) iki veri türünü ayırır: geliştirme sırasında kontrollü testlerle toplanan lab verisi ve yayından sonra gerçek alışverişçileri yansıtan saha verisi. Google, sayfa deneyimi sıralamasında Lighthouse skorlarını değil, Chrome UX Report (CrUX) saha verisini kullanır. Aynı sayfaya göre CrUX **28 günlük kayan ortalamadır**, metrikleri **75. yüzdelikte** değerlendirir, ağırlıklı olarak **hard navigation'lara** bakar (bu yüzden tek sayfalı uygulamalardaki route değişiklikleri az temsil edilir) ve **iOS cihazlarını içermez**.

| Core Web Vital | "İyi" eşiği | SFCC'deki olağan şüpheliler |
|---|---|---|
| Largest Contentful Paint (LCP) | 2,5 sn veya altı | Önbelleğe alınmamış HTML, büyük hero görselleri, render'ı bloklayan CSS ve JavaScript, web fontları |
| Interaction to Next Paint (INP) | 200 ms veya altı | Ağır istemci JavaScript'i, üçüncü taraf tag'ler, headless storefront'larda uzun hydration görevleri |
| Cumulative Layout Shift (CLS) | 0,1 veya altı | Boyutu belirtilmemiş görseller, geç yüklenen slot ve banner'lar, font değişimleri, onay çubukları |

Lab verisi için Salesforce; Lighthouse, PageSpeed Insights, WebPageTest ve Chrome DevTools panellerini listeler. Testleri ofis ağının dışından yapın: şirket içi LAN testleri, başka bölgelerdeki alışverişçileri ve eCDN edge önbelleğinin etkisini yansıtmaz.

### Sunucu verisi: Business Manager araçları

| Soru | Araç | Nerede |
|---|---|---|
| En çok istenen, en yavaş veya en az önbelleğe alınan controller'lar hangileri? | Technical raporu | Reports & Dashboards, Technical sekmesi |
| İsteğin içinde süre nereye gidiyor? | Code Profiler | Administration > Operations > Code Profiler |
| Hangi entegrasyonlar yavaş veya hata veriyor? | Service Status | Administration > Operations > Service Status |
| Custom kod platform limitlerine takılıyor mu? | Quota Status | Administration > Operations > Quota Status |
| Hata veya uyarılarda ani artış var mı? | Log Center | Administration > Site Development > Development Setup > Log Center |
| Job'lar storefront'la yarışıyor mu? | Jobs | Administration > Operations > Jobs |
| Ek yük alışverişçilerden değil bot'lardan mı geliyor? | Top Robots | Reports & Dashboards, Traffic sekmesi |

Reports & Dashboards verisi olaylardan 24 saat sonra görünür: canlı olaylar için değil, trendler için kullanın.

### Salesforce'un referans medyanları

[B2C Commerce performans sorun giderme rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-troubleshooting-platform-performance.html), en kritik pipeline'lar için grid genelindeki medyan yanıt sürelerini yayımlar. Kritik controller'larınız bu değerlerin çevresindeyse Salesforce siteyi ölçeklenebilir kabul eder:

| Pipeline | Grid geneli medyan |
|---|---|
| `Search-Show` | 400 ms |
| `Product-Show` | 300 ms |
| `Cart-Show` | 400 ms |
| `Home-Show` | 90 ms |
| `Page-Show` | 90 ms |
| `Product-HitTile` | 10 ms |
| `OCAPI-Request` (tüm OCAPI istekleri) | 250 ms |

Bunlar sunucu süreleridir; dış izleme araçlarının ölçtüğü uçtan uca sürelerin çok daha yüksek olması beklenir. `Product-HitTile`, SiteGenesis'in ürün tile'ıdır; SFRA'da `Tile-Show` ile karşılaştırın.

---

## Adım 2: Sunucu tarafını profilleyin

### Önce Technical raporunu okuyun

Technical sekmesinde ana controller isteklerini istek sayısına göre azalan şekilde sıralayın. Yoğun her controller için yanıt süresine ve önbellek sütunlarına bakın, ardından süre çoğu zaman orada harcandığı için remote include'larını açın.

### Code Profiler'ı production'a zarar vermeden çalıştırın

Site Performance rehberi üç mod tanımlar:

- **Production Mode** isteklerin bir alt kümesini örnekler: sandbox dışı instance'larda varsayılandır, kapatılamaz, etkisi minimumdur.
- **Development Mode** her isteği ölçer: sandbox'larda varsayılandır, bir miktar ek yük getirir.
- **Extended Script Development Mode** fonksiyon ve tek satır düzeyine iner; Salesforce production'da ciddi performans etkisi konusunda uyarır.

Ekran yalnızca Business Manager oturumunuza hizmet eden uygulama sunucusunun verisini gösterir; saatlik bir job veriyi CSV olarak dışa aktarır ve ardından sıfırlar. **Elapsed Time**'ı **Wait Time** (veritabanı veya servis I/O'su ya da kilitlenme) ile birlikte okuyun: yüksek elapsed time ve düşük wait time script işine, yüksek wait time sorgulara veya entegrasyonlara işaret eder. Sonuç türüne göre filtreleyin: Controller (`SCRIPT_CONTROLLER`), Script details (`SCRIPT_API`, `SCRIPT_HOOK`) ve View (ISML).

### Sunucu tarafındaki sıcak noktalar

Site Performance rehberinin kodlama standartlarından:

| Sıcak nokta | Neye bakılır | Çözüm |
|---|---|---|
| İstek başına hook'lar | 10 ms'yi aşan custom `onRequest` veya `onSession` mantığı (Salesforce'un belirttiği sınır) | Taşıyın, önbelleğe alın veya ne zaman çalıştığını daraltın |
| Sonradan işlenen aramalar | Arama sonuçlarını filtreleyen veya sıralayan kod | Her kriteri sorgunun içine koyun |
| Listelemelerde varyant döngüleri | Tile başına `Product.getVariants()` veya `Product.getVariationModel()` | `ProductSearchHit` metotları (aşağıda) |
| Yoğun sayfalarda veritabanı ağırlıklı API'ler | `Category.getProducts()`, `Category.getOnlineProducts()`, `ProductMgr.queryAllSiteProducts()`, `Product.getPriceModel()` | Index dostu `ProductSearchModel` API'leri |
| Sayfalanmamış sonuç kümeleri | Tamamı işlenen veya render edilen sonuç kümeleri | Sayfa boyutu sınırlı `PagingModel`; Salesforce'un örneği "View all" dahil 120 üründür |
| Gezinme sayfalarında canlı çağrılar | Ana sayfa, kategori, arama veya ürün sayfalarında dış çağrılar | Veriyi import edin veya önbelleğe alın; kaçınılmazsa düşük bir timeout (Salesforce'un örneği: 1 saniye) |
| Controller'da uzun iş | Import, export, büyük döngüler, 1.000 değiştirilmiş nesneye yaklaşan transaction'lar | Bir job; web katmanı tarayıcı bağlantılarını 5 dakika sonra kapatır |
| Nesne şişmesi | Gereksiz session nesneleri ve cookie'ler, her anonim alışverişçi için açılan wishlist, hiç temizlenmeyen custom object'ler | Yalnızca gerektiğinde oluşturun; purge job'ları |

Canlı çağrılar en önemlisidir: Salesforce'a göre dış bir sistemi bekleyen bir thread başka istekleri karşılayamaz ve bekleyen çok sayıda thread tüm cluster'ı yanıt veremez hâle getirebilir.

### Varyant döngülerini search hit'lerle değiştirin

`ProductSearchHit`, fiyat aralığı ve varyasyon değeri sorularını arama index'inden yanıtlar. [ProductSearchModel referansı](https://salesforcecommercecloud.github.io/b2c-dev-doc/docs/current/scriptapi/html/api/class_dw_catalog_ProductSearchModel.html), her sonuç için ürünleri yüklemek çok pahalı olduğundan `getProducts()` metodunu deprecated ilan eder.

```javascript
'use strict';

var ProductSearchModel = require('dw/catalog/ProductSearchModel');
var PagingModel = require('dw/web/PagingModel');

// Listeleme sayfasında anti-pattern: her ürünün her varyantına dokunur
// master.getVariants().toArray().forEach(function (variant) { ... });

function getTiles(categoryId, start, pageSize) {
    var psm = new ProductSearchModel();
    psm.setCategoryID(categoryId);
    psm.setOrderableProductsOnly(true); // stok filtrelemesi kodda değil, sorguda
    psm.search();

    var paging = new PagingModel(psm.getProductSearchHits(), psm.getCount());
    paging.setStart(start);
    paging.setPageSize(Math.min(pageSize, 120)); // sayfa boyutunu sınırlayın, "View all" dahil

    var tiles = [];
    var hits = paging.getPageElements(); // iterator kaynağında yalnızca bir kez çağırın
    while (hits.hasNext()) {
        var hit = hits.next();
        tiles.push({
            id: hit.getProductID(),
            minPrice: hit.getMinPrice(), // index fiyatları: varyant başına price model yok
            maxPrice: hit.getMaxPrice(),
            colors: hit.getRepresentedVariationValues('color') // yalnızca eşleşen varyantlar
        });
    }
    return tiles;
}

module.exports = { getTiles: getTiles };
```

Referanstan iki uyarı: index fiyatları `ProductPriceModel` fiyatlarından farklı olabilir ve hit'ler son index güncellemesinden beri offline'a alınmış ürünleri içerebilir.

---

## Adım 3: Entegrasyonlar ve servis framework'ü

Salesforce'un standardı, doğrudan yapılan her üçüncü taraf HTTP çağrısının servis framework'üne taşınmasıdır ([Web Services](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-webservices.html)); timeout, circuit breaker ve rate limit'ler orada yönetilir.

### Timeout'lar

Timeout, servis profilinde milisaniye cinsinden ayarlanır (**Administration > Operations > Services**, **Profiles** sekmesi). Çağrının tamamına değil, bağlantıya ve her bir okumaya uygulanır: Salesforce'un örneğinde 5.000 ms timeout ile 4 saniyelik bir bağlantı ve ardından 4'er saniyelik iki okuma, timeout'a düşmeden yaklaşık 13 saniye sürer.

`api.dw.serviceTimeoutNotSet` kotası, timeout'u olmayan veya 30 saniye ya da üzeri timeout'a sahip FTP, SFTP, HTTP ve web servis çağrılarını işaretler ([Salesforce Help](https://help.salesforce.com/s/articleView?id=What-is-the-quota-api-dw-serviceTimeoutNotSet-and-what-do-the-warnings-mean&language=en_US&type=1)). Her kaydı bir bulgu olarak ele alın.

### Circuit breaker ve rate limiter

- **Enable Circuit Breaker** varsayılan olarak işaretlidir. Salesforce, onu açık tutup **Max Circuit Breaker Calls** alanını boş veya sıfır bırakmayı önerir; bu, sistem düzeyindeki circuit breaker'ı etkinleştirir. Çağrı sayısını girerseniz **Circuit Breaker Interval (ms)** alanını da doldurun.
- Breaker; bağlantı hatalarını, HTTP 500 ve 503 gibi protokol hatalarını ve çağrı sırasında fırlatılan exception'ları sayar. HTTP 4xx yanıtları sayılmaz.
- **Enable Rate Limit**, belirli bir aralıktaki giden çağrı sayısını sınırlar.

İkisinden biri devreye girdiğinde çağrı yapılmaz. Bu durumda ve bir çağrı timeout'a düştüğünde [`dw.svc.Result`](https://salesforcecommercecloud.github.io/b2c-dev-doc/docs/current/scriptapi/html/api/class_dw_svc_Result.html) nesnesinin status'u `SERVICE_UNAVAILABLE`, `unavailableReason` değeri ise `CIRCUIT_BROKEN`, `RATE_LIMITED` veya `TIMEOUT` olur. Fallback'i ihtiyaç duymadan önce tasarlayın:

```javascript
'use strict';

var LocalServiceRegistry = require('dw/svc/LocalServiceRegistry');
var Logger = require('dw/system/Logger');

// Timeout, circuit breaker ve rate limit kodda değil,
// Business Manager'daki servis profilinde tanımlıdır.
function getStockService() {
    return LocalServiceRegistry.createService('example.stock.http', {
        createRequest: function (svc, params) {
            svc.setRequestMethod('GET');
            svc.addParam('sku', params.sku);
        },
        parseResponse: function (svc, client) {
            return JSON.parse(client.text);
        }
    });
}

function getStock(sku) {
    var result = getStockService().call({ sku: sku });
    if (result.ok) {
        return result.object;
    }
    Logger.warn('Stock lookup failed: {0} {1}', result.status, result.unavailableReason || result.errorMessage);
    return null; // kontrollü düşüş: sayfayı canlı stok olmadan render edin
}

module.exports = { getStock: getStock };
```

Örnek, canlı bir durum olan stoku önbelleğe almaz. Yalnızca URL'e bağlı yanıtlar için `HTTPService.setCachingTTL()` kolayca gözden kaçar. [HTTPService referansına](https://salesforcecommercecloud.github.io/b2c-dev-doc/docs/current/scriptapi/html/api/class_dw_svc_HTTPService.html) göre içerik uzunluğu 50 KB'ın altındaki 2xx GET yanıtlarını, URL ve kullanıcı adını anahtar alarak ve uzak sunucunun önbellek header'larını yok sayarak önbelleğe alır.

**Service Status** (**Administration > Operations > Service Status**) her servisin performansını neredeyse gerçek zamanlı gösterir ve veriyi 10 güne kadar saklar.

---

## Adım 4: Önbellek kapsamını kontrol edin

Mekanikleri [SFCC önbellek rehberi](https://www.ozanaltinbas.com/tr/makale/sfcc-caching) anlatıyor. Denetimde şunları kontrol edin:

- **Her yoğun controller ve remote include'un bir önbellek direktifi var.** Technical raporunda hiç önbellekten sunulmayan bir controller önbelleğe alınmıyordur.
- **Önbelleğe alınan yanıtlarda kişiselleştirilmiş içerik yok**; `price_promotion`'ın farklılaştırdığı boyutlar hariç.
- **URL'ler benzersiz parametre taşımıyor.** Sorun giderme rehberi, benzersiz URL parametreli e-posta kampanyaları konusunda uyarır.
- **Önbellek temizlikleri iyi zamanlanıyor.** Salesforce'un yaygın hatalar listesinde bir satış zirvesinden hemen önce, birkaç değişiklik için günde birkaç kez veya statik içerik yayınlamak için invalidation yapmak var. `<iscache type="daily">` tag'i de o türdeki tüm sayfaları aynı anda sona erdirir.
- **Replikasyonlar yoğun saatlerden kaçınıyor.** Code replication, code activation ve data replication, job aksini belirtmedikçe önbelleği temizler.
- **Kimse önbelleği bir spider ile ısıtmıyor**; Salesforce bunun az fayda için ciddi kaynak tükettiğini söyler.
- **Okumalar GET kullanıyor.** Yalnızca GET istekleri page cache'e alınabilir.

---

## Adım 5: Kota uyarılarını performans sinyali olarak okuyun

[Governance and Quotas](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-governance-and-quotas.html) bir ihlali, custom kodun platformu verimsiz kullandığının işareti olarak görür. Her kotanın üç eyleminden biri vardır:

- `log_only`: Salesforce tarafından değerlendirme aşamasında; şimdilik yok sayın.
- `warn`: uyarı eşiğinde (limitin %60'ı) harekete geçin. Limitin ötesindeki kullanım engellenmez ama kararsızlık doğabilir.
- `error`: zorunlu (enforced). İşlem engellenir ve storefront isteğinde genel hata sayfası gösterilir.

Kota exception'larını catch etmeyin; tasarımla önleyin. **Quota Status** son 24 saati (veya son yeniden başlatmadan bu yana) yeşil, turuncu ve kırmızı ile gösterir ve ihlallerin günlük özetini e-postayla gönderebilir. WebDAV log klasöründeki `quota` log dosyaları siteyi, en üst pipeline'ı ve çoğu zaman template'i veya script'i belirtir. Salesforce'un standardı: staging veya production'da hiç enforced ihlal olmaması ve kota uyarılarına tüm site yöneticilerinin abone olması.

Doğrudan performans sorunlarına işaret eden kotalar ([API Quotas](https://salesforcecommercecloud.github.io/b2c-dev-doc/docs/current/quota/html/API_Quotas.html), [Object Quotas](https://salesforcecommercecloud.github.io/b2c-dev-doc/docs/current/quota/html/Object_Quotas.html)):

| Kota | Limit (uyarı) | Genellikle ne anlama gelir |
|---|---|---|
| `api.dw.serviceTimeoutNotSet` | 0 | Makul timeout'u olmayan bir giden çağrı |
| `api.dw.net.HTTPClient.send()` | Storefront sayfası başına 16 (10) | Tek istekte çok fazla uzak çağrı |
| `api.dw.catalog.ProductMgr.queryAllProducts()` | Storefront'ta 0 | Tüm kataloğu sorgulayan storefront kodu |
| `api.dw.object.CustomObjectMgr.create()` | Storefront sayfası başına 10 (6) | Yazma ağırlıklı depo olarak kullanılan custom object'ler |
| `api.dw.util.collectionSize` | 20.000 (12.000) | Bellekte kurulan büyük koleksiyonlar |
| `api.jsStringLength` | 1.000.000 (600.000) | Çoğunlukla bellekte birleştirilen JSON veya HTML'den oluşan dev string'ler |
| `object.NonStageableCustomObjectPO` | Instance başına 400.000 (240.000) | Purge job'u olmadan büyüyen custom object hacmi |

---

## Adım 6: Front-end: görseller, JavaScript ve üçüncü taraflar

### Dynamic Imaging Service ile görseller

Görsel URL'lerini `URLUtils` veya `MediaFile` ile üretin: [Dynamic Imaging Service dokümantasyonuna](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-dynamic-imaging-service.html) göre API parametreleri doğrular ve sizi URL kalıbındaki değişikliklerden korur. Template'e asla `/dw/image/v2/` veya bir hostname yapıştırmayın.

| URL parametresi | Transform nesnesi anahtarı | Notlar |
|---|---|---|
| `sw`, `sh` | `scaleWidth`, `scaleHeight` | 10 ile 3.000 piksel arası |
| `sm` | `scaleMode` | `cut` (varsayılan) veya `fit`; yalnızca iki boyutla birlikte |
| `q` | `quality` | JPG ve JP2: 1 ile 100 arası, varsayılan 80 |
| Dosya uzantısı, `sfrm` | `format` | Hedefler arasında AVIF ve WebP var; çıktıyı uzantı seçer, `sfrm` kaynak formatı belirtir |
| `strip` | `strip` | EXIF verisini ve renk profillerini kaldırır; varsayılan `true` |

10 MB'ın üzerindeki görseller dönüştürülmez, üst sınır 3.000 × 3.000 pikseldir ve 29 saniyeyi aşan dönüşümler HTTP 408 döner.

```javascript
// Bir model veya controller'da; ISML'de asla sabit yazılmaz
var image = product.getImage('large', 0); // view type'ın ilk görseli
var tileUrl = image ? image.getAbsImageURL({ scaleWidth: 400, format: 'jpg' }).toString() : null;
```

- **Her slot'u boyutlandırın.** Her slot'un render edildiği genişliği, `srcset` içinde birkaç sabit genişlikle isteyin.
- **Modern formatlar sunun.** Salesforce'un [AVIF ve WebP rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-dynamic-imaging-avif-webp.html), AVIF ve WebP kaynakları ile JPEG fallback'i olan bir `<picture>` elementi önerir; her URL script'te üretilir.
- **Parametreleri sabit tutun.** Aynı parametreler tek bir CDN önbellek anahtarına karşılık gelir; 80 zaten varsayılansa `q=80` eklemeyin.
- **LCP görselini lazy-load etmeyin.** Ekranın altında kalanları lazy-load edin.

### JavaScript, CSS ve fontlar

SFRA, istemci JavaScript'ini ve SCSS'i `sgmf-scripts` ile derler (`npm run compile:js`, `npm run compile:scss`). Bu build'in ne gönderdiğini, Salesforce'un kullanılmayan kodu bulmak için önerdiği DevTools Coverage paneliyle denetleyin. Salesforce'un [PWA Kit performans rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/perf-tips.html) self-host edilen, subset'lenmiş WOFF2 fontları ve bilinçli seçilmiş bir `font-display` değerini önerir; bu SFRA için de geçerlidir. Kaçınılabilir yönlendirmeleri kaldırın ve her istekle gittikleri için cookie'leri küçük tutun.

### Üçüncü taraf tag'ler

Aynı rehberin üçüncü taraf script kuralları her storefront için geçerlidir:

- Her dış script'i denetleyin ve maliyetini haklı çıkarmayanları kaldırın.
- Asla senkron yüklemeyin; `async` veya `defer` kullanın.
- Sohbet ve sosyal medya widget'larını kaydırma veya tıklamayla lazy-load edin.
- Pazarlama tag'lerini bir consent management platform'un (onay yönetimi) arkasına alın.

---

## Adım 7: Headless'a özgü konular

PWA Kit'te veya SCAPI üzerindeki herhangi bir front-end'de yukarıdaki sunucu kuralları hook'lar ve Custom API'ler için de geçerlidir. Salesforce'un [Shopper API performans rehberi](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/performance.html) şunları ekler:

- **Kimin neden sorumlu olduğunu bilin.** Salesforce hazır Shopper API'leri test eder; hook'larda kendi kodunuzun performansı, Custom API'lerde tamamı size aittir.
- **Yanıtları kırpın.** Yalnızca ihtiyacınız olanı döndürmek için `select` ve `expand` kullanın; kategoriler ve varyantlar sayfalanmaz.
- **Kısa ömürlü expansion'ları ayırın.** `availability` yalnızca 60 saniye önbelleğe alınabilir; yanıtın geri kalanı daha uzun önbellekte kalsın diye onu ayrı çekin.
- **10 saniye sınırına uyun.** Daha yavaş Shopper API yanıtları HTTP 504 döner.
- **Hook'larınızın süresini ölçün.** `sfdc_verbose: true` request header'ı hook sürelerini Log Center'a yazar; PWA Kit'te `?__server_timing=true` render aşamaları için bir Server-Timing header'ı döndürür.
- **CDN'i izleyin.** Log Center'daki Metrics Dashboard, Managed Runtime istek süresini ve önbellek isabet (cache hit) oranını gösterir.

Mimari ödünleşimler için [SFRA mı PWA Kit mi?](https://www.ozanaltinbas.com/tr/makale/sfra-vs-pwa-kit); rate limit ve load shedding için [SCAPI ve OCAPI farkı](https://www.ozanaltinbas.com/tr/makale/scapi-vs-ocapi); hook tasarımı için [SFCC hook rehberi](https://www.ozanaltinbas.com/tr/makale/sfcc-hooks).

---

## Adım 8: Job'lar ve operasyon

Arka plan işleri, alışverişçilerle aynı instance için yarışır. Salesforce'un kuralları:

- **Job yük faktörü:** bir instance'ta günlük toplam job saniyesi bölü 86.400; Salesforce bunu 0,20'nin altında tutmayı söyler.
- **Uzun job'lar:** bir saatten uzun süren her job'u analiz edin ve başlangıç saatlerini dağıtın.
- **Arama index'i ve yedekler:** staging'de tam index rebuild ve Site Backup, her biri günde en fazla bir kez.
- **Yoğun saatler:** page cache invalidation, code replication veya data replication yok.
- **Yük testleri:** Support'a, tercihen bir hafta önceden, test penceresi, beklenen trafik ve yük üreticilerinin IP'leriyle bir case açarak haber verin.

---

## Önceliklendirme: etki × efor

Bu puanlar bir başlangıç noktasıdır; kendi kanıtlarınızla düzeltin.

| Bulgu | Etki | Efor | Sıra |
|---|---|---|---|
| Önbelleğe alınmamış yoğun controller veya include | Yüksek | Düşük | 1 |
| Timeout'u veya circuit breaker'ı olmayan gezinme sayfası entegrasyonu | Yüksek | Düşük | 1 |
| Production'da enforced kota ihlalleri | Yüksek | Düşük-orta | 1 |
| LCP template'lerinde büyük görseller | Yüksek | Düşük | 1 |
| Yoğun saatlerde önbellek temizliği veya replikasyon | Yüksek | Düşük (süreç) | 1 |
| Varyant döngüleri veya sonradan işlenen aramalar | Yüksek | Orta | 2 |
| Pahalı `onRequest` mantığı | Yüksek (her istekte) | Orta | 2 |
| Senkron üçüncü taraf tag'ler | Orta-yüksek | Düşük-orta | 2 |
| İstemci JavaScript ve CSS ağırlığı | Orta | Orta-yüksek | 3 |
| Storefront'u yeniden platformlamak | Değişken | Yüksek | Yalnızca kanıtla |

Partiler hâlinde düzeltin ve her partiden sonra yeniden ölçün; böylece her kazanım bir değişikliğe bağlanır.

---

## İyi bir denetim raporunda neler olmalı

1. **Kapsam ve baseline:** template'ler, tarihler, kod versiyonu, son replikasyonlar, trafik.
2. **Template başına yan yana saha ve lab verisi:** 75. yüzdelik CrUX değerleri, ayrıca lab aracı ve ayarları.
3. **Sunucu kanıtları:** Technical raporu dışa aktarımları, Code Profiler CSV'leri, Service Status trendleri, kota log satırları.
4. **Bulgu başına bir kayıt:** kanıt, kök neden, çözüm, sorumlu, etki, efor ve düzeltmeyi kanıtlayacak metrik.
5. **Entegrasyon envanteri:** servis ID'si, timeout, circuit breaker, çağıran sayfalar, fallback.
6. **Önceliklendirilmiş bir backlog**, yukarıdaki tablodan.
7. **Yeniden ölçüm planı**, 28 günlük CrUX penceresini ve Reports & Dashboards'taki 24 saatlik gecikmeyi hesaba katarak.

---

## Temel çıkarımlar

- Saha verisi (75. yüzdelikte CrUX) sonucu, lab verisi ve Code Profiler nedeni gösterir.
- Önce kritik controller'larınızı Salesforce'un yayımladığı medyanlarla karşılaştırın.
- Her entegrasyonu bilinçli bir timeout ve açık circuit breaker ile servis framework'ünden geçirin.
- Kota uyarıları erken alarmdır; enforced ihlaller alışverişçinin gördüğü hatalardır.
- Görsel URL'lerini `URLUtils` veya `MediaFile` ile, slot'a göre boyutlandırarak ve modern formatlarda üretin.
- Önce yüksek etkili, düşük eforlu bulguları düzeltin, sonra yeniden ölçün.

Storefront'unuz için bağımsız bir performans denetimi istiyorsanız [hizmet sayfasında](https://www.ozanaltinbas.com/tr/hizmet) nasıl çalıştığıma bakın veya [benimle iletişime geçin](https://www.ozanaltinbas.com/tr/iletisim).

## Ek kaynaklar

- [Troubleshooting Salesforce B2C Commerce Performance](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-troubleshooting-platform-performance.html): referans medyanlar, Technical raporu ve bir teşhis sırası.
- [Site Performance](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-site-performance.html): Code Profiler modları ile performans ve kararlılık kodlama standartları.
- [Web Services](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-webservices.html): servis profilleri, timeout'lar, circuit breaker ve Service Status.
- [Governance and Quotas](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-governance-and-quotas.html): kota eylemleri, Quota Status ve kota log dosyaları.
- [Dynamic Imaging Service](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-dynamic-imaging-service.html): dönüşüm parametreleri, limitler ve önbellek.
- [Monitor the Performance of Your Storefront](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/perf-monitor.html): saha ve lab verisi, CrUX ve Core Web Vitals eşikleri.
