İçeriğe geç
Muhammet Şafak
en

Chart.js'i nasıl import ettiğin, ziyaretçiye kaç kilobayt gönderdiğini belirliyor

`chart.js/auto` ile seçmeli `Chart.register()` arasındaki fark, gerçek bir üretim derlemesinde kaç kilobayt?

Bulgu

Seçmeli register, `chart.js/auto` yerine 9,7 kB gzip tasarruf ettiriyor (67,8 → 58,1 kB, %14,3). Asıl büyük düşüş kütüphanenin kendisinde değil, hiç kullanılmayan controller'ları dışarıda bırakmakta: yalnız çubuk grafiği kaydeden bir sayfa 46,0 kB'a iniyor — auto'nun üçte ikisi.

Seçmeli register
58,1 kB -14,3%
chart.js/auto
67,8 kB
Yalnız çubuk
46,0 kB -33,9%
Sayfanın ada maliyeti
65,3 kB

Yöntem

Aynı depo, aynı grafik bileşeni ve aynı içerik dosyasıyla dört ayrı `npx astro build` koşuldu; her koşuda yalnız `chart-render.ts`'in import/register satırları değiştirildi. Ölçülen şey Rolldown'ın ürettiği `dist/_astro/chart-render.*.js` parçasının `gzip -9` boyutudur. Derleme deterministik olduğu için tek koşu yeterli: aynı girdi aynı baytı üretti, dört strateji de iki kez koşulup aynı sonuç doğrulandı.

Yüksek güven Tekrarlı ölçüm, denetimli ortam, ham veri paylaşıldı.
Ölçüm tarihi

28 gün önce ölçüldü

Yayın
Güncelleme

Ortam

Astro
7.1.3
Chart.js
4.5.1
Bundler
Rolldown (Astro 7 varsayılanı)
Node
24.18.0
İşletim sistemi
macOS (Darwin 25.6)
Sıkıştırma
gzip -9

Teknolojiler

Chart.js Astro Rolldown Preact

Tekrarlamak için

npx astro build && gzip -9 -c dist/_astro/chart-render.*.js | wc -c

Bu sitede yıllardır tek bir kural vardı: zorunlu istemci JS yok. Research bölümünü açarken o kuralı bilerek deldim — çok serili bir ölçüm, tooltip’i olmayan bir grafikte okunmuyor. Ama “deldim” ile “önemsedim” arasındaki fark, gönderilen baytı ölçüp ölçmediğinde ortaya çıkıyor.

Chart.js’in dokümantasyonu iki yol gösteriyor. Kısa yol:

import Chart from 'chart.js/auto';

Uzun yol:

import { Chart, BarController, BarElement, CategoryScale, LinearScale } from 'chart.js';
Chart.register(BarController, BarElement, CategoryScale, LinearScale);

İkisi de çalışıyor. Sorum şuydu: aradaki fark, gerçek bir derlemede ölçülebilir bir sayı mı, yoksa mikro-optimizasyon mu?

Neyi ölçtüm

Sentetik bir bundler kurmadım — çünkü ölçmek istediğim şey “Chart.js ne kadar küçülebilir” değil, bu depo ne kadar gönderiyor. O yüzden dört koşunun dördü de sitenin kendi astro build hattından geçti: aynı MDX kaydı, aynı grafik bileşeni, aynı Preact adası. Koşular arasında değişen tek şey src/components/research/chart-render.ts dosyasının ilk on satırıydı.

Chart.js parçasının gzip boyutu, import stratejisine göre

Dördü de aynı grafiği çiziyor. Fark yalnızca hangi controller ve eklentinin pakete girdiğinde.

kB düşük olan iyi Kaynak: astro build çıktısı, dist/_astro/chart-render.*.js, gzip -9

Veri tablosu
astro build çıktısı, dist/_astro/chart-render.*.js, gzip -9
Seri chart.js/autobar+line+tooltip+fillerbar+line, eklentisizyalnız bar
gzip 67,8 kB58,1 kB51,2 kB46 kB

Grafik tarayıcıda çizilir; aşağıdaki tablo aynı veriyi taşır.

Ham (sıkıştırılmamış) boyutlarla birlikte tablo şöyle:

Strateji Ham gzip auto’ya göre
chart.js/auto 204.965 B 69.466 B
bar + line + Tooltip + Filler bu sitede kullanılan 172.313 B 59.538 B −9.928 B (%14,3)
bar + line, eklentisiz 149.793 B 52.378 B −17.088 B (%24,6)
yalnız bar 134.868 B 47.114 B −22.352 B (%32,2)
Ham boyut ile gzip boyutu aynı yönde ama aynı oranda hareket etmiyor: sıkıştırma, silinen kodun bir kısmını zaten sıkıştırıyordu.

Sayı ne söylüyor

Seçmeli register, auto’ya göre 9,7 kB gzip kazandırdı. Bu, dokümantasyonun “tree-shaking destekleniyor” cümlesinin arkasındaki gerçek rakam — ve tek başına bakıldığında mütevazı: %14,3.

Asıl bilgi ikinci ve üçüncü satırda. Tooltip ile Filler eklentilerini düşürmek 7,2 kB daha götürüyor; çizgi grafiği hiç kullanmayan bir sayfa 5,3 kB daha kazanıyor. Yani maliyetin çoğu kütüphanenin çekirdeğinde değil, kullanılmayan çizim türlerinde. auto’nun yaptığı şey de tam olarak bu: hepsini kaydediyor.

Sayfanın tamamı ne ödüyor

