14 Ağu 2025·6 dk
Derleyici yaklaşımıyla web performansı: Rich Harris'in görüşü
Derleyici yaklaşımına pratik bir bakış: çalışma zamanı ağırlıklı çerçeveler ile derleme-zamanı çıktısını karşılaştırma ve basit bir karar çerçevesi.
Derleyici yaklaşımına pratik bir bakış: çalışma zamanı ağırlıklı çerçeveler ile derleme-zamanı çıktısını karşılaştırma ve basit bir karar çerçevesi.
Kullanıcılar nadiren performansı teknik terimlerle tanımlar. Uygulama ağır geliyor derler. Sayfalar hiçbir şey göstermesi için biraz gecikiyor, butonlar geç tepki veriyor ve menü açmak, arama kutusuna yazmak veya sekme değiştirmek gibi basit eylemler takılıyor.
Belirtiler tanıdık: yavaş ilk yükleme (boş veya yarım oluşmuş UI), gecikmeli etkileşimler (tıklamaların bir duraklama sonrası gerçekleşmesi, titreyen kaydırma) ve form kaydetme veya liste filtreleme gibi anında hissetmesi gereken işlemler sonrası uzun spinner'lar.
Bunun büyük kısmı çalışma zamanı maliyetidir. Basitçe, sayfa yüklendikten sonra tarayıcının uygulamayı kullanılabilir hale getirmek için yapması gereken işler: daha fazla JavaScript indirmek, ayrıştırmak, çalıştırmak, UI oluşturmak, handler'ları bağlamak ve her güncellemede ekstra işler yapmak. Hızlı cihazlarda bile tarayıcıya çok fazla JavaScript aktarırsanız deneyim yavaşlamaya başlar.
Performans problemleri genelde geç ortaya çıkar. Başlangıçta uygulama küçüktür: birkaç ekran, hafif veri, basit UI. Sonra ürün büyür. Pazarlama izleyiciler ekler, tasarım daha zengin bileşenler ekler, ekipler durum, özellikler, bağımlılıklar ve kişiselleştirme ekler. Her değişiklik tek başına zararsız görünür, ama toplam iş birikir.
İşte bu yüzden ekipler derleyici-öncelikli performans fikirlerine bakmaya başlar. Amaç genelde mükemmel puanlar değil. Amaç, uygulamanın her ay daha da yavaşlamasını engelleyecek şekilde göndermeye devam edebilmektir.
Çoğu frontend çerçevesi iki şeyi yapmanıza yardımcı olur: bir uygulama inşa etmek ve UI'yı verilerle eş tutmak. Temel fark ikinci kısmın ne zaman gerçekleştiğidir.
Çalışma zamanı-ağır bir çerçevede işin daha fazlası sayfa yüklendikten sonra tarayıcıda gerçekleşir. Birçok durumu halledebilen genel amaçlı bir runtime gönderirsiniz: değişiklikleri takip etme, neyin güncelleneceğine karar verme ve bu güncellemeleri uygulama. Bu esneklik geliştirme için harika olabilir, ama genellikle UI hazır hissetmeden önce indirilecek, ayrıştırılacak ve çalıştırılacak daha fazla JavaScript anlamına gelir.
Derleme-zamanı optimizasyonunda bu işin daha fazlası build adımına kayar. Tarayıcıya geniş bir kural seti göndermek yerine build aracı bileşenlerinizi analiz eder ve daha doğrudan, uygulamaya özgü kod üretir.
Kafa modeli faydalıdır:
Gerçek ürünlerin çoğu bu iki uç arasında bir yerde durur. Derleyici-öncelikli yaklaşımlar hâlâ bazı runtime kodu gönderir (routing, veri getirme, animasyonlar, hata yönetimi). Çalışma zamanı-ağır çerçeveler de istemci işini azaltmak için build-zamanı tekniklerine (minifikasyon, code-splitting, server rendering) dayanır. Pratik soru hangi kampın “doğru” olduğu değil, hangi karışımın ürününüze uyduğu.
Rich Harris derleyici-öncelikli frontend düşüncesinin en net seslerinden biridir. Argümanı basittir: kullanıcıların daha az kod indirmesi ve tarayıcının daha az iş yapması için işi önceden yapın.
Motivasyon pratiktir. Birçok çalışma zamanı-ağır çerçeve genel amaçlı bir motor gönderir: bileşen mantığı, reaktivite, diffing, zamanlama ve her uygulama için çalışması gereken yardımcılar. Bu esneklik byte ve CPU maliyeti getirir. UI küçükken bile büyük bir runtime için ödeme yapabilirsiniz.
Derleyici yaklaşımı modeli tersine çevirir. Build sırasında derleyici gerçek bileşenlerinize bakar ve ihtiyaç duydukları spesifik DOM güncelleme kodunu üretir. Bir etiket hiç değişmiyorsa düz HTML olur. Sadece bir değer değişiyorsa, sadece o değer için güncelleme yolu üretilir. Genel bir UI makinesi göndermek yerine ürününüze özel çıktıyı gönderirsiniz.
Bu genellikle şu sonucu verir: kullanıcılara gönderilen daha az framework kodu ve her etkileşimde yapılan daha az iş. Ayrıca düşük kaliteli cihazlarda bu fark daha çabuk görünür.
Takaslar hala önemlidir:
Pratik bir kural: UI'nızın çoğu derleme zamanında bilinebiliyorsa derleyici sıkı çıktı üretebilir. UI'nız yüksek derecede dinamik veya eklenti odaklıysa daha ağır bir runtime daha kolay olabilir.
Derleme-zamanı optimizasyonu işin nerede yapıldığını değiştirir. Daha fazla karar build sırasında verilir ve tarayıcıya daha az iş kalır.
Gözle görülen bir sonuç daha az JavaScript gönderilmesidir. Daha küçük bundle'lar ağ süresini, ayrıştırma süresini ve sayfanın bir dokunuşa veya tıklamaya yanıt vermesi arasındaki gecikmeyi azaltır. Orta seviye telefonlarda bu birçok ekibin beklediğinden daha önemlidir.
Derleyiciler ayrıca daha doğrudan DOM güncellemeleri üretebilir. Build adımı bir bileşenin yapısını görebildiğinde, her etkileşimde sadece gerçekten değişen DOM düğümlerine dokunan güncelleme kodu üretebilir; bu, soyutlama katmanlarını azaltır. Bu, listeler, tablolar ve formlarda sık gerçekleşen güncellemelerin daha hızlı hissetmesini sağlayabilir.
Build-zamanı analizleri tree-shaking ve dead-code kaldırmayı da güçlendirebilir. Ödül sadece daha küçük dosyalar değildir; tarayıcının yüklemesi ve çalıştırması gereken daha az kod yolu demektir.
Hydration başka bir alandır; build-zamanı seçimleri burada yardımcı olabilir. Hydration, sunucu tarafından render edilmiş bir sayfanın tarayıcıda etkileşimli hale gelmesi adımıdır. Eğer build gerçekten hangi kısımların etkileşim gerektirdiğini işaretleyebiliyorsa, ilk yüklemeye kalan iş azaltılabilir.
Yan etki olarak, derleme genellikle CSS kapsamlamasını da iyileştirir. Build sınıf adlarını yeniden yazabilir, kullanılmayan stilleri kaldırabilir ve bileşenler arası stil sızıntısını azaltabilir. Bu, UI büyüdükçe sürpriz maliyetleri düşürür.
Bir dashboard'u düşünün: filtreler ve büyük bir veri tablosu. Derleyici-öncelikli bir yaklaşım ilk yüklemeyi hafif tutabilir, bir filtre tıklamasından sonra sadece değişen hücreleri güncelleyebilir ve asla etkileşim gerektirmeyen sayfa bölümlerini hydrate etmekten kaçınabilir.
Daha büyük bir runtime otomatik olarak kötü değildir. Genelde esneklik satın alır: runtime sırasında karar verilen desenler, çok sayıda üçüncü taraf bileşen ve yıllardır test edilmiş iş akışları.
Çalışma zamanı-ağır çerçeveler UI kurallarının sık değiştiği yerlerde parıldar. Karmaşık yönlendirme, iç içe yerleşimler, zengin formlar ve derin durum modellerine ihtiyacınız varsa olgun bir runtime güvenlik ağı gibi gelebilir.
Runtime, uygulama çalışırken çok şeyi halletmesini istediğinizde yardımcı olur; sadece build sırasında değil. Bu ekiplerin günlük olarak daha hızlı hissetmesini sağlayabilir, hatta ek yük getirse bile.
Yaygın kazanımlar: büyük bir ekosistem, durum ve veri getirme için tanıdık desenler, güçlü geliştirici araçları, eklenti tarzı genişletme kolaylığı ve işe alımda ortak bir yetenek havuzundan hızlı onboarding.
Ekip tanıdıklığı gerçek bir maliyet ve gerçek bir faydadır. Biraz daha yavaş bir çerçeve, ekibinizin güvenle gönderebildiği bir yapı olarak, daha hızlı ama yeniden eğitim, daha sıkı disiplin veya özel araçlar gerektiren daha hızlı bir yaklaşımdan daha iyi olabilir.
Birçok “yavaş uygulama” şikayeti framework runtime'dan kaynaklanmaz. Sayfanız yavaş API bekliyorsa, ağır görseller, çok fazla font veya üçüncü taraf betikler varsa framework değiştirmek çekirdek sorunu çözmez.
Bir iç admin dashboard'ı genelde daha büyük bir runtime ile bile iyi hissedebilir; çünkü kullanıcılar güçlü cihazlarda olur ve işler tablolar, izinler ve backend sorguları tarafından domine edilir.
Erken aşamada “yeterince hızlı” doğru hedef olabilir. Ürününüzün değerini hala test ediyorsanız, iterasyon hızını yüksek tutun, temel bütçeler belirleyin ve derleyici-öncelikli karmaşıklığı ancak bunun gerçekten fark yaratacağına dair kanıt olduğunda üstlenin.
İterasyon hızı geri bildirim süresidir: birinin bir ekranı değiştirmesi, çalıştırması, neyin bozulduğunu görmesi ve düzeltmesi ne kadar sürer. Bu döngüyü kısa tutan ekipler daha sık gönderir ve daha hızlı öğrenir. Bu yüzden çalışma zamanı-ağır çerçeveler erken aşamada üretken hissettirebilir: tanıdık desenler, hızlı sonuçlar, çok yerleşik davranış.
Performans çalışması çok erken veya çok geniş yapıldığında bu döngüyü yavaşlatır. Her pull request mikro-optimizasyon tartışmalarına dönüşürse ekip risk almaktan vazgeçer. Ürüne dair belirsizken karmaşık bir pipeline inşa ederseniz, insanlar araçlarla uğraşarak kullanıcılarla konuşmak yerine zaman harcar.
Püf noktası “yeterince iyi”nin ne olduğunda uzlaşmak ve o kutu içinde iterasyon yapmaktır. Bir performans bütçesi size bu kutuyu verir. Mesele mükemmel puan peşinde koşmak değil; geliştirmeyi ilerletirken deneyimi koruyacak sınırlar koymaktır.
Pratik bir bütçe şunları içerebilir:
Eğer performansı görmezden gelirseniz, genelde ileride ödersiniz. Ürün büyüdüğünde yavaşlık mimari kararlara bağlanır; geç bir yeniden yazım özellikleri dondurmak, ekibi yeniden eğitmek ve eskiden çalışan iş akışlarını kırmak anlamına gelebilir.
Derleyici-öncelikli araçlar bu takası kaydırabilir. Daha uzun build'leri kabul edebilirsiniz ama her cihaz, her ziyaret için yapılan işi azaltırsınız.
Ürün kendini ispat ettikçe bütçeleri yeniden gözden geçirin. Erken aşamada temelleri koruyun. Trafik ve gelir arttıkça bütçeleri sıkılaştırın ve değişikliklerin gerçek metrikleri hareket ettirdiği yerlere yatırım yapın, gurur değil.
Performans tartışmaları “hızlı”nın ne olduğunu kimsenin kabul etmemesiyle karışır. Küçük bir metrik seti seçin, yazın ve ortak bir skor tahtası gibi davranın.
Basit bir başlangıç seti:
Geliştirici dizüstü bilgisayarıyla değil, temsilci cihazlarda ölçün. Hızlı bir CPU, sıcak önbellek ve yerel sunucu gecikmeleri saklayabilir; orta seviye bir telefonda ve ortalama mobil veride ortaya çıkan gecikmeleri gizleyebilir.
Sayıları somut tutun: gerçek kullanıcılara uyan iki veya üç cihaz seçin ve her seferinde aynı akışı çalıştırın (ana ekran, giriş, yaygın bir görev). Bunu tutarlı şekilde yapın.
Çerçeve değiştirmeden önce bir başlangıç alın. Bugünün build'ini alın, aynı akışlar için rakamları kaydedin ve görünür tutun. Bu başlangıç fotoğrafınızdır.
Performansı tek bir laboratuvar skoruna göre yargılamayın. Lab araçları yardımcı olur, ama yanlış şeyi ödüllendirebilir (mükemmel ilk yükleme) ve kullanıcıların şikayet ettiği şeyi kaçırabilir (takılan menüler, yavaş yazma, ilk ekrandan sonraki gecikmeler).
Sayılar kötüye gittiğinde tahmin yürütmeyin. Ne gönderildiğini, neyin render'ı engellediğini ve zamanın nerede geçtiğini (ağ, JavaScript, veya API) kontrol edin.
Framework ve render kararlarını sakin, tekrarlanabilir bir seçim gibi ele alın. Amaç en iyi teknoloji değil; performans ile ekibinizin ihtiyaç duyduğu hız arasında doğru dengeyi bulmaktır.
Bir ince dilim daima karmaşayı içermeli: gerçek veri, auth ve en yavaş ekranınız.
Prototiplemek için hızlı bir yol arıyorsanız, Koder.ai (koder.ai) sohbet üzerinden web, backend ve mobil uygulama akışları oluşturmanıza ve ardından kaynak kodunu dışa aktarmanıza olanak tanır. Bu, gerçek bir rotayı erken test etmenize ve denemeleri geri almayı kolaylaştıran snapshot'larla deneyleri tersine çevirebilir.
Kararı açık ve basit dille belgeleyin; hangi koşullar altında yeniden gözden geçireceğinizi (trafik artışı, mobil pay, SEO hedefleri) yazın. Bu, ekip değiştiğinde seçimi dayanıklı kılar.
Performans kararları genelde ekipler bugün gördükleri şeyi optimize ettiğinde değil, üç ay sonra kullanıcıların hissedeceğini öngöremediklerinde yanlış gider.
Erken aşamada aşırı optimize etmek bir hata. Ekip günlük değişen bir sayfanın milisaniyelerini azaltmak için günler harcar; o sırada gerçek problem kullanıcıların doğru özellikleri almaması olabilir. Erken dönemde öğrenmeyi hızlandırın; rotalar ve bileşenler stabilize olduğunda daha derin performans çalışması yapın.
Bir diğer hata bundle büyümesini acıya kadar görmezden gelmektir. 200 KB iyi görünürken bir süre sonra birkaç “küçük” ekleme megabaytlarca göndermeye yol açar. Basit bir alışkanlık yardımcı olur: bundle boyutunu zaman içinde takip edin ve ani sıçramaları hata gibi ele alın.
Ekipler her şeyi istemci tarafı render ile yapma eğilimine girer, oysa bazı rotalar çoğunlukla statik olabilir (fiyatlandırma sayfaları, dökümantasyon, onboarding adımları). Bu sayfalar genellikle cihazda çok daha az iş ile sunulabilir.
Daha sessiz bir tuzak, kolaylık için büyük bir UI kütüphanesi eklemektir; bunun prod build maliyetini ölçmeden yapmak tehlikelidir. Kolaylık geçerlidir; ama ekstra JavaScript, ekstra CSS ve orta seviye telefonlarda yavaşlayan etkileşimler için ne ödediğinizi bilerek karar verin.
Son olarak, yaklaşımları net sınırlar koymadan karıştırmak hata ayıklaması zor uygulamalar yaratır. Uygulamanın yarısı derleyici tarafından üretilmiş güncellemelere dayanırken diğer yarısı runtime sihrine güveniyorsa, belirsiz kurallar ve kafa karıştırıcı hatalar ortaya çıkar.
Gerçek ekiplerde işe yarayan birkaç kural:
3 kişilik bir ekip bir planlama ve faturalama SaaS'i geliştiriyor. İki yüzü var: halka açık pazarlama sitesi (landing, fiyatlandırma, dökümantasyon) ve kimlik doğrulamaya sahip dashboard (takvim, faturalar, raporlar, ayarlar).
Çalışma zamanı-öncelikli bir yol seçersek, UI değişiklikleri hızlı olduğu için runtime-ağır bir kurulum seçerler. Dashboard büyük bir client-side uygulama olur; yeniden kullanılabilir bileşenler, bir durum kütüphanesi ve zengin etkileşimler var. İterasyon hızlıdır. Zamanla ilk yükleme orta seviye telefonlarda ağır hissetmeye başlar.
Derleyici-öncelikli bir yol seçersek, client JavaScript'ini azaltmak için daha fazla işi build zamanına kaydıran bir framework seçerler. Yaygın akışlar (dashboard açma, sekme değiştirme, arama) daha hızlı hissedilir. Takas: ekip desenler ve araçlar konusunda daha dikkatli olmalı ve bazı kolay runtime hileleri doğrudan kullanmak o kadar basit olmayabilir.
Değişimi tetikleyen nadiren zevktir. Genelde gerçek hayat baskısıdır: yavaş sayfalar kayıtları düşürür, daha fazla kullanıcı düşük kaliteli cihazlarda gelir, kurumsal alıcılar öngörülebilir bütçeler ister, dashboard sürekli açık olduğunda bellek önem kazanır veya destek biletleri gerçek ağlarda yavaşlıktan bahseder.
Hibrit bir seçenek genelde kazanır. Pazarlama sayfalarını hafif tutun (server-rendered veya büyük ölçüde statik, minimal istemci kodu) ve interaktivitenin değeri olduğu dashboard'da daha ağır runtime kabul edin.
Karar adımlarını kullanarak: kritik yolculukları (kayıt, ilk fatura, haftalık raporlama) adlandırırlar, orta seviye bir telefonda ölçerler, bir bütçe koyarlar ve hibrit seçerler. Pazarlama sayfaları ve paylaşılan bileşenler için derleyici-öncelikli varsayılan, sadece deney hızını gerçekten artırdığı yerlerde runtime-ağır kullanılır.
Bu fikirleri gerçek kılmanın en kolay yolu kısa bir haftalık döngüdür.
15 dakikalık bir tarama ile başlayın: bundle boyutu artıyor mu, hangi rotalar yavaş hissettiriyor, o rotalardaki en büyük UI parçaları neler (tablolar, grafikler, editörler, haritalar) ve en çok hangi bağımlılıklar ağırlık katıyor. Sonra yığını değiştirmeden çözebileceğiniz bir darboğaz seçin.
Bu hafta için küçük tutun:
Seçimleri geri alınabilir tutmak için rotalar ve özellikler arasında net sınırlar çizin. Sonradan değiştirebileceğiniz modülleri tercih edin (grafikler, zengin metin editörleri, analitik SDK'ları) ki tüm uygulamayı ellemeye gerek kalmasın.
Çoğunlukla sorun sadece ağ değildir — asıl neden çalışma zamanı maliyeti: tarayıcının JavaScript indirmesi, ayrıştırması ve çalıştırması, UI oluşturması ve her güncellemede ekstra işler yapmasıdır.
Bu yüzden JavaScript yükü büyüdüğünde uygulama iyi bir dizüstü bilgisayarda bile “ağır” hissedebilir.
Her iki yaklaşım da aynı amaca hizmet eder (istemcide daha az iş yapmak), ama mekanizma farklıdır.
Bu, framework'ün bileşenlerinizi derleme zamanında analiz edebilmesi ve büyük, genel amaçlı bir UI motoru göndermek yerine uygulamanıza özel kod üretmesi demektir.
Pratik fayda genellikle daha küçük bundle'lar ve etkileşimler sırasında (tıklamalar, yazma, kaydırma) daha az CPU işi olur.
Şununla başlayın:
Aynı kullanıcı akışını her seferinde ölçün ki build'leri karşılaştırabilesiniz.
Evet — ama önce nerede zaman harcandığını doğrulayın. Yavaş API'ler, büyük görseller, fazla font veya üçüncü taraf betikler varken framework değiştirmek temel sorunu çözmez.
Framework seçimi bir kaldıraçtır; önce zamanın ağda mı, JavaScript CPU'da mı, render'da mı yoksa backend'de mi gittiğini doğrulayın.
Çalışma zamanı daha fazla esneklik sağlar ve yine de değerli olabilir:
Çalışma zamanı gerçekten darboğaz değilse, ek kolaylık fazladan byte'lara değer olabilir.
Basit bir varsayılan:
Hibrit genelde en iyi sonucu verir; sınırları yazılı hale getirin ki uygulama karışmasın.
Kullanıcı hissini engellemeden ekip için makul bir bütçe belirleyin. Örnek:
Bütçeler rehberdir; mükemmel puan peşinde koşmak değildir.
Hydration, sunucu tarafından oluşturulan bir sayfanın tarayıcıda etkileşimli hale getirilmesi; event handler'ların bağlanması ve yeterli durumun yeniden kurulması işlemidir.
Çok fazla hydrate ederseniz, HTML hızlı görünse bile ilk yükleme ağır hissedebilir. Build zamanı araçları gerçekten etkileşim gerektiren kısımları işaretleyerek bu işi azaltabilir.
İyi bir “ince dilim” prototip şunları içerir:
Koder.ai bu dilimi sohbet üzerinden inşa etmenize yardımcı olabilir ve kaynağı dışa aktarmanıza olanak tanır; böylece tam bir yeniden yazıma gerek kalmadan yaklaşımları erken ölçebilirsiniz.