Kullanıcı Etkileşimlerini Yavaşlatmayan Animasyon Teknikleri

Kullanıcı Etkileşimlerini Yavaşlatmayan Animasyon Teknikleri, yalnızca ekranda daha akıcı hareketler üretmek için değil, kullanıcının tıklama, kaydırma, yazma ve sürükleme gibi temel işlemlerine hızlı cevap veren arayüzler oluşturmak için ele alınmalıdır. On yılı aşkın frontend çalışmalarında gördüğüm en yaygın hata, animasyon performansının yalnız FPS değeriyle ölçülmesidir; oysa kullanıcı butona bastığında tepki gecikiyorsa ekranda 60 FPS çalışan dekoratif hareketlerin pek anlamı kalmaz. Bu nedenle web animasyonları kullanıcı etkileşimini yavaşlatmadan nasıl optimize edilir sorusunun cevabı, CSS veya JavaScript seçmekten önce browser rendering pipeline içinde hangi işi oluşturduğunuzu anlamaktan geçer. Performanslı CSS animasyonları için transform ve opacity nasıl kullanılır, CSS JavaScript ve Web Animations API performans karşılaştırması nasıl yapılır ve 60 FPS animasyon için requestAnimationFrame GPU acceleration ve layout shift optimizasyonu nasıl birlikte düşünülür gibi soruları bu rehberde uygulama perspektifiyle ele alacağız. Amacımız yalnız daha güzel hareketler üretmek değil, düşük güçlü telefonda bile kullanıcı input'unu öne alan, erişilebilir ve ölçülebilir animasyon sistemi kurmaktır.

Web Animasyonlarında Performans Neden Önemlidir?

Web animasyonu kullanıcıya durum değişimini anlatabilir, bir öğenin nereden geldiğini gösterebilir ve arayüzdeki ilişkiyi daha anlaşılır hale getirebilir. Ancak animasyon sırasında main thread uzun süre meşgulse kullanıcı tıklaması, klavye girdisi veya scroll işlemi gecikebilir ve görsel kalite doğrudan kullanılabilirlik problemine dönüşebilir. Performans değerlendirmesinde yalnız frame rate değil interaction latency, paint maliyeti, layout süresi ve JavaScript task uzunluğu birlikte ele alınmalıdır. Özellikle kurumsal uygulamalarda aynı ekranda tablo, grafik, form ve modal gibi birçok yoğun bileşen bulunabildiği için dekoratif hareketlerin işlem bütçesi kontrollü tutulmalıdır. Animasyonun hedefi kullanıcıyı bekletmek değil arayüzün durumunu daha hızlı anlamasını sağlamak olmalıdır.

Animasyon Görsel Bir Özellikten İbaret Değildir

Animasyon çoğu zaman tasarım katmanının küçük bir süsü gibi değerlendirilir, fakat doğru kullanıldığında kullanıcıya state değişimini, hiyerarşiyi ve neden sonuç ilişkisini açıklayan iletişim aracına dönüşür. Bir drawer'ın sağdan gelmesi, kullanıcının yeni içeriğin mevcut sayfaya bağlı ikincil alan olduğunu anlamasını sağlayabilir. Aynı hareket 800 milisaniye sürer ve kullanıcı kapanmasını beklemek zorunda kalırsa fayda hızla kaybolur. Bu nedenle hareketin süresi, kesilebilirliği ve kullanıcı input'una verdiği öncelik görsel tasarım kadar önemlidir. Tasarım ekibiyle frontend ekibinin animasyonu yalnız easing ve duration üzerinden değil interaction contract üzerinden konuşması daha iyi sonuç verir.

Yavaş Animasyon Kullanıcı Etkileşimini Nasıl Etkiler?

Yavaş animasyonun etkisi yalnız hareketin takılması değildir; kullanıcı yeni state'e geçmek istediğinde eski animasyonun bitmesini bekliyorsa interaction doğrudan gecikir. Menü kapanmadan navigation başlatılmaması, modal fade tamamlanmadan butonun aktif olmaması veya accordion hareketinin input handler içinde ağır hesaplama başlatması buna örnektir. Bu tür yapılar kullanıcının cihazı güçlü olduğunda fark edilmeyebilir, ancak düşük CPU kapasitesinde gecikme belirginleşir. Uzun JavaScript task'ları input delay'i artırabilir ve INP sonuçlarını olumsuz etkileyebilir. Bu nedenle kullanıcı action'ının görsel animasyonun tamamlanmasına gereksiz şekilde bağlanmaması önemli bir frontend prensibidir.

Jank Nedir?

Jank, animasyon veya scroll sırasında framelerin beklenen zamanda üretilememesi nedeniyle hareketin takılıyor, sıçrıyor veya düzensiz görünmesidir. Browser bir frame için gerekli JavaScript, style, layout, paint ve composite işlerini ekran yenileme deadline'ından önce tamamlayamazsa frame atlanabilir. Kullanıcı bunu özellikle drag, scroll ve büyük panel geçişlerinde kolayca fark eder. Jank yalnız düşük FPS ortalamasıyla anlaşılmaz, çünkü birkaç ağır frame genel ortalamanın içinde saklanabilir. Performance trace üzerinde frame sürelerini, long task'ları ve layout sıçramalarını birlikte görmek gerçek sorunun kaynağını daha iyi gösterir.

Input Lag Nedir?

Input lag kullanıcının fiziksel etkileşimi ile arayüzün bu etkileşime görünür cevap vermesi arasındaki gecikmedir. Kullanıcı butona dokunduğunda main thread başka bir animasyonun JavaScript işini yürütüyorsa event handler başlamadan önce bekleme oluşabilir. Handler hızlı olsa bile ardından gelen uzun style ve layout çalışması görünür feedback'i geciktirebilir. Bu nedenle input latency yalnız event listener kodunun süresine indirgenmemelidir. Kullanıcı deneyimi açısından en önemli hedeflerden biri, animasyon devam ederken bile yeni input geldiğinde uygulamanın mümkün olduğunca erken cevap vermesidir.

Smoothness ve Responsiveness Arasındaki Fark

Smoothness hareketin frameler arasında ne kadar düzenli ilerlediğini, responsiveness ise kullanıcı input'una ne kadar hızlı cevap verildiğini anlatır. Bir canvas animasyonu yüksek FPS ile çalışırken main thread sürekli yoğun hesaplama yapıyorsa aynı sayfadaki buton tıklaması geç işlenebilir. Bunun tersi de mümkündür; buton hızlı tepki verebilir fakat büyük layout animasyonu sırasında birkaç frame düşebilir. İyi frontend performansı bu iki hedefi birlikte değerlendirir. Ben performans incelemelerinde önce kullanıcının etkileşim zincirini kontrol edip ardından frame pacing'e bakmayı daha faydalı buluyorum, çünkü kullanıcı için hızlı tepki çoğu zaman dekoratif akıcılıktan önce gelir.

Akıcı Animasyon ile Hızlı Etkileşim Aynı Şey mi?

Akıcı animasyon ile hızlı etkileşim ilişkili olsa da aynı performans problemi değildir. FPS yüksek olabilir, fakat input sırasında uzun JavaScript task çalışıyorsa kullanıcı gecikme hissedebilir. Buna karşılık interaction hızlı tepki verirken karmaşık paint işlemleri bazı animasyon framelerinin düşmesine neden olabilir. Bu nedenle yalnız FPS meter açıp sistemi başarılı kabul etmek doğru değildir. Frame time, INP, long task, event handler süresi ve presentation delay aynı performans incelemesinde birlikte değerlendirilmelidir.

FPS

FPS bir saniyede kullanıcıya kaç frame sunulduğunu ifade eder ve animasyon smoothness hakkında temel sinyal sağlar. 60 Hz ekranda her yenileme aralığına bir frame yetiştirildiğinde yaklaşık 60 FPS elde edilir. Ancak ortalama 60 FPS değeri birkaç ağır frame'i gizleyebilir, bu nedenle frame distribution ayrıca izlenmelidir. 120 Hz ekranda aynı kullanıcı daha yüksek yenileme hızına alışmış olabilir ve 60 FPS hareket farklı hissedebilir. FPS değerini tek başarı kriteri yapmak yerine etkileşim gecikmesiyle birlikte değerlendirmek daha anlamlıdır.

Frame Time

Frame time tek frame'i üretmek için harcanan toplam süreyi ifade eder. JavaScript, style, layout, paint ve composite işlemlerinin toplamı frame deadline'ı geçtiğinde yeni frame zamanında hazır olmayabilir. 60 Hz için teorik aralık yaklaşık 16,7 milisaniyedir, fakat browser'ın başka işleri de bulunduğu için uygulamanın tamamını bu sürenin sonuna kadar tüketmesi güvenli değildir. Daha yüksek refresh rate bu bütçeyi daha da küçültür. Performance panelinde yüksek frame time görüldüğünde sorunu yalnız animation code içinde değil rendering pipeline'ın tüm aşamalarında aramak gerekir.

Input Latency

Input latency pointer, keyboard veya başka input'un alınmasıyla görünür arayüz cevabı arasındaki süreyi temsil eder. Ana thread üzerinde çalışan uzun task event'in başlamasını geciktirebilir. Handler içindeki yoğun hesaplama ikinci maliyet katmanıdır, style ve layout sonrasında üçüncü gecikme alanı oluşabilir. Bu zincir kullanıcıya “buton basmadı” hissi verir. Animasyon sistemi tasarlanırken event handler küçük tutulmalı ve görsel hareket gerektiğinde sonraki frame'e planlanmalıdır.

INP

INP, sayfadaki kullanıcı etkileşimlerinin responsiveness kalitesini ölçmeye yönelik Core Web Vitals metriğidir. Etkileşim zincirinde input delay, event processing ve sonraki paint'e kadar geçen bölüm önem taşır. Animasyon devam ederken main thread üzerindeki uzun script işleri etkileşimin başlamasını geciktirebilir. web.dev saha analizinde uzun script evaluation ve Long Animation Frame kayıtlarının yavaş etkileşimleri açıklamak için kullanılabileceğini gösteriyor. Bu nedenle animasyon performansını production RUM verisinde INP ile ilişkilendirmek yalnız laboratuvar FPS ölçümünden daha güçlü sonuç sağlar. :contentReference[oaicite:1]{index=1}

Animasyon 60 FPS Olurken Buton Neden Geç Tepki Verebilir?

Bir animasyon compositor üzerinde akıcı biçimde ilerlerken aynı anda main thread yoğun bir JavaScript task çalıştırıyor olabilir. Compositor hareketi belirli süre devam ettirebilir, fakat kullanıcı click event'i main thread tarafından işleneceği için yeni etkileşim bekleyebilir. Bu durum görsel smoothness ile responsiveness arasındaki farkın en iyi örneklerinden biridir. Kullanıcı ekranda hareket gördüğü için sistem canlı görünür, ancak buton tepki vermediğinde deneyim yine yavaş hissedilir. Bu yüzden production analizinde compositor animasyon başarısını kullanıcı interaction sonuçlarından ayrı değerlendirmek gerekir.

Tarayıcı Bir Frame'i Nasıl Oluşturur?

Browser bir frame oluştururken uygulamadaki değişikliğe bağlı olarak JavaScript execution, style calculation, layout, paint ve composite aşamalarından bir kısmını çalıştırabilir. Her CSS property aynı işlem zincirini tetiklemez. Layout değiştiren property çevredeki öğelerin geometrisini yeniden hesaplatabilirken bazı transform değişiklikleri uygun koşullarda daha geç pipeline aşamalarında işlenebilir. Bu fark animasyon performansının temelidir. Property seçimini yalnız görsel ihtiyaç üzerinden değil hangi rendering işini doğurduğu üzerinden yapmak daha doğru sonuç verir.

JavaScript

JavaScript input handler, animation loop, framework render veya hesaplama işlerini main thread üzerinde çalıştırabilir. Bir frame sırasında script çok uzun sürerse style ve layout için kalan süre azalır. requestAnimationFrame kullanmak callback'i doğru zamana planlar, fakat callback içindeki ağır hesaplamayı otomatik olarak hızlandırmaz. Bu yüzden animation loop içinde yalnız o frame için gerekli minimum işi yapmak gerekir. Ağır data processing mümkünse animasyondan ayrılmalı veya farklı zaman dilimlerine bölünmelidir.

Style Calculation

Style calculation DOM öğelerine hangi CSS kurallarının uygulanacağını hesaplayan aşamadır. Class değişiklikleri veya state güncellemeleri bu işlemi tetikleyebilir. Çok geniş DOM ve karmaşık selector yapısı hesaplama maliyetini artırabilir. Bir animasyonda her frame class değiştirmek gereksiz style hesaplamaları oluşturabilir. Animasyon state'ini transform veya opacity gibi doğrudan değişen property'lerle sınırlamak bu yükü azaltmaya yardımcı olabilir.

Layout

Layout öğelerin ekrandaki boyut ve konumlarının hesaplandığı aşamadır. Width, height, top ve bazı layout etkili property değişiklikleri bu hesaplamayı tetikleyebilir. Parent geometry değiştiğinde child ve sibling elementler de etkilenebilir. Büyük kurumsal dashboard gibi yoğun DOM yapılarında layout maliyeti animasyon sırasında hızla büyüyebilir. Bu nedenle görsel hareketi mümkün olduğunda transform üzerinden simüle etmek ve gerçek layout değişikliğini sınırlı tutmak faydalıdır.

Paint

Paint aşamasında browser hangi piksellerin nasıl çizileceğini belirler. Shadow, border, background ve bazı filter etkileri paint alanını büyütebilir. Büyük bir element her frame yeniden boyanıyorsa güçlü bilgisayarda bile maliyet fark edilmeyebilir, fakat mobil cihazda jank oluşturabilir. DevTools paint flashing hangi alanların yeniden boyandığını görmeye yardımcı olur. Animasyon sırasında büyük full-screen paint görüyorsanız önce hangi property değişiminin bunu tetiklediğini araştırmak gerekir.

Composite

Composite daha önce hazırlanmış katmanların ekranda doğru konum ve görünürlükle birleştirilmesi aşamasıdır. Transform ve opacity gibi bazı değişiklikler uygun browser koşullarında layout ve paint'i atlayarak compositor seviyesinde işlenebilir. Bu durum onları hareket animasyonları için güçlü başlangıç noktası yapar. Ancak “transform kullandım, kesin GPU'da çalışır” şeklinde garanti verilmemelidir, çünkü layer kararı browser implementation ve element özelliklerine bağlıdır. Gerçek sonucu DevTools trace ve layer analiziyle görmek gerekir.

Browser Rendering Pipeline

Rendering pipeline animasyon sırasında hangi property seçiminin neden pahalı veya ucuz olabileceğini açıklayan en yararlı modeldir. Bazı değişiklikler JavaScript sonrası style, layout, paint ve composite zincirinin tamamını çalıştırabilir. Bazıları layout aşamasını atlayıp paint ve composite'e gidebilir. Uygun koşullarda bazı transform ve opacity değişiklikleri yalnız composite tarafına yakın çalışabilir. Bu nedenle performanslı animasyon tasarımının merkezinde library değil değiştirilen property ve oluşturulan workload vardır.

JavaScript → Style → Layout → Paint → Composite

Bu yol en fazla rendering işinin oluştuğu senaryoyu temsil eder. JavaScript style değiştirir, yeni geometry hesaplanır, pikseller yeniden hazırlanır ve son olarak layer'lar birleştirilir. Her frame width veya top değiştiren büyük animasyonlar bu tür zincire yaklaşabilir. DOM büyüdükçe layout ve paint maliyeti daha yüksek hale gelir. Hareket yalnız görsel konum değişimiyse transform'a dönüştürmek çoğu zaman daha uygun tasarımdır.

Style → Paint → Composite

Bazı property değişiklikleri element geometrisini değiştirmeden yeniden çizim gerektirebilir. Background color veya shadow gibi görsel özellikler bu gruba yaklaşabilir. Layout yapılmaması maliyeti azaltır, fakat büyük paint alanı yine pahalı olabilir. Özellikle full-screen blur veya geniş box-shadow animasyonlarında repaint yükü önem kazanır. Paint alanı ve sıklığı gerçek trace üzerinden ölçülmelidir.

Style → Composite

Uygun şartlarda transform ve opacity gibi property'ler daha kısa pipeline ile işlenebilir. Browser ilgili element için compositor layer kullanabiliyorsa hareket geometry veya pixel repaint ihtiyacını azaltabilir. Bu yaklaşım menu slide, button press ve modal enter gibi mikro etkileşimlerde oldukça etkilidir. Yine de layer oluşturmanın memory maliyeti vardır. Compositor path'i amaç edinmek yerine kullanıcı input'una daha fazla main thread bütçesi bırakmak için araç olarak görmek gerekir.

En Ucuz Rendering Path Hangisidir?

Genel olarak en az pipeline aşamasını tetikleyen ve en küçük görsel alanı değiştiren path daha düşük maliyetlidir. Ancak tek başına composite path her zaman bedava değildir, çünkü layer memory, texture upload ve composite işlemi yine kaynak kullanır. Yüzlerce element ayrı layer olursa GPU memory ve management maliyeti büyüyebilir. Bu nedenle hedef “her şeyi GPU'ya atmak” değildir. Hedef, kullanıcı etkileşimi sırasında gereksiz style, layout, paint ve script işini azaltmaktır.

Frame Budget Nedir?

Frame budget browser'ın bir ekran yenileme aralığı içinde yeni frame'i hazırlamak için sahip olduğu yaklaşık zaman aralığını ifade eder. 60 Hz ekran yaklaşık 16,7 milisaniyede bir yenilenirken 120 Hz ekran yaklaşık 8,3 milisaniyede bir yeni görüntü ister. Bu sürenin tamamı uygulama JavaScript'ine ait değildir, çünkü browser input, rendering ve başka işleri de yürütür. Bu nedenle animation callback'in bütçenin tamamını tüketmemesi gerekir. Refresh rate yükseldikçe aynı kodun daha önce fark edilmeyen maliyetleri daha görünür hale gelebilir.

60 Hz Ekran

60 Hz ekran saniyede yaklaşık altmış yenileme yapar ve web performansında uzun süre varsayılan referans olmuştur. Her yenileme aralığı yaklaşık 16,7 milisaniyedir. Bu sürede JavaScript, rendering ve composite işi tamamlanamazsa frame düşebilir. Ancak uygulamanın tam 16,7 milisaniye JavaScript kullanması güvenli değildir. Input işlemleri için ek zaman bırakmak responsive arayüz açısından daha değerlidir.

Yaklaşık 16,7 ms Frame

Bir saniyenin altmış parçaya bölünmesi yaklaşık 16,7 milisaniyelik frame interval verir. Bu değer teorik üst sınır gibi düşünülmeli, hedef JavaScript çalışma süresi olarak kullanılmamalıdır. Browser'ın style, layout, paint ve system scheduling gibi ek işleri vardır. Özellikle interaction sırasında event processing de aynı aralığa girebilir. Animasyon callback'ini birkaç milisaniyelik küçük işlerle sınırlamak daha güvenli yaklaşımdır.

90 Hz Ekran

90 Hz cihazlarda frame aralığı yaklaşık 11,1 milisaniyeye düşer. Mobil cihazlarda yüksek refresh rate yaygınlaştıkça yalnız 60 Hz'e göre test yapmak yeterli değildir. Animasyon time-based hesaplanmıyorsa daha yüksek callback frequency hareket hızını değiştirebilir. requestAnimationFrame timestamp kullanmak bu nedenle önemlidir. Gerçek cihaz testi frame pacing sorunlarını emulator'dan daha iyi gösterebilir.

120 Hz Ekran

120 Hz ekran saniyede yüz yirmi kez yenilenebilir ve frame interval 60 Hz'in yaklaşık yarısına iner. Kullanıcı hızlı scrolling ve gesture sırasında daha akıcı hareket bekleyebilir. Aynı animasyon workload'u her frame tekrarlandığında işlem sıklığı arttığı için CPU maliyeti de hissedilebilir. Timestamp tabanlı progression kullanılmalıdır. Yalnız FPS değil battery ve thermal davranış da mobil testte dikkate alınmalıdır.

Yaklaşık 8,3 ms Frame

120 Hz yenilemede frame başına teorik aralık yaklaşık 8,3 milisaniyedir. Bu kadar kısa aralıkta 6 veya 7 milisaniyelik JavaScript işi bile browser rendering ve input için dar alan bırakabilir. requestAnimationFrame callback'in yüksek refresh rate ekranlarda daha sık çağrılabileceği unutulmamalıdır. MDN de animation progression hesaplamak için callback timestamp değerinin kullanılmasını özellikle önerir. Böylece animasyon 60 Hz ve 120 Hz cihazlarda zamana bağlı olarak tutarlı ilerler. :contentReference[oaicite:2]{index=2}

Browser Overhead

Frame budget yalnız application code'a ayrılmış boş zaman değildir. Browser input dispatch, style calculation, layout, rasterization ve compositing gibi işlemleri yürütür. Extension, operating system ve başka process'ler de CPU yarışına girebilir. Bu yüzden performance test yalnız boş developer laptop'ında yapılmamalıdır. CPU throttling ve gerçek düşük güçlü cihaz testleri daha gerçekçi güvenlik payı sağlar.

Frame Deadline Kaçırılırsa Ne Olur?

Frame hazır değilse browser mevcut görüntüyü daha uzun süre gösterebilir ve kullanıcı hareketin düzensiz olduğunu hisseder. Birkaç ardışık deadline kaçırıldığında scroll veya drag jank belirginleşir. Input event de aynı sırada bekliyorsa responsiveness aynı anda kötüleşebilir. Frame drop sayısını tek başına değil hangi task'ın deadline'ı aştırdığıyla birlikte incelemek gerekir. DevTools main thread flame chart bu bağlantıyı görmeye yardımcı olur.

60 FPS Her Zaman Hedef Olmalı mı?

60 FPS yararlı referanstır, ancak her cihaz ve interaction için tek hedef değildir. 120 Hz ekranda kullanıcı daha yüksek frame rate görebilirken düşük güçlü cihazda enerji ve CPU sınırı daha kritik hale gelebilir. Kullanıcı açısından önemli olan hareketin tutarlı olması ve input'un takılmamasıdır. Bu nedenle “mutlaka 60 FPS” yerine “etkileşimi düşürmeden cihazın yenileme ritmine uyum sağlayan hareket” daha sağlıklı hedeftir. Decorative animasyonlar gerekirse düşük güçlü cihazlarda azaltılabilir.

Frame Rate ve Refresh Rate

Refresh rate ekranın saniyede kaç kez yenilenebildiğini, frame rate uygulamanın kaç yeni frame üretebildiğini anlatır. 120 Hz ekran 120 FPS kapasitesine sahip olabilir, ancak uygulama her yenilemeye yeni frame yetiştirmeyebilir. Browser scheduling ve OS davranışı sonucu etkiler. requestAnimationFrame genellikle display refresh rate ile uyumlu callback zamanlaması sağlar. Bu yüzden sabit 16 milisaniye varsayımı yerine timestamp kullanılmalıdır. :contentReference[oaicite:3]{index=3}

120 Hz Cihazlar

120 Hz cihazlar animation loop'un daha sık çalışmasına neden olabilir. Her callback'te ağır computation varsa toplam CPU tüketimi artabilir. Hareket distance per frame yerine time delta üzerinden hesaplanmalıdır. Test sırasında DevTools yanında gerçek cihaz screen recording veya RUM data kullanılabilir. High refresh support görsel kalite kadar enerji tüketimini de düşünmelidir.

Düşük Güçlü Telefonlar

Düşük güçlü telefonlarda CPU, GPU, memory bandwidth ve thermal kapasite daha sınırlıdır. Developer workstation'da akıcı çalışan blur veya particle effect cihazda hızlıca jank oluşturabilir. Network throttling asset decode ve initialization süresini de etkiler. Reduced-feature mobile animation tasarlamak kullanıcı deneyimini koruyabilir. Ancak hardware tahmininden önce kullanıcının prefers-reduced-motion tercihi daha yüksek öncelik taşımalıdır.

Tutarlı Frame Pacing

Tutarlı frame pacing hareketin frameler arasında eşit zaman dağılımına yakın ilerlemesini sağlar. Ortalama FPS yüksek olsa bile arada 40 milisaniyelik frame oluşursa kullanıcı sıçrama hissedebilir. Bu nedenle percentile veya individual frame duration incelenmelidir. Animation loop delta time kullanmalıdır. Ağır work mümkünse frame dışına veya daha seyrek güncellemeye taşınmalıdır.

60 FPS Yerine “No Dropped Interaction” Yaklaşımı

“No Dropped Interaction” yaklaşımı görsel frame hedefinden önce kullanıcı input'unun gecikmemesini önemser. Dekoratif animation bir frame kaybedebilir, fakat kullanıcı click'inin yüzlerce milisaniye beklemesi daha ciddi UX problemidir. Main thread budget bu önceliğe göre dağıtılmalıdır. Animasyon user input geldiğinde azaltılabilir, kesilebilir veya sonraki frame'e taşınabilir. Bu yaklaşım özellikle kurumsal uygulamalarda form, tablo ve workflow ekranlarında daha doğru performans kriteri sunar.

INP Nedir ve Animasyonlarla Nasıl İlişkilidir?

INP kullanıcı etkileşimlerinden sonra sayfanın ne kadar hızlı görsel cevap ürettiğini değerlendiren önemli responsiveness metriğidir. Animasyon sırasında main thread uzun süre JavaScript, framework render, layout veya paint işi yürütüyorsa interaction gecikmesi artabilir. Bu nedenle animation optimization yalnız smoothness amacıyla değil Core Web Vitals açısından da önemlidir. Saha verisi laboratuvar testinden farklı cihaz ve kullanıcı koşullarını gösterir. Animasyon workload'u ile INP outlier'larını aynı telemetry kaydı içinde ilişkilendirmek performans araştırmasını hızlandırır.

Interaction to Next Paint

Interaction to Next Paint kullanıcı input'unun işlenip bir sonraki görünür güncellemenin ekrana gelmesine kadar oluşan deneyimi ölçmeye odaklanır. Click, tap ve keyboard interaction bu bağlamda önemlidir. Bir animasyon long task yaratıyorsa input handler başlayamayabilir. Handler hızlı olsa bile sonraki rendering işi uzarsa presentation gecikir. Bu yüzden animation sırasında browser'ın kullanıcıya paint üretebilmesi için sık sık boşluk bırakmak gerekir.

Input Delay

Input delay event'in browser tarafından alınmasıyla handler'ın başlayabilmesi arasındaki bekleme bölümüdür. Main thread yoğun bir animation task yürütüyorsa event queue'da kalabilir. Özellikle her frame büyük JavaScript array işlemek veya framework state güncellemek bu gecikmeyi artırabilir. Long task'ları bölmek ve compositor-friendly animation kullanmak faydalıdır. Production INP attribution input delay'in hangi script nedeniyle yükseldiğini göstermeye yardımcı olabilir. :contentReference[oaicite:4]{index=4}

Event Handler Süresi

Handler süresi click veya pointer event callback'inin yürüttüğü iş miktarına bağlıdır. Handler içinde layout ölçüp style yazmak, API sonucu işlemek veya ağır component render tetiklemek süreyi uzatabilir. Immediate visual feedback için küçük state değişikliği yapılabilir ve daha ağır iş sonraki task'e planlanabilir. Handler'ın animation preparation işiyle dolması gereksizdir. Kullanıcı action'ını kabul etmek ile dekoratif transition başlatmak ayrı sorumluluklar olarak düşünülebilir.

Presentation Delay

Handler tamamlandıktan sonra browser'ın style, layout, paint ve composite işlerini bitirip sonucu göstermesine kadar ek gecikme oluşabilir. Büyük DOM değişikliği presentation delay'i artırabilir. Animation state change çok fazla element etkiliyorsa kullanıcı click sonucu geç görünür. Bu nedenle immediate pressed state küçük transform veya opacity değişimiyle verilebilir. Ağır content update daha sonra yapılabilir.

Animation Sırasında INP'nin Kötüleşmesi

Animation devam ederken kullanıcı interaction geldiğinde aynı main thread üzerinde yarış oluşabilir. requestAnimationFrame callback'i, framework update ve event handler aynı zaman diliminde birleşebilir. Görsel hareket akıcı görünse bile input delay veya presentation delay yükselir. RUM verisinde interaction anındaki Long Animation Frame kayıtları incelenebilir. Animasyonun gerektiğinde durması veya iş yükünü azaltması bu tür sorunları hafifletir. :contentReference[oaicite:5]{index=5}

Animasyon Sırasında Main Thread Neden Kritik?

Main thread web sayfasındaki JavaScript, birçok style ve layout işi ile kullanıcı event handler'larının ortak çalışma alanıdır. Bu nedenle animasyonun main thread'i sürekli meşgul etmesi doğrudan input responsiveness ile yarışır. Framework render, DOM measurement ve paint hazırlığı aynı zaman dilimine girdiğinde frame budget hızla tükenir. Compositor-friendly yaklaşımın gerçek avantajı yalnız daha yüksek FPS değil main thread'e daha fazla boşluk bırakmasıdır. Kullanıcı input'u geldiğinde browser'ın mümkün olduğunca kısa sürede handler çalıştırabilmesi ana hedef olmalıdır.

JavaScript Execution

Animation loop içinde sürekli JavaScript çalıştırmak main thread'e düzenli yük bindirir. Physics veya canvas gibi ihtiyaçlarda bu gerekli olabilir. Basit fade veya slide için CSS veya WAAPI daha az application-level script gerektirebilir. Ağır hesaplama frame callback dışında yapılmalıdır. Long task oluşuyorsa iş parçalara bölünmelidir.

Framework Rendering

React veya başka framework state update'i component tree reconciliation ve DOM update üretebilir. Her animation frame setState çağırmak gereksiz render zinciri oluşturabilir. UI state ile animation progress state ayrılmalıdır. Motion value veya DOM ref gibi daha doğrudan yollar bazı durumlarda daha uygundur. Framework profiler ile render sayısı kontrol edilmelidir.

Layout

Layout browser'ın element geometry'sini yeniden hesaplamasını gerektirir. Animation sırasında her frame geometry değişirse main thread süresi artabilir. Büyük table veya dashboard içinde etki daha geniş olur. Containment ve transform alternatifleri düşünülebilir. Layout gerekiyorsa scope mümkün olduğunca küçük tutulmalıdır.

Paint

Paint ağır görsel efektlerin yeniden çizilmesini gerektirir. Full-screen blur, large shadow veya gradient animation mobile cihazlarda pahalı olabilir. Paint alanı layer sınırlarıyla azaltılabilir. Pseudo element kullanıp opacity değiştirmek bazı shadow geçişlerini daha ucuz hale getirebilir. Paint flashing ile gerçek etki doğrulanmalıdır.

User Input Handler

User input handler'ın çalışabilmesi için main thread'in uygun anda boş olması gerekir. Animation script sürekli uzun task üretirse handler bekler. Drag gibi yüksek frekanslı interaction'da pointermove eventleri birikebilir. Son input position saklanıp requestAnimationFrame içinde tek visual update yapılması daha iyi olabilir. Böylece event sayısı ile render sayısı birebir bağlanmaz.

Aynı Thread İçin Rekabet

Animation ve interaction aynı thread üzerinde işlem zamanı istediğinde öncelik tasarım kararı haline gelir. Kullanıcı input'u beklememelidir. Decorative animation gerektiğinde frame atlayabilir veya pause edilebilir. Critical transition kısa ve interruptible olmalıdır. Bu düşünce performans budget'ın merkezine kullanıcıyı yerleştirir.

Compositor Thread Nedir?

Compositor thread bazı görsel katmanları main thread'den bağımsız biçimde birleştirebilen browser bileşenidir. Element uygun layer'a sahipse transform veya opacity değişikliği main thread layout ve paint işini azaltabilir. Scroll gibi bazı işlemler de compositor tarafında daha akıcı ilerleyebilir. Fakat her elementin ayrı layer olması iyi değildir, çünkü memory ve texture maliyeti oluşur. Compositor avantajından yararlanmak kontrollü property ve layer stratejisi gerektirir.

Main Thread'den Farkı

Main thread JavaScript ve DOM ağırlıklı işleri yürütürken compositor daha çok hazırlanmış layer'ların ekrandaki konum ve görünürlüğünü birleştirir. Bu ayrım user input sırasında değerlidir. Main thread kısa süre meşgul olsa bile bazı compositor animation frameleri ilerlemeye devam edebilir. Yine de yeni interaction logic main thread'e ihtiyaç duyabilir. Bu yüzden compositor kullanımı responsiveness için alan açar ama bütün sorunları çözmez.

Composite İşlemleri

Composite işlemi layer'ları final frame içinde bir araya getirir. Transform layer position'ını değiştirebilir, opacity görünürlük seviyesini ayarlayabilir. Pixel içeriği yeniden paint edilmeden hareket mümkün olabilir. Büyük layer sayısı composite maliyetini artırabilir. DevTools Layers görünümü gereksiz promotion sorunlarını bulmaya yardımcı olur.

Scroll ile İlişkisi

Modern browserlar scroll hareketinin bazı bölümlerini main thread'den bağımsız ilerletebilir. Ancak blocking touch veya scroll listener browser'ın main thread cevabını beklemesine neden olabilir. Passive listener kullanımı browser'a default scroll davranışının engellenmeyeceği sinyalini verebilir. Scroll-driven CSS animation da progress'i declarative timeline'a bağlayabilir. Böylece her pixel hareket için application JavaScript çalıştırma ihtiyacı azalabilir.

Compositor-Friendly Animasyonların Avantajı

Compositor-friendly animation layout ve paint yükünü azaltarak main thread üzerinde kullanıcı input'u için daha fazla alan bırakabilir. Menu slide, tooltip fade veya button press gibi küçük hareketlerde transform ve opacity güçlü başlangıç seçenekleridir. Fakat büyük texture'ların hareketi GPU memory kullanımını artırabilir. “Compositor-friendly” etiketi gerçek cihaz testi ihtiyacını ortadan kaldırmaz. Performans kararı DevTools ve RUM ile doğrulanmalıdır.

Hangi CSS Özellikleri Animasyon İçin En Güvenlidir?

Animasyon için genellikle ilk tercih transform ve opacity olmalıdır, çünkü bu property'ler uygun koşullarda layout ve paint işini azaltarak composite ağırlıklı ilerleyebilir. Ancak browser implementation, element boyutu ve efekt kombinasyonları sonucu değiştirebilir. Filter ve clip-path gibi property'ler bazı cihaz ve browserlarda hızlı olabilirken başka koşullarda paint veya GPU maliyeti yaratabilir. Bu nedenle sabit “performanslı property listesi” yerine rendering davranışı test edilmelidir. Yine de başlangıç tasarımında hareket ve görünürlük için transform ile opacity kullanmak güvenli bir varsayımdır.

transform

Transform elementin görsel konumunu, boyutunu veya dönüşünü layout akışını yeniden hesaplamadan değiştirebilir. Translate drawer hareketi, scale button feedback'i ve rotate ikon dönüşü için kullanılabilir. Transform origin hareket algısını etkiler. Büyük scale efektlerinde texture quality ve layer alanı düşünülmelidir. Layout gerçekten değişecekse visual transform son state ile uyumlu hale getirilmelidir.

translate

Translate elementi x veya y ekseninde görsel olarak taşır. Top veya left değiştirmek yerine off-canvas menu ve tooltip hareketinde güçlü alternatiftir. Document flow değişmediği için sibling geometry yeniden hesaplanmaz. Pointer hit area transform edilen konumu takip eder. Çok büyük layer'ın translate edilmesi yine composite ve texture maliyeti oluşturabilir.

scale

Scale elementin görsel boyutunu değiştirmek için kullanılabilir. Button press veya card hover microinteraction'da width ve height değişimine göre daha uygun olabilir. İçerik de birlikte ölçeklendiği için text raster görünümü kontrol edilmelidir. Layout çevredeki elementler için değişmez. Gerçek alan genişlemesi gerekiyorsa scale yalnız transition tekniği olarak kullanılmalıdır.

rotate

Rotate icon, chevron veya loader hareketleri için kullanılabilir. Layout geometry yeniden hesaplanmadan görsel dönüş sağlanabilir. Büyük element dönüşünde layer bounding area büyüyebilir. Continuous spinner infinite animation olduğu için visibility durumunda pause edilmelidir. Reduced motion tercihi dekoratif rotate hareketini azaltabilir.

opacity

Opacity elementin görünürlük seviyesini değiştirir ve fade transition için yaygın kullanılır. Layout değişmediği için geometry maliyeti düşüktür. Tamamen invisible element yine pointer event veya accessibility tree içinde olabilir, bu nedenle interaction state ayrıca yönetilmelidir. Modal exit sırasında focus davranışı opacity'den bağımsız ele alınmalıdır. Büyük semi-transparent layer composite maliyeti oluşturabileceği için gerçek cihaz testi yapılmalıdır.

Tarayıcıya Göre Değişebilen Compositor Özellikleri

Bazı CSS property'ler browser sürümü, GPU ve içerik yapısına göre farklı rendering path kullanabilir. Bu nedenle “bu property kesin compositor'da çalışır” şeklinde mutlak varsayım doğru değildir. Filter ve clip-path bunun iyi örnekleridir. Küçük bir elementte sorun çıkarmayan efekt full-screen panelde pahalı olabilir. DevTools Performance, paint flashing ve layer incelemesiyle gerçek davranış kontrol edilmelidir.

filter

Filter blur, brightness ve başka piksel işlemleri sağlar. Küçük element üzerinde kısa geçiş kabul edilebilir olabilir. Büyük blur radius ve geniş yüzey GPU veya paint maliyetini yükseltebilir. Filter animation mobile cihazda ayrıca test edilmelidir. Decorative etki düşük güçlü cihazlarda azaltılabilir.

clip-path

Clip-path reveal veya shape transition için güçlü görsel imkan sunar. Rendering maliyeti kullanılan şekil ve browser implementation'a göre değişebilir. Basit inset animasyonu ile complex polygon aynı performans profiline sahip değildir. Büyük alanlarda paint veya compositing davranışı incelenmelidir. Fallback veya daha basit transform alternatifi hazır tutulabilir.

Neden top ve left Yerine transform Kullanılmalı?

Top ve left positioned elementin layout geometry'sini değiştirebildiği için animation sırasında daha fazla rendering işi oluşturabilir. Transform translate ise elementi görsel olarak taşırken document flow geometry'sini değiştirmez. Bu fark özellikle her frame hareket eden drawer, tooltip veya draggable elementlerde önemlidir. Ancak top veya left hiçbir zaman kullanılmamalı şeklinde katı bir kural yoktur; tek seferlik layout konumu için gayet uygundur. Sürekli animation loop söz konusu olduğunda translate daha iyi başlangıçtır.

Layout Recalculation

Top veya left değişikliği layout etkisi oluşturabilir. Browser element konumunu ve gerektiğinde çevresini yeniden hesaplar. Büyük DOM'da bu maliyet artar. Animation her frame aynı işi tetiklediğinde frame budget zorlanır. Transform visual movement ile bu ihtiyacı azaltabilir.

Repaint

Layout sonrası pixel içeriğinin yeniden paint edilmesi gerekebilir. Element shadow veya complex child içeriyorsa maliyet büyüyebilir. Paint area Performance panelde incelenebilir. Translate edilmiş compositor layer paint'i tekrar kullanabilir. Ancak layer'ın kendisi çok büyükse composite maliyeti yine vardır.

Composite-Only Hareket

Transform uygun koşullarda yalnız composite seviyesinde hareket edebilir. Bu durum main thread layout ve paint işini azaltır. User input için daha fazla zaman kalabilir. Browser layer kararı otomatik verir. Gerektiğinde will-change kısa süreli hint olarak kullanılabilir, fakat sürekli her elemente eklenmemelidir.

translate Örneği

Drawer açarken left: -100% değerinden left: 0 değerine geçmek yerine transform: translateX(-100%) ile başlayıp translateX(0) değerine geçmek daha uygun olabilir. Element başlangıçtan layout içindeki final boyutuna sahip olur. Hareket yalnız visual offset üzerinden yapılır. Overlay opacity aynı anda animasyon alabilir. Focus ve Escape davranışı animasyon süresinden bağımsız çalışmalıdır.

width ve height Animasyonlarının Maliyeti

Width ve height değişiklikleri element geometry'sini doğrudan etkilediği için layout hesaplamasını tetikleyebilir. Parent veya child ilişkileri nedeniyle etki yalnız animasyon verilen elementle sınırlı kalmayabilir. Accordion ve expandable panel gibi bileşenlerde bu durum sık görülür. Küçük, izole DOM alanında maliyet kabul edilebilir olabilir. Büyük layout değişikliklerinde scale, grid teknikleri, FLIP veya View Transition gibi alternatifler değerlendirilmelidir.

Layout Değişikliği

Width veya height değiştiğinde browser yeni geometry hesaplar. Flex veya grid container içinde sibling position da değişebilir. Text wrapping farklılaşabilir. Her frame layout maliyeti oluşabilir. DevTools trace gerçek süreyi gösterebilir.

Child Element'lerin Etkilenmesi

Parent genişliği değiştiğinde child text yeniden satıra bölünebilir. Image veya percentage width yeniden ölçülebilir. Büyük component tree etkilenebilir. Container isolation maliyeti azaltabilir. Animation yalnız visual olabiliyorsa scale daha uygun olabilir.

Sibling Element'lerin Etkilenmesi

Normal flow içinde element yüksekliği değiştiğinde aşağıdaki sibling'ler yeni konuma taşınır. Accordion bunun tipik örneğidir. Bu hareket kullanıcı için gerekli olabilir. Küçük listelerde doğrudan layout kabul edilebilir. Yoğun sayfada FLIP ile visual movement daha kontrollü hale getirilebilir.

Scale ile Görsel Alternatif

Scale element boyutunu görsel olarak değiştirir fakat layout alanını değiştirmez. Hover card büyümesi gibi decorative durumda iyi alternatiftir. Accordion gibi gerçek content alanı açılması gereken durumda tek başına scale uygun değildir. Text scale edilirse distortion hissi oluşabilir. Bu nedenle scale yalnız visual geometry ile document geometry arasındaki fark kullanıcıyı yanıltmadığında kullanılmalıdır.

Layout Animasyonu Gerekiyorsa Ne Yapılmalı?

Bazı arayüzlerde gerçek layout değişikliği kaçınılmazdır ve performanslı tasarım bu gereksinimi yok saymamalıdır. Önce layout etkisini küçük bir container içinde tutmak, ardından containment veya FLIP gibi tekniklerle yeniden hesaplama alanını azaltmak gerekir. View Transition API bazı state değişikliklerini snapshot tabanlı geçişe dönüştürebilir. Bu seçenekler kullanılmadan önce browser desteği ve accessibility davranışı değerlendirilmelidir. Son karar gerçek cihaz profiling sonucu verilmelidir.

Küçük ve İzole Layout

Layout animation küçük DOM subtree içinde kalıyorsa maliyet çoğu zaman yönetilebilir olur. Accordion content container ayrı bir alan olarak tasarlanabilir. Global page layout her frame yeniden hesaplanmamalıdır. Component sınırı performance sınırı olarak da düşünülmelidir. DevTools layout duration ile etki doğrulanabilir.

CSS Containment

CSS containment browser'a bir bölümün layout veya paint etkisinin dışarıya sınırlı olduğunu anlatabilir. Bu sayede büyük sayfalarda yeniden hesaplama alanı küçülebilir. Yanlış contain değeri ölçüm veya sticky behavior gibi özellikleri etkileyebilir. Component bazında test edilmelidir. Performans kazanımı yalnız gerçek trace ile doğrulanmalıdır.

FLIP

FLIP önce eski ve yeni geometry'yi ölçer, ardından farkı transform ile tersleyip görsel transition üretir. Böylece final layout tek seferde uygulanabilir ve hareket transform üzerinden gerçekleşebilir. Liste reorder ve grid değişimi için güçlü tekniktir. DOM read ve write aşamalarını karıştırmamak önemlidir. Layout ölçümleri animation loop içinde sürekli tekrar edilmemelidir.

View Transition API

View Transition API eski ve yeni görünümün snapshot'larını kullanarak DOM state değişiklikleri arasında animasyon kurmayı kolaylaştırır. Aynı document state değişimleri ve uygun koşullarda cross-document navigation için kullanılabilir. MDN, API'nin SPA ve MPA geçişlerini desteklediğini ve snapshot tabanlı süreci browser tarafından yönettiğini açıklıyor. 2026 itibarıyla temel View Transition desteği modern browserlarda daha geniş hale gelmiş olsa da alt özelliklerin uyumluluğu yine kontrol edilmelidir. Progressive enhancement yaklaşımı en güvenli yöntemdir. :contentReference[oaicite:6]{index=6}

Gerçek Cihazda Profiling

Layout animation teorik olarak optimize görünse bile gerçek cihaz sonucu farklı olabilir. Mobile CPU, GPU ve memory bandwidth developer laptop'ından daha sınırlıdır. Touch interaction ve thermal throttling ek etki oluşturur. En az bir düşük güçlü Android cihaz ve yüksek refresh rate cihazla test yapmak değerlidir. RUM sonrasında production segmentlerini doğrular.

FLIP Animasyon Tekniği Nedir?

FLIP, First, Last, Invert ve Play adımlarından oluşan layout transition yaklaşımıdır. Önce elementin mevcut geometry'si ölçülür, sonra final layout uygulanıp yeni geometry elde edilir. İki durum arasındaki fark transform ile terslenerek element eski yerde görünmeye devam eder. Ardından transform sıfıra animasyonla götürülerek kullanıcıya akıcı layout hareketi gösterilir. Bu teknik gerçek layout değişikliğini sürekli frame bazında yapmak yerine visual transition'ı transform üzerinden yürütmeye yardımcı olur.

First

First adımında elementin değişiklik öncesi position ve size bilgisi okunur. Genellikle getBoundingClientRect() kullanılabilir. Bu DOM read aşamasıdır. Aynı anda style write yapılmamalıdır. Ölçüm yalnız ihtiyaç duyulan elementlerle sınırlanmalıdır.

Last

Last adımında final DOM state veya layout uygulanır. Browser yeni geometry'yi hesaplar. Ardından elementin final position ve size bilgisi okunur. Bu iki ölçüm arasındaki fark transition temelini oluşturur. Final state gerçek document flow içinde kalır.

Invert

Invert adımında first ve last geometry arasındaki position veya scale farkı hesaplanır. Element transform ile final layout'ta olmasına rağmen eski konumunda görünür hale getirilir. Kullanıcı ani layout sıçramasını görmez. Transform origin doğru seçilmelidir. Bu aşama write olarak batch edilebilir.

Play

Play adımında invert transform sıfıra doğru animasyonla kaldırılır. Element visually eski konumdan yeni konuma hareket eder. CSS transition veya WAAPI kullanılabilir. Animation interruptible olmalıdır. Yeni reorder gelirse eski animation cancel edilip yeni geometry üzerinden tekrar hesap yapılmalıdır.

Layout Değişikliğini Transform Animasyonuna Çevirmek

FLIP'in temel avantajı layout değişimini sürekli width, height, top veya left güncellemek yerine transform transition'a dönüştürmesidir. Final layout bir kez hesaplanır. Görsel hareket compositor-friendly property üzerinden yürütülebilir. Bu özellikle list reorder ve grid geçişlerinde etkilidir. Ancak ölçüm sayısı çok fazla elementte yükselirse initial layout read maliyeti yine profile edilmelidir.

FLIP Hangi Durumlarda Kullanılır?

FLIP özellikle elementlerin gerçek document geometry'sinin değiştiği ancak kullanıcının bu değişimi kesintisiz hareket olarak görmesinin istendiği durumlarda kullanışlıdır. Liste yeniden sıralama, accordion, responsive grid, shared element ve drag-drop geçişleri tipik örneklerdir. Her microinteraction için FLIP kullanmak gereksizdir. Basit fade veya slide CSS transition ile daha kolay çözülür. Teknik seçimi animation ihtiyacının yapısına göre yapmak bakım maliyetini azaltır.

Liste Yeniden Sıralama

Sort sonrasında liste elemanları yeni position alır. FLIP eski ve yeni rect farkını ölçerek her item'i transform ile eski konumda başlatabilir. Ardından item'ler yeni konuma hareket eder. Çok uzun listede yalnız visible itemler animasyon almalıdır. Virtualized list ile entegrasyon ayrıca test edilmelidir.

Accordion

Accordion content açıldığında aşağıdaki öğeler yeni y konumuna taşınabilir. FLIP sibling hareketlerini transform üzerinden gösterebilir. Content'in kendi height değişimi ayrı çözülür. Focus accordion header üzerinde korunmalıdır. Reduced motion modunda hareket basitleştirilebilir.

Grid Layout

Grid column sayısı veya item order değiştiğinde birçok element position değiştirir. FLIP bu hareketleri tek final layout sonrası animasyonla gösterebilir. Resize sırasında sürekli ölçüm yapılmamalıdır. Debounce veya breakpoint sonrası tek transition kullanılabilir. Çok büyük grid'de animation subset seçilebilir.

Shared Element

Card içindeki image detail view'da büyüyerek devam edebilir. FLIP eski ve yeni geometry arasındaki farkı transform ile yönetebilir. View Transition API modern browserlarda bu senaryoyu daha az manuel kodla çözebilir. Fallback basit fade olabilir. User navigation animation bitişine bağlanmamalıdır.

Drag-and-Drop

Drag sırasında pointer hareketi transform ile uygulanabilir. Drop sonrası diğer itemler reorder olduğunda FLIP kullanılabilir. Pointermove içinde sürekli layout ölçmekten kaçınılmalıdır. Drag geometry başlangıçta cache edilebilir. Latest pointer position requestAnimationFrame ile görsele yansıtılabilir.

View Transition API Nedir?

View Transition API, bir DOM görünümünden diğerine geçerken eski ve yeni state'i snapshot'layarak browser tarafından yönetilen transition oluşturmayı sağlar. Aynı document SPA değişiklikleri için document.startViewTransition() kullanılabilir. Aynı origin içinde cross-document geçişler de uygun opt-in ile desteklenebilir. API manual FLIP kodunu bazı senaryolarda azaltır, ancak her layout transition problemine otomatik çözüm değildir. Browser uyumluluğu ve reduced motion davranışı progressive enhancement ile ele alınmalıdır. :contentReference[oaicite:7]{index=7}

Eski ve Yeni View Snapshot'ları

Browser transition başlamadan önce eski görünümün belirli snapshot'larını oluşturur. DOM update gerçekleştikten sonra yeni view için karşılık gelen snapshot hazırlanır. Transition pseudo-elementleri üzerinden bu iki görüntü arasında animation uygulanabilir. Böylece aynı anda eski ve yeni gerçek DOM'u manuel yönetmek gerekmez. Snapshot alanı büyükse memory ve render maliyeti yine test edilmelidir. :contentReference[oaicite:8]{index=8}

Same-Document Transition

Same-document transition SPA veya tek document içindeki state değişiminde kullanılır. document.startViewTransition() callback'i DOM update işlemini kapsayabilir. API bir ViewTransition nesnesi döndürür. Ready ve finished gibi aşamalarla kontrol yapılabilir. Destek yoksa aynı state update animasyonsuz devam etmelidir. :contentReference[oaicite:9]{index=9}

Page Navigation Transition

Cross-document transition aynı origin içindeki sayfalar arasında navigation animation sağlayabilir. Her iki document uygun CSS opt-in ile transition'a katılır. Navigation'ın kendisi animation bitişini bekletmemelidir. Browser yeni sayfa state'ini hazırlayıp transition lifecycle'ını yönetir. Older browser fallback normal navigation olmalıdır. :contentReference[oaicite:10]{index=10}

Shared Element Transition

Shared element belirli view-transition-name üzerinden eski ve yeni view arasında ayrı snapshot olarak eşleştirilebilir. Product card image'in detail page'de devam etmesi buna örnektir. Kullanıcı context kaybetmeden navigation'ı anlayabilir. Aynı name birden fazla eşleşmede dikkatle yönetilmelidir. Çok sayıda shared element animasyonu gereksiz visual yük oluşturabilir.

Manuel FLIP'e Alternatif Olduğu Senaryolar

View Transition API state değişimini snapshot üzerinden yönettiği için manual geometry ölçümü gerektirmeyen birçok layout transition'da FLIP kodunu azaltabilir. Card-grid detail geçişi veya route transition örnek olabilir. FLIP daha düşük seviyeli kontrol gereken drag-reorder gibi durumlarda hâlâ değerlidir. Browser desteği target audience ile kontrol edilmelidir. Basit fallback tasarlamak API adoption'ını daha güvenli hale getirir.

CSS Transition mı CSS Animation mı?

CSS Transition ve CSS Animation aynı rendering property'lerini değiştirebildiği için temel performans farkı çoğu zaman kullanılan property ve browser workload'undan gelir. Transition iki state arasında doğal geçiş sağlar. Keyframe animation birden fazla aşama ve tekrar davranışı için daha uygundur. Basit hover effect için keyframe kullanmak gereksiz olabilir. Teknik seçim kodun anlaşılabilirliği ve kontrol ihtiyacına göre yapılmalıdır.

Transition

Transition property'nin eski ve yeni değeri arasında browser kontrollü geçiş oluşturur. Hover, focus, open veya active state için basittir. JavaScript yalnız class veya attribute değiştirebilir. Transform ve opacity ile birlikte kullanıldığında çoğu microinteraction için yeterlidir. Interrupt edildiğinde yeni target değere geçiş davranışı test edilmelidir.

İki State Arasında Geçiş

Button normalden pressed state'e geçebilir. Drawer closed ve open state arasında translate kullanabilir. Transition iki endpoint'i otomatik interpolasyonla birleştirir. Additional timeline state gerekmez. Kullanıcı hızlıca geri dönerse transition yeni target'a doğal şekilde yönlenebilir.

Keyframe Animation

Keyframe animation from ve to dışında ara aşamalar tanımlayabilir. Loading indicator, staged entrance veya kısa attention cue için uygundur. Infinite kullanım CPU ve battery maliyeti nedeniyle sınırlanmalıdır. Animation-play-state visibility durumunda pause edilebilir. Reduced motion preference'e göre alternatif keyframe verilebilir.

Çok Aşamalı Animasyon

Keyframe içinde yüzde noktalarıyla birden fazla transform veya opacity state tanımlanabilir. Bounce veya staged reveal gibi hareketler kolaylaşır. Çok fazla keyframe property farklı rendering aşamalarını tetiklememelidir. Timing toplam duration'ı gereksiz uzatmamalıdır. Animation user action'ını bloke etmemelidir.

Performans Açısından Temel Fark

CSS transition ile CSS animation arasında otomatik performans üstünlüğü yoktur. İkisi de aynı property'yi aynı browser pipeline içinde animasyonlayabilir. Transform transition ile transform keyframe benzer rendering davranışı gösterebilir. Asıl fark lifecycle ve control modelidir. Performance gerçek property ve element alanıyla profile edilmelidir.

Kullanım Senaryosuna Göre Seçim

İki state varsa transition genellikle daha az kod gerektirir. Çok aşamalı veya tekrar eden movement için keyframe daha uygundur. Runtime cancellation ve dynamic timeline gerekiyorsa WAAPI değerlendirilebilir. Canvas physics gibi özel render için requestAnimationFrame gerekir. Library seçimi ancak native seçenekler yetersiz kaldığında yapılmalıdır.

CSS Animasyonu mu JavaScript Animasyonu mu Daha Hızlıdır?

“CSS her zaman JavaScript'ten hızlıdır” yaklaşımı doğru bir performans modeli değildir. JavaScript yalnız animation state'i başlatıp transform property'yi browser'a bırakabilir veya her frame ağır layout değişikliği yapabilir. CSS de width, blur veya başka pahalı property'leri sürekli animasyonlayabilir. Bu nedenle gerçek belirleyici hangi property'nin değiştiği, main thread'de ne kadar JavaScript çalıştığı ve browser'ın hangi rendering aşamalarını tetiklediğidir. CSS JavaScript ve Web Animations API performans karşılaştırması yapılırken aynı görsel sonucu ve aynı cihaz koşullarını test etmek gerekir.

“CSS Her Zaman Daha Hızlıdır” Mitinin Problemi

CSS syntax kullanmak pahalı property'yi otomatik olarak ucuz hale getirmez. Width animation CSS ile yazılsa bile layout oluşturabilir. JavaScript class ekleyip transform transition başlatıyorsa application-level script çok az iş yapabilir. requestAnimationFrame ile transform güncellemesi de uygun tasarlanırsa akıcı olabilir. Teknoloji etiketi yerine rendering trace'e bakmak gerekir.

Rendering Cost

Rendering cost property ve element yapısına bağlıdır. Transform ve opacity genellikle daha düşük maliyetli başlangıçtır. Width, height veya büyük filter daha fazla work oluşturabilir. Aynı CSS animation farklı DOM büyüklüğünde farklı sonuç verir. Performance benchmark gerçek component üzerinde yapılmalıdır.

Main-Thread JavaScript

JavaScript animation her frame computation yapıyorsa main thread yükü artar. Physics veya canvas için bu gerekli olabilir. Basit timeline için browser-native animation engine daha az application code gerektirebilir. Heavy function frame callback'ten ayrılmalıdır. Long task rate izlenmelidir.

Compositor Animation

Compositor animation main thread layout ve paint işini azaltabilir. CSS, WAAPI veya bazı JavaScript-controlled animation aynı compositor-friendly property'yi kullanabilir. Dolayısıyla “CSS vs JS” ayrımı tek başına yeterli değildir. Browser layer kararını DevTools ile doğrulamak gerekir. Büyük layer memory kullanımı da hesaba katılmalıdır.

Gerçek Belirleyicinin Property ve Workload Olması

En doğru karar modeli property, DOM size, paint area, script workload ve interaction önceliğini birlikte değerlendirir. Basit state transition CSS'e uygundur. Runtime control WAAPI ile daha temiz olabilir. Custom rendering requestAnimationFrame gerektirebilir. Kullanıcıya aynı UX'i en az işlemle sunan yaklaşım seçilmelidir.

requestAnimationFrame Nedir?

requestAnimationFrame() browser'a bir sonraki repaint öncesinde animation callback çalıştırmak istediğinizi bildirir. Callback frekansı genellikle ekran yenileme hızıyla uyumludur ve modern cihazlarda 60 Hz dışında 90, 120 veya daha yüksek değerler görülebilir. MDN, background tab ve hidden iframe durumlarında çağrıların çoğu browserda duraklatıldığını belirtiyor. Her callback tek seferliktir ve sürekli animation için yeniden request edilmesi gerekir. Yüksek refresh rate cihazlarda hareket hızının değişmemesi için callback timestamp değeri kullanılmalıdır. :contentReference[oaicite:11]{index=11}

Browser Repaint Döngüsü

requestAnimationFrame callback'i browser'ın bir sonraki repaint hazırlığına yakın zamanda çalışır. Bu scheduling animation update'ini visual frame döngüsüyle uyumlu hale getirir. setInterval gibi bağımsız timer aynı ritmi garanti etmez. Browser kendi rendering işini daha iyi planlayabilir. Callback yine main thread üzerinde çalıştığı için ağır koddan kaçınılmalıdır.

Callback Timing

Callback browser tarafından uygun frame öncesinde çağrılır. Exact delay sabit değildir. Display refresh rate ve page visibility sonucu etkiler. Timestamp progression hesabında source of truth olabilir. Fixed frame increment kullanılmamalıdır.

Timestamp

requestAnimationFrame callback'e yüksek çözünürlüklü timestamp sağlar. Önceki frame zamanı ile fark hesaplanarak delta time bulunabilir. Object position delta time ile güncellenirse refresh rate farkı animation speed'i bozmaz. MDN yüksek refresh rate ekranlarda timestamp kullanılması gerektiğini özellikle vurgular. Physics simulation gerekiyorsa maximum delta clamp uygulanabilir. :contentReference[oaicite:12]{index=12}

Animation Loop

Animation loop callback sonunda yeni requestAnimationFrame çağrısı yapar. Loop yalnız animation aktifken çalışmalıdır. User element viewport dışına çıktığında veya animation tamamlandığında request durdurulabilir. CancelAnimationFrame mevcut request'i iptal etmek için kullanılabilir. Infinite loop decorative effect için varsayılan olmamalıdır.

Background Tab Davranışı

Browserlar battery ve performance tasarrufu için background tab requestAnimationFrame callback'lerini çoğu durumda pause eder. Bu davranış timer-based loop'a göre avantaj sağlar. Tab geri geldiğinde timestamp farkı çok büyük olabilir. Delta time clamp veya state reset gerekebilir. Page Visibility API ek lifecycle control sağlayabilir. :contentReference[oaicite:13]{index=13}

Neden setInterval() Yerine requestAnimationFrame()?

setInterval callback'i belirli zaman aralığına göre planlar, fakat browser repaint ritmine doğrudan bağlı değildir. requestAnimationFrame visual update'i browser'ın frame scheduling mekanizmasıyla uyumlu hale getirir. Background durumda browser çağrıları duraklatabilir ve gereksiz CPU kullanımını azaltabilir. Yüksek refresh rate ekranlarda callback doğal olarak display ile uyum sağlar. Animation loop için bu özellikler timer tabanlı yaklaşıma göre daha uygun davranış üretir.

Refresh Rate Senkronizasyonu

requestAnimationFrame callback frequency genellikle display refresh rate'i takip eder. 60 Hz ve 120 Hz cihaz farklı callback sıklığı görebilir. Delta time kullanılınca movement speed tutarlı kalır. setInterval sabit 16 ms seçilirse 120 Hz display'in fırsatları kaçırılabilir. Timer scheduling delay de frame pacing'i bozabilir.

Gereksiz Callback'leri Önleme

Animation durduğunda yeni requestAnimationFrame çağrılmazsa loop doğal olarak sona erer. Timer ayrıca clear edilmelidir. User interaction olmadan çalışan infinite callbacks enerji tüketir. Offscreen state observer ile loop stop edilebilir. Decorative animation lifecycle açık tasarlanmalıdır.

Background Tab Optimizasyonu

requestAnimationFrame çoğu browserda hidden tab'da pause edilir. Bu battery kullanımını azaltır. setInterval ise browser throttling uygulasa da animation amacı için daha az doğal modeldir. Tab geri döndüğünde current state yeniden hesaplanabilir. Page visibility event ile media decode veya particle system de durdurulabilir.

Frame Scheduling

Browser repaint öncesinde animation update alır. Böylece DOM write doğru zaman aralığına yakın yapılabilir. Birden fazla pointer event update'i tek frame'de coalesce edilebilir. Read phase ve write phase ayrılabilir. Scheduling avantajı callback içinde ağır iş yapılırsa kaybolur.

requestAnimationFrame Tek Başına Performans Garantisi Verir mi?

requestAnimationFrame yalnız scheduling API'sidir ve içindeki kodu otomatik olarak hızlandırmaz. Callback 30 milisaniye sürerse 60 Hz frame deadline zaten kaçırılır. Her frame layout ölçüp ardından style yazmak forced reflow oluşturabilir. Büyük canvas render veya array processing aynı problemi yaratabilir. API'yi doğru kullanmak, callback içindeki işi minimumda tutmakla birlikte düşünülmelidir.

rAF İçinde 30 ms İş Yapmak

30 milisaniyelik callback 60 Hz frame interval'ın oldukça üzerindedir. Browser sonraki frame'i zamanında hazırlayamaz. User click aynı task boyunca bekleyebilir. İş küçük parçalara bölünmeli veya daha seyrek çalıştırılmalıdır. Web Worker yalnız DOM gerektirmeyen hesaplamalar için değerlendirilebilir.

Main Thread Blocking

requestAnimationFrame callback main thread üzerinde çalışır. Bu nedenle synchronous heavy computation input event'lerini bloke eder. Callback kısa tutulmalıdır. Data processing animation state'ten ayrılmalıdır. RUM long task metric ile gerçek kullanıcı etkisi izlenebilir.

Layout ve Paint Maliyeti

Callback hızlı olsa bile yaptığı DOM write width veya height değiştiriyorsa ardından layout ve paint maliyeti oluşabilir. JavaScript duration tek performance ölçüsü değildir. Performance trace full frame işini göstermelidir. Transform-based visual update daha düşük maliyetli olabilir. Büyük paint effect yine test edilmelidir.

Frame Deadline

Browser frame'i display refresh deadline'ına kadar hazırlamaya çalışır. Script bitse bile style ve paint için yeterli zaman kalmıyorsa frame düşebilir. Bu nedenle callback budget teorik frame interval'dan daha küçüktür. Higher refresh rate daha dar budget getirir. Animation performance budget script ve rendering sürelerini ayrı izlemelidir.

İyi Bir requestAnimationFrame Döngüsü Nasıl Tasarlanır?

İyi requestAnimationFrame döngüsü yalnız gerçekten değişen visual state'i günceller ve minimum JavaScript çalıştırır. DOM measurement'ları read phase içinde toplanır, style write'lar daha sonra yapılır. Movement delta time üzerinden hesaplanır ve animation tamamlandığında loop durdurulur. Pointer event gibi yüksek frekanslı input'ta son değer saklanıp frame başına tek update yapılabilir. Bu model hem frame pacing'i hem input responsiveness'i korumaya yardımcı olur.

Minimum JavaScript

Her frame büyük object tree işlemekten kaçınılmalıdır. Sadece position veya progress gibi gerekli numeric state hesaplanabilir. Business logic animation loop dışında tutulur. Function allocation ve logging de hot path'ten çıkarılabilir. Profiling gerçek bottleneck'i doğrular.

DOM Read'leri Gruplamak

getBoundingClientRect veya offsetWidth gibi ölçümler browser layout bilgisine ihtiyaç duyar. Read işlemleri style write'lardan önce toplu yapılmalıdır. Aynı rect tekrar tekrar okunmamalıdır. Başlangıçta cache edilebilen geometry saklanabilir. Responsive change olduğunda cache invalidate edilir.

DOM Write'ları Gruplamak

Transform ve style değişiklikleri bir write phase içinde uygulanabilir. Read, write, read sıralaması forced layout riskini artırır. Birden fazla element update aynı frame içinde batch edilebilir. Framework kullanılıyorsa DOM commit davranışı anlaşılmalıdır. Mutation sayısı mümkün olduğunca azaltılmalıdır.

Delta Time Kullanmak

Delta time önceki frame ile current timestamp arasındaki farktır. Movement speed milisaniye veya saniye bazında hesaplanabilir. 60 ve 120 Hz cihazda aynı gerçek zaman süresi korunur. Background tab dönüşünde çok büyük delta clamp edilmelidir. Physics simulation fixed timestep gerektiriyorsa accumulator modeli kullanılabilir.

Gereksiz Loop'u Durdurmak

Animation bittiğinde request zinciri devam etmemelidir. Element offscreen olduğunda pause değerlendirilebilir. Tab hidden ise Page Visibility API ek kontrol sağlayabilir. User reduced motion tercih ediyorsa loop hiç başlamayabilir. Infinite decorative loop'lar battery budget ile değerlendirilmelidir.

Layout Thrashing Nedir?

Layout thrashing DOM write ve geometry read işlemlerinin aynı frame içinde tekrar tekrar karışması nedeniyle browser'ın layout'u defalarca senkron hesaplamak zorunda kalmasıdır. Style değiştirdikten hemen sonra getBoundingClientRect() okumak browser'ı pending değişiklikleri uygulamaya zorlayabilir. Bu pattern loop içinde çok sayıda elementte çalışırsa performans ciddi şekilde düşebilir. Read ve write işlemlerini batch etmek temel çözümdür. Animation sırasında özellikle drag ve scroll handler'larında bu anti-pattern sık görülür.

DOM Write

DOM write style, class veya geometry etkileyen attribute değişikliği olabilir. Browser çoğu zaman layout'u hemen hesaplamak yerine daha sonraya bırakır. Ardından geometry read yapılırsa deferred work zorla tamamlanabilir. Bu nedenle write sonrası read sırası dikkatle yönetilmelidir. Bir frame içindeki write'lar toplu uygulanmalıdır.

DOM Read

offsetWidth, clientHeight veya getBoundingClientRect gibi değerler current layout bilgisine ihtiyaç duyabilir. Pending style değişiklikleri varsa browser doğru sonucu vermek için layout çalıştırabilir. Bu read işlemi tek başına kötü değildir. Problem write ile sürekli dönüşümlü yapılmasıdır. Ölçüm bir phase içinde toplanmalıdır.

Forced Synchronous Layout

Forced synchronous layout browser'ın normalde daha sonra yapacağı geometry hesabını JavaScript çağrısı sırasında hemen yapmasıdır. Script bundan dolayı bekler. DevTools Performance trace call stack içinde forced reflow warning gösterebilir. Kaynak satıra kadar gidilmelidir. DOM access pattern yeniden düzenlenmelidir.

Her Frame Tekrar Eden Reflow

Animation loop her frame write-read-write yapıyorsa reflow sürekli oluşur. List item sayısı arttıkça maliyet katlanabilir. Dragging sırasında kullanıcı doğrudan jank hisseder. Geometry başlangıçta cache edilmeli veya gerektiğinde daha seyrek güncellenmelidir. Transform visual movement layout değişikliğini azaltabilir.

Layout Thrashing Örneği

Basit bir hata pattern'i element style'ını değiştirmek, hemen ardından geometry okumak ve sonra tekrar style değiştirmektir. Browser ilk write'ı henüz render etmeden geometry read geldiğinde yeni layout sonucu üretmek zorunda kalabilir. Bu döngü çok sayıda element için çalıştığında bir frame içinde tekrar tekrar layout hesaplanır. Kod satır sayısı az olsa bile rendering maliyeti yüksek olur. DevTools flame chart bu nedenle yalnız JavaScript function duration değil layout eventlerini de incelenmelidir.

Style Değiştir

Örneğin element width değeri değiştirilir. Browser style invalidation kaydeder. Layout hemen çalışmayabilir. JavaScript devam eder. Sonraki geometry read kritik hale gelir.

getBoundingClientRect() Oku

Geometry read current layout sonucuna ihtiyaç duyar. Browser pending style değişikliğini hesaplar. Synchronous layout oluşabilir. Bir elementte küçük maliyet olabilir. Loop içinde yüz elementte büyük sorun olur.

Tekrar Style Değiştir

Read sonucuna göre başka style write yapılır. Browser layout tekrar dirty hale gelir. Ardından yeni read gelirse süreç yeniden başlar. Bu ping-pong pattern thrashing oluşturur. Batch update ile kırılmalıdır.

Browser'ın Layout'u Zorla Hesaplaması

JavaScript geometry sonucunu hemen istediği için browser deferred render optimizasyonunu kullanamaz. Main thread daha uzun süre bloklanır. Input event kuyruğu bekleyebilir. Performance trace forced layout kaynağını gösterebilir. Kod read-first, write-second phase'e ayrılmalıdır.

Layout Thrashing Nasıl Önlenir?

Layout thrashing'i önlemenin temel yolu DOM read ve write işlemlerini ayrı aşamalarda yürütmektir. Önce gerekli ölçümler okunur ve local değişkenlerde saklanır. Sonra bütün style değişiklikleri toplu uygulanır. requestAnimationFrame write phase'i planlamak için kullanılabilir. Geometry değişmediği sürece ölçümleri cache etmek gereksiz layout read sayısını azaltır.

Read Phase

Frame başında ihtiyaç duyulan rect ve size bilgileri okunabilir. Henüz style mutation yapılmamalıdır. Birden fazla element ölçümü aynı phase içinde tamamlanır. Değerler array veya object içinde saklanır. Sonraki frame'e kadar geçerlilik koşulu bilinmelidir.

Write Phase

Hesaplanan yeni transform veya style değerleri daha sonra toplu uygulanır. Write sırasında yeniden geometry okunmaz. Browser değişiklikleri tek render cycle içinde değerlendirebilir. Framework commit phase ile çakışma varsa profiling yapılmalıdır. Mutation sayısı sınırlı tutulmalıdır.

DOM Ölçümlerini Cache Etmek

Drag boundary veya container rect her pointermove'da değişmiyorsa başlangıçta bir kez ölçülebilir. Resize veya content change olduğunda cache yenilenir. Bu yaklaşım layout read sayısını düşürür. Stale geometry bug oluşturabileceği için invalidation açık tasarlanmalıdır. ResizeObserver bazı senaryolarda yardımcı olabilir.

Batch Updates

Birden fazla element position update'i tek loop içinde hesaplanabilir. DOM write tek phase'e bırakılır. Utility scheduler ekip genelinde read/write discipline sağlayabilir. Çok fazla microtask ile aynı pattern yeniden üretilmemelidir. Profiling batching sonrası layout event sayısını karşılaştırmalıdır.

requestAnimationFrame ile Schedule Etmek

Input event yalnız latest value'yu memory'ye kaydedebilir. requestAnimationFrame callback bu değeri bir sonraki visual frame'de uygular. On pointermove event aynı frame'de gelse bile tek DOM write yapılabilir. Bu coalescing drag smoothness'i artırabilir. Callback içinde yeniden heavy measurement yapılmamalıdır.

will-change Nedir?

will-change browser'a belirli element veya property'nin yakında değişeceğine dair rendering hint verir. Browser bu bilgiyi ön hazırlık veya layer oluşturma gibi optimizasyonlar için kullanabilir. MDN özelliğin performans problemi çözmek için son çare olarak ve sınırlı şekilde kullanılmasını öneriyor. Sürekli çok sayıda elemente uygulamak memory tüketimini ve rendering yükünü artırabilir. Bu nedenle animasyondan kısa süre önce eklemek ve bittikten sonra kaldırmak daha güvenli kullanımdır. :contentReference[oaicite:14]{index=14}

Browser'a Değişiklik İpucu Vermek

will-change browser'a elementin transform, opacity veya başka özelliğinin değişeceğini önceden bildirir. Browser gerekli hazırlığı interaction başlamadan yapabilir. Bu sayede ilk frame jank'i azalabilir. Ancak browser zaten birçok optimizasyonu kendi heuristic'leriyle yapar. Gereksiz hint eklemek ters etki yaratabilir.

Layer Promotion

will-change bazı durumlarda elementin ayrı compositing layer'a alınmasına yol açabilir. Bu transform animation için fayda sağlayabilir. Her layer texture memory kullanır. Büyük sayıda promoted element GPU memory baskısı oluşturur. Layers panel sonucu doğrulamak için kullanılmalıdır.

transform

will-change: transform yaklaşan transform değişikliğini browser'a bildirir. Drag veya büyük panel hareketinde ön hazırlık için kullanılabilir. Sürekli stylesheet üzerinde bırakmak gereksiz olabilir. Hover öncesi kısa süreli eklenebilir. Animation sonunda auto durumuna dönülebilir.

opacity

will-change: opacity fade animation öncesi kullanılabilir. Browser stacking context gibi davranışları önceden oluşturabilir. Bu visual stacking sonucunu değiştirebilir. Çok büyük layer'da memory kullanımı izlenmelidir. Basit küçük fade zaten akıcıysa hint eklemeye gerek yoktur.

will-change Neden Her Elemana Eklenmemeli?

will-change performans artıran genel amaçlı sihirli property değildir. Browser güçlü optimizasyonları uzun süre açık tutabilir ve bu durum memory kullanımını artırabilir. Büyük bir container veya yüzlerce element için will-change kullanmak layer sayısını büyütebilir. MDN bu property'nin aşırı kullanımının performansı iyileştirmek yerine kötüleştirebileceğini açıkça belirtiyor. Bu yüzden yalnız ölçülmüş problem bulunan elementte, animasyondan kısa süre önce ve sınırlı süre kullanılmalıdır. :contentReference[oaicite:15]{index=15}

GPU Memory

Promoted layer pixel texture olarak GPU memory tüketebilir. Büyük full-screen element yüksek çözünürlüklü cihazda önemli alan kaplar. Birden fazla layer memory pressure oluşturabilir. Mobile GPU sınırı daha düşüktür. Layer memory DevTools ile incelenmelidir.

Layer Explosion

Her card, icon ve button ayrı layer olursa compositor yönetmesi gereken çok sayıda yüzey oluşur. Bu “layer explosion” olarak düşünülebilir. Composite süresi ve memory maliyeti artar. Browser'ın kendi promotion kararına güvenmek çoğu durumda daha iyidir. Manual hint yalnız problemli component'te kullanılmalıdır.

Compositing Maliyeti

Layer oluşturmak paint'i azaltabilir fakat final frame'de layer'ların birleştirilmesi gerekir. Çok sayıda büyük transparent layer fill-rate ve memory bandwidth kullanır. Mobile cihazda maliyet daha yüksek hissedilebilir. FPS iyileşirken battery tüketimi artabilir. Bu nedenle optimization sonucu birden fazla metric ile doğrulanmalıdır.

Sadece Gerektiğinde Aktif Etmek

Mouseenter veya interaction başlangıcından kısa süre önce will-change eklenebilir. Browser'a hazırlık zamanı verilmelidir. Animasyon başlamışken eklemek beklenen faydayı vermeyebilir. Aynı anda aktif element sayısı sınırlandırılmalıdır. Kullanım lifecycle component içinde açık tutulmalıdır.

Animasyon Sonrası Kaldırmak

Animation bitince will-change değeri auto yapılabilir. Böylece browser kaynakları uzun süre reserve etmek zorunda kalmaz. Cancel veya interrupted durumda cleanup unutulmamalıdır. transitionend tek cleanup kaynağı değil state machine de kullanılabilir. Reduced motion durumunda property hiç eklenmeyebilir.

GPU Acceleration Nedir?

GPU acceleration bazı rendering ve compositing işlerinin grafik işlemci tarafından yürütülmesini ifade eder. Web animasyonlarında özellikle layer transform ve opacity değişiklikleri bu modelden yararlanabilir. Ancak GPU kullanımı otomatik performans garantisi değildir. Texture upload, large layer ve memory bandwidth maliyetleri vardır. 60 FPS animasyon için requestAnimationFrame GPU acceleration ve layout shift optimizasyonu birlikte ele alınırken hedef, daha fazla GPU kullanmak değil her frame için daha az gereksiz iş oluşturmaktır.

CPU ve GPU Görev Ayrımı

CPU JavaScript ve birçok layout işini yürütür. GPU raster veya compositing süreçlerinde rol alabilir. Browser implementation ayrıntıları platforma göre değişir. Application developer doğrudan “bu property GPU'da” garantisi vermemelidir. DevTools layer ve trace üzerinden sonucu gözlemlemelidir.

Compositor Layer

Compositor layer sayfanın belirli bölümünü bağımsız yüzey gibi yönetebilir. Transform layer'ın final position'ını değiştirebilir. Paint tekrar kullanılabilir. Layer oluşturmak memory tüketir. Büyük layer sayısı sınırlı tutulmalıdır.

Texture

Layer pixel içeriği GPU texture olarak temsil edilebilir. Büyük retina görsel yüzeyi ciddi memory kullanabilir. Scale veya filter sırasında texture sampling maliyeti vardır. Asset decode ve upload animation başlangıcında jank oluşturabilir. Preload ve smaller asset stratejisi değerlidir.

GPU Acceleration = Her Zaman Daha Hızlı mı?

Hayır, GPU kullanımı tek başına hız garantisi vermez. Çok büyük blur veya yüzlerce layer GPU'yu yoğun biçimde meşgul edebilir. Low-end cihaz thermal throttling yaşayabilir. Browser CPU ve GPU arasında data transferi yapabilir. Gerçek user device testleri karar için gereklidir.

Büyük GPU Layer'ların Problemi

Büyük compositor layer'lar layout ve paint yükünü azaltabilse de texture memory açısından pahalı olabilir. Full-screen backdrop, çok büyük image veya geniş off-canvas panel yüksek çözünürlüklü cihazlarda ciddi pixel alanı taşır. Birden fazla böyle layer memory pressure oluşturabilir. Mobile GPU memory kapasitesi daha sınırlı olduğu için uygulama desktop'ta iyi, telefonda kötü davranabilir. Layer boyutunu mümkün olduğunca interaction alanıyla sınırlamak faydalıdır.

Texture Memory

Texture boyutu element pixel alanı ve device pixel ratio ile büyür. Yüksek DPR cihazda aynı CSS boyutu daha fazla physical pixel anlamına gelir. Birkaç full-screen layer memory kullanımı artırabilir. Browser gerektiğinde texture yeniden upload edebilir. Animation sırasında memory pressure ölçülmelidir.

Büyük Görsel Alan

Full-screen layer hareket ettirildiğinde compositor büyük alanı her frame birleştirir. Semi-transparent efekt overdraw yaratabilir. Büyük blur daha da pahalı olabilir. Effect yalnız gerekli section'a sınırlandırılmalıdır. Mobile fallback daha sade olabilir.

Mobil GPU Sınırları

Mobil GPU desktop kadar yüksek sustained throughput sunmayabilir. Thermal throttling uzun animation session'da performansı düşürebilir. Battery tüketimi önemlidir. Low-end gerçek cihaz test edilmelidir. Performance yalnız ilk birkaç saniyede ölçülmemelidir.

Layer Boyutunu Küçültmek

Animasyon verilen element yalnız visual gereken alanı kapsamalıdır. Full viewport wrapper yerine küçük child layer kullanılabilir. Pseudo element shadow veya overlay'i ayrı küçük yüzeyde taşıyabilir. Unused transparent area azaltılabilir. DevTools layer bounds kontrol edilmelidir.

Paint-Heavy Animasyonlar

Paint-heavy animasyonlar her frame büyük pixel alanının yeniden hesaplanmasını veya çizilmesini gerektirebilir. Box-shadow, blur, gradient ve backdrop-filter gibi efektler özellikle geniş yüzeylerde maliyetli olabilir. Border-radius bazı kombinasyonlarda clipping maliyeti ekleyebilir. Bu property'lerin hiç kullanılmaması gerekmez, ancak animation süresi ve alanı sınırlanmalıdır. Ben kurumsal arayüzlerde çoğu gölge hareketini gerçek shadow interpolasyonu yerine hazır pseudo element opacity geçişiyle çözmeyi tercih ediyorum.

box-shadow

Box-shadow geniş blur radius ile büyük paint alanı oluşturabilir. Shadow property'yi sürekli interpolate etmek repaint maliyeti yaratabilir. Küçük button hover'da sorun olmayabilir. Büyük card grid'de aynı efekt yüzlerce paint oluşturabilir. Pseudo element opacity alternatifi değerlendirilebilir.

blur

Blur komşu pixel alanını örneklemek zorundadır. Radius arttıkça işlem alanı büyür. Full-screen blur özellikle mobile GPU için ağır olabilir. Modal overlay'de düşük radius veya solid translucent background tercih edilebilir. Device-adaptive fallback kullanılabilir.

border-radius

Border-radius tek başına çoğu durumda kabul edilebilir, ancak clip ve large content kombinasyonu maliyet oluşturabilir. Radius animation shape rasterization'ı etkileyebilir. Küçük componentlerde problem olmayabilir. Büyük media container geçişinde profile edilmelidir. View Transition snapshot farklı sonuç verebilir.

Gradient

Gradient animation color stop veya position değişimiyle paint yükü oluşturabilir. Full-screen animated gradient decorative olduğu için maliyetine değmeyebilir. Static gradient üzerinde pseudo element opacity geçişi daha uygun olabilir. Canvas veya shader çözümü ancak gerçek visual gereksinim varsa değerlendirilmelidir. Battery etkisi göz önünde bulundurulmalıdır.

filter

Filter brightness veya blur gibi pixel işlemleri sağlar. Animasyon davranışı browser ve hardware'e göre değişebilir. Küçük image effect kabul edilebilir. Büyük content area'da maliyet artar. Paint ve GPU profiling ile kontrol edilmelidir.

backdrop-filter

Backdrop-filter elementin arkasındaki içeriği işlemek zorunda olduğu için özellikle blur kullanıldığında pahalı olabilir. Scroll altında sürekli değişen background ek maliyet yaratır. Modal backdrop için düşük blur veya plain opacity alternatif olabilir. Mobile cihazda effect kapatılabilir. Design system fallback tanımlamalıdır.

Blur ve Backdrop Blur Neden Pahalı Olabilir?

Blur işlemi her pixelin çevresindeki alanı dikkate aldığı için radius büyüdükçe daha fazla çalışma gerektirir. Backdrop blur ayrıca element arkasındaki değişen içeriği de işlemek zorunda kalabilir. Full-screen overlay üzerinde sürekli blur animation bu nedenle yüksek GPU ve memory bandwidth kullanabilir. Düşük güçlü telefonlarda frame drop veya battery tüketimi görülebilir. Blur kullanmanız gerekiyorsa alanı ve radius'u minimumda tutup gerçek cihazda profile etmek en güvenli yaklaşımdır.

Büyük Pixel Alanı

Blur hesaplaması element bounds ile sınırlı değildir, radius çevresindeki pixel alanını da etkileyebilir. Full viewport blur büyük iş demektir. Device pixel ratio alanı daha da büyütür. Small card blur daha yönetilebilir olabilir. Effect scope küçültülmelidir.

Her Frame Yeniden Hesaplama

Blur radius veya backdrop içeriği sürekli değişirse browser her frame yeni görüntü üretmek zorunda kalabilir. Static blurred background daha ucuz olabilir. Animation sırasında property value sabit tutulabilir. Overlay yalnız opacity ile fade edilebilir. Performance trace paint activity'yi göstermelidir.

Mobil GPU

Mobile GPU yüksek fill-rate gerektiren blur efektlerinde zorlanabilir. Thermal ve battery sınırlamaları vardır. Developer laptop benchmark yeterli değildir. Low-end Android cihaz özellikle önemlidir. Fallback visual daha sade tasarlanabilir.

Blur Radius

Radius arttıkça sampling area büyür. 4 px ile 40 px blur aynı maliyette değildir. Designer ile threshold belirlenebilir. Perceived effect küçük radius'ta yeterli olabilir. CSS variable üzerinden device mode'a göre azaltılabilir.

Küçük Alanla Sınırlamak

Blur yalnız gerekli UI parçasına uygulanmalıdır. Full-screen wrapper yerine küçük overlay kullanılabilir. Clip bounds pixel işini azaltabilir. Scroll content üzerinde persistent blur dikkatle seçilmelidir. DevTools paint area ölçümü değişiklik sonrası karşılaştırılmalıdır.

Shadow Animasyonlarını Optimize Etmek

Shadow state değişimini doğrudan box-shadow property'yi her frame interpolate ederek yapmak zorunlu değildir. İki hazır shadow state pseudo elementlerde tutulup opacity ile cross-fade edilebilir. Bu yaklaşım paint davranışını bazı durumlarda azaltabilir ve compositor-friendly transition sağlayabilir. Drop-shadow filter de her zaman daha hızlı değildir, çünkü büyük raster alanında maliyet oluşturabilir. En doğru yöntem component boyutu ve browser davranışına göre profile edilmelidir.

box-shadow

Box-shadow standard card depth için uygundur. Static state'te maliyeti çoğu zaman kabul edilebilir. Sürekli animation repaint oluşturabilir. Hover state kısa ise sorun küçük olabilir. Büyük card listesi birlikte test edilmelidir.

drop-shadow

Drop-shadow alpha shape üzerinden shadow üretebilir. Irregular SVG veya image için faydalıdır. Filter pipeline maliyetlidir. Box-shadow'dan otomatik daha hızlı değildir. Gerçek paint/composite trace karar vermelidir.

Pseudo Element Kullanmak

Card üzerinde normal shadow ve elevated shadow pseudo element olarak hazırlanabilir. Pseudo element absolute konumlanır. Hover sırasında yalnız opacity değişir. Böylece shadow geometry her frame yeniden hesaplanmayabilir. Stacking ve pointer event davranışı kontrol edilmelidir.

Opacity ile Shadow State Değiştirmek

İki shadow layer arasında opacity cross-fade yapılabilir. Bu visual olarak depth transition hissi verir. Layer memory maliyeti vardır. Küçük component için iyi trade-off olabilir. Düşük güçlü cihaz test edilmelidir.

Scroll-Driven Animation Nedir?

Scroll-driven animation, animation progress'inin geçen zamana değil scroll konumuna veya elementin viewport içindeki görünürlük ilerlemesine bağlandığı modeldir. CSS Scroll-Driven Animations modülü animation-timeline, scroll() ve view() gibi araçlar sunar. Bu yaklaşım klasik scroll event içinde sürekli JavaScript hesaplamayı azaltabilir. MDN, scroll progress ve view progress timeline'ların JavaScript olmadan CSS keyframe ilerlemesini scroll'a bağlayabildiğini açıklıyor. Ancak 2026 itibarıyla bazı alt özellikler Baseline dışında kalabildiği için browser compatibility kontrol edilmelidir. :contentReference[oaicite:16]{index=16}

Scroll Position Animation Progress'i Belirler

Time-based animation'da progress elapsed time üzerinden ilerler. Scroll-driven modelde progress scroller'ın position veya subject visibility durumundan gelir. Kullanıcı geri scroll ettiğinde animation progress de geri gidebilir. Bu doğal bağlantı progress bar veya reveal effect için uygundur. User scroll kontrolü korunmalıdır.

Time-Based Animation'dan Farkı

Time-based animation kullanıcı scroll'u durdursa da devam eder. Scroll-driven animation scroll ilerlemesi durduğunda aynı progress noktasında kalabilir. Bu behavior storytelling veya progress indicator için daha tutarlıdır. Timing duration yerine timeline range kullanılır. Fallback normal static state olabilir.

Scroll Timeline

Scroll timeline scroller'ın scroll range'ini animation timeline olarak kullanır. scroll() anonymous timeline tanımlayabilir. Axis block, inline, x veya y seçilebilir. Named timeline da kullanılabilir. Browser desteği target matrix'te kontrol edilmelidir. :contentReference[oaicite:17]{index=17}

View Timeline

View timeline subject elementin scroller viewport içindeki progress'ini animation timeline'a bağlar. Element içeri girerken veya çıkarken keyframe ilerleyebilir. view() anonymous view progress timeline oluşturabilir. Reveal effect için IntersectionObserver'a alternatif olabilir. Compatibility ve reduced motion desteği eklenmelidir. :contentReference[oaicite:18]{index=18}

Klasik Scroll Event Animasyonlarının Problemi

Klasik scroll animation genellikle her scroll event'inde position ölçüp style yazan JavaScript ile geliştirilir. Scroll event çok sık gelebilir ve handler ağırsa main thread sürekli meşgul olur. Geometry read ile write aynı handler içinde karışırsa forced layout oluşabilir. Kullanıcı scroll yaparken aynı main thread başka interaction'ları da işlemeye çalışır. Declarative scroll timeline, IntersectionObserver veya requestAnimationFrame scheduling gereksiz sürekli işi azaltabilir.

Çok Sık Event

Scroll hareketi yüksek frekansta event üretebilir. Her event ayrı DOM update gerektirmez. Latest scroll position saklanabilir. Frame başına tek visual update yeterli olabilir. Throttle daha seyrek analytics veya non-visual iş için kullanılabilir.

Main-Thread Handler

Scroll event handler JavaScript çalıştırır. Büyük loop veya data calculation scroll smoothness'i etkileyebilir. Handler passive ve küçük tutulmalıdır. Visual progress mümkünse CSS timeline'a taşınabilir. Heavy analytics idle zamanda yapılmalıdır.

Layout Read

Her scroll event getBoundingClientRect okumak geometry hesabı oluşturabilir. Çok sayıda element için maliyet büyür. Visibility gerekiyorsa IntersectionObserver daha uygundur. Exact progress gerekiyorsa Scroll Timeline kullanılabilir. Manual measurement gerektiğinde values cache edilmelidir.

Style Write

Scroll handler içinde top veya height değiştirmek layout maliyeti oluşturabilir. Transform kullanmak daha uygun olabilir. Update requestAnimationFrame'e planlanabilir. Birden fazla write batch edilir. Browser main thread daha az parçalanmış iş görür.

Scroll Jank

Handler frame deadline'ı kaçırdığında scrolling düzensiz hissedilir. Touch device'da sorun daha belirgin olabilir. Passive event listener default scroll'u bekletmeme konusunda yardımcı olabilir. Heavy layout ve paint azaltılmalıdır. RUM scroll-specific telemetry ayrı instrumentation gerektirebilir.

CSS Scroll-Driven Animations

CSS Scroll-Driven Animations scroll progress veya view progress bilgisini doğrudan CSS animation timeline olarak kullanır. animation-timeline default document timeline yerine scroll veya view timeline seçebilir. Bu yaklaşım scroll event listener içinde her frame JavaScript yazma ihtiyacını azaltır. MDN modern dokümantasyonda scroll() ve view() fonksiyonlarını resmi CSS API olarak tanımlıyor. Özellik adoption'ında compatibility query ve fallback şarttır. :contentReference[oaicite:19]{index=19}

animation-timeline

animation-timeline animation progress'i hangi timeline'ın yöneteceğini seçer. Default auto document time-based timeline kullanır. Scroll veya view timeline bu davranışı değiştirebilir. CSS animation shorthand bazı durumlarda timeline değerini resetleyebildiği için declaration sırası önemlidir. MDN bu ayrıntıyı güncel dokümantasyonda açıkça belirtiyor. :contentReference[oaicite:20]{index=20}

scroll()

scroll() anonymous scroll progress timeline oluşturur. Nearest, root veya self scroller seçilebilir. Axis belirtilebilir. Progress scroll range'in başlangıç ve sonuna göre hesaplanır. Browser support fallback ile birlikte ele alınmalıdır. :contentReference[oaicite:21]{index=21}

view()

view() elementin scrollport içindeki görünürlük ilerlemesini timeline'a bağlar. Reveal ve progress effect için uygundur. Element geri scroll edildiğinde animation progress geri hareket edebilir. JavaScript visibility polling gerekmez. Reduced motion mode'da static final state kullanılabilir. :contentReference[oaicite:22]{index=22}

Progress Indicator

Page reading progress için root scroll timeline kullanılabilir. Indicator scaleX ile 0'dan 1'e büyütülebilir. Width animation yerine transform kullanılabilir. JavaScript scroll listener gerekmez. Unsupported browserda indicator static veya hidden olabilir.

Reveal Animation

Element viewport'a yaklaştıkça opacity ve transform progress alabilir. View timeline bu ilişkiyi declarative biçimde kurar. Movement küçük tutulmalıdır. Content animation bitmeden hidden kalmamalıdır. Reduced motion'da doğrudan görünür state kullanılmalıdır.

Scroll Timeline ile Progress Animation

Scroll Timeline, scroller'ın başlangıç ve bitiş konumunu animation progress aralığına dönüştürür. Reading progress bar gibi bileşenlerde JavaScript scroll handler ihtiyacını ortadan kaldırabilir. Bar width yerine transform scaleX kullanılırsa layout değişikliği azaltılabilir. Scroll progress browser timeline tarafından hesaplanır. Feature desteği olmayan browser için basit fallback sağlanmalıdır.

Scroll Range

Scroll range scroller'ın hareket edebildiği toplam mesafeyi temsil eder. Timeline bu range'i progress'e dönüştürür. Root veya nested container kullanılabilir. Axis doğru seçilmelidir. Content height değişirse browser timeline'ı günceller.

Animation Progress

Progress 0 ile 100 percent arasında keyframe state'e bağlanır. User scroll geri giderse progress de geri gider. Time duration ana kontrol değildir. Scroll behavior kullanıcı controlünü korur. Visual effect scroll'u manipüle etmemelidir.

transform: scaleX

Progress bar genişliğini width ile değiştirmek yerine transform scaleX kullanılabilir. Transform origin left seçilir. Layout yeniden hesaplanmaz. Bar visual progress'i temsil eder. Screen reader için text progress gerekliyse semantic value ayrıca sağlanmalıdır.

Main-Thread JavaScript'i Azaltmak

Declarative timeline browser'a animation relationship'i doğrudan anlatır. Application her scroll event'te progress hesaplamaz. Main thread input ve başka work için daha fazla alan kazanabilir. MDN scroll-driven CSS modelinin JavaScript event listener riskini azaltabildiğini belirtiyor. Yine de property ve paint maliyeti ayrı profile edilmelidir. :contentReference[oaicite:23]{index=23}

Scroll Event Kullanmak Zorundaysak Nasıl Optimize Ederiz?

Bazı projelerde browser desteği veya özel business logic nedeniyle scroll event kullanmak gerekebilir. Bu durumda handler passive yapılmalı, minimum iş yürütmeli ve visual update requestAnimationFrame ile frame başına sınırlandırılmalıdır. Throttle non-visual işlemlerde callback sayısını azaltabilir. DOM read ve write ayrı phase'lerde yapılmalıdır. Aynı değeri her event yeniden hesaplamak yerine cache ve change detection kullanılabilir.

Passive Listener

Passive listener browser'a handler'ın default scroll davranışını preventDefault() ile engellemeyeceğini bildirir. Bu özellikle touch ve wheel senaryolarında browser'ın scroll'u daha güvenli planlamasına yardımcı olabilir. Passive seçeneği gerçekten preventDefault gerekmeyen listenerlarda kullanılmalıdır. Gesture logic gerekiyorsa touch-action gibi CSS seçenekleri de değerlendirilmelidir. Kullanıcı native scrolling'i kaybetmemelidir.

requestAnimationFrame Scheduling

Scroll event yalnız latest scrollY değerini memory'ye yazabilir. Eğer update pending değilse requestAnimationFrame schedule edilir. Callback visual transform'u bir kez uygular. Aynı frame içinde on event gelse bile tek render update yapılır. Bu pattern handler yoğunluğunu azaltır.

Throttle

Throttle callback'in belirli aralıktan daha sık çalışmasını engeller. Analytics, lazy telemetry veya expensive non-visual hesaplama için uygundur. Smooth visual animation için yalnız throttle düşük update rate oluşturabilir. rAF scheduling daha doğal olabilir. Throttle interval user experience'e göre seçilmelidir.

DOM Read/Write Batch

Scroll sırasında geometry read ve style write karıştırılmamalıdır. Önce gereken rect bilgileri okunur. Sonra transform update yapılır. Loop içinde element başına read-write sırası kullanılmamalıdır. Forced layout DevTools ile kontrol edilmelidir.

Gereksiz Hesaplamayı Önlemek

Element offscreen ise ilgili animation calculation yapılmayabilir. IntersectionObserver active set tutabilir. Scroll progress yalnız visible componentler için hesaplanabilir. Aynı value değişmediyse DOM write atlanabilir. Bu optimizasyon düşük güçlü cihazda önemli fark yaratabilir.

IntersectionObserver Ne Zaman Kullanılmalı?

IntersectionObserver bir elementin viewport veya belirlenmiş root ile kesişim durumunu takip etmek için uygundur. Reveal animation başlatmak, offscreen animation durdurmak veya asset lazy initialization yapmak için kullanılabilir. Her scroll pixeline tam progress hesaplamak için tasarlanmamıştır. Bu tür progress ihtiyacında Scroll Timeline daha doğal seçenek olabilir. Observer callback'i yine application logic çalıştırdığı için içine ağır işlem koymamak gerekir.

Element Viewport'a Girdi mi?

Observer threshold üzerinden elementin görünürlük durumunu bildirebilir. Scroll event içinde sürekli rect ölçmeye gerek kalmaz. Once reveal için observe sonlandırılabilir. Root margin ile viewport'a gelmeden biraz önce initialization yapılabilir. Çok fazla observer yerine shared observer kullanılabilir.

Reveal Animation

Element ilk kez görünür olduğunda class eklenebilir. CSS transform ve opacity transition çalışır. Content başlangıçta erişilebilir kalmalıdır. JavaScript çalışmazsa content hidden olmamalıdır. Reduced motion modunda transition kaldırılabilir.

Lazy Animation Start

Lottie veya canvas initialization element yaklaştığında başlatılabilir. Initial page load CPU ve bundle execution azalabilir. Asset preload timing ayrıca düşünülmelidir. Observer fire olduktan sonra setup maliyeti ilk frame'i bloke etmemelidir. Hazırlık bir miktar root margin ile erken yapılabilir.

Offscreen Animasyonları Durdurmak

Element viewport dışına çıktığında infinite animation pause edilebilir. Video veya canvas render da durdurulabilir. Battery ve CPU kullanımı azalır. State element geri geldiğinde devam ettirilebilir. User context'e göre reset veya resume seçilir.

Scroll Position'ın Her Pixelini Takip Etmek İçin Kullanılmaması

IntersectionObserver threshold crossing mantığına dayanır. Pixel-perfect scroll progress için çok sayıda threshold üretmek gereksiz olabilir. Scroll Timeline veya requestAnimationFrame scroll progress daha uygundur. Observer visibility ve coarse progress için kullanılmalıdır. API amacıyla uyumlu kullanım daha sade kod üretir.

Scroll-Triggered ve Scroll-Driven Animation Arasındaki Fark

Scroll-triggered animation belirli görünürlük koşulu oluştuğunda hareketi bir kez veya zaman tabanlı olarak başlatır. Scroll-driven animation ise scroll miktarını animation progress'in kendisine bağlar. IntersectionObserver trigger modeli için uygundur. Scroll Timeline progress modeline uygundur. Bu ayrımı doğru yapmak gereksiz scroll event kodunu azaltır.

Scroll-Triggered

Triggered modelde element viewport'a girer ve animation başlar. Bundan sonra progress elapsed time ile devam edebilir. Scroll geri giderse animation otomatik geri gitmez. Reveal pattern için yeterlidir. IntersectionObserver iyi seçimdir.

Görünür Olunca Başlat

Observer isIntersecting true olduğunda class eklenebilir. Transition opacity ve translate çalışır. Bir kez oynatılacaksa observer disconnect edilir. User hızlı scroll yapsa bile content kullanılabilir kalmalıdır. Reduced motion'da class doğrudan final state'e geçebilir.

Scroll-Driven

Scroll-driven modelde animation progress sürekli scroll position ile ilişkilidir. User geri scroll ettiğinde hareket de geriye gider. Reading progress veya parallax benzeri effect buna örnektir. Native scroll timeline JavaScript işini azaltabilir. Scroll-jacking yapılmamalıdır.

Scroll Miktarı Progress'i Belirler

Animation bir saniye duration'a bağlı olmak yerine scroll range'e bağlıdır. Keyframe yüzde noktaları scroll progress ile eşleşir. User movement doğrudan visual state'i kontrol eder. Bu nedenle easing seçimi scroll hissini etkileyebilir. Linear çoğu progress indicator için daha doğal olur.

IntersectionObserver vs Scroll Timeline

Viewport'a girdi mi sorusu için IntersectionObserver daha sade ve geniş destekli yaklaşımdır. Scroll miktarı animation progress'i belirleyecekse Scroll Timeline daha doğal declarative modeldir. Browser compatibility requirement seçimde önemlidir. Fallback gerekiyorsa trigger animation statik state'e dönüşebilir. Aynı iş için iki API birlikte gereksiz kullanılmamalıdır.

Scroll-Jacking Nedir?

Scroll-jacking web sayfasının kullanıcının doğal scroll davranışını kendi sanal hareket sistemiyle değiştirmesi veya beklenmeyen şekilde kontrol etmesidir. Scroll mesafesini yapay biçimde yavaşlatmak, hızlandırmak veya user input'u animation timeline'a zorla bağlamak buna örnek olabilir. Bu yaklaşım kullanıcı kontrolünü azaltır. Keyboard, touchpad ve accessibility cihazlarında beklenmedik davranışlar oluşturabilir. Native scroll'u koruyup yalnız visual effect'i ona bağlamak daha güvenli tasarımdır.

Native Scroll Davranışını Değiştirmek

Browser scrolling cihaz ve işletim sistemi davranışına uyumludur. JavaScript virtual scroll bu modeli değiştirir. Touchpad momentum ve keyboard navigation bozulabilir. Browser history restoration etkilenebilir. Gerçek business gerekçesi yoksa native scroll korunmalıdır.

Scroll Mesafesini Manipüle Etmek

User 500 pixel scroll yaptığında content daha az veya daha fazla hareket ettirilebilir. Bu durum physical input ile visual sonuç arasındaki beklentiyi bozar. Motion sickness riski artabilir. Native scroll timeline visual effect için yeterli olabilir. Content position manipüle edilmemelidir.

Kullanıcı Kontrolünü Azaltmak

Scroll sırasında zorunlu scene geçişi veya snap user'ın istediği noktaya hızlı ulaşmasını engelleyebilir. Accessibility user kendi pace'ini seçemeyebilir. Escape veya reduced motion fallback sunulmalıdır. Daha iyi çözüm effect'i content navigation'dan ayırmaktır. Kullanıcı content'e her zaman doğrudan ulaşmalıdır.

Performans ve Accessibility Sorunları

Virtual scroll her frame JavaScript ve transform update gerektirebilir. Screen reader document position beklentisi farklılaşabilir. Focus element görünür alanda beklenmedik yerde olabilir. Browser find ve anchor navigation etkilenebilir. Bu maliyetler yalnız visual demo üzerinden değerlendirilemez.

Smooth Scroll ile Scroll-Jacking Arasındaki Fark

Smooth scroll native navigation hedefi arasında kısa ve kontrollü geçiş sağlayabilirken scroll-jacking kullanıcının genel scroll mekanizmasını yeniden tanımlar. CSS scroll-behavior: smooth browser'ın native modelini korur. JavaScript virtual scroll ise wheel veya touch input'unu intercept edip kendi position hesaplamasını yapabilir. Bu fark accessibility ve performance açısından önemlidir. Smooth davranış da reduced motion preference'e göre azaltılmalıdır.

Native Scrolling

Native scrolling browser ve OS tarafından optimize edilir. Touch, wheel ve keyboard interaction doğal çalışır. Compositor optimizasyonları kullanılabilir. Accessibility araçları beklenen document modelini görür. Varsayılan seçenek olarak korunmalıdır.

CSS scroll-behavior

scroll-behavior: smooth anchor veya programmatic scroll geçişini yumuşatabilir. JavaScript animation loop gerektirmez. Browser behavior kontrol eder. Reduced motion durumunda auto kullanılabilir. Long-distance hareket kullanıcıyı bekletmemelidir.

JavaScript Virtual Scroll

Virtual scroll input delta'yı alıp content transform'unu kendisi hesaplar. Native scroll position ile visual state ayrılabilir. Anchor ve focus behavior ek kod gerektirir. Main-thread work artabilir. Yalnız çok güçlü product gerekçesi varsa kullanılmalıdır.

Ne Zaman Kaçınılmalı?

Content site, kurumsal portal, form veya e-ticaret akışında native scroll çoğu zaman daha doğru seçimdir. Kullanıcı hız ve kontrol bekler. Virtual scroll branding amacıyla eklenmemelidir. Accessibility maliyeti yüksektir. Scroll-driven visual effect native scrolling üzerinde kurulabilir.

Kullanıcı Etkileşimleri Animasyondan Nasıl Öncelikli Tutulur?

Kullanıcı interaction her zaman dekoratif animation'dan daha yüksek öncelik taşımalıdır. Click, tap, typing, scroll, drag ve keyboard navigation anında görsel veya fonksiyonel cevap almalıdır. Animation bu input'u bekletmemeli, gerektiğinde kesilebilmeli veya yeni state'e yönlenebilmelidir. Event handler küçük tutulmalı ve immediate feedback mümkün olduğunca erken verilmelidir. Bu yaklaşım özellikle kurumsal form ve workflow ekranlarında animasyonun kullanıcı üretkenliğini düşürmesini engeller.

Click

Click geldiğinde button pressed veya loading state hemen görünmelidir. Navigation animation bitişi beklenmemelidir. Heavy logic ayrı task'e bölünebilir. Double-click behavior açık olmalıdır. Disabled state action başlatıldığında doğru uygulanmalıdır.

Tap

Touch kullanıcı küçük target veya uzun delay yaşamamalıdır. Press feedback 100 ile 200 milisaniye civarında kısa hissedilebilir. Gesture detection default scroll'u gereksiz bloke etmemelidir. Passive listener kullanılabilir. Motion düşük güçlü telefonda test edilmelidir.

Typing

Typing sırasında decorative animation main thread'i meşgul etmemelidir. Input value update önceliklidir. Search suggestion query debounce edilebilir. Background animation gerekiyorsa pause azaltılabilir. Text caret ve key response gecikmemelidir.

Scroll

Scroll native behavior ile ilerlemelidir. Heavy event handler kullanılmamalıdır. Visual effect declarative timeline'a taşınabilir. Offscreen animation pause edilebilir. Scroll-jacking'den kaçınılmalıdır.

Drag

Drag movement pointer position'a yakın tepki vermelidir. Transform translate kullanmak layout maliyetini azaltabilir. Pointermove eventleri frame başına coalesce edilebilir. Geometry sürekli ölçülmemelidir. Drop transition interruptible olmalıdır.

Keyboard Navigation

Focus hareketi animation bitişini beklememelidir. Modal açıldığında focus doğru hedefe geçmelidir. Drawer exit sırasında focused element DOM'dan kaldırılıyorsa focus fallback belirlenmelidir. Reduced motion keyboard kullanıcı için de geçerlidir. Focus outline animation tarafından gizlenmemelidir.

Animasyon Tıklamayı Geciktirmemeli

Tıklama kullanıcı niyetinin açık sinyalidir ve animation pipeline bu niyetin önüne geçmemelidir. Uzun JavaScript task'lardan kaçınmak, handler'ı küçük tutmak ve immediate visual feedback vermek temel yöntemlerdir. Görsel transition daha sonra başlayabilir veya ayrı compositor animation olabilir. Navigation veya form submit yalnız transitionend event'ine bağlanmamalıdır. Kullanıcı ikinci kez tıklarsa state machine yeni niyeti eski animasyondan daha öncelikli işlemelidir.

Uzun JavaScript Task'larından Kaçınmak

50 milisaniye ve üzeri uzun task input queue'yu bloke edebilir. Animation calculation büyükse parçalara bölünmelidir. Framework render yoğunluğu azaltılmalıdır. Data parsing animasyon anından ayrılabilir. RUM long task rate izlenebilir.

Event Handler'ı Küçük Tutmak

Handler user intent'i kaydeder ve gerekli küçük state'i günceller. Heavy query veya DOM measurement hemen yapılmayabilir. Callback süresi performance trace ile ölçülür. Async scheduling doğru yerde kullanılabilir. Handler içinde synchronous network mümkün değildir.

Görsel Animasyonu Daha Sonra Başlatmak

Pressed state ilk frame'de gösterilebilir. Daha büyük decorative transition sonraki frame'de başlar. Kullanıcı action kabul edildiğini anlar. Perceived latency düşer. Long animation işlevsel state'i bloke etmez.

Immediate UI Feedback

Button scale, background veya status text hızlı değişebilir. Server response bekleniyorsa loading state gösterilir. Optimistic UI güvenli transaction'larda değerlendirilebilir. Feedback 1 saniyelik giriş animasyonundan sonra verilmemelidir. Kullanıcının action'ı kaybolmuş hissi oluşmamalıdır.

Immediate Feedback Pattern

Immediate Feedback Pattern kullanıcı input'u geldiğinde işin tamamlanmasını beklemeden arayüzün niyeti kabul ettiğini göstermesidir. Press state, optimistic update veya loading indicator bu yaklaşımın parçalarıdır. Görsel feedback küçük ve hızlı olmalıdır. Uzun animation daha sonra devam edebilir. Kullanıcı tekrar action yaparsa state yeni intent'e göre güncellenmelidir.

Button Press State

Button tap edildiğinde kısa scale veya color response verilebilir. Transform ile 0.98 scale küçük hareket sağlar. Handler başlamadan önce CSS :active state kullanılabilir. 100 ile 200 milisaniyelik transition yeterlidir. Action completion bu movement'a bağlanmamalıdır.

Optimistic UI

Geri alınabilir veya güvenilir işlemlerde UI sonucu server response öncesi gösterebilir. User latency hissi azalır. Error durumunda rollback yapılmalıdır. Finansal kritik operation'da daha temkinli yaklaşım gerekir. Animation optimistic state değişimini açıklayabilir.

Loading State

Request belli süreyi aşacaksa loading state kullanıcıya işin devam ettiğini gösterir. Çok hızlı response için spinner flash yaratmamak adına kısa debounce kullanılabilir. Ancak content hazır olduğu halde minimum spinner süresiyle kullanıcı bekletilmemelidir. Skeleton yalnız layout öngörülebiliyorsa kullanışlıdır. Loading animation infinite CPU yükü oluşturmamalıdır.

Uzun Animasyon Öncesi Kullanıcıya Tepki Vermek

Page transition 400 milisaniye sürecekse navigation action önce başlatılabilir. Button state hemen değişir. Transition loading'i saklamak için değil state değişimini açıklamak için kullanılır. User yeniden input verdiğinde animation cancel edilebilir. Böylece motion kontrolü kullanıcıda kalır.

Animation Interruptibility Nedir?

Interruptibility devam eden animasyonun yeni kullanıcı input'u geldiğinde durdurulabilmesi, tersine çevrilebilmesi veya yeni hedefe yönlendirilebilmesidir. Kullanıcı menu açılırken tekrar kapatma düğmesine bastığında eski animation sıraya girmemelidir. Yeni state eski görsel timeline'ın bitmesini beklememelidir. WAAPI cancel ve reverse gibi kontrol mekanizmaları sunar. CSS transition da target value değiştiğinde doğal retarget davranışı sağlayabilir.

Kullanıcı İkinci Kez Tıklarsa

İkinci click yeni intent'tir. İlk transition tamamlanana kadar ignored edilmemelidir. State machine current state'i ve target state'i ayırabilir. Animation object mevcut progress'ten reverse edilebilir. UI kullanıcının en son isteğini takip etmelidir.

Yeni State Eski Animasyonu Kesebilmeli

Drawer entering durumundayken close gelirse exiting state'e geçebilir. Animation current visual state'ten yeni target'a yönlenir. Eski timeout veya promise stale işlem yapmamalıdır. Cleanup controller kullanılabilir. Latest state wins prensibi uygulanabilir.

Reverse

Reverse current animation'ı ters yönde oynatır. Menu open-close için doğal hissedebilir. WAAPI reverse() desteği sağlar. Playback rate ve current time korunabilir. Animation başlamamış veya tamamlanmış durumlar test edilmelidir. :contentReference[oaicite:24]{index=24}

Cancel

Cancel animation effect'ini kaldırır ve playback state'i sıfırlar. WAAPI cancel() mevcut keyframe effect'i durdurmak için kullanılabilir. Cancel sonrası final style ayrıca uygulanabilir. Finished promise rejection davranışı yönetilmelidir. MDN cancel metodunun animation'ı abort ettiğini ve effect'leri temizlediğini açıklar. :contentReference[oaicite:25]{index=25}

Retarget

Retarget yeni target position veya opacity değerine mevcut visual state'ten geçiş yapmayı ifade eder. Drag target veya responsive menu senaryosunda faydalıdır. CSS transition property value değişimi bunu doğal biçimde yapabilir. Custom physics current velocity'yi koruyabilir. Stale endpoint'e gitmekten kaçınılmalıdır.

Interruptible Animasyon Neden Önemlidir?

Hızlı kullanıcılar animasyon tasarımının öngördüğünden daha hızlı action yapabilir. Hover spam, rapid click veya menu aç-kapat gibi durumlar normal kullanımın parçasıdır. Interruptible olmayan hareketler input queue oluşturur ve kullanıcı kontrolünü azaltır. State her zaman son kullanıcı niyetini temsil etmelidir. Bu yaklaşım yalnız performans değil doğruluk ve UX açısından da gereklidir.

Hızlı Kullanıcı Etkileşimi

Kullanıcı birkaç yüz milisaniye arayla action yapabilir. Animation duration bundan uzun olabilir. App input'u ignore etmemelidir. Current transition cancel veya reverse edilir. Final state son intent'e göre belirlenir.

Hover Spam

Mouse hızlıca birkaç card üzerinde hareket edebilir. Her hover için queued animation başlatılırsa hareketler geriden gelir. CSS transition target değişimini doğal takip edebilir. Heavy library timeline queue kapatılmalıdır. Pointer coarse cihazda hover uygulanmamalıdır.

Rapid Click

Toggle button birkaç kez hızlı tıklanabilir. Her click ayrı animation queue oluşturmamalıdır. State boolean en son değeri tutar. Current animation target'a göre reverse veya cancel edilir. Debounce user intent'i engellemek için kullanılmamalıdır.

Menü Aç/Kapat

Menu opening sırasında Escape basılırsa hemen close süreci başlamalıdır. Focus return logic animation end'i beklememelidir. Overlay click de aynı state transition'ı çağırır. Multiple close event idempotent olmalıdır. Animation state machine bunu kolaylaştırır.

Kullanıcı Kontrolü

Animation UI'ın kullanıcıya rağmen devam eden ayrı bir süreç olmamalıdır. User input timeline'ı kontrol edebilmelidir. Reduced motion tercihi bu kontrolün başka boyutudur. Native scrolling korunmalıdır. Animation işlevin önüne geçmemelidir.

Animation Queue Anti-Pattern

Animation queue anti-pattern kullanıcı her input verdiğinde yeni hareketin önceki hareketlerin arkasına sıraya eklenmesiyle oluşur. Beş click beş sequential animation anlamına gelirse UI gerçek state'in saniyeler gerisinde kalabilir. Stale animation eski hedeflere doğru hareket eder. Daha doğru yaklaşım latest state wins veya cancel previous animation modelidir. Queue yalnız gerçekten sıralı choreography kullanıcı deneyiminin parçasıysa kullanılmalıdır.

Kullanıcı Beş Kez Tıkladığında Beş Animasyon Sıraya Girerse

User menu toggle'a beş kez basabilir. Queue modelinde uygulama birkaç saniye aç-kapa yapmaya devam eder. Kullanıcı kontrolü kaybolur. Final state en son click'e göre hemen hedeflenmelidir. Existing animation replace edilmelidir.

Stale Animations

Stale animation artık geçerli olmayan state'i temsil eder. Async promise tamamlandığında yanlış class ekleyebilir. Transition end handler old state'i commit edebilir. State token veya animation id kullanılabilir. Callback yalnız hâlâ current ise sonuç uygulamalıdır.

Latest State Wins

Latest state wins kullanıcıdan gelen son intent'i source of truth kabul eder. Existing movement yeni target'a geçer. Queue temizlenir. UI state daha öngörülebilir olur. Rapid interaction test otomasyona eklenmelidir.

Cancel Previous Animation

WAAPI animation reference saklanıp yeni animation başlamadan cancel() çağrılabilir. CSS class modelinde old transition target değiştirilebilir. Timer cleanup yapılmalıdır. Focus veya aria state animation cancellation'dan etkilenmemelidir. Visual state function state'i takip etmelidir.

Web Animations API (WAAPI)

Web Animations API JavaScript üzerinden browser animation engine'ini programatik biçimde kontrol etmeyi sağlar. element.animate() keyframe ve timing option alır, ardından bir Animation object döndürür. Bu nesne play, pause, cancel ve reverse gibi lifecycle kontrolü sunar. CSS keyframe ile aynı tür property'ler kullanılabilir. Runtime-controlled ve interruptible hareketlerde WAAPI, manual requestAnimationFrame loop'undan daha temiz model sağlayabilir. :contentReference[oaicite:26]{index=26}

element.animate()

element.animate() verilen keyframe ve option ile yeni animation oluşturup oynatır. Geri dönen object kontrol için saklanabilir. Bir element üzerinde birden fazla animation bulunabilir. CSS class yönetmeden dynamic timeline kurulabilir. Browser support modern ortamlarda geniştir. :contentReference[oaicite:27]{index=27}

Keyframes

Keyframes array veya property listesi olarak tanımlanabilir. Transform ve opacity performanslı başlangıç property'leridir. Dynamic değer runtime'da hesaplanabilir. Çok fazla layout property yine aynı rendering maliyetini taşır. WAAPI pahalı property'yi ucuz hale getirmez.

Timing Options

Duration, easing, delay, iterations ve fill gibi seçenekler object içinde belirlenebilir. User setting'e göre duration azaltılabilir. Infinite iteration yalnız gerekli component'te kullanılmalıdır. Easing perceived movement'ı etkiler. Runtime config design token ile standardize edilebilir.

Animation Object

Animation object current time, playback rate ve state üzerinde kontrol sağlar. Promise ve event lifecycle kullanılabilir. Reference component lifecycle boyunca saklanabilir. Unmount durumunda cancel edilmelidir. Multiple animation ownership açık olmalıdır.

play

play() paused veya idle animation'ı başlatabilir. Component visible olduğunda resume yapılabilir. User reduced motion mode'da play çağrısı atlanabilir. State machine play kararını verir. Animation object methodları manual timer'a göre daha yapılandırılmış kontrol sağlar.

pause

pause() animation'ı mevcut progress noktasında durdurur. Offscreen veya hidden tab senaryosunda kullanılabilir. Visible olduğunda resume yapılabilir. Business state pause'dan bağımsız kalmalıdır. UI content erişilebilir olmaya devam etmelidir.

cancel

cancel() animation playback'i ve effect'i sonlandırır. Rapid click sırasında old animation temizlenebilir. Cancel sonrası visual final style gerekirse set edilmelidir. Finished promise rejection handle edilmelidir. MDN behavior ayrıntılarını resmi olarak belgeliyor. :contentReference[oaicite:28]{index=28}

reverse

reverse() current animation direction'ını tersine çevirebilir. Menu veya accordion rapid toggle için kullanışlıdır. Existing progress korunarak daha doğal movement üretilebilir. End boundary state'leri test edilmelidir. Playback rate logic complexity gereksiz büyütülmemelidir. :contentReference[oaicite:29]{index=29}

WAAPI Ne Zaman CSS'ten Daha Uygundur?

WAAPI basit hover veya open-close transition için zorunlu değildir. Runtime'da keyframe üretmek, animation'ı programatik cancel etmek, sequence yönetmek veya current time kontrol etmek gerektiğinde daha güçlü hale gelir. CSS declarative state transition daha az kodla çözebiliyorsa CSS tercih edilmelidir. WAAPI JavaScript kontrolü verirken browser-native animation modelini kullanır. Bu nedenle custom manual animation loop yazmadan dynamic control elde edilebilir.

Runtime-Controlled Animation

User action'a göre duration veya target değişebilir. Animation object state kontrolü sağlar. Play, pause ve reverse programatik kullanılabilir. CSS class kombinasyonları büyümek zorunda kalmaz. Business state ile animation state yine ayrılmalıdır.

Dynamic Keyframes

Element geometry veya user selection'a göre keyframe runtime'da hesaplanabilir. Drag release sonrası current position target olabilir. Generated keyframe transform kullanabilir. Layout measurement başlangıçta yapılır. Animation sırasında tekrar ölçmekten kaçınılır.

Cancellation

Current animation explicit reference ile cancel edilebilir. Rapid user input için değerlidir. Async cleanup daha nettir. CSS transitionend event bağımlılığı azalır. Final state state machine tarafından belirlenir.

Sequencing

Bir animation finished olduktan sonra başka animation başlatılabilir. Promise chain veya timeline utility kullanılabilir. User interrupt geldiğinde sequence iptal edilebilmelidir. Long choreography critical workflow'u bekletmemelidir. Reduced motion sequence'i kısaltabilir.

Scroll Timeline

Web Animations API tarafında ScrollTimeline interface'i animation progress'i scroll timeline'a bağlayabilir. MDN 2026 itibarıyla bu interface'i Limited Availability olarak işaretliyor. Bu nedenle progressive enhancement ve CSS alternatifleri düşünülmelidir. Support olmayan browser normal state kullanabilir. Feature detection zorunludur. :contentReference[oaicite:30]{index=30}

CSS, WAAPI ve requestAnimationFrame Karar Modeli

Animasyon teknolojisi seçimini görsel popülerlik yerine kontrol ihtiyacına göre yapmak daha sürdürülebilir sonuç verir. Basit iki state transition CSS ile çözülebilir. Runtime-controlled keyframe ve cancellation WAAPI için uygundur. Canvas, physics veya custom renderer requestAnimationFrame gerektirebilir. Aynı projede bu üç yöntemin birlikte kullanılması normaldir ve tek teknoloji standardına zorlamak gereksiz kod üretir.

Basit State Transition → CSS

Hover, focus, menu open veya button pressed iki state arasında geçer. CSS transition en az JavaScript ile çözüm sağlar. Transform ve opacity tercih edilebilir. Reduced motion media query kolay uygulanır. Framework yalnız state class'ını değiştirir.

Kontrollü Timeline → WAAPI

Animation cancel, reverse veya dynamic timing gerektiriyorsa WAAPI daha uygun olabilir. Object reference lifecycle kontrolü sağlar. Runtime keyframe üretilebilir. Manual frame loop gerekmez. Property maliyeti yine browser pipeline'a bağlıdır.

Canvas/Physics/Custom Rendering → requestAnimationFrame

Canvas scene her frame application tarafından çizilecekse requestAnimationFrame doğal seçimdir. Physics state delta time ile ilerler. Main thread budget dikkatle yönetilir. Çok ağır hesaplama worker'a ayrılabilir. Hidden durumda loop durdurulur.

Karmaşık Choreography → Animation Library Değerlendir

Çok sayıda element timeline, spring veya gesture coordination gerektiriyorsa library developer experience sağlayabilir. Ancak bundle ve runtime cost ölçülmelidir. Native CSS veya WAAPI ile çözülen işler library'ye bağımlı hale getirilmemelidir. Tree shaking ve route lazy loading uygulanabilir. Maintenance sahipliği açık olmalıdır.

Animation Library Kullanılmalı mı?

Animation library geliştirme hızını artırabilir, ancak her projede gerekli değildir. Native CSS, WAAPI ve View Transition modern browserlarda birçok interaction'ı çözebilir. Library seçimi bundle size, layout animation, gesture, spring physics ve ekip deneyimi üzerinden yapılmalıdır. Bir kütüphanenin kolay API sunması rendering maliyetini ortadan kaldırmaz. Kurumsal projede uzun vadeli bakım ve upgrade davranışı da kararın parçasıdır.

Native API Yetiyor mu?

İlk soru mevcut hareket CSS transition veya WAAPI ile çözülebiliyor mu olmalıdır. Basit slide ve fade için evet olabilir. Native çözüm bundle eklemez. Browser capability kullanılır. Custom choreography gerekirse library sonraki seçenek olur.

Bundle Size

Animation library JavaScript transfer, parse ve compile maliyeti getirir. Marketing page'de birkaç hover için büyük package gereksiz olabilir. Bundle analyzer gerçek route etkisini gösterir. Tree shaking doğrulanmalıdır. Lazy import secondary animation için kullanılabilir.

Layout Animation

Bazı library'ler FLIP veya layout transition abstraction sağlar. React list reorder gibi durumlarda developer effort azalabilir. Underlying DOM measurement maliyeti devam eder. Büyük listede profile edilmelidir. Native View Transition alternatif olabilir.

Gesture

Drag, swipe ve spring gesture library ile daha kolay yönetilebilir. Pointer event ve velocity calculation hazır gelir. Touch scroll conflict doğru ele alınmalıdır. Library default behavior accessibility açısından test edilmelidir. Simple drag için native pointer event yeterli olabilir.

Spring Physics

Spring animation natural motion hissi verir. Runtime simulation veya analytically solved curve kullanılabilir. Overshoot kullanıcı task'ını geciktirmemelidir. Reduced motion mode'da spring kaldırılabilir. Framework re-render yerine motion value kullanımı daha uygun olabilir.

Developer Experience

Library declarative syntax ve lifecycle entegrasyonu sağlayabilir. Ekip aynı pattern'i daha hızlı uygular. Ancak abstraction rendering pipeline bilgisini gizlememelidir. Developer performans trace okumayı bilmelidir. Standard design motion token library üzerinde ortaklaştırılabilir.

GSAP, Motion ve Native API Arasında Nasıl Karar Verilir?

GSAP, Motion veya native API seçimi animasyonun karmaşıklığı, framework entegrasyonu, bundle hedefi ve choreography ihtiyacına göre yapılmalıdır. Basit hover ve modal transition için native CSS yeterli olabilir. Çok katmanlı timeline veya yoğun gesture kontrolü library kullanımını haklı çıkarabilir. Scroll behavior mümkün olduğunda native Scroll-Driven Animations ile karşılaştırılmalıdır. Karar teknik demo kolaylığına değil production bundle, interaction latency ve bakım maliyetine dayanmalıdır.

Animasyon Karmaşıklığı

Tek element iki state ise native çözüm daha basittir. Çok elementli timeline library ile okunabilir olabilir. Complexity arttıkça state cancellation daha önemli hale gelir. Library timeline interrupt test edilmelidir. Kullanıcı input'u her zaman öncelikli kalmalıdır.

Bundle Büyüklüğü

Library full bundle yerine kullanılan modüller alınabilir. Tree shaking gerçek build output'ta doğrulanmalıdır. Route-specific animation lazy load edilebilir. Marketing route ve dashboard aynı bundle'a zorlanmamalıdır. Transfer size yanında parse cost ölçülmelidir.

Framework Entegrasyonu

Motion benzeri çözümler framework lifecycle ile daha doğal çalışabilir. DOM mount ve unmount transition kolaylaşır. Ancak her frame framework state güncellemekten kaçınılmalıdır. Animation state library internal value'da tutulabilir. Component cleanup doğru yapılmalıdır.

Scroll Choreography

Complex pinned timeline library ile kolay kurulabilir. Ancak native scrolling'i bozmamak gerekir. CSS Scroll-Driven Animations daha basit progress effect için değerlendirilebilir. Browser support fallback yapılır. Scroll-jacking library kullanımıyla normalleştirilmemelidir.

Browser-Native Acceleration

Native CSS ve WAAPI browser animation engine'ini doğrudan kullanır. Library de çoğu zaman aynı transform ve opacity property'lerini sürer. “Library GPU hızlandırıyor” marketing ifadesi tek başına karar kriteri değildir. DevTools gerçek layer ve main-thread work'u gösterir. Property choice belirleyicidir.

Maintenance

Library version upgrade framework upgrade ile birlikte takip edilmelidir. API breaking change riski vardır. Native API uzun vadede bağımlılığı azaltabilir. Ekip library uzmanlığına tek kişi üzerinden bağlı kalmamalıdır. Motion guideline abstraction layer bakımını kolaylaştırabilir.

React Uygulamalarında Animasyon Performansı

React uygulamalarında browser animation ile React render lifecycle birbirinden ayrılmalıdır. Her frame setState() çağırmak component tree reconciliation ve render oluşturabilir. Animation progress yalnız DOM visual state ise CSS, WAAPI veya motion value gibi framework render'ından bağımsız mekanizma daha uygun olabilir. Expensive component render animation sırasında input responsiveness'i etkileyebilir. React Profiler ile browser Performance trace birlikte kullanılmalıdır.

React Render ve Browser Animation Ayrımı

React application state'i ve component structure'ı yönetir. Browser animation engine visual interpolation yapabilir. Her interpolation step React state olmak zorunda değildir. State yalnız meaningful UI state'i temsil eder. Animation progress browser tarafında kalabilir.

Her Frame setState Kullanmanın Riski

60 veya 120 kez state update component tree render edebilir. Memoization her sorunu çözmez. Scheduling input handler ile yarışabilir. Canvas veya data visualization dışında çoğu UI motion için gereksizdir. Profiler render count'u göstermelidir.

DOM Ref / Motion Value

Drag position gibi yüksek frekanslı visual değer ref veya specialized motion value içinde tutulabilir. React render yalnız start veya end state'te gerekir. DOM transform doğrudan güncellenebilir. Ownership ve cleanup açık olmalıdır. Accessibility state React içinde kalabilir.

Compositor Animation

React component class veya style target'ı bir kez değiştirir. CSS transition interpolasyonu browser'a bırakır. Main thread framework work azalır. Transform ve opacity tercih edilir. DevTools behavior doğrular.

Expensive Component Render

Animation state değişikliği chart veya table gibi pahalı subtree'yi yeniden render etmemelidir. Component boundary ve memoization kullanılabilir. State colocated tutulmalıdır. Context update geniş render oluşturabilir. Performance profiling source component'i bulmalıdır.

State Update ile Her Frame Animasyon Yapılmalı mı?

Çoğu kullanıcı arayüzü animasyonunda framework state'i her frame güncellemek gerekli değildir. State open, closed veya selected gibi anlamlı uygulama durumunu tutabilir. Ara visual progress CSS veya WAAPI tarafından yürütülebilir. Bu ayrım reconciliation maliyetini azaltır ve animation lifecycle'ı daha sade hale getirir. Canvas veya fizik simülasyonu gibi özel senaryolar farklı model gerektirebilir.

Framework Reconciliation

State update virtual tree comparison veya başka reconciliation işi tetikleyebilir. Bu işlem küçük componentte ucuz olabilir. Large dashboard'da pahalı hale gelebilir. Animation frame budget aynı thread'i kullanır. Gereksiz per-frame state kaldırılmalıdır.

Component Tree Re-Render

Parent state update birçok child render edebilir. Animation yalnız bir icon hareketiyse bu gereksizdir. State component'e daha yakın taşınabilir. CSS pseudo class kullanılabilir. Profiler affected tree'yi gösterir.

CSS/WAAPI Alternatifi

Open state değiştiğinde CSS transition başlayabilir. Dynamic cancellation gerekiyorsa WAAPI object kullanılabilir. Framework yalnız lifecycle başlangıç ve bitişini yönetir. Browser interpolation'ı yapar. Application JavaScript daha az çalışır.

UI State ile Animation State'i Ayırmak

UI state “menu open” bilgisidir. Animation state “entering yüzde 42” olabilir. İkinci bilgi çoğu durumda application store'a ait değildir. Animation controller içinde tutulabilir. Böylece business logic visual frame detayından bağımsız kalır.

Gesture Animasyonları

Gesture animation drag, swipe, pinch ve başka continuous pointer input'ları doğrudan visual response'a bağlar. Kullanıcı eliyle hareket ettiği için latency çok daha görünür hissedilir. Pointer Events farklı input türleri için ortak model sağlar. Transform translate ve scale layout değişimini azaltabilir. Event stream frame başına coalesce edilerek gereksiz DOM update sayısı düşürülebilir.

Drag

Drag element pointer position'ı takip eder. Pointer capture interaction continuity sağlar. Geometry başlangıçta cache edilebilir. Visual movement transform ile uygulanabilir. Drop sonrası layout transition FLIP ile yapılabilir.

Swipe

Swipe direction ve velocity gesture sonunda target belirleyebilir. Pointermove sırasında translate güncellenir. Threshold user expectation'a göre seçilir. Native horizontal scroll ile conflict dikkatle yönetilir. Reduced motion final snap'i kısaltabilir.

Pinch

Pinch iki pointer arasındaki distance değişimini scale'e dönüştürebilir. Image viewer gibi özel use case'te uygundur. Browser native zoom engellenmemelidir, özellikle page accessibility için. Gesture target area açık olmalıdır. Heavy image decode interaction öncesi tamamlanmalıdır.

Pointer Events

Pointer Events mouse, touch ve pen için ortak API sağlar. Pointer ID multi-touch yönetimini kolaylaştırır. Pointer capture drag sırasında target continuity sağlar. Event handler küçük tutulmalıdır. Touch-action CSS browser gesture behavior'ını doğru tanımlamalıdır.

Touch Input

Touch screen'de scroll ve gesture aynı input yüzeyini paylaşır. preventDefault gereksiz kullanılırsa native scrolling bozulur. Passive listener veya touch-action doğru yerde kullanılmalıdır. Target boyutu erişilebilir olmalıdır. Low-end Android interaction testi önemlidir.

Drag Animasyonlarında Performans

Drag hareketinde kullanıcı parmağı veya mouse ile element arasında doğrudan ilişki bekler, bu nedenle birkaç frame gecikme bile fark edilir. Pointermove event'inde layout-changing property kullanmak yerine transform translate tercih edilmelidir. Geometry her event tekrar ölçülmemelidir. Son pointer position saklanıp requestAnimationFrame içinde tek visual update yapılabilir. Bu yaklaşım event flood'u ile rendering frequency'yi ayırır.

Pointermove

Pointermove çok sık çalışabilir. Handler yalnız latest coordinates saklayabilir. Heavy collision detection her event yapılmamalıdır. Gerekirse belirli frame'lerde çalıştırılır. Pointer capture outside bounds movement'ı korur.

transform: translate

Element position translate ile güncellenebilir. Layout sibling position'ı değişmez. Drag placeholder gerçek layout alanını koruyabilir. Drop sonunda final DOM order güncellenir. FLIP transition eklenebilir.

Layout Değiştirmemek

Top, left veya margin her pointermove değiştirilirse layout maliyeti oluşabilir. Transform visual position için daha uygundur. Drop target highlight ayrı class ile yapılabilir. Sibling reorder drag bitişinde veya threshold crossing'de hesaplanabilir. Performance trace doğrulanmalıdır.

DOM Ölçümünü Her Pointer Event'te Yapmamak

Container bounds drag başlangıcında cache edilebilir. Resize olmadığı sürece tekrar okumaya gerek yoktur. Target list geometry de snapshot alınabilir. Dynamic list değişirse cache invalidate edilir. Forced layout riski azalır.

requestAnimationFrame Coalescing

Bir frame içinde gelen çok sayıda pointer event'in son coordinate'i kullanılabilir. requestAnimationFrame callback element transform'unu bir kez günceller. Visual motion display refresh ile uyumlu olur. Handler workload küçülür. Delta veya velocity calculation timestamp ile yapılabilir.

Passive Event Listener Nedir?

Passive event listener browser'a handler'ın default event davranışını preventDefault() ile engellemeyeceğini bildiren listener seçeneğidir. Scroll ve touch input'ta browser'ın kullanıcı hareketini daha rahat planlamasına yardımcı olabilir. Her listener passive yapılmamalıdır, çünkü bazı gerçek gesture senaryolarında preventDefault gerekebilir. Bu durumda touch-action gibi daha declarative CSS kontrolü önce değerlendirilmelidir. Interaction responsiveness için listener içinde ağır JavaScript yine önlenmelidir.

Scroll ve Touch Event'leri

Wheel ve touchmove browser scroll davranışını etkileyebilir. Non-passive listener preventDefault çağrısı ihtimali nedeniyle browser'ı bekletebilir. Passive true bu ihtimali kaldırır. Handler analytics gibi non-blocking iş yapıyorsa uygundur. Visual update rAF ile schedule edilebilir.

Browser'ın Scroll'u Bekletmemesi

Browser listener'ın scroll'u cancel etmeyeceğini biliyorsa default movement daha erken ilerleyebilir. Kullanıcı latency hissi azalabilir. Heavy handler yine CPU tüketir. Passive yalnız scheduling signal'dır. Scroll performance bütün pipeline ile ölçülmelidir.

preventDefault Gerektiren Durumlar

Custom drag veya canvas gesture bazı default behavior'ları engellemek isteyebilir. Listener passive olamaz. Önce touch-action ile browser'a allowed gesture bildirilebilir. Accessibility ve native zoom davranışı korunmalıdır. Global preventDefault kullanılmamalıdır.

Interaction Responsiveness

Input event hızlı işlenmelidir. Listener içinde network veya heavy DOM work yapılmamalıdır. Update batch edilir. INP saha metric'i kullanıcı etkisini gösterir. Gesture component düşük güçlü cihazda test edilir.

Offscreen Animasyonlar Durdurulmalı mı?

Görünmeyen animasyon kullanıcıya hiçbir görsel değer üretmediği halde CPU, GPU ve battery kullanmaya devam edebilir. Infinite spinner, particle canvas veya Lottie offscreen olduğunda pause edilmelidir. IntersectionObserver visibility durumunu izleyebilir. Page Visibility API tab tamamen hidden olduğunda daha geniş pause davranışı sağlayabilir. Element geri geldiğinde state'e göre resume veya reset yapılabilir.

Görünmeyen Animasyonun CPU Maliyeti

Canvas loop viewport dışında olsa bile JavaScript çalışabilir. CSS infinite animation browser tarafından optimize edilse bile GPU/composite işi oluşabilir. Particle simulation CPU tüketir. User hiçbir şey görmez. Pause enerji verimliliğini artırır.

IntersectionObserver

Observer element viewport'tan çıktığında animation pause edebilir. Root margin küçük buffer sağlayabilir. CSS class veya WAAPI pause kullanılabilir. Canvas request loop durdurulur. Element yeniden görünür olduğunda resume edilir.

Page Visibility API

Document hidden olduğunda non-essential animation ve media work durdurulabilir. requestAnimationFrame çoğu browserda zaten pause edilir. Custom timer ve worker simulation ayrıca kontrol edilmelidir. User tab'a dönünce elapsed time davranışı belirlenmelidir. Large delta clamp yapılabilir.

pause/resume

WAAPI animation pause ve play methodları state'i korur. CSS animation-play-state kullanılabilir. Canvas loop last state'i memory'de tutar. Resume visual jump oluşturmamalıdır. Business timer animation timer'dan ayrılmalıdır.

Battery Usage

Continuous animation CPU ve GPU wakeup oluşturabilir. Mobile battery tüketimi artar. Decorative background saatlerce açık dashboard'da gereksizdir. Visibility pause önemli tasarım standardı olmalıdır. Energy profile mümkünse gerçek cihazda gözlemlenmelidir.

Sonsuz Animasyonların Maliyeti

Infinite animation başlangıçta küçük görünse de kullanıcı sayfayı uzun süre açık tuttuğunda sürekli CPU veya GPU tüketebilir. Spinner gerçekten loading varken anlamlıdır, loading bittikten sonra DOM'da çalışmamalıdır. Decorative background ve particle effect kullanıcı göreviyle doğrudan ilişkili değilse özellikle sınırlanmalıdır. Offscreen ve hidden tab durumunda pause edilmelidir. Kurumsal dashboard gibi saatlerce açık kalan uygulamalarda enerji tüketimi önemli performans kriteridir.

Spinner

Spinner yalnız işlem sürerken görünmelidir. CSS rotate transform kullanılabilir. Çok sayıda spinner aynı anda çalışmamalıdır. Content hazır olur olmaz kaldırılmalıdır. Reduced motion'da static progress indicator kullanılabilir.

Decorative Background

Animated gradient veya floating shape sürekli hareket edebilir. Main task'a katkısı yoksa cost budget çok düşük tutulmalıdır. Mobile'da kapatılabilir. Visibility pause uygulanmalıdır. Background animation input ile yarışmamalıdır.

Particle Effects

Particle system yüzlerce object update edebilir. Canvas veya WebGL DOM'dan daha uygun olabilir. Particle count device capability'ye göre azaltılabilir. User reduced motion preference'inde effect kapatılmalıdır. Long session thermal behavior test edilmelidir.

CPU/GPU Kullanımı

Infinite visual her frame render işi oluşturabilir. Compositor-only olsa bile GPU aktif kalabilir. Battery profile etkilenir. Performance monitor CPU ve GPU activity gösterebilir. User value ile kaynak maliyeti kıyaslanmalıdır.

Battery Drain

Mobil browserlarda sürekli animation battery tüketimini artırabilir. High refresh rate device'da callback frequency daha yüksek olabilir. Background tab pause önemlidir. Offscreen effect stop edilmelidir. Product requirement motion duration sınırı koyabilir.

Görünür Değilken Pause

IntersectionObserver visible state'i yönetebilir. WAAPI pause veya CSS class kullanılabilir. Canvas loop cancel edilir. Resume state korunur. Bu behavior reusable animation component içinde varsayılan yapılabilir.

Loading Animasyonları Kullanıcıyı Yavaş Hissettirebilir mi?

Evet, loading animation yanlış tasarlandığında gerçek sistem hızlı olsa bile kullanıcıya gereksiz bekleme hissi verebilir. Minimum spinner duration koyup content hazır olduğu halde animasyonu devam ettirmek buna örnektir. Skeleton layout stability sağlarken uzun süre kalırsa aynı etkiyi oluşturabilir. Progress indicator gerçek ilerleme varsa daha güven vericidir. Loading görseli işlemi açıklamalı, işlemin bitmesini geciktirmemelidir.

Skeleton Screen

Skeleton içerik layout'unu önceden göstererek layout shift azaltabilir. Gerçek content boyutuna yakın olmalıdır. Shimmer infinite animation düşük maliyetli tutulmalıdır. Reduced motion'da shimmer kapatılabilir. Content hazır olduğunda skeleton hemen kaldırılmalıdır.

Spinner

Spinner kısa belirsiz beklemeyi gösterir. Çok hızlı operation'da blink oluşturabilir. 100 ile 200 ms gecikmeli gösterim değerlendirilebilir. Gösterildikten sonra gereksiz minimum süre uygulanmamalıdır. Process tamamlanınca hemen değişmelidir.

Progress Indicator

Known progress varsa percentage kullanıcıya daha fazla bilgi verir. Fake progress güven kaybı oluşturabilir. Update frequency gereksiz yüksek olmamalıdır. Width yerine transform scale kullanılabilir. Screen reader progress semantics eklenmelidir.

Content Hazır Olduğunda Animasyonu Geciktirmemek

Data response geldiyse sadece güzel exit animation için content'i yüzlerce milisaniye bekletmek çoğu durumda gereksizdir. Loading element kısa fade ile çıkabilir. Content aynı frame veya hemen sonraki frame'de görünür olmalıdır. User input tekrar aktif hale gelmelidir. Animation function state'e bağlı kalmamalıdır.

Minimum Spinner Duration Anti-Pattern

Minimum duration hızlı response'u yapay olarak yavaşlatır. Amaç spinner flash'ını önlemekse spinner gösterimini geciktirmek daha mantıklıdır. Request 150 ms altında biterse spinner hiç görünmez. Uzun sürerse gösterilir ve iş biter bitmez kaldırılır. Kullanıcı gerçek performansı hisseder.

SVG Animasyon Performansı

SVG icon, diagram ve data visualization için güçlüdür, ancak node sayısı arttıkça DOM ve paint maliyeti büyüyebilir. Transform ve opacity genellikle iyi başlangıç property'leridir. Path morph veya stroke-dash animation daha fazla geometry işi yapabilir. Filter effect özellikle blur veya shadow maliyeti ekler. Çok büyük scene için canvas veya WebGL alternatifi düşünülmelidir.

transform

SVG group veya element transform ile taşınabilir ve döndürülebilir. Layout DOM akışını etkilemez. Browser implementation layer davranışı farklı olabilir. Transform-box ve transform-origin dikkat ister. Büyük SVG scene profile edilmelidir.

opacity

SVG opacity fade için basittir. Group opacity birçok child üzerinde tek transition sağlayabilir. Çok büyük group compositing layer olabilir. Pointer ve accessibility state ayrıca yönetilir. Hidden element gerektiğinde DOM'dan çıkarılabilir.

Path Animation

Path morph geometry hesaplaması gerektirir. Çok karmaşık path her frame pahalı olabilir. Point sayısı optimize edilebilir. Precomputed keyframe kullanılabilir. Mobile test gereklidir.

Çok Fazla SVG Node

Binlerce SVG node DOM overhead oluşturur. Chart label ve marker sayısı sınırlandırılmalıdır. Aggregation veya sampling kullanılabilir. Canvas daha uygun olabilir. Accessibility için semantic summary korunmalıdır.

Filter Effects

SVG filter blur, shadow ve distortion sağlayabilir. Büyük filter region paint maliyetini artırır. Filter bounds küçültülmelidir. Continuous filter animation azaltılmalıdır. Static effect daha güvenli olabilir.

Lottie Animasyonlarında Performans

Lottie tasarım araçlarından export edilen JSON tabanlı animasyonları web'de oynatmayı kolaylaştırır, fakat dosya boyutu ve layer sayısı performansı doğrudan etkiler. Çok complex illustration düşük güçlü telefonda beklenenden daha ağır olabilir. SVG ve canvas renderer farklı trade-off sunar. Offscreen Lottie pause edilmelidir. Asset production'a çıkmadan önce JSON size, initialization time ve frame behavior gerçek cihazda ölçülmelidir.

JSON Boyutu

Büyük Lottie JSON network transfer ve parse maliyeti getirir. Path ve keyframe sayısı azaltılabilir. Gzip veya Brotli transferi küçültür. Animation route lazy load edilebilir. Critical content animation asset'ine bağlı olmamalıdır.

Layer Sayısı

Export içinde çok fazla layer runtime work'u artırabilir. Hidden layer temizlenmelidir. Designer export optimization yapmalıdır. Repeater veya mask sayısı kontrol edilmelidir. Performance budget design handoff'a dahil edilmelidir.

SVG Renderer

SVG renderer DOM node'ları üretir. Accessibility veya CSS control avantajı olabilir. Node sayısı yüksek olduğunda DOM maliyeti artar. Filter effect dikkat ister. Küçük icon animation için uygun olabilir.

Canvas Renderer

Canvas tek drawing surface kullanır. Çok sayıda shape için DOM overhead azaltabilir. Accessibility semantic content ayrı sunulmalıdır. Resize ve high-DPI rendering maliyeti vardır. Static fallback image sağlanabilir.

Offscreen Pause

Lottie viewport dışındaysa playback pause edilmelidir. IntersectionObserver kullanılabilir. Infinite loop yalnız visible durumda çalışır. Tab hidden state ayrıca kontrol edilir. Battery tüketimi azalır.

Düşük Güçlü Cihaz Testi

Export laptop'ta akıcı olabilir. Android entry-level cihaz decode ve render sırasında zorlanabilir. CPU throttling ilk sinyal verir. Gerçek cihaz final karar için gereklidir. Frame drop ve battery gözlemlenmelidir.

Canvas Ne Zaman DOM Animasyonundan Daha Uygundur?

Canvas çok sayıda drawable object'in her frame değiştiği sahnelerde DOM element sayısını azaltarak daha uygun olabilir. Particle system, yoğun chart veya game-like rendering bu kategoriye girer. Canvas visual pixel surface olduğu için accessibility semantics otomatik gelmez. User interaction hit testing application tarafından yapılır. Basit button veya menu animation için canvas kullanmak gereksizdir.

Yüzlerce/H binlerce Drawable Object

Binlerce DOM node yerine tek canvas üzerinde çizim yapılabilir. Draw call ve state change optimize edilmelidir. Offscreen object culling yapılabilir. High-DPI canvas pixel count kontrol edilmelidir. Animation loop requestAnimationFrame kullanır.

Particle System

Particle object position ve velocity array içinde tutulabilir. Canvas toplu çizim yapar. Particle count device adaptive azaltılabilir. Offscreen olduğunda loop durur. Reduced motion effect'i kapatabilir.

Chart

Scatter plot milyonlarca point için SVG uygun olmayabilir. Canvas sampling ve rendering performansı sağlar. Hover hit test ayrı data structure gerektirir. Accessibility table summary sunulmalıdır. Zoom interaction CPU budget ile test edilir.

Game-Like Rendering

Continuous scene update canvas modeline uygundur. Physics ve input loop requestAnimationFrame kullanır. Asset decode ve sprite atlas optimize edilir. Background tab pause yapılır. Keyboard focus ve controls semantic DOM ile desteklenir.

Accessibility Trade-Off

Canvas içindeki shape'ler DOM accessibility tree'de doğal element değildir. Button veya data point interaction için semantic alternatif sağlanmalıdır. Screen reader user aynı bilgiye ulaşabilmelidir. Keyboard control ayrıca geliştirilir. Performance kazanımı erişilebilirlik kaybı pahasına olmamalıdır.

WebGL Ne Zaman Kullanılmalı?

WebGL GPU tabanlı 2D ve 3D rendering için güçlü API'dir ve çok sayıda sprite, shader effect veya complex scene için değer üretir. Ancak basit UI animation için gereksiz geliştirme yükü oluşturur. GPU throughput yüksek olsa bile draw call, texture upload ve shader cost performansı sınırlar. Context loss ve device capability yönetilmelidir. WebGL kullanmak otomatik olarak daha hızlı olmak anlamına gelmez.

3D

Gerçek 3D scene WebGL'in doğal alanıdır. Camera ve mesh GPU pipeline içinde işlenir. Asset size ve texture memory önemlidir. Mobile polygon count azaltılabilir. Reduced motion camera movement'ı sınırlayabilir.

Çok Sayıda Sprite

Sprite batching draw call sayısını azaltabilir. Texture atlas kullanılabilir. Particle veya map visualization uygun örnektir. Overdraw kontrol edilmelidir. Frame time GPU profiler ile ölçülmelidir.

Shader Effects

Custom shader blur, distortion veya procedural effect sağlar. Full-screen fragment shader yüksek pixel throughput kullanır. Mobile GPU'da maliyet hızla artabilir. Resolution scaling uygulanabilir. Decorative shader low-power mode'da kapatılabilir.

GPU Throughput

GPU paralel pixel ve vertex işlemlerinde güçlüdür. Ancak memory bandwidth sınırlıdır. Büyük texture upload frame jank oluşturabilir. CPU-GPU synchronization da maliyetlidir. Rendering pipeline dengeli tasarlanmalıdır.

WebGL Kullanmanın Otomatik Olarak Hızlı Olmadığı Durumlar

Her frame büyük texture upload etmek WebGL'i yavaşlatabilir. Çok fazla draw call CPU bottleneck oluşturabilir. Shader branch veya overdraw GPU'yu zorlayabilir. Low-end device driver davranışı farklıdır. Profiling olmadan teknoloji etiketi üzerinden karar verilmemelidir.

Görsel ve Video Tabanlı Scroll Animasyonları

Scroll ile image sequence veya video scrubbing etkileyici olabilir, ancak asset decode ve memory maliyeti çok yüksektir. Yüzlerce büyük frame'i preload etmek mobile memory'yi tüketebilir. Video codec hardware decode avantajı sağlayabilir. User scroll progress ile playback time bağlanabilir. Mobile fallback daha kısa sequence veya static poster olarak tasarlanmalıdır.

Image Sequence

Her scroll progress farklı image frame gösterebilir. File count network request'i artırır. Sprite sheet veya packed format düşünülebilir. Decode önceden yapılmalıdır. Resolution device'a göre seçilmelidir.

Video Scrubbing

Video timeline scroll progress'e bağlanabilir. Codec seek behavior önemlidir. Keyframe interval scrubbing smoothness'i etkiler. Preload strategy network kullanımını kontrol eder. Browser autoplay policy audio içerikte dikkate alınmalıdır.

Decode Maliyeti

Compressed asset ekrana gelmeden decode edilmelidir. Decode CPU veya hardware decoder kullanabilir. Scroll sırasında on-demand decode jank oluşturabilir. Yaklaşan frame önceden hazırlanabilir. Memory ile preload arasında denge kurulmalıdır.

Memory

Decoded image compressed file'dan çok daha fazla memory kullanabilir. Yüzlerce 4K frame cihazı zorlar. Cache window yalnız yakın frameleri tutabilir. Eski frame release edilir. Mobile memory pressure test edilmelidir.

Preloading

İlk birkaç frame critical olabilir. Bütün sequence başlangıçta indirilmemelidir. Viewport yaklaşınca preload yapılabilir. Network priority primary content'i engellememelidir. Slow connection fallback static media olabilir.

Mobile Fallback

Mobile'da shorter sequence veya static image seçilebilir. Reduced motion user için animation kaldırılabilir. Device memory hint tek başına güvenilir karar kaynağı değildir. User preference daha yüksek önceliklidir. Fallback content aynı bilgiyi taşımalıdır.

Asset Decode Animasyonu Nasıl Etkiler?