Chart.js parçası tek başına anlamlı değil; ziyaretçi ada hidratlandığında şunları indiriyor:

Parça gzip Ne
chart-render 58,1 kB Chart.js + tema köprüsü
preact 4,9 kB çalışma zamanı çekirdeği
hooks 0,8 kB useRef / useEffect
client 0,8 kB @astrojs/preact istemci köprüsü
ChartIsland 0,6 kB bileşenin kendisi
Toplam 65,3 kB
Ölçüm, tek grafikli bir research sayfasının ada maliyetidir. `signals.module` parçası derlemede üretiliyor ama sayfa onu hiç istemiyor — @astrojs/preact yalnız `data-preact-signals` varsa yüklüyor.

Framework tarafı toplamın %10’undan azı (6,3 kB). Yani Preact yerine React seçmek burada asıl fark yaratmazdı demek yanlış olur — tam tersi: React’in react-dom maliyeti tek başına Chart.js’e yaklaşıyor. Ama bu ayrı bir ölçüm, ayrı bir kayıt.

Ne yaptım

chart-render.ts bu dört satırla açılıyor ve auto girişini hiç kullanmıyor:

import {
  BarController, BarElement, LineController, LineElement, PointElement,
  CategoryScale, LinearScale, Tooltip, Filler,
} from 'chart.js';

Chart.register(
  BarController, BarElement, LineController, LineElement, PointElement,
  CategoryScale, LinearScale, Tooltip, Filler,
);

Legend listede yok: gösterge sunucuda HTML olarak basılıyor. Böylece hem sitenin kendi token’larıyla biçimleniyor hem de JavaScript hiç çalışmasa bile yerinde duruyor — bu sayfadaki grafiğin altındaki “Veri tablosu” katlamasıyla aynı mantık.

İlgili yazılar

Paylaş:

Güncelleme:

Diğer Kayıtlar

Tüm kayıtlar

PHP ile Go'yu aynı OAuth2 API'de ölçtüm: 10.000 yazmada fark yok, 50.000 okumada var

Her istekte OAuth2 token'ı doğrulayıp PostgreSQL'e yazan ya da okuyan aynı API, dört çekirdekte PHP-FPM, FrankenPHP worker ve Go ile saniyede 10.000 yazmayı ve 50.000 okumayı kaç CPU'yla karşılıyor?

Bulgu

Saniyede 10.000 yazmada üç aday da hedefi beş tekrarın beşinde tutturdu, p99 üçünde de 2,5 ms'yi aşmadı: bu yükte dil bir kapasite kalemi değil. Saniyede 50.000 okumayı dört çekirdekte yalnız Go tutturdu (p99 6,45 ms); PHP-FPM 23.528'de, FrankenPHP 22.859'da kaldı. İstek başına CPU okumada Go'da 64, FrankenPHP'de 117, PHP-FPM'de 168 mikrosaniye. 50.000 okuma için instance hesabı Go'ya 3,4, iki PHP adayına 8,2–8,8 çekirdek yazdırıyor. FrankenPHP'nin CPU tasarrufu kapasiteye dönmüyor: doygunken dört çekirdeğin birini boşta bırakıyor.

bugün ölçüldü

Orta güven

Partial index on beş dakikada üç yüz beş kat şişti — ve autovacuum bir kez bile gelmedi

Sürekli churn altındaki bir kuyruk tablosunda partial index'in küçüklüğü kalıcı mı, ve varsayılan autovacuum ayarları ona yetişiyor mu?

Bulgu

Canlı küme beş bin satırda sabit dururken partial index 0,125 MB'dan 38,2 MB'a çıktı — üç yüz beş kat. Küçüklüğü canlı satır sayısından geliyor, şişme hızı iş hacminden, ve ikisi arasında hiçbir bağ yok. Composite index oransal olarak daha az şişti (%42) ama mutlak olarak daha çok (+126 MB) ve şişerken belleğe sığmayı bıraktı: gecikmesi 0,52 ms'den 61 saniyeye çıktı, kuyruğu 126 bine tırmandı. On beş dakikada 1,75 milyon ölü satır birikti ve autovacuum **bir kez bile koşmadı** — varsayılan eşik tablonun tamamına göre ölçekleniyor (50 + 0,2 × 10 milyon ≈ 2 milyon), churn ise küçük canlı kümede oluyor.

25 gün önce ölçüldü

Yüksek güven

Laravel'in preload eğrisi: 123 dosya, 1.912 dosyadan sekiz kat fazla kazandırıyor

Laravel için elle seçilmiş bir preload nereye kadar iner, ve her dilim ne kadar açılış bedeline mal olur?

Bulgu

Eğri hacimle orantılı değil. İlk 1.592 dosya (Laravel çekirdeği) 30 ms kazandırıyor ve açılışa 1,2 saniye ekliyor. Sonraki 1.094 Symfony dosyası 9,5 ms kazandırıyor, bedava. Ondan sonraki **123 dosya** (psr, carbon) 15,7 ms kazandırıyor — kendinden önceki 1.094 dosyadan fazla. Ve son 1.912 dosya yalnız 1,8 ms kazandırıp açılışa 1,2 saniye daha yazıyor. Yani önceki kaydın tavan olarak ölçtüğü "hepsini derle", eğrinin başlangıç noktası dışındaki en kötü fiyat/performans bölgesi: 2.809 dosyada durmak 12,77 ms ve 1.514 ms açılış verirken, 4.721 dosya 10,96 ms için 2.691 ms istiyor.

25 gün önce ölçüldü

Yüksek güven

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi