İç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

25 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

Partial index on beş dakikada üç yüz seksen 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,1 MB'dan 38,2 MB'a çıktı — üç yüz seksen 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.

22 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.

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

Yüksek güven

Partial index kuyruk tablosunu kırk bir kat küçültüyor — planner onu seçtiği sürece

Milyonlarca ölü satır biriken bir Postgres kuyruk tablosunda partial index ne kazandırıyor, ve planner onu ne zaman seçmiyor?

Bulgu

10 milyon ölü satırda partial index saniyede 11.537 iş çıkarıyor, index'siz tablo 7. Composite index'le hız farkı küçük (%6,9) ama boyut farkı değil: 7,6 MB'a karşı 310,4 MB, ve partial tabloyla birlikte büyümüyor çünkü yalnız 5.000 canlı satırı indeksliyor. Asıl bulgu bunların hiçbiri: planner hazırlanmış bir deyimde generic plana geçtiği anda partial index tamamen devre dışı kalıyor — 11.752 tps 7'ye, 0,68 ms 1,1 saniyeye düşüyor. Bin altı yüz yetmiş üç kat. Aynı koşulda composite index etkilenmiyor.

22 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