Animation code hızlı olsa bile image veya video asset ilk kez gerektiğinde decode işlemi frame'i geciktirebilir. Büyük görselin networkten gelmiş olması decode edildiği anlamına gelmez. Scroll sahnesinde tam interaction anında decode başlarsa jank görülebilir. Gerekli asset'leri doğru zamanda preload ve decode etmek önemlidir. Ancak her asset'i başlangıçta hazırlamak memory ve initial load maliyetini artırır.

Büyük Görsel

4K image yüksek compressed size ve decode memory kullanabilir. Display size daha küçükse responsive asset sunulmalıdır. Unused resolution indirilmemelidir. Image dimensions layout stability sağlar. Lazy loading critical olmayan asset için kullanılabilir.

Image Decode

Browser compressed image data'yı pixel buffer'a çevirir. img.decode() bazı senaryolarda paint öncesi hazırlık için kullanılabilir. Çok sayıda image aynı anda decode edilmemelidir. Priority sıralanmalıdır. Memory release takip edilmelidir.

Video Decode

Video decode codec ve hardware support'a bağlıdır. High resolution ve frame rate maliyeti artırır. Scrubbing random seek decoder için zor olabilir. Keyframe structure production pipeline'da optimize edilmelidir. Mobile test yapılmalıdır.

Main Thread / Decoder Pressure

Decode ayrı thread veya hardware kullanabilse de resource contention yaratabilir. Image decode sonucu texture upload gerekir. Animation başlangıcında başka script work varsa combined latency artabilir. Initialization schedule ayrıştırılmalıdır. Performance trace medya eventleriyle birlikte incelenebilir.

Görselleri Önceden Hazırlamak

Yaklaşan animation asset viewport'a yaklaşınca preload edilebilir. IntersectionObserver trigger sağlayabilir. Bütün site media'sı upfront alınmamalıdır. Critical first frame öncelikli tutulur. Network throttling ile timing test edilir.

prefers-reduced-motion Nedir?

prefers-reduced-motion kullanıcı işletim sistemi veya browser düzeyinde daha az hareket tercih ettiğinde CSS tarafından algılanabilen media feature'dır. Bu tercih vestibüler hassasiyet yaşayan veya motion distraction istemeyen kullanıcılar için önemlidir. Animasyonun yalnız duration'ını azaltmak bazen yeterli olur, bazı büyük parallax veya zoom hareketlerini tamamen kaldırmak gerekebilir. Fonksiyonellik motion olmadan çalışmaya devam etmelidir. Accessibility tasarımında bu destek opsiyon değil temel production kriteri olmalıdır.

İşletim Sistemi Kullanıcı Tercihi

Kullanıcı OS accessibility setting içinde motion reduction seçebilir. Browser bunu media query üzerinden sayfaya iletebilir. Application ayrıca kendi setting'ini sunabilir. User explicit preference hardware optimization'dan daha yüksek öncelik taşımalıdır. Preference runtime değişikliğinde UI güncellenebilir.

CSS Media Query

@media (prefers-reduced-motion: reduce) alternate style tanımlamak için kullanılabilir. Animation duration çok kısaltılabilir veya animation kaldırılabilir. Opacity transition küçük hareketlere alternatif olabilir. JavaScript matchMedia ile preference okuyabilir. Default content görünürlüğü korunmalıdır.

Animasyonu Azaltmak

Büyük movement distance küçültülebilir. Parallax kaldırılabilir. Spring overshoot azaltılabilir. Modal yalnız fade yapabilir. Information hierarchy motion olmadan anlaşılır kalmalıdır.

Animasyonu Tamamen Kapatmak Gereken Durumlar

Continuous zoom, large parallax veya vestibüler tetikleyici movement tamamen kaldırılabilir. Loading state static indicator ile gösterilebilir. Critical progress bilgisi text veya percentage ile korunur. Animation olmaması işlevi bozmaz. User preference'e saygı UX güveni oluşturur.

Reduced Motion Modunda Ne Yapılmalı?

Reduced Motion modu bütün geçişleri kör şekilde sıfırlamak yerine hareketin amacını koruyarak daha sakin alternatif sunmalıdır. Parallax ve büyük zoom gibi spatial hareketler kaldırılabilir. Uzun slide transition yerine kısa opacity değişimi kullanılabilir. State change kullanıcıya yine görünür olmalıdır. Focus, content visibility ve navigation davranışı motion olmadan eksiksiz çalışmalıdır.

Parallax'ı Kapatmak

Background ve foreground farklı hızda hareket etmeyebilir. Content normal document flow'da kalır. Scroll native behavior korunur. Visual depth başka tasarım araçlarıyla sağlanabilir. User setting runtime uygulanmalıdır.

Büyük Zoom/Scale Efektlerini Kaldırmak

Full-screen scale movement vestibüler rahatsızlık oluşturabilir. Direct state change veya subtle fade kullanılabilir. Button küçük press scale gibi microinteraction bazı kullanıcılar için kabul edilebilir olabilir. Preference reduce olduğunda distance ve duration küçültülür. Default güvenli alternatif tasarlanmalıdır.

Uzun Slide Animasyonlarını Azaltmak

Drawer 500 pixel yol almak yerine daha kısa movement veya anında açılabilir. Content erişimi gecikmez. Overlay opacity korunabilir. Focus hemen doğru yere taşınır. Escape close instant olabilir.

Basit Opacity Geçişi Kullanmak

Opacity spatial movement içermez. Kısa fade state change'i yine anlaşılır kılabilir. Çok uzun fade kullanıcıyı bekletmemelidir. Hidden state pointer ve accessibility behavior doğru yönetilir. Critical content doğrudan görünür olabilir.

Fonksiyonelliği Korumak

Animation disable edilince modal açılmıyor gibi bug olmamalıdır. State transition animationend event'e bağlı olmamalıdır. Business state doğrudan commit edilmelidir. Motion yalnız presentation katmanıdır. Automated reduced motion test eklenebilir.

Animasyon ve Erişilebilirlik

Animasyon erişilebilirlik açısından vestibüler hassasiyet, flashing, content visibility, keyboard focus ve screen reader davranışını etkileyebilir. Hareket bilgiye erişmenin tek yolu olmamalıdır. Modal veya accordion transition sırasında focus yanlış elementte kalmamalıdır. Screen reader kullanıcının yeni content'i animation süresi kadar beklemesi gerekmemelidir. Çok dilli kurumsal arayüzlerde erişilebilir animation ile locale ve layout değişimlerini birlikte düşünmek de önemlidir; i18n tasarımına ilişkin ilgili içerik için https://www.diyarbakiryazilim.com.tr/posts/kurumsal-web-uygulamalarinda-dil-zenginlestirme-i18n adresi kullanılabilir.

Vestibüler Hassasiyet

Large zoom, parallax ve viewport-spanning movement bazı kullanıcılar için rahatsız edici olabilir. Reduced motion preference dikkate alınmalıdır. Movement distance sınırlanabilir. Content stability korunur. User motion kapatınca hiçbir function kaybolmamalıdır.

Flash/Flicker

Hızlı flashing görsel rahatsızlık ve erişilebilirlik riski oluşturabilir. Critical alert sürekli blink etmemelidir. Renk ve icon gibi static signal kullanılabilir. Flicker frequency dikkatle sınırlandırılmalıdır. Automated test tek başına yeterli olmayabilir.

Content Visibility

Content yalnız animation sonunda DOM'a eklenirse screen reader gecikebilir. DOM state ve visual state ayrı tasarlanmalıdır. Hidden attribute doğru zamanda uygulanmalıdır. Opacity zero içerik erişilebilir tree'de kalabilir. Accessibility semantics explicit yönetilmelidir.

Keyboard Focus

Focus animation hareketinden bağımsız doğru interactive target'a taşınmalıdır. Drawer açılırken focus first element'e geçebilir. Closing sırasında trigger'a döner. Transition sürerken focus offscreen elementte kalmamalıdır. Escape anında çalışmalıdır.

Screen Reader

Visual movement screen reader'a otomatik anlam taşımaz. State change aria-expanded veya dialog semantics ile açıklanmalıdır. Loading progress live region ile gerektiğinde duyurulabilir. Decorative animation ignored kalabilir. Motion bilgiyi tek channel olarak taşımamalıdır.

Motion'ın Bilgiye Erişmek İçin Zorunlu Olmaması

User animation görmese de state relation anlaşılmalıdır. Color, text ve structure destekleyici sinyal sunar. Scroll reveal content'i JavaScript olmadan hidden bırakmamalıdır. Reduced motion mode aynı information'a erişim sağlar. Progressive enhancement temel yaklaşım olmalıdır.

Animasyon Sırasında Focus Yönetimi

Focus yönetimi modal, drawer ve accordion gibi animasyonlu bileşenlerde görsel transition'dan ayrı lifecycle olarak ele alınmalıdır. Element görünür olmaya başladığında keyboard kullanıcı doğru hedefe ulaşabilmelidir. Exit sırasında focused element DOM'dan kaldırılmadan önce focus güvenli hedefe taşınmalıdır. Animation end event tek güven kaynağı olmamalıdır. Reduced motion durumunda duration sıfıra yakın olduğunda da aynı focus logic doğru çalışmalıdır.

Modal

Modal açıldığında focus heading veya ilk meaningful control'e geçebilir. Background interaction engellenir. Focus trap motion bitişini beklememelidir. Close sonrası trigger'a dönülür. Escape anında çalışır.

Drawer

Navigation drawer açılırken focus içeriğe geçebilir. Off-canvas transform movement focus semantics'i değiştirmez. Closing sırasında focused child hidden olmadan trigger'a dönülür. Overlay click ve Escape aynı close action'ını çağırır. Animation interruptible olur.

Accordion

Accordion trigger focus'u korur. Content açıldığında automatic focus çoğu durumda gerekmez. aria-expanded state hemen değişir. Height animation semantic state'i geciktirmez. Reduced motion no-animation behavior aynı olur.

Element Görsel Olarak Çıkarken DOM'da Kalması

Exit animation için element kısa süre DOM'da tutulabilir. Ancak user interaction disabled yapılmalıdır. aria-hidden veya inert behavior context'e göre uygulanır. Focus o elementte kalmamalıdır. Cleanup timer state machine tarafından güvenli yönetilir.

Focus'un Kaybolmaması

Focused node DOM'dan kaldırılırsa browser focus body'ye düşebilir. Bu keyboard user için yön kaybıdır. Remove öncesi next logical target belirlenir. Rapid open-close scenario test edilir. Animation cancellation focus state'i bozmamalıdır.

Animasyon Süresi Nasıl Seçilmeli?

Animation duration hareketin mesafesi, context'i ve user task önceliğine göre seçilmelidir. Microinteraction kısa olmalı ve kullanıcı input'unu bekletmemelidir. Modal veya page transition biraz daha uzun olabilir, ancak fonksiyonel state change bu süreye kilitlenmemelidir. Uzak mesafe hareketi biraz daha uzun hissedilebilir. En iyi süre sabit bir kuraldan çok user testing ve interaction rhythm ile belirlenir.

Microinteraction

Button press, hover veya icon rotate kısa olmalıdır. 100 ile 200 milisaniye aralığı birçok küçük feedback için iyi başlangıç olabilir. Kullanıcı hızlı action yapabilmelidir. Animation reverse kolay olmalıdır. Reduced motion daha da kısaltabilir.

Modal

Modal enter movement 200 ile 300 milisaniye civarında doğal hissedebilir. Ancak exact value brand motion'a göre değişir. Content interaction animation bitişini beklememelidir. Backdrop fade kısa tutulur. Exit daha hızlı olabilir.

Page Transition

Page transition navigation'ı geciktirmemelidir. Snapshot animation 200 ile 400 milisaniye arasında değerlendirilebilir. Data loading ayrı progress state'tir. Long transition slow site hissi yaratır. User repeat navigation'da sıkılmamalıdır.

Distance-Aware Duration

50 pixel movement ile full-screen movement aynı duration kullanmak doğal görünmeyebilir. Distance arttıkça duration sınırlı artırılabilir. Çok uzun hareket yine kullanıcıyı bekletir. Spring model distance ve velocity'yi doğal yansıtabilir. Maximum duration token belirlenebilir.

Kullanıcıyı Bekleten Animasyonlardan Kaçınmak

Animation functional action'ın gate'i olmamalıdır. Menu item click navigation'ı transitionend sonrası başlatmamalıdır. Form submit visual effect bitişini beklememelidir. User input state hemen işlenmelidir. Motion presentation olarak kalmalıdır.

Easing Performansı Etkiler mi?

Easing çoğu durumda aynı property animation'ın rendering maliyetini kökten değiştirmez, ancak movement hız dağılımı perceived performance ve belirli frame'lerde visual change miktarını etkiler. Linear progress indicator için doğal olabilir. Ease veya cubic-bezier UI giriş çıkışlarını daha fiziksel hissettirebilir. Spring implementation JavaScript simulation kullanıyorsa computation maliyeti farklı olabilir. Easing seçimi performans kadar kullanıcı algısı üzerinden de değerlendirilmelidir.

Linear

Linear progress her zaman diliminde eşit değişim üretir. Progress bar ve scroll timeline için uygundur. UI panel movement'ında mechanical hissedebilir. Rendering property aynıysa cost benzer kalır. User perception context'e bağlıdır.

Ease

Ease başlangıç ve bitiş hızını yumuşatır. Modal ve menu movement için daha doğal olabilir. Browser interpolation native yapılır. Performance farkı genellikle property choice'tan küçüktür. Duration ile birlikte tasarlanmalıdır.

Cubic-Bezier

Cubic-bezier custom speed curve tanımlar. Overshoot olmadan hızlı başlangıç ve sakin bitiş yapılabilir. Extreme curve user'a gecikme hissi verebilir. Design token olarak standardize edilebilir. MDN easing functions kapsamında cubic-bezier ve linear fonksiyonlarını resmi olarak tanımlar. :contentReference[oaicite:31]{index=31}

Spring

Spring velocity ve damping hissi verir. Library internal solver kullanabilir. High-frequency physics calculation CPU cost oluşturabilir. Analytical spring curve daha hafif olabilir. Reduced motion mode'da overshoot azaltılmalıdır.

Algılanan Performans

Hızlı başlayan ease-out UI'ın input'a hemen tepki verdiği hissini artırabilir. Uzun ease-in başlangıcı gecikme hissi yaratabilir. Ancak actual input processing hala ölçülmelidir. Easing kötü INP'yi gizleyemez. Immediate feedback gerçek performansla birlikte gelmelidir.

Fiziksel Hareket Hissi

Objects inertia ve distance ile uyumlu hareket ederse kullanıcı transition'ı daha doğal algılar. Her component farklı easing kullanırsa ürün tutarsız hissedilir. Motion token ortaklaştırılmalıdır. Excessive bounce ciddi workflow'da dikkat dağıtabilir. User preference ile motion azaltılmalıdır.

Animation Duration ile Perceived Performance

Perceived performance kullanıcı sistemin ne kadar hızlı cevap verdiğini hissettiği deneyimdir. Teknik işlem 50 milisaniyede tamamlanıp transition 800 milisaniye sürerse kullanıcı uygulamayı yavaş algılar. Kısa immediate feedback bu hissi iyileştirir. Movement distance ve context duration seçimini etkiler. Interruptible animation kullanıcıyı zorunlu beklemekten kurtarır.

Hızlı Tepki

Pressed state ilk frame'de görünmelidir. Server task daha uzun sürse bile action kabul edildiği anlaşılır. Animation küçük ve net olur. Main thread long task bulunmamalıdır. INP gerçek responsiveness'i doğrular.

Aşırı Yavaş UI

Her menu ve modal 500 milisaniye sürerse yoğun kullanıcı workflow'u yavaş hisseder. Tek tek hoş görünen transition toplamda zaman kaybettirir. Kurumsal back-office uygulamada hareket daha kısa tutulabilir. Frequent action frequency duration seçiminde önemli faktördür. Power user test edilmelidir.

Hareket Mesafesi

Small icon rotation çok kısa olabilir. Full-screen panel biraz daha uzun hareket edebilir. Distance-aware duration natural pace sağlar. Maximum cap kullanıcıyı beklemekten korur. Mobile viewport distance desktop'tan farklı olabilir.

Context

Marketing hero animation ile finance form confirmation aynı motion dilini kullanmak zorunda değildir. Critical workflow speed önceliklidir. Onboarding motion daha açıklayıcı olabilir. Context user frequency ve risk üzerinden değerlendirilir. Design system farklı motion token setleri sunabilir.

Interruptibility

Uzun transition kesilebiliyorsa user kontrolü korunur. Menu açılırken close yapılabilir. Page navigation yeni route'a yönlenebilir. Animation queue oluşmaz. Perceived performance önemli ölçüde iyileşir.

Content-Visibility ve Containment

content-visibility ve CSS containment büyük sayfalarda browser'ın görünmeyen veya izole edilmiş içerik için rendering işini azaltmasına yardımcı olabilir. Animasyonlu component başka büyük DOM subtree'sini gereksiz etkilememelidir. Containment layout ve paint scope'unu sınırlayabilir. Ancak intrinsic size, sticky behavior ve measurement gibi alanlarda yan etkiler test edilmelidir. Bu özellikler animasyon motoru değil genel rendering maliyetini azaltan destekleyici araçlardır.

content-visibility

Offscreen section rendering işini ertelemek için kullanılabilir. Uzun landing page veya documentation sayfasında faydalıdır. Browser viewport yakınlaştığında content'i render eder. Intrinsic size placeholder layout shift'i azaltabilir. Animation initialization visibility state ile uyumlu olmalıdır.

contain

Contain property layout, paint veya size etkisini belirli boundary içinde tutabilir. Widget başka page alanını daha az etkiler. Yanlış kullanılırsa percentage sizing veya position behavior değişebilir. Component-level test gereklidir. Performance trace impact'i doğrular.

Büyük Sayfalarda Rendering İşini Azaltmak

Below-the-fold yüzlerce component initial render'a dahil olmayabilir. Browser daha az style ve paint işi yapar. Interaction-ready time iyileşebilir. Lazy asset loading ile birlikte kullanılabilir. SEO veya find-in-page davranışı target browserlarda test edilmelidir.

Animasyonlu Bölümü İzole Etmek

Animation container containment ile daha küçük rendering scope'a sahip olabilir. Width veya layout change global page'i daha az etkiler. Transform yine tercih edilir. Isolation side effect oluşturuyorsa kullanılmamalıdır. DevTools layout invalidation sonucu incelenmelidir.

Animasyonları Lazy Başlatmak

Her animation page load sırasında initialize edilmemelidir. Viewport'a yaklaşan component için asset ve animation setup daha sonra yapılabilir. IntersectionObserver bu trigger'ı verebilir. Initialization maliyeti ilk interaction anına bırakılmamalı, gerekiyorsa biraz erken hazırlanmalıdır. Lazy strategy network, CPU ve memory kullanımını azaltır.

Viewport'a Yaklaşana Kadar Başlatmamak

Below-the-fold Lottie veya canvas hemen çalışmamalıdır. Observer root margin ile yaklaşım algılanabilir. Animation asset bu noktada load edilir. User hiç scroll etmezse maliyet oluşmaz. Content static fallback ile görünür kalır.

IntersectionObserver

Observer coarse visibility trigger sağlar. Birden fazla animation shared observer kullanabilir. Callback kısa tutulur. Once-only component observe'dan çıkarılır. Unsupported environment simple immediate state kullanabilir.

Asset Preload

Animation görünmeden biraz önce gerekli image veya video preload edilebilir. Priority main content'i engellememelidir. Network save-data gibi user preference düşünülebilir. Asset decode ayrıca planlanır. Memory window sınırlı tutulur.

Animation Initialization Cost

Library import, JSON parse ve scene setup ilk frame'i bloke edebilir. Initialization observer trigger sonrası hemen visual frame ile aynı task'te yapılmamalıdır. Chunked setup uygulanabilir. Route lazy loading bundle maliyetini azaltır. Long task trace ile ölçülür.

Performanslı Hover ve Microinteraction Teknikleri

Hover ve microinteraction çok sık tekrarlandığı için küçük performans hataları kullanıcı deneyiminde sürekli hissedilebilir. Transform ve opacity kısa CSS transition ile çoğu ihtiyacı karşılar. Pointer fine ve coarse farkı dikkate alınmalıdır, çünkü mobil cihazda hover assumption doğru değildir. Animasyon hızlı kullanıcı input'unu takip etmelidir. Büyük shadow, blur veya framework state update her hover için tetiklenmemelidir.

transform

Card hafif translateY veya scale ile response verebilir. Movement 2 ile 4 pixel gibi küçük tutulabilir. Layout değişmez. Sibling shift olmaz. Hover spam transition target'ı doğal takip eder.

opacity

Icon veya secondary action opacity ile görünür olabilir. Display none yerine opacity transition kullanılırken pointer state yönetilmelidir. Focus kullanıcı action'a hover olmadan ulaşabilmelidir. Reduced motion opacity kalabilir. Large overlay opacity memory maliyeti test edilir.

CSS Transition

Hover state iki value arasında olduğu için CSS transition doğal seçenektir. JavaScript mouseenter loop gerekmez. Duration kısa tutulur. Transition-property explicit yazılmalıdır. transition: all gereksiz property animation riskini artırır.

Pointer Fine/Coarse

CSS pointer media feature mouse benzeri fine input ile touch coarse input'u ayırabilir. Hover effect coarse cihazda gereksiz olabilir. Tap interaction primary feedback olur. Layout hover'a bağlı olmamalıdır. Accessibility keyboard focus state ayrıca tasarlanmalıdır.

Mobilde Hover Varsaymamak

Touch device hover state'i persistent veya hiç olmayabilir. Critical action hover altında saklanmamalıdır. Button görünür olmalıdır. Press feedback :active ile verilebilir. Mobile test gerçek touch cihazda yapılmalıdır.

Button Press Animasyonları

Button press animation kullanıcıya action'ın alındığını hissettiren en kısa microinteraction'lardan biridir. Küçük scale ve opacity değişimi 100 ile 200 milisaniye içinde yeterli feedback sağlayabilir. Click handler animation bitişini beklememelidir. Async operation başlarsa loading veya disabled state hemen uygulanmalıdır. Keyboard active ve focus state aynı görsel dil içinde erişilebilir olmalıdır.

scale

Pressed state 0.97 veya 0.98 scale kullanabilir. Büyük küçülme dikkat dağıtabilir. Transform layout değiştirmez. Release state hızlı geri döner. Reduced motion scale kaldırılabilir.

opacity

Opacity veya background tint pressed state'i destekleyebilir. Contrast bozulmamalıdır. Disabled state ile karışmamalıdır. Transition kısa tutulur. Color tek signal olmamalıdır.

100–200 ms Feedback

Microinteraction kısa olmalıdır. 100 ile 200 milisaniye iyi başlangıç aralığıdır. Exact duration design system'e göre test edilir. Fast user rapid click yapabilmelidir. Action availability animation'dan bağımsızdır.

Click Handler'ı Bekletmemek

Press animation yalnız presentation'dır. Handler hemen business action'ı başlatır. Navigation transitionend'e bağlanmaz. User response daha hızlı hissedilir. INP iyileşebilir.

Disabled State

Async action duplicate olmamalıysa button disabled olabilir. Disabled transition kısa ve açık olmalıdır. Focus behavior context'e göre korunabilir. Loading text kullanıcıya açıklama verir. Disabled state sadece opacity düşürmekle bırakılmamalıdır.

Menü ve Drawer Animasyonları

Menu ve drawer büyük yüzey hareket ettirdiği için property seçimi ve focus yönetimi birlikte önemlidir. Off-canvas movement transform translate ile yapılabilir. Width animation yerine final width başlangıçtan belirlenir. Overlay opacity ile fade olabilir. Escape veya close action animation bitişini beklemeden anında state değiştirmelidir.

transform ile Off-Canvas

Drawer final width ile layout'ta bulunur. Closed state translateX ile viewport dışında tutulur. Open state translateX(0) olur. Layout her frame değişmez. Large layer mobile test edilir.

width Animasyonu Yapmamak

Width her frame değişirse child layout ve sibling effect oluşabilir. Drawer çoğu durumda sabit width ile hareket edebilir. Responsive width breakpoint'te belirlenir. Content reflow transition dışında yapılır. Performance daha öngörülebilir olur.

Overlay Opacity

Backdrop opacity 0 ile final value arasında değişebilir. Backdrop blur gerekmedikçe eklenmemelidir. Pointer event open state ile yönetilir. Fade duration drawer movement'tan kısa olabilir. Reduced motion direct state kullanabilir.

Focus Management

Open olduğunda focus drawer içine geçer. Background inert olabilir. Close öncesi focus trigger'a döner. Transition focus'u geciktirmez. Screen reader semantics dialog veya navigation context'e uygun olur.

Escape ile Anında Kapatma

Escape user cancel intent'idir. Current open animation reverse veya cancel edilir. State closing'e geçer. Focus güvenli hedefe taşınır. Queued transition beklenmez.

Accordion Animasyonları

Accordion gerçek content height değişikliği nedeniyle performans ve implementation açısından özel bir bileşendir. height: auto klasik transition içinde doğrudan interpolate edilmesi zor bir değerdir. Max-height hack timing ve büyük boşluk sorunları yaratabilir. Grid technique, WAAPI ölçümlü height veya View Transition alternatif olabilir. Reduced motion modunda content doğrudan açılmalıdır.

height: auto Problemi

Auto final pixel değeri content'e bağlıdır. Traditional transition numeric endpoints ister. Browser modern özelliklerle bazı çözümler geliştirse de compatibility dikkat ister. JavaScript ölçüm yapılabilir. Repeated measurement thrashing oluşturmamalıdır.

max-height Yaklaşımının Sınırlamaları

Max-height büyük sabit value'dan geçiş yapabilir. Actual content küçükse visual timing duration'ın yalnız bir bölümünde gerçekleşir. Easing beklenmedik hissedilebilir. Çok büyük max value layout işini yine oluşturur. Daha modern yöntemler tercih edilebilir.

Grid Teknikleri

Grid row fraction 0fr ile 1fr arasında transition bazı browserlarda accordion effect sağlayabilir. Content overflow hidden kullanır. Layout yine değişir. Small componentte maliyet yönetilebilir. Compatibility ve accessibility test edilmelidir.

WAAPI

Content scrollHeight veya rect ölçülüp numeric height keyframe oluşturulabilir. Animation object cancel edilebilir. End state height auto yapılabilir. Read ve write phase ayrılır. Rapid toggle state test edilir.

View Transition

DOM state change snapshot üzerinden animate edilebilir. Manual height interpolation gerekmez. Browser support progressive enhancement ile ele alınır. Focus accordion trigger'da kalır. Reduced motion fallback normal state change olur.

Reduced Motion

Accordion content anında açılabilir. Opacity küçük transition olabilir. Height animation kaldırılır. aria-expanded hemen güncellenir. User bilgiye gecikmeden ulaşır.

Modal Animasyonlarında Performans

Modal animation genellikle overlay ve dialog yüzeyinin kısa opacity ile transform geçişinden oluşmalıdır. Backdrop blur görsel olarak hoş olabilir, fakat büyük pixel alanında pahalıdır. Focus trap ve accessibility state animation'dan bağımsız hemen kurulmalıdır. User Escape ile modalı anında kapatabilmelidir. Interaction'ı animation end event'e bağlamak hızlı kullanıcıda gecikme yaratır.

Overlay

Overlay semi-transparent background olabilir. Opacity transition düşük maliyetli başlangıçtır. Full-screen blur gerekiyorsa mobile test edilir. Pointer block open state ile anında uygulanır. Exit state'te click-through engellenmelidir.

transform + opacity

Dialog küçük translateY ve opacity ile giriş yapabilir. Scale movement çok büyük olmamalıdır. Transform layout değişmez. Duration kısa tutulur. Reduced motion yalnız opacity veya no motion kullanabilir.

Backdrop Blur Maliyeti

Backdrop blur tüm arka sahneyi işleyebilir. Scroll veya video arka planda hareket ediyorsa maliyet büyür. Low-end cihazda kaldırılabilir. Solid translucent color çoğu durumda yeterlidir. GPU profile karar verir.

Focus Trap

Focus modal açılır açılmaz doğru alana taşınır. Trap animation bitişini beklemez. Background focus disabled olur. Closing state trigger'a focus döndürür. Rapid close bug test edilir.

Interaction'ı Animation End'e Bağlamamak

Submit veya close action transitionend beklememelidir. Browser reduced motion veya interrupted transition event behavior değişebilir. State machine function state'i hemen günceller. Visual exit paralel yürür. Cleanup safe timeout veya animation finished state ile yapılabilir.

Page Transition Animasyonları

Page transition kullanıcıya navigation context'i gösterebilir ancak asıl navigation'ı geciktirmemelidir. View Transition API aynı document ve belirli cross-document senaryolarda browser-native snapshot geçişi sunar. Shared element görsel continuity sağlayabilir. Route data load ile visual animation timing ayrı yönetilmelidir. Content hazırsa yalnız animationı tamamlamak için kullanıcı bekletilmemelidir.

Navigation'ı Geciktirmemek

Link click route change'i başlatır. Exit animation server request'ten önce zorunlu bekleme olmamalıdır. New content hazır olunca transition devam eder. Prefetch page latency'yi azaltabilir. Animation yalnız visual bağlam sağlar.

View Transition API

API old ve new view snapshot'larını yönetir. Same-document startViewTransition() ile çalışabilir. Cross-document aynı origin opt-in desteklenebilir. Progressive enhancement gereklidir. MDN modern kullanım akışını ayrıntılı biçimde belgeliyor. :contentReference[oaicite:32]{index=32}

Shared Element

Card image detail sayfaya taşınıyor hissi verilebilir. Unique transition name kullanılır. Çok fazla shared element göz yorgunluğu yaratabilir. Reduced motion state simple cross-fade kullanır. Navigation semantics normal kalır.

Route Change

Router state değişikliği animation lifecycle ile koordineli olabilir. Old route cleanup new content hazır olmadan focus'u kaybetmemelidir. Error route fallback bulunmalıdır. Back navigation farklı animation type kullanabilir. View transition types bu amaçla modern API'de desteklenir. :contentReference[oaicite:33]{index=33}

Loading Data ile Animation Timing

Transition data fetching'i gizlemek için gereksiz uzatılmamalıdır. Skeleton veya progress gerçek loading state'i gösterir. Content ready olduğunda hemen kullanıma açılır. Prefetch delay'i azaltabilir. Animation ve network timeline ayrı metriclerle ölçülür.

Animation End Event'e Aşırı Bağımlılığın Riski

transitionend ve animationend eventleri presentation lifecycle için faydalıdır, fakat business state'in tek kaynağı olmamalıdır. Reduced motion ile duration sıfıra düştüğünde event behavior değişebilir. Element animation bitmeden DOM'dan çıkarılabilir veya user yeni state'e geçebilir. Bu durumda beklenen cleanup çalışmayabilir. State machine ve explicit lifecycle daha güvenli kontrol sağlar.

transitionend

Transition property tamamlandığında event gelir. Birden fazla property farklı event üretebilir. Cancel veya display change event'i engelleyebilir. Business action event'e bağlanmamalıdır. Cleanup idempotent olmalıdır.

animationend

CSS keyframe tamamlandığında event gelir. Infinite animation hiç end event üretmez. Element remove edilirse behavior farklılaşabilir. Reduced motion animation-name none olabilir. State explicit yönetilmelidir.

Reduced Motion Durumu

