Ana içeriğe atla
OZAN ALTINBAŞ
Performans ve SEO

SFCC Performans Optimizasyonu: Storefront Denetim Listesi

Yazar: 12 dk okuma

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). 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 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, 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 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ğiSFCC'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ı

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

PipelineGrid geneli medyan
Search-Show400 ms
Product-Show300 ms
Cart-Show400 ms
Home-Show90 ms
Page-Show90 ms
Product-HitTile10 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 noktaNeye bakılırÇözüm
İstek başına hook'lar10 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 aramalarArama sonuçlarını filtreleyen veya sıralayan kodHer kriteri sorgunun içine koyun
Listelemelerde varyant döngüleriTile başına Product.getVariants() veya Product.getVariationModel()ProductSearchHit metotları (aşağıda)
Yoğun sayfalarda veritabanı ağırlıklı API'lerCategory.getProducts(), Category.getOnlineProducts(), ProductMgr.queryAllSiteProducts(), Product.getPriceModel()Index dostu ProductSearchModel API'leri
Sayfalanmamış sonuç kümeleriTamamı işlenen veya render edilen sonuç kümeleriSayfa boyutu sınırlı PagingModel; Salesforce'un örneği "View all" dahil 120 üründür
Gezinme sayfalarında canlı çağrılarAna sayfa, kategori, arama veya ürün sayfalarında dış çağrılarVeriyi 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'larBir job; web katmanı tarayıcı bağlantılarını 5 dakika sonra kapatır
Nesne şişmesiGereksiz session nesneleri ve cookie'ler, her anonim alışverişçi için açılan wishlist, hiç temizlenmeyen custom object'lerYalnı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ı, her sonuç için ürünleri yüklemek çok pahalı olduğundan getProducts() metodunu deprecated ilan eder.

'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); 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). 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 nesnesinin status'u SERVICE_UNAVAILABLE, unavailableReason değeri ise CIRCUIT_BROKEN, RATE_LIMITED veya TIMEOUT olur. Fallback'i ihtiyaç duymadan önce tasarlayın:

'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 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 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 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, Object Quotas):

KotaLimit (uyarı)Genellikle ne anlama gelir
api.dw.serviceTimeoutNotSet0Makul 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 0Tü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.collectionSize20.000 (12.000)Bellekte kurulan büyük koleksiyonlar
api.jsStringLength1.000.000 (600.000)Çoğunlukla bellekte birleştirilen JSON veya HTML'den oluşan dev string'ler
object.NonStageableCustomObjectPOInstance 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 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 parametresiTransform nesnesi anahtarıNotlar
sw, shscaleWidth, scaleHeight10 ile 3.000 piksel arası
smscaleModecut (varsayılan) veya fit; yalnızca iki boyutla birlikte
qqualityJPG ve JP2: 1 ile 100 arası, varsayılan 80
Dosya uzantısı, sfrmformatHedefler arasında AVIF ve WebP var; çıktıyı uzantı seçer, sfrm kaynak formatı belirtir
stripstripEXIF 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.

// 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, 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 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 ş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?; rate limit ve load shedding için SCAPI ve OCAPI farkı; hook tasarımı için SFCC hook rehberi.


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.

BulguEtkiEforSıra
Önbelleğe alınmamış yoğun controller veya includeYüksekDüşük1
Timeout'u veya circuit breaker'ı olmayan gezinme sayfası entegrasyonuYüksekDüşük1
Production'da enforced kota ihlalleriYüksekDüşük-orta1
LCP template'lerinde büyük görsellerYüksekDüşük1
Yoğun saatlerde önbellek temizliği veya replikasyonYüksekDüşük (süreç)1
Varyant döngüleri veya sonradan işlenen aramalarYüksekOrta2
Pahalı onRequest mantığıYüksek (her istekte)Orta2
Senkron üçüncü taraf tag'lerOrta-yüksekDüşük-orta2
İstemci JavaScript ve CSS ağırlığıOrtaOrta-yüksek3
Storefront'u yeniden platformlamakDeğişkenYüksekYalnı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 nasıl çalıştığıma bakın veya benimle iletişime geçin.

Ek kaynaklar