Duration sıfıra düşürülürse expected event farklı olabilir. Application modal cleanup için yalnız animationend beklerse bug oluşabilir. Motion setting test suite'e eklenmelidir. Function state animation'dan önce commit edilir. Visual cleanup optional olur.

Element'in DOM'dan Erken Çıkması

Framework condition false olduğunda element hemen unmount olabilir. Exit animation görünmez. Animation library presence abstraction kullanabilir. Manual çözüm exiting state'te DOM'u kısa süre tutar. Focus ve accessibility bu sürede doğru yönetilir.

State Machine Yaklaşımı

Idle, entering, entered, exiting ve exited gibi state'ler lifecycle'ı açık hale getirir. User interrupt reverse veya cancel transition oluşturur. Business state ve animation state karıştırılmaz. Cleanup transition event'e bağımlı kalmaz. Test senaryoları daha öngörülebilir olur.

Performanslı Animasyon State Machine

Animation state machine görsel lifecycle'ı explicit durumlarla yöneterek rapid input ve cancellation hatalarını azaltır. Idle, entering, entered, exiting ve exited durumları transition direction'ı açıklar. Interrupt veya reverse yeni kullanıcı intent'ini mevcut movement'a uygular. Timer ve event cleanup her state transition'da kontrollü yapılır. Bu model özellikle modal, drawer ve route transition gibi complex interactionlarda faydalıdır.

Idle

Component henüz animation çalıştırmıyor olabilir. Resource reserve edilmez. will-change aktif değildir. User event target state belirler. Animation object yoktur.

Entering

Element görünür state'e doğru hareket eder. Focus gerektiğinde hemen taşınır. will-change kısa süre active olabilir. New close input reverse yapabilir. Completion entered state'e geçer.

Entered

Visual state stable'dır. Animation resource temizlenir. will-change kaldırılır. User interaction normal çalışır. Exit input yeni transition başlatır.

Exiting

Element visual olarak çıkarken business availability context'e göre disabled olabilir. Focus safe target'a taşınır. New open input reverse veya retarget yapabilir. DOM cleanup completion sonrası yapılır. Reduced motion immediate exited state olabilir.

Exited

Element DOM'dan kaldırılabilir veya hidden state'e geçebilir. Animation object cancel edilir. Event listener temizlenir. Resource release edilir. New open state yeniden entering başlatır.

Interrupt / Reverse

Current state yeni user intent'e göre yön değiştirir. Entering sırasında close exiting'e geçer. Existing WAAPI animation reverse edilebilir. Queue oluşturulmaz. Latest state wins uygulanır.

Düşük Güçlü Cihazlarda Animasyon

Düşük güçlü cihazlarda animation yalnız daha düşük FPS değil daha yüksek input latency, battery tüketimi ve thermal throttling oluşturabilir. CPU throttling desktop simulation ilk ipucu verir, ancak gerçek Android cihaz testi daha güvenilirdir. RAM ve GPU sınırlaması büyük layer ve asset sequence'leri etkiler. Animation effect'in reduced version'ı product tasarımında önceden düşünülmelidir. Kullanıcı experience'i güçlü laptop'a göre optimize etmek geniş kullanıcı kitlesini dışarıda bırakabilir.

CPU Throttling

DevTools CPU slowdown ağır script ve layout sorunlarını görünür hale getirir. 4x veya 6x slowdown baseline oluşturabilir. Exact low-end device simulation değildir. Bottleneck source bulmak için kullanışlıdır. Final karar real device ile doğrulanır.

Düşük GPU

Large blur, shadow ve WebGL effect düşük GPU'da zorlanabilir. Layer count memory baskısı oluşturur. Compositor frame düşebilir. Effect fallback uygulanabilir. GPU-heavy workload battery'yi etkiler.

Az RAM

Image sequence veya çok layer memory pressure yaratabilir. Browser texture discard yapabilir. GC veya tab reload riski oluşabilir. Asset cache window küçültülmelidir. DOM node sayısı sınırlanmalıdır.

Thermal Throttling

Telefon uzun süre yüksek CPU/GPU kullanırsa sıcaklık nedeniyle frekans düşebilir. İlk 20 saniye test sonucu yeterli değildir. Uzun session animasyon performansı incelenmelidir. Infinite decorative effect thermal load yaratabilir. Battery-aware design önemlidir.

Gerçek Android Cihaz Testi

Entry-level ve mid-range Android cihaz önemli test segmentidir. Touch latency ve scroll doğrudan hissedilir. Remote DevTools trace alınabilir. 60 Hz ve 120 Hz farklı cihaz karşılaştırılabilir. Production RUM device class trendi doğrular.

Device-Adaptive Animation Mantıklı mı?

Device-adaptive animation bazı ağır efektleri düşük kaynaklı cihazlarda azaltmak için kullanılabilir, ancak device capability tahmini kusursuz değildir. Büyük blur veya particle count azaltılabilir. Feature detection support kontrolü için güvenlidir. User prefers-reduced-motion tercihi hardware tahmininden daha yüksek öncelik taşımalıdır. Basit ve hızlı default animation çoğu zaman agresif cihaz sınıflandırmasından daha güvenli stratejidir.

Düşük Güçlü Cihazlarda Efekt Azaltmak

Decorative background kapatılabilir. Transition distance kısaltılabilir. Layer count azaltılabilir. Product functionality değişmemelidir. RUM hangi segmentin gerçekten problem yaşadığını göstermelidir.

Büyük Blur'ları Kapatmak

Backdrop blur yerine translucent solid background kullanılabilir. Visual hierarchy korunur. GPU yükü azalır. Design token device mode seçebilir. Accessibility contrast korunmalıdır.

Particle Count Azaltmak

Canvas veya WebGL scene particle sayısını düşürebilir. Frame time hedefi üzerinden adaptive quality yapılabilir. Sudden quality shift kullanıcıya görünmemelidir. Battery consumption azalır. Reduced motion'da tamamen kapanabilir.

Feature Detection

API support runtime feature detection ile kontrol edilir. View Transition veya Scroll Timeline yoksa fallback çalışır. User agent string üzerinden capability tahmini yapılmamalıdır. CSS @supports kullanılabilir. Browser upgrade doğal olarak yeni capability açar.

Kullanıcı Tercihini Donanım Tahmininden Üstün Tutmak

User reduced motion seçmişse güçlü cihazda bile motion azaltılmalıdır. User preference accessibility sinyalidir. Hardware model yalnız performance adaptation içindir. Bu iki kavram karıştırılmamalıdır. App setting user'a daha fazla kontrol verebilir.

Animasyon Performansı Nasıl Ölçülür?

Animasyon performansı FPS, dropped frames, frame time, long task, INP, CPU ve GPU göstergelerinin birlikte incelenmesiyle ölçülmelidir. Tek metric bütün resmi açıklamaz. Lab test deterministic regression bulur, RUM gerçek user dağılımını gösterir. Interaction sırasında trace almak idle animation benchmark'ından daha değerlidir. En iyi test senaryosu scroll, typing ve click gibi gerçek kullanıcı hareketlerini animation açıkken birlikte çalıştırır.

FPS

FPS genel smoothness sinyalidir. Average değer tek başına yeterli değildir. Frame pacing incelenmelidir. High refresh device farklı target'a sahiptir. RUM FPS collection maliyetli olabileceği için sample kullanılabilir.

Dropped Frames

Frame deadline kaçırıldığında movement sıçrayabilir. Dropped frame oranı interaction segmentinde ölçülebilir. Büyük spike hangi task ile eşleşiyor incelenir. Scroll ve drag özel önem taşır. Low-end device segmentlenir.

Frame Time

Her frame duration timeline üzerinde görülebilir. 60 Hz'de 16,7 ms üstü frame risklidir. 120 Hz daha dar interval getirir. Script, layout ve paint breakdown incelenir. Outlier percentile önemlidir.

Long Tasks

Uzun JavaScript task user input'u geciktirebilir. Performance trace task duration gösterir. Source script bulunur. Work chunk edilir. RUM long task rate production etkisini gösterir.

INP

INP interaction responsiveness'i saha kullanıcıları üzerinden değerlendirmek için kritik metriktir. Animation workload input delay'e katkı sağlayabilir. web.dev slow interaction analysis LoAF attribution ile script kaynağını ilişkilendirmeyi gösteriyor. Device ve browser segmenti incelenmelidir. FPS iyi olsa bile INP kötü olabilir. :contentReference[oaicite:34]{index=34}

CPU

CPU usage JavaScript, layout ve paint yükünü yansıtır. Performance monitor kullanılabilir. Throttling bottleneck'i büyütür. Infinite animation idle CPU'yu artırmamalıdır. Thermal test long session'da yapılır.

GPU

GPU usage compositor ve WebGL workload ile artabilir. Browser tool desteği platforma göre farklıdır. Layer count proxy sinyal olabilir. Large blur ve texture memory kontrol edilir. Battery impact gerçek cihazda gözlemlenir.

Chrome DevTools Performance Panel

Chrome DevTools Performance panel animation sırasında JavaScript, style, layout, paint ve composite işlerinin zaman çizgisini görmeye yardımcı olur. Gerçek interaction kaydı almak yalnız page load trace'den daha değerlidir. Record sırasında scroll, drag veya rapid click senaryosu uygulanabilir. Frame strip ve main thread flame chart bottleneck'i gösterir. CPU throttling ile düşük güçlü cihaz davranışı daha görünür hale getirilebilir.

Record

Performance panel record başlatılır. Test senaryosu kısa ve tekrarlanabilir olmalıdır. Click veya scroll belirli sırayla yapılır. Gereksiz background activity azaltılır. Trace kaydedilip karşılaştırma için saklanabilir.

Frames

Frames track dropped veya uzun frame'leri gösterir. Spike seçilerek detay incelenebilir. Animation jank hangi anda oluştuğu anlaşılır. Screenshot filmstrip visual state'i destekler. High refresh monitor farkı dikkate alınır.

Main Thread

Main Thread flame chart script, style ve layout task'larını gösterir. Long task geniş blok olarak görünür. Function call stack source'a indirilebilir. Framework render ayrı görülebilir. Input event zamanı ile karşılaştırılır.

Long Task

Long task user interaction'ı geciktirebilir. Animation callback veya unrelated analytics script kaynak olabilir. Task kırılabilir. Third-party script deferred olabilir. Improvement trace ile doğrulanır.

Layout

Layout event geometry calculation süresini gösterir. Her frame tekrar eden layout anti-pattern sinyalidir. Forced reflow source call stack bulunabilir. Width animation veya read-write pattern incelenir. Containment etkisi karşılaştırılabilir.

Paint

Paint event yeniden çizilen alanın maliyetini gösterir. Large area highlight edilebilir. Shadow veya blur trigger bulunabilir. Paint flashing live debug sağlar. Pseudo element opacity alternatifi test edilir.

Composite

Composite layer birleştirme aşamasını gösterir. Large number of layers maliyet oluşturabilir. Transform animation çoğu work'u burada tutabilir. Layer promotion etkisi ölçülür. will-change öncesi sonrası karşılaştırılır.

Paint Flashing ile Animasyon Debugging

Paint Flashing browser'ın yeniden boyadığı alanları ekranda highlight ederek animation sırasında beklenmeyen repaint'leri görmenizi sağlar. Transform ile hareket ettiğini düşündüğünüz element full-screen paint oluşturuyorsa sorun hızlıca fark edilir. Hover ve scroll sırasında sürekli yeşil flash geniş alanı kaplıyorsa property veya layer tasarımı yeniden incelenmelidir. Paint alanını küçültmek GPU ve CPU yükünü azaltabilir. Tool yalnız sinyal verir, exact duration için Performance trace ile birlikte kullanılmalıdır.

Hangi Alanlar Repaint Ediliyor?

Paint flashing active olduğunda changed pixel region görünür olur. Animation elementinin dışındaki area flash ediyorsa invalidation geniştir. CSS dependency incelenir. Containment veya layer isolation uygulanabilir. Result tekrar test edilir.

Beklenmeyen Full-Screen Paint

Backdrop effect veya fixed background full-screen repaint oluşturabilir. Küçük hover'un bütün viewport'u boyaması ciddi işarettir. Property kaldırılarak A/B trace yapılır. GPU layer design gözden geçirilir. Mobile etkisi daha büyük olabilir.

Hover/Scroll Sırasında Paint

Hover shadow tüm card listesinde repaint tetikleyebilir. Scroll fixed blur overlay'i sürekli paint ettirebilir. Visual effect scope azaltılır. Opacity layer alternatifi kullanılabilir. Paint flashing değişiklik sonrası kontrol edilir.

Paint Alanını Küçültmek

Effect yalnız gereken element bounds içinde tutulur. Overflow clip veya separate pseudo element kullanılabilir. Large background animation azaltılır. Content isolation uygulanabilir. Visual design sadeleştirmek çoğu zaman en iyi optimizasyondur.

Layers Panel ile GPU Layer Analizi

Layers analizi browser'ın hangi elementleri ayrı compositing layer olarak tuttuğunu anlamaya yardımcı olur. Layer count, size ve memory tahmini will-change kullanımının beklenmeyen sonuçlarını gösterebilir. Çok fazla promoted element performansı iyileştirmek yerine memory ve composite maliyetini artırabilir. Büyük full-screen layer dikkatle incelenmelidir. Optimization sonrası layer sayısı ve frame behavior birlikte karşılaştırılmalıdır.

Compositor Layers

Layer listesi elementlerin ayrı surface olup olmadığını gösterir. Transform animation promoted olabilir. Browser automatic decision verebilir. Manual promotion zorunlu değildir. Layer reason incelenebilir.

Layer Count

Yüzlerce layer layer explosion işareti olabilir. Her layer memory kullanır. Card grid içinde will-change sık sebep olabilir. Gereksiz hint kaldırılır. Browser default optimization'a dönülür.

Layer Size

Layer bounds büyük olduğunda texture memory artar. Full viewport 2x DPR ciddi alan kullanır. Transparent empty area da bounds'a dahil olabilir. Container küçültülür. Mobile memory etkisi düşünülür.

will-change Etkisi

will-change eklemeden önce ve sonra layer listesi karşılaştırılabilir. Fayda frame time ile doğrulanır. Sadece layer oluşması başarı değildir. Memory cost dikkate alınır. Animasyon sonrası property kaldırılır.

Gereksiz Promotion

Static element ayrı layer'a alınmış olabilir. CSS transform hack veya will-change sebep olabilir. Promotion kaldırılır. Paint behavior tekrar ölçülür. Hedef minimum gerekli layer setidir.

Performance Trace'de Layout Thrashing Nasıl Görülür?

Layout thrashing Performance trace üzerinde kısa aralıklarla tekrar eden Recalculate Style ve Layout eventleri olarak görülebilir. JavaScript call stack içinde geometry read ve style write kaynak satırlarına kadar inilebilir. Bir frame içinde aynı pattern birkaç kez tekrarlanıyorsa read-write batching ihtiyacı vardır. DevTools bazen forced reflow uyarısı da sağlar. Problem düzeltildikten sonra trace'de layout sayısı ve toplam duration azalmalıdır.

Recalculate Style

Style invalidation sonrası browser CSS sonuçlarını tekrar hesaplar. Çok sık event class mutation'a işaret edebilir. Animation her frame selector state değiştirmemelidir. Direct transform write daha sade olabilir. Trace source function bulunur.

Layout

Layout geometry hesaplar. Tek frame birkaç layout event içeriyorsa thrashing şüphesi artar. DOM read pattern incelenir. Affected nodes büyüklüğü önemlidir. Containment veya batching uygulanır.

Forced Reflow

JavaScript pending style sonrası geometry istediğinde forced reflow oluşabilir. Browser synchronous layout çalıştırır. Source line inspector ile bulunabilir. getBoundingClientRect veya offsetWidth call pattern incelenir. Read phase öne taşınır.

JavaScript Call Stack

Layout event hangi function tarafından tetiklenmiş görülebilir. Framework internals altında application function bulunabilir. Source map doğru olmalıdır. Hot path refactor edilir. Third-party library kaynaksa kullanım şekli değiştirilir.

Problemi Kaynak Satıra Kadar İzlemek

Performance optimization tahmine dayanmamalıdır. Trace source location'a kadar götürülür. Problemli read ve write satırları belirlenir. Kod değiştirilir ve aynı interaction tekrar kaydedilir. Before-after metric karşılaştırılır.

CPU Throttling ile Test

CPU throttling güçlü developer bilgisayarında gizlenen animation sorunlarını daha görünür hale getirir. 4x veya 6x slowdown heavy script, layout ve framework render sürelerini büyütür. Bu gerçek low-end cihazın birebir simülasyonu değildir, fakat bottleneck discovery için değerlidir. Interaction testleri animation açıkken yapılmalıdır. Son doğrulama gerçek telefon üzerinde gerçekleştirilmelidir.

High-End Laptop Yanılsaması

Modern laptop tek frame'de çok fazla işi tamamlayabilir. Production kullanıcı aynı CPU gücüne sahip olmayabilir. Developer animation smooth gördüğü için problem yok sanabilir. Throttling maliyeti görünür kılar. RUM device distribution gerçek resmi tamamlar.

4x/6x CPU Slowdown

DevTools CPU slowdown script ve layout duration'ı yapay olarak artırır. Regression test threshold belirlenebilir. 6x altında interaction hala usable ise güçlü sinyal olabilir. Exact device class değildir. Comparative test için kullanışlıdır.

Low-End Mobile Simülasyonu

CPU throttling düşük cihaz davranışının bir kısmını simüle eder. GPU, memory ve thermal özellikleri aynı değildir. Device emulation network ve viewport ekler. Real device hala gerekir. Android remote debugging kullanılabilir.

Interaction Testleri

Modal aç-kapat, menu rapid click, drag ve scroll senaryosu kaydedilir. Typing sırasında background animation test edilir. INP-like latency gözlenir. Long task source bulunur. Regression automation'a senaryo eklenir.

Animasyon Performansında RUM Nedir?

Real User Monitoring gerçek kullanıcı cihazlarında oluşan performance verisini production ortamından toplar. Lab testi repeatable olsa da gerçek browser, CPU, network ve interaction çeşitliliğini tam temsil edemez. RUM INP, long task ve device segmentleri üzerinden animasyonun saha etkisini gösterebilir. Belirli route veya animation feature flag ile metric karşılaştırması yapılabilir. Privacy ve sampling maliyeti instrumentation tasarımında dikkate alınmalıdır.

Lab Test vs Real User Monitoring

Lab deterministic environment sağlar. Regression kolay tekrarlanır. RUM gerçek user distribution gösterir. İkisi birbirinin yerine geçmez. Lab sorunu bulur, RUM etki alanını doğrular.

INP

INP gerçek user interaction responsiveness'i gösterir. Animation active state ile metric event ilişkilendirilebilir. High INP session'da LoAF veya long task attribution incelenebilir. Route ve device segmentlenir. User-level sensitive data toplanmamalıdır.

Device Segment

Mobile, desktop ve approximate device class ayrı analiz edilebilir. Low-end segment higher latency gösterebilir. Hardware fingerprinting yapılmamalıdır. Coarse capability data yeterlidir. Optimization en kötü meaningful segment'e göre yapılabilir.

Browser Segment

Rendering behavior browser engine'e göre değişebilir. Scroll timeline support farklı olabilir. INP ve frame issue browser bazında segmentlenir. Feature fallback etkisi görülür. Browser-specific hack son çare olmalıdır.

Connection Segment

Animation asset lazy load network hızına bağlı olabilir. Slow connection initialization gecikir. Interaction code bundle download olmadan başlamayabilir. Route lazy loading strategy segmentlenir. Asset-heavy animation low bandwidth'te fallback kullanabilir.

Animasyonlar İçin Real User Metrics

Animasyon için production metric yalnız FPS olmamalıdır. INP, long task rate, navigation responsiveness, animation cancel oranı ve device class birlikte anlamlı sinyal üretir. User sık sık animation'ı cancel ediyorsa duration veya interaction design yavaş olabilir. Navigation transition sırasında error veya abandonment ayrıca incelenebilir. Metric collection sampling ve privacy sınırlarıyla uygulanmalıdır.

INP

Interaction responsiveness ana kullanıcı metriğidir. Animation active durumunda ayrı custom dimension kullanılabilir. High percentile takip edilir. Before-after release comparison yapılır. Core Web Vitals dashboard ile ilişkilendirilebilir.

Long Task Rate

Session başına long task sayısı animation workload riskini gösterir. Route veya feature segmentlenir. Script source attribution mümkünse eklenir. Decorative effect açıldığında rate artıyorsa sorun açıktır. Threshold product context'e göre belirlenir.

Navigation Responsiveness

Link click ile new content usable state arasındaki süre ölçülebilir. Page transition animation bu süreyi yapay uzatmamalıdır. Network ve render breakdown ayrılır. Back navigation ayrıca test edilir. View Transition rollout karşılaştırılabilir.

Animation Error/Cancel Rate

WAAPI cancel veya user interrupt event instrumentation yapılabilir. Çok yüksek cancel rate animation'ın gereksiz uzun olduğunu gösterebilir. User intent data içermeden aggregate ölçülür. Error event unsupported browser bug gösterebilir. Product team trendi yorumlar.

Device Class

Coarse performance segment low, mid ve high gibi sınıflanabilir. Fingerprinting yapılmamalıdır. Animation degradation strategy performans segmentine göre test edilir. User reduced motion tercihi ayrıca ayrı sinyaldir. RUM gerçek etkiyi doğrular.

Long Animation Frame (LoAF) Analizi

Long Animation Frame API uzun süren animation framelerini ve bu framelerdeki script work'u analiz etmeye yardımcı olabilir. web.dev yavaş interaction analizinde Long Animation Frame kayıtlarını INP attribution ile ilişkilendirmeye yönelik örnekler sunuyor. Bu sayede input delay sırasında hangi script'in main thread'i tuttuğu görülebilir. LoAF yalnız animation library değil sayfadaki tüm uzun frame work'unu anlamak için değerlidir. Production instrumentation browser desteği ve veri hacmi göz önünde bulundurularak uygulanmalıdır. :contentReference[oaicite:35]{index=35}

Uzun Frame

Frame beklenen refresh interval'dan önemli ölçüde uzun sürebilir. User jank hisseder. LoAF entry ilgili work hakkında bilgi verebilir. Interaction zamanı ile eşleştirilebilir. High percentile önemlidir.

Script Work

Long frame içindeki script duration source'a bağlanabilir. Animation callback, framework render veya third-party script bulunabilir. En uzun invoker incelenir. Code split veya defer uygulanabilir. User input ile yarış azaltılır.

Style/Layout

Long frame yalnız script nedeniyle oluşmaz. Style ve layout da presentation delay'e katkı verir. DOM mutation source incelenir. Width animation veya thrashing düzeltilebilir. LoAF ve Performance trace birbirini tamamlar.

Animation Sırasında Uzun Frame'leri Bulmak

Custom marker animation start ve end aralığını belirleyebilir. Bu sürede LoAF entry sayısı ölçülür. Non-animation baseline ile karşılaştırılır. Feature flag experiment yapılabilir. Problem specific component'e indirgenir.

Interaction ile Korelasyon

Click veya key interaction long frame ile aynı anda gerçekleşirse INP etkisi artabilir. Attribution input delay ve script source gösterebilir. Animation active dimension faydalıdır. User privacy korunur. Optimization başarısı production percentile ile izlenir.

Animasyon Performance Budget

Animation performance budget ekiplerin motion feature eklerken kabul edilebilir main thread, layout, paint ve bundle sınırlarını önceden belirlemesini sağlar. Tek değer yerine birkaç metric birlikte kullanılmalıdır. Main thread ms/frame, maximum layout time, dropped frame oranı, INP hedefi ve JavaScript bundle artışı örnek olabilir. Budget low-end test profilinde kontrol edilmelidir. Aşıldığında design veya implementation sadeleştirilir.

Main Thread ms/frame

Animation aktifken main thread her frame için küçük work yapmalıdır. Exact limit device ve refresh rate'e göre değişir. 60 Hz teorik 16,7 ms'nin tamamı application'a verilmemelidir. 120 Hz daha sıkıdır. Internal target daha düşük seçilebilir.

Maximum Layout Time

Layout duration specific interaction için threshold alabilir. Her frame layout olmaması ideal olabilir. Accordion gibi gerçek layout movement istisnadır. p95 layout time ölçülür. Regression CI trace ile yakalanabilir.

Maximum Paint Time

Large shadow veya blur paint budget'ı aşabilir. Paint area ve duration birlikte incelenir. Design alternative kullanılır. Mobile threshold daha düşük olabilir. Full-screen effect özel review gerektirir.

Dropped Frame Oranı

Animation session içinde dropped frame percentage izlenebilir. Average FPS yerine tail behavior görünür olur. Low-end cihaz için threshold belirlenir. User input sırasında stricter budget uygulanabilir. High refresh device ayrı değerlendirilir.

INP Hedefi

Core Web Vitals hedefi product performance budget'a eklenebilir. Animation rollout sonrası INP bozulmamalıdır. Route ve device segmenti izlenir. p75 user experience önemlidir. Lab interaction latency ayrı synthetic metric olabilir.

Bundle Size

Animation library veya Lottie runtime bundle artışı ölçülür. Transfer ve parse cost birlikte düşünülür. Route lazy loading uygulanabilir. Native API alternatifi değerlendirilir. Budget aşımı pull request'te görünür olmalıdır.

CI/CD'de Animasyon Performansı Test Edilebilir mi?

Animasyon performansının tamamını CI ortamında kusursuz ölçmek zor olsa da regression yakalamak mümkündür. Lighthouse genel main-thread ve Core Web Vitals sinyalleri sağlar. Browser performance trace belirli interaction script ile otomatik kaydedilebilir. Visual regression animation state screenshot'larını kontrol edebilir. Performance threshold değişiklikleri pull request aşamasında görünür hale getirilebilir.

Lighthouse

Lighthouse bundle ve main-thread performance hakkında genel sinyal verir. Animation specific FPS testi değildir. CI baseline regression için kullanılabilir. Lab environment fixed tutulmalıdır. Real user INP RUM ile tamamlanır.

Browser Performance Trace

Playwright veya browser automation belirli interaction çalıştırabilir. Trace kaydedilir. Long task, layout ve paint duration parse edilebilir. Baseline threshold ile karşılaştırılır. CI hardware variation tolerance gerektirir.

Automated Interaction

Menu aç-kapat, rapid click veya scroll script ile tekrar edilebilir. User-like delay ve pointer path tanımlanır. Animation state stable olmadan ikinci input gönderilebilir. Queue bug yakalanır. Reduced motion senaryosu ayrı çalıştırılır.

Visual Regression

Animation başlangıç, orta ve final state screenshot alınabilir. Layout shift veya missing content tespit edilir. Dynamic timestamp maskelenir. Reduced motion snapshot da test edilir. Visual test performance testi yerine geçmez.

Performance Regression Threshold

Bundle artışı, long task count veya interaction duration için threshold konabilir. Küçük noise tolerance gerekir. Large regression pipeline'ı fail edebilir. Override gerekçeli review ile yapılır. Trend dashboard uzun vadeli değişimi gösterir.

Animasyon Library Bundle Maliyetini Ölçmek

Animation library kullanım kararı yalnız API kolaylığıyla verilmemelidir. JavaScript transfer size, parse ve compile süresi route başlangıç performansını etkiler. Tree shaking gerçekten kullanılmayan kodu çıkarıyor mu production build üzerinde kontrol edilmelidir. Basit transition native CSS veya WAAPI ile yapılabiliyorsa ek runtime gerekmeyebilir. Secondary route animation package'i lazy load edilebilir.

JavaScript Transfer Size

Compressed bundle network üzerinden gelir. Brotli size bundle analyzer ile izlenebilir. Slow mobile network etkisi büyüktür. Shared chunk her route'ta yüklenmemelidir. Feature usage transfer maliyetini haklı çıkarmalıdır.

Parse/Compile Cost

Küçük network file bile complex JavaScript parse ve compile maliyeti oluşturabilir. Low-end CPU'da süre artar. Main thread initial interaction'ı geciktirebilir. Library deferred load edilebilir. Runtime initialization profile edilmelidir.

Tree Shaking

Named import kullanmak tek başına tree shaking garantisi değildir. Package module structure ve bundler config önemlidir. Production output inspect edilmelidir. Side-effect settings kontrol edilir. Unused plugin bundle'dan çıkarılmalıdır.

Native CSS/WAAPI Alternatifi

Fade, slide veya simple keyframe native API ile çözülebilir. Ek runtime bundle gerekmez. WAAPI cancellation ve reverse sunar. View Transition layout movement çözebilir. Library ancak ek değer sağlıyorsa kullanılır.

Route-Level Lazy Loading

Animation-heavy marketing route library'yi kendisi yükleyebilir. Dashboard core bundle etkilenmez. Dynamic import kullanılabilir. Prefetch user navigation pattern'e göre yapılabilir. First interaction package load nedeniyle gecikmemelidir.

Performanslı Animasyon İçin Karar Ağacı

Karar ağacı ekiplerin her yeni hareket için aynı soruları sormasını sağlar. Önce animation'ın basit state transition mı, scroll progress mi, viewport trigger mı, layout transition mı yoksa custom rendering mi olduğu belirlenir. Böylece gereksiz library veya manual loop eklenmez. Property olarak transform ve opacity başlangıç seçimi olur. Son karar DevTools ve düşük güçlü cihaz testiyle doğrulanır.

Basit Hover/State Transition mı?

İki state arasında visual change varsa en basit çözüm tercih edilir. Button hover, menu open ve tooltip fade buna örnektir. JavaScript animation loop gerekmez. CSS state selector kullanılabilir. Reduced motion kolay eklenir.

CSS Transition

Transition property explicit seçilir. Transform ve opacity kullanılır. Duration kısa tutulur. Rapid target change doğal test edilir. transition: all kullanılmaması tercih edilir.

Çok Aşamalı Timeline mı?

Animation birkaç keyframe içeriyorsa CSS keyframe veya WAAPI uygundur. Runtime control ihtiyacı karar verir. Static sequence CSS ile basittir. Dynamic cancellation WAAPI avantajı sağlar. Timeline user input'u bloke etmemelidir.

CSS Keyframes / WAAPI

CSS keyframe declarative motion sağlar. WAAPI runtime object kontrolü verir. İkisi aynı transform property'yi kullanabilir. Performance property cost üzerinden değerlendirilir. Reduced motion alternate path hazırlanır.

Scroll Progress'e Bağlı mı?

Animation progress elapsed time değil scroll position'a bağlıysa scroll-driven model düşünülmelidir. JavaScript event listener ilk seçenek olmamalıdır. Browser support kontrol edilir. Static fallback hazırlanır. Native scroll behavior korunur.

Scroll-Driven Animations

animation-timeline, scroll() veya view() kullanılabilir. Main-thread scroll handler azalır. Property transform veya opacity olur. MDN compatibility check yapılmalıdır. Reduced motion effect'i kapatabilir. :contentReference[oaicite:36]{index=36}

Viewport'a Girince mi Başlayacak?

Element yalnız görünür olduğunda time-based animation başlayacaksa IntersectionObserver uygundur. Scroll position'ın her pixelini izlemek gerekmez. Observer once trigger olabilir. Content JavaScript olmadan visible kalır. Initialization lazy yapılabilir.

IntersectionObserver

Observer element visibility threshold bildirir. Shared instance kullanılabilir. Callback class ekler. Transform ve opacity transition başlar. Offscreen pause için aynı API kullanılabilir.

Complex Layout Transition mı?

Element gerçek layout position veya size değiştiriyorsa FLIP veya View Transition değerlendirilebilir. Width animation ilk tercih olmamalıdır. Final layout tek seferde uygulanabilir. Visual movement transform veya snapshot üzerinden yürür. Browser support progressive enhancement ile çözülür.

FLIP / View Transition API

FLIP manual geometry control sağlar. View Transition browser snapshot modelini kullanır. Drag reorder FLIP için daha uygundur. Route veya state change View Transition ile sadeleşebilir. Gerçek cihaz profile edilmelidir.

Canvas/Physics Gerekiyor mu?

Yüzlerce object veya custom physics browser CSS animation modelini aşabilir. Canvas veya WebGL renderer kullanılabilir. Application frame loop gereklidir. requestAnimationFrame timestamp kullanılmalıdır. Accessibility semantic layer ayrıca sağlanmalıdır.

requestAnimationFrame

rAF display refresh ile uyumlu callback sağlar. Delta time movement hesaplar. Callback minimal tutulur. Background durumda çoğu browser pause eder. Loop yalnız visible ve active olduğunda çalışır. :contentReference[oaicite:37]{index=37}

Production-Ready Animasyon Akışı

Production-ready animation geliştirme UX amacıyla başlayıp gerçek kullanıcı ölçümüyle tamamlanan bir süreç olmalıdır. Önce hareketin gerçekten gerekli olup olmadığı sorulur. Ardından transform veya opacity gibi düşük maliyetli property tercih edilir, interaction priority ve interruptibility tasarlanır. Reduced motion desteği ve DevTools profiling release öncesi tamamlanır. Production RUM sonuçları tahminlerin gerçek kullanıcı cihazlarında doğru olup olmadığını gösterir.

1. UX Amacını Belirle

Animation hangi bilgi veya state değişimini açıklıyor sorusu cevaplanmalıdır. Dekorasyon tek amaçsa performance budget düşük tutulur. Critical workflow hareket olmadan da anlaşılır olmalıdır. User persona frequency dikkate alınır. Acceptance criteria motion amacı içerir.

2. Animasyonun Gerçekten Gerekli Olup Olmadığını Sor

Her state transition hareket gerektirmez. Frequent table action'da animation verimliliği düşürebilir. Static highlight yeterli olabilir. Motion kaldırıldığında UX aynıysa daha sade çözüm tercih edilir. Battery ve accessibility kazanılır.

3. transform/opacity ile Tasarla

Movement translate ve scale ile başlanır. Visibility opacity kullanabilir. Width ve top yalnız gerçek layout ihtiyacında değerlendirilir. Designer ile visual alternatifler konuşulur. Rendering trace ile doğrulanır.

4. Kullanıcı Input'unu Önceliklendir

Click veya key state hemen işlenir. Animation handler uzun task oluşturmaz. Navigation movement bitişini beklemez. Input sırasında decorative effect azaltılabilir. INP hedefi acceptance criterion olur.

5. Animasyonu Interruptible Yap

Rapid click ve reverse senaryosu tasarlanır. Latest state wins uygulanır. WAAPI cancel veya CSS retarget kullanılabilir. Queue önlenir. State machine test edilir.

6. Reduced Motion Desteği Ekle

Prefers-reduced-motion media query yazılır. Büyük spatial movement kaldırılır. Fonksiyonellik korunur. Automated test eklenir. App setting varsa OS tercihiyle uyumlu çalışır.

7. DevTools ile Layout/Paint Kontrol Et

Performance trace record edilir. Layout ve paint eventleri incelenir. Paint flashing beklenmeyen alanı gösterir. Layers panel promotion kontrol eder. Before-after kayıt saklanır.

8. Low-End Cihazda Test Et

CPU throttling ilk sinyal sağlar. Gerçek Android final test yapılır. Touch, scroll ve rapid interaction kullanılır. Battery ve thermal behavior gözlenir. Mobile fallback doğrulanır.

9. INP ve Frame Metrics Ölç

FPS yanında interaction latency ölçülür. Long task ve frame time kaydedilir. 60 ve 120 Hz cihaz karşılaştırılır. Slow interaction source bulunur. Performance budget kontrol edilir.

10. Production RUM ile İzle

Release sonrası gerçek user INP trendi izlenir. Device ve browser segmentleri karşılaştırılır. Feature flag rollout risk azaltır. Regression alert kurulabilir. Animation user value sağlamıyorsa sadeleştirilir.

Production'a Çıkmadan Önce Animasyon Kontrol Listesi

Production kontrolü animasyonun yalnız görsel olarak doğru çalışıp çalışmadığına bakmamalıdır. Property seçimi, layout maliyeti, scroll handler davranışı, requestAnimationFrame iş yükü, will-change kullanımı, visibility lifecycle, accessibility ve interaction metrics birlikte doğrulanmalıdır. 120 Hz cihaz ve low-end mobile farklı sorunlar gösterebilir. Paint Flashing ve layer analizi beklenmeyen rendering maliyetini yakalar. Kontrol listesi CI testleri ve manuel gerçek cihaz testleriyle desteklenmelidir.

transform/opacity Tercih Edildi mi?

Movement için translate veya scale değerlendirildi mi kontrol edilir. Visibility opacity ile çözülebilir. Layout property gerçekten gerekli mi sorulur. Paint trace alınır. Visual requirement değişmeden daha ucuz property varsa seçilir.

Gereksiz Layout Animasyonu Var mı?

Width, height, top veya left animation listelenir. Her biri için business gerekçesi kontrol edilir. FLIP veya transform alternatifi test edilir. Small isolated layout kabul edilebilir. Performance trace karar verir.

Scroll Handler Main Thread'i Blokluyor mu?

Scroll event callback duration ölçülür. Passive option kontrol edilir. DOM read/write batching uygulanır. CSS scroll timeline alternatifi değerlendirilir. Scroll jank gerçek cihazda test edilir.

requestAnimationFrame İçinde Fazla İş Var mı?

Callback flame chart incelenir. Heavy loop çıkarılır. Delta time kullanılır. Loop yalnız active durumda çalışır. Input handler ile yarış kontrol edilir.

Layout Thrashing Var mı?

Repeated Recalculate Style ve Layout eventleri aranır. Forced reflow source bulunur. Read phase write phase ayrılır. Geometry cache uygulanır. Trace tekrar alınır.

will-change Gereksiz Kullanılıyor mu?

Stylesheet genel will-change aranır. Yüzlerce element etkileniyorsa kaldırılır. Sadece problemli component'te kısa süre kullanılır. Layer count karşılaştırılır. Animation sonrası auto yapılır.

Offscreen Animasyonlar Durduruluyor mu?

IntersectionObserver lifecycle kontrol edilir. Lottie ve canvas pause edilir. Hidden tab behavior test edilir. Resume visual state doğrulanır. Battery usage azalır.

Infinite Animasyonlar Gerekli mi?

Spinner gerçekten loading durumunda mı kontrol edilir. Decorative loop business value taşımıyorsa kaldırılır. Visible değilken pause edilir. Reduced motion alternate state vardır. CPU idle usage ölçülür.

Kullanıcı Animasyonu Kesebiliyor mu?

Rapid click test edilir. Escape close anında çalışır. WAAPI cancel veya reverse kullanılabilir. Queue oluşmaz. Latest state final görünümü belirler.

prefers-reduced-motion Destekleniyor mu?

OS setting reduce yapılarak uygulama test edilir. Spatial movement azaltılır. Content hidden kalmaz. Functionality aynı çalışır. Focus behavior korunur.

Keyboard Kullanımı Bozulmuyor mu?

Tab order animation sırasında test edilir. Modal focus trap çalışır. Drawer close focus'u geri getirir. Invisible element focus alamaz. Reduced motion aynı semantics'i korur.

INP Ölçüldü mü?

Lab interaction duration ve production RUM hazırlanır. Animation sırasında click test edilir. Long task attribution toplanabilir. p75 hedefi izlenir. Release sonrası regression alert kurulur.

Low-End Mobil Test Yapıldı mı?

Gerçek düşük güçlü Android cihaz kullanılır. Scroll, typing ve drag aynı route'ta test edilir. Thermal etkisi uzun session'da incelenir. Heavy effect fallback doğrulanır. Network yavaşlatması asset animation'ı test eder.

120 Hz Cihazda Test Edildi mi?

Animation timestamp kullanıyor mu kontrol edilir. Fixed 16 ms increment bug aranır. Callback frequency CPU usage ölçülür. Frame pacing gözlemlenir. Motion speed 60 Hz ile aynı gerçek duration'ı korur.

Paint Flashing Kontrol Edildi mi?

Hover ve scroll sırasında unexpected paint aranır. Full-screen repaint olmamalıdır. Blur ve shadow impact görülür. Paint area küçültülür. Final trace saklanır.

Layer Sayısı Kontrol Edildi mi?

Layers panel gereksiz promotion gösteriyor mu incelenir. will-change etkisi kontrol edilir. Large layer memory değerlendirilir. Mobile GPU riskli alanlar azaltılır. Browser default promotion mümkün olduğunca korunur.

Sık Yapılan Animasyon Performans Hataları

Animasyon performans hatalarının çoğu yanlış property seçimi, aşırı JavaScript işi ve kullanıcı input'unu ikincil görme yaklaşımından kaynaklanır. Top veya left ile sürekli movement, width ve height'i her frame değiştirmek, scroll sırasında DOM ölçmek ve requestAnimationFrame içine ağır logic koymak sık örneklerdir. will-change'in her elemente eklenmesi de optimization yerine memory problemine dönüşebilir. Framework state'ini her frame güncellemek gereksiz render oluşturabilir. Son olarak yalnız FPS ölçüp INP ve gerçek interaction latency'yi görmezden gelmek kullanıcı deneyiminin önemli bölümünü kaçırır.

top/left ile Sürekli Hareket Ettirmek

Position property layout hesaplaması oluşturabilir. Continuous movement için translate daha uygun olabilir. Sibling effect kontrol edilir. DevTools trace alınır. Static position için top ve left kullanılmaya devam edebilir.

width/height'i Her Frame Değiştirmek

Geometry değişimi layout ve reflow oluşturur. Child content yeniden wrap olabilir. Scale visual alternatif olabilir. Real layout gerekiyorsa FLIP veya isolated container düşünülür. Performance gerçek DOM'da ölçülür.

Her Scroll Event'te DOM Ölçmek

getBoundingClientRect sürekli layout read yapabilir. Multiple element cost büyür. IntersectionObserver visibility için kullanılır. Scroll Timeline progress için değerlendirilebilir. Manual measurement cache edilir.

setInterval ile Animation Loop Kurmak

Timer display refresh ile senkron değildir. Background behavior daha az uygun olabilir. requestAnimationFrame visual animation için doğal API'dir. Timestamp progression kullanılır. Loop idle durumda durdurulur.

requestAnimationFrame İçine Ağır İş Koymak

rAF callback 30 ms sürerse scheduling avantajı kaybolur. Frame deadline kaçırılır. Input gecikir. Heavy calculation ayrılır. Callback yalnız visual update yapar.

will-change'i Her Elemana Eklemek

Layer count ve memory artabilir. MDN aşırı kullanımdan kaçınılmasını önerir. Browser zaten automatic optimization yapar. Only measured problem için kullanılır. Animation sonrası kaldırılır. :contentReference[oaicite:38]{index=38}

Büyük Blur/Shadow Alanlarını Sürekli Animate Etmek

Paint ve GPU cost artar. Full-screen effect low-end mobile'da problem olur. Pseudo layer opacity alternatifi denenir. Radius azaltılır. Paint flashing ile kontrol edilir.

Framework State'ini Her Frame Güncellemek

Component tree reconciliation oluşur. Animation progress application state'e taşınır. CSS veya WAAPI daha uygun olabilir. Ref veya motion value kullanılabilir. Framework profiler render sayısını gösterir.

Görünmeyen Animasyonları Çalıştırmaya Devam Etmek

User value olmadan CPU ve battery tüketilir. IntersectionObserver pause eder. Page Visibility tab state'i yönetir. Infinite loop kapatılır. Resume doğru state'ten devam eder.

Reduced Motion Tercihini Görmezden Gelmek

User accessibility tercihi göz ardı edilir. Parallax veya large zoom rahatsızlık yaratabilir. Media query eklenmelidir. Functionality motion olmadan çalışmalıdır. Test automation reduce mode içermelidir.

Sadece Güçlü Developer Laptop'unda Test Etmek

Production device distribution farklıdır. CPU throttling sorunları görünür kılar. Low-end Android final test gereklidir. High refresh device ayrı davranır. RUM gerçek kullanıcı sonucunu doğrular.

FPS Ölçüp INP'yi Ölçmemek

Animation akıcı görünürken button input gecikebilir. FPS responsiveness metric değildir. INP user interaction latency'yi ölçer. Long task attribution source'u bulur. Performance review iki metriği birlikte kullanmalıdır.

Sık Sorulan Sorular

Web animation performansı konusunda en sık sorulan sorular CSS ile JavaScript karşılaştırmasından GPU acceleration ve INP ilişkisine kadar uzanır. Bu soruların çoğunda tek cümlelik evrensel cevap yoktur, çünkü browser rendering behavior değiştirilen property, DOM yapısı, cihaz ve interaction türüne göre değişir. Yine de transform ve opacity ile başlamak, kullanıcı input'unu önceliklendirmek ve gerçek cihazda ölçmek güçlü ortak prensiplerdir. Aşağıdaki cevaplar teknik karar verirken hızlı referans olarak kullanılabilir. Daha kapsamlı kurumsal web sitesi animasyon ve frontend performans optimizasyon hizmeti planlanırken aynı sorular production ölçüm hedeflerine dönüştürülebilir.

Web animasyonları performansı etkiler mi?

Evet, animasyonlar property ve implementation'a göre CPU, GPU, layout, paint ve main-thread süresi kullanabilir. Transform ve opacity gibi property'ler çoğu durumda daha düşük rendering maliyetiyle başlayabilir. Width, blur veya heavy JavaScript loop daha pahalı olabilir. Kullanıcı etkileşimleri sırasında bu iş yükü input gecikmesine dönüşebilir. Bu nedenle animasyonun etkisi DevTools ve RUM ile ölçülmelidir.

CSS animation mı JavaScript animation mı daha hızlıdır?

Tek başına CSS veya JavaScript etiketi performansı belirlemez. CSS width animation pahalı olabilirken JavaScript yalnız transform target değiştirebilir. JavaScript her frame heavy computation yaparsa main thread yükü artar. CSS, WAAPI ve requestAnimationFrame aynı visual sonuçla test edilmelidir. Property ve workload gerçek belirleyicidir.

60 FPS için kaç milisaniye vardır?

60 Hz ekranda yenileme aralığı teorik olarak yaklaşık 16,7 milisaniyedir. Browser'ın başka rendering ve input işleri de bu süreyi kullanır. Bu nedenle application JavaScript'inin tamamını 16,7 milisaniyeye kadar kullanması iyi hedef değildir. 120 Hz ekranda aralık yaklaşık 8,3 milisaniyedir. Daha küçük internal budget güvenlidir.

transform neden top/left'ten daha performanslıdır?

Transform visual movement yaparken document geometry'sini değiştirmeyebilir. Top veya left layout recalculation oluşturabilir. Transform uygun koşullarda compositor seviyesinde işlenebilir. Bu nedenle continuous movement için güçlü başlangıçtır. Browser behavior yine DevTools ile doğrulanmalıdır.

opacity animasyonu performanslı mıdır?

Opacity çoğu fade transition için uygun property'dir. Layout geometry değişmez. Browser uygun layer koşullarında composite üzerinden ilerleyebilir. Büyük transparent surface yine composite maliyeti oluşturabilir. Hidden element pointer ve accessibility state ayrıca yönetilmelidir.

width ve height animasyonu neden yavaştır?

Width ve height element geometry'sini değiştirir. Parent, child ve sibling layout yeniden hesaplanabilir. Text wrap ve grid position değişebilir. Her frame bu işlem tekrarlanırsa jank oluşabilir. Scale, FLIP veya View Transition alternatifleri değerlendirilebilir.

requestAnimationFrame nedir?

requestAnimationFrame browser repaint öncesi animation callback planlayan API'dir. Callback frequency genellikle display refresh rate ile uyumludur. Background tablarda çoğu browser çağrıları pause eder. Sürekli loop için callback içinde yeniden request gerekir. Timestamp hareketin refresh rate bağımsız ilerlemesi için kullanılmalıdır. :contentReference[oaicite:39]{index=39}

requestAnimationFrame neden setInterval'dan daha iyidir?

requestAnimationFrame visual update'i browser frame scheduling ile uyumlu hale getirir. setInterval sabit timer ritmine bağlıdır. rAF background durumda doğal olarak pause edilebilir. High refresh monitor ile callback frequency uyum sağlar. İçindeki kod yine küçük tutulmalıdır.

will-change ne işe yarar?

will-change browser'a elementin yakında hangi property'de değişeceğini bildirir. Browser ön hazırlık veya layer promotion yapabilir. Transform veya opacity için gerektiğinde kullanılabilir. Sürekli her elemente eklenmemelidir. MDN kullanımı ölçülmüş performans problemiyle sınırlandırmayı önerir. :contentReference[oaicite:40]{index=40}

will-change performansı kötüleştirebilir mi?

Evet, fazla kullanım memory ve layer sayısını artırabilir. Browser gereksiz optimization resource tutabilir. Büyük container üzerinde etkisi daha yüksek olur. Sadece gerektiğinde kısa süre kullanılmalıdır. Animation sonrası auto değerine dönmek iyi pratiktir. :contentReference[oaicite:41]{index=41}

GPU acceleration nedir?

GPU acceleration rendering veya compositing işlerinin grafik işlemci tarafından yürütülmesidir. Transform ve opacity layer animation bundan yararlanabilir. GPU kullanmak her zaman daha hızlı değildir. Büyük texture ve blur yüksek maliyet oluşturabilir. Gerçek cihazda ölçüm gerekir.

Layout thrashing nedir?

Layout thrashing DOM write ve read işlemlerinin sürekli birbirini tetiklemesi sonucu browser'ın layout'u tekrar tekrar hesaplamasıdır. Style değiştirip hemen geometry okumak klasik örnektir. Read ve write phase ayrılmalıdır. Geometry cache edilebilir. Performance trace forced reflow kaynağını gösterebilir.

Scroll animasyonları nasıl hızlandırılır?

Scroll event handler mümkün olduğunca kaldırılmalı veya küçük tutulmalıdır. CSS Scroll-Driven Animations progress için değerlendirilebilir. IntersectionObserver reveal trigger için uygundur. Manual handler passive ve requestAnimationFrame scheduled olabilir. DOM read ve write batch edilmelidir.

IntersectionObserver animasyon için nasıl kullanılır?

Element viewport'a girdiğinde observer callback animation class ekleyebilir. Offscreen olduğunda animation pause edilebilir. Her scroll pixelini takip etmek için kullanılmamalıdır. Root margin lazy initialization'ı biraz erken başlatabilir. Reduced motion durumda animation başlatılmayabilir.

Scroll-driven animation nedir?

Scroll-driven animation animation progress'ini time yerine scroll veya view progress'e bağlar. CSS animation-timeline, scroll() ve view() kullanılabilir. JavaScript scroll handler ihtiyacı azalır. User geri scroll ettiğinde progress geri hareket edebilir. Browser compatibility kontrol edilmelidir. :contentReference[oaicite:42]{index=42}

View Transition API nedir?

View Transition API eski ve yeni DOM görünümünün snapshot'larını kullanarak state veya page transition oluşturmayı kolaylaştırır. Same-document ve belirli cross-document navigation senaryoları desteklenir. Shared element transition kurulabilir. Manual FLIP kodunu bazı durumlarda azaltır. Progressive enhancement ve browser desteği kontrol edilmelidir. :contentReference[oaicite:43]{index=43}

FLIP animation nedir?

FLIP First, Last, Invert ve Play adımlarından oluşur. Eski ve yeni layout geometry ölçülür. Aradaki fark transform ile invert edilir. Sonra transform final state'e animasyonla gider. Layout transition visual olarak compositor-friendly hareket haline getirilebilir.

prefers-reduced-motion nedir?

Prefers-reduced-motion kullanıcının daha az motion istediğini bildiren CSS media feature'dır. Büyük parallax ve zoom hareketleri azaltılabilir. Kısa opacity transition alternatif olabilir. Fonksiyonellik animation olmadan çalışmalıdır. User tercihi device capability tahmininden önce gelir.

Animasyonlar INP'yi etkiler mi?

Evet, main thread'i yoğun kullanan animation input delay ve presentation delay'i artırabilir. CSS compositor animation doğrudan daha az main-thread work oluşturabilir. Heavy requestAnimationFrame veya framework render sorun yaratabilir. RUM INP ve Long Animation Frame attribution birlikte incelenebilir. FPS iyi olsa bile INP kötü olabilir. :contentReference[oaicite:44]{index=44}

React animasyonları neden takılır?

Her frame setState veya geniş component tree render jank oluşturabilir. Animation progress framework state'e taşınmamalıdır. CSS, WAAPI veya motion value kullanılabilir. Expensive child component memoize edilebilir. React Profiler ve browser trace birlikte incelenmelidir.

GSAP mı CSS mi kullanılmalı?

Basit state transition için CSS çoğu zaman yeterlidir. Çok aşamalı choreography veya özel timeline control için animation library değer sağlayabilir. Bundle size ve maintenance ölçülmelidir. Rendering property yine aynı performans kurallarına tabidir. Native WAAPI ve View Transition alternatifleri de değerlendirilmelidir.

Animasyon performansı DevTools ile nasıl ölçülür?

Performance panelde interaction kaydı alınır. Frames, Main Thread, Layout, Paint ve Composite eventleri incelenir. Paint Flashing unexpected repaint'i gösterir. Layers panel promotion ve layer size'ı açıklar. CPU throttling düşük cihaz riskini görünür kılar.

Mobil cihazlarda animasyon performansı nasıl test edilir?

Önce DevTools CPU ve network throttling kullanılabilir. Ardından gerçek low-end Android cihazda touch, scroll ve drag test edilir. Long session thermal behavior gözlenir. High refresh phone ayrıca test edilir. Production RUM gerçek user distribution'ını doğrular.

Kullanıcı etkileşimlerini yavaşlatmayan web animasyonları nasıl oluşturulur?

Önce kullanıcı input'unun main thread üzerindeki önceliği korunmalıdır. Hareket ve fade için mümkün olduğunca transform ile opacity tercih edilir, animation interruptible yapılır ve layout read ile write işlemleri birbirinden ayrılır. Scroll effects mümkün olduğunda declarative API'lere taşınır. Düşük güçlü cihazlarda CPU throttling ve gerçek telefon testleri yapılır. Kullanıcı Etkileşimlerini Yavaşlatmayan Animasyon Teknikleri yaklaşımının başarısı yalnız FPS değil INP, long task ve gerçek interaction latency ile ölçülmelidir.

CSS animasyonlarında transform ve opacity kullanımı performansı nasıl artırır?

Transform ve opacity document geometry'sini değiştirmeden görsel hareket veya görünürlük sağlayabildiği için layout ve paint maliyetini azaltabilir. Uygun browser koşullarında compositor katmanında işlenmeleri mümkündür. Böylece main thread kullanıcı click veya keyboard eventleri için daha fazla zaman bulabilir. Yine de büyük layer ve texture memory maliyeti unutulmamalıdır. Sonucun gerçekten daha hızlı olduğu DevTools Performance ve Layers analiziyle doğrulanmalıdır.

JavaScript animasyonlarında requestAnimationFrame kullanmak neden önemlidir?

requestAnimationFrame callback'i browser'ın repaint döngüsüyle uyumlu zamanda çalıştırır. Callback sıklığı çoğunlukla ekran refresh rate'ini takip eder ve background tablarda çoğu browser tarafından pause edilir. Bu davranış setInterval tabanlı loop'a göre animation scheduling açısından daha doğaldır. Timestamp kullanmak 60 Hz ve 120 Hz cihazlarda animation speed'in aynı gerçek sürede kalmasını sağlar. Buna rağmen callback içine ağır JavaScript koymak performansı yine düşürür. :contentReference[oaicite:45]{index=45}

Animasyonların Core Web Vitals ve Interaction to Next Paint (INP) performansını olumsuz etkilemesi nasıl önlenir?

Main thread üzerinde çalışan uzun animation task'ları azaltılmalı ve interaction handler'ları küçük tutulmalıdır. Framework state her frame güncellenmemeli, layout thrashing engellenmeli ve decorative animation user input geldiğinde pause veya cancel edilebilmelidir. Production ortamında INP attribution ve Long Animation Frame verileri problemli script'i belirlemek için kullanılabilir. FPS iyi göründüğü halde input delay yüksekse animation sistemi responsive değildir. RUM ve gerçek cihaz testleri release sonrasında da sürdürülmelidir. :contentReference[oaicite:46]{index=46}

Performanslı web animasyonları ve kullanıcı deneyimi optimizasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Frontend performans ve web animasyon danışmanlığı yakınımda şeklindeki aramalarda yalnız animasyon demosu gösterebilen değil rendering pipeline, Core Web Vitals, accessibility ve gerçek cihaz ölçümü konusunda uygulamalı çalışma yapabilen ekip veya toplulukları değerlendirmek daha faydalıdır. Diyarbakır'da teknik paylaşım, açık kaynak çalışma ve frontend geliştirme odağında topluluk çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresindeki projelere bakabilirsiniz. Topluluk yapısı ve çalışma alanları hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Kurumsal eğitim planlanırken gerçek proje trace'leri, düşük güçlü cihaz testi ve DevTools workshop'ları teorik sunumdan daha fazla uygulama değeri sağlar. Eğitim sonunda ekiplerin kendi performance budget ve production kontrol listesini oluşturması sürdürülebilir sonuç üretir.

Sonuç: Kullanıcı Etkileşimlerini Yavaşlatmadan Animasyon Nasıl Tasarlanır?

Performanslı web animasyonu daha fazla GPU kullanmak veya her hareketi bir animation library ile çözmek değildir. Asıl hedef kullanıcının click, tap, scroll, typing ve drag işlemleri için browser'a mümkün olduğunca fazla zaman bırakırken state değişimini anlaşılır hareketlerle desteklemektir. Transform ve opacity güçlü başlangıç property'leridir, fakat property choice gerçek DevTools ölçümüyle doğrulanmalıdır. Scroll-driven API'ler, WAAPI, View Transition ve requestAnimationFrame yalnız doğru problemde kullanıldığında değer üretir. Kullanıcı Etkileşimlerini Yavaşlatmayan Animasyon Teknikleri, tasarım kararını FPS sayısından çıkarıp kullanıcı responsiveness, accessibility ve production ölçümüyle birlikte değerlendiren bir frontend disiplinidir.

Animasyonun Amacını UX ile Başlatın

İlk soru “hangi library?” değil “bu hareket kullanıcıya ne anlatıyor?” olmalıdır. State change, hierarchy veya feedback amacı yoksa animasyon kaldırılabilir. Frequent workflow'da duration daha kısa tutulabilir. User research motion'un gerçekten faydalı olup olmadığını gösterir. Tasarım amacı performance budget belirlemeyi kolaylaştırır.

Rendering Pipeline'da Yapılan İşi Minimuma İndirin

Her property style, layout, paint ve composite zincirinde farklı iş yaratabilir. Animation mümkün olduğunca az aşama tetiklemelidir. Layout ve paint gerektiğinde scope küçültülür. DevTools trace gerçek davranışı gösterir. Performance kararları varsayıma bırakılmaz.

Mümkün Olduğunca transform ve opacity Kullanın

Translate, scale, rotate ve opacity birçok UI animation için yeterlidir. Document geometry değişmeden visual movement yapılabilir. Compositor-friendly davranış mümkün olur. Büyük layer memory yine kontrol edilir. CSS property seçiminde ilk seçenek olarak değerlendirilir.

Main Thread'i Kullanıcı Input'una Bırakın

Animation JavaScript'i kısa tutulur. Framework render her frame çalıştırılmaz. Heavy computation animation dışına alınır. User click handler hemen çalışabilir. INP ve long task metricleri bu hedefi doğrular.

Scroll İşlerini Declarative API'lere Taşıyın

Scroll progress gerekiyorsa CSS Scroll-Driven Animations değerlendirilebilir. Reveal trigger IntersectionObserver ile yapılabilir. Manual scroll handler son seçenek olur. Native scrolling korunur. Browser support progressive enhancement ile yönetilir. :contentReference[oaicite:47]{index=47}

Layout Read ve Write'larını Ayırın

Geometry ölçümleri önce yapılır. Style mutation daha sonra batch edilir. Forced synchronous layout azaltılır. Cache kullanılabilir. Performance trace layout count düşüşünü doğrular.

Animasyonları Interruptible Hale Getirin

Rapid click ve reverse normal kullanıcı davranışıdır. Current animation yeni intent'e göre cancel veya reverse edilir. Queue oluşturulmaz. Latest state wins uygulanır. Kullanıcı kontrolü korunur.

Reduced Motion Tercihine Saygı Gösterin

Large movement, parallax ve zoom azaltılır. Fonksiyonellik motion olmadan çalışır. Focus ve content visibility aynı kalır. CSS media query ve JavaScript preference birlikte kullanılabilir. Accessibility production checklist'in temel maddesidir.

Güçlü Laptop Yerine Gerçek Düşük Güçlü Cihazlarda Test Edin

CPU throttling başlangıç araçtır. Low-end Android gerçek touch ve GPU davranışını gösterir. Long session thermal impact ölçülür. 120 Hz cihaz ayrıca kontrol edilir. Production RUM sonuçları lab varsayımını doğrular.

FPS ile Birlikte INP ve Kullanıcı Etkileşim Gecikmesini Ölçün

Akıcı görünmek responsive olmakla aynı değildir. FPS frame smoothness, INP interaction responsiveness hakkında farklı bilgi verir. Long task ve LoAF attribution bottleneck source'unu gösterebilir. Animation release sonrası user interaction percentile izlenmelidir. Kullanıcı action'ı animation'dan önce gelmelidir.

Performanslı Animasyonu “Daha Fazla GPU Kullanmak” Değil, Kullanıcı Etkileşimi İçin Mümkün Olduğunca Az İş Yapmak Olarak Ele Alın

En iyi animation optimizasyonu browser'ın gereksiz iş yapmasını önleyen tasarımdır. Her elemente will-change eklemek veya her hareketi GPU layer'a zorlamak doğru yaklaşım değildir. Daha az DOM mutation, daha küçük paint alanı, daha kısa script task ve daha sade motion çoğu zaman daha güçlü sonuç verir. Kurumsal web sitesi animasyon ve frontend performans optimizasyon hizmeti planlanırken başarı kriteri kullanıcıya gösterilen efekt sayısı değil etkileşim hızının korunması olmalıdır. Diyarbakır Yazılım Topluluğu ile frontend geliştirme, performans ve proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects ve topluluk hakkında daha fazla bilgi almak için https://www.diyarbakiryazilim.com.tr/about adreslerini kullanabilirsiniz.