Variable font di produksi: tradeoff yang jarang dibicarakan
Variable font dapat menyederhanakan font stack dan meningkatkan fleksibilitas desain, tetapi bukan kemenangan performa otomatis.
Daftar isi
- Variable font bukan kompresi font ajaib
- Keunggulan yang jelas: lebih sedikit file, type yang lebih ekspresif
- Tradeoff tersembunyi pertama: satu file bisa lebih besar daripada file yang benar-benar Anda butuhkan
- Kasus A: situs marketing dengan banyak weight
- Kasus B: aplikasi produk dengan regular dan bold saja
- Tradeoff kedua: subsetting menjadi lebih penting, bukan kurang penting
- Tradeoff ketiga: CSS bisa menjadi terlalu pintar
- Tradeoff keempat: perbedaan rendering tetap ada
- Tradeoff kelima: caching bisa menguntungkan atau merugikan
- Tradeoff keenam: Lighthouse tidak akan menjelaskan seluruh cerita
- Checklist produksi yang praktis
- 1. File statis apa yang digantikannya?
- 2. Axis mana yang akan Anda ekspos?
- 3. Bisakah Anda melakukan subset dengan aman?
- 4. Apakah metrik fallback sudah dikonfigurasi?
- 5. Apakah `font-display` disengaja?
- 6. Apakah Anda sudah menguji perangkat kelas bawah?
- 7. Apakah ada rencana rollback?
- Kapan variable font menjadi pilihan produksi yang baik
- Aturan praktis produksi
Variable font bukan kompresi font ajaib
Variable font sering diperkenalkan sebagai jawaban rapi untuk tipografi web: satu file, banyak weight, lebih sedikit request, sistem desain yang lebih mulus. Klaim itu secara umum benar, tetapi belum lengkap.
Di produksi, variable font bukan sekadar mengganti enam file dengan satu file; ia lebih mirip mengadopsi runtime tipografi baru. Anda mendapat kontrol ekspresif atas weight, width, slant, optical size, dan kadang axis kustom. Anda juga mewarisi keputusan baru tentang ukuran file, rendering browser, perilaku fallback, tata kelola desain, dan pengukuran performa.
Hasilnya bisa sangat baik. Namun bisa juga lebih buruk daripada setup statis yang digantikannya.
Jika situs Anda saat ini mengirim lima weight dari family yang sama, variable font yang di-subset dengan baik mungkin mengurangi request dan menyederhanakan CSS. Jika situs Anda hanya mengirim satu weight regular dan satu weight bold, variable font mungkin menambah byte demi fleksibilitas yang tidak pernah dirasakan pengguna. Itulah tradeoff produksi yang sering dilewatkan orang.
Untuk baseline yang lebih luas tentang strategi pemuatan font, panduan kami tentang mengapa web font masih menjadi kemenangan performa termudah di sebagian besar situs adalah bacaan pendamping yang berguna. Variable font tidak mengubah dasarnya: kirim lebih sedikit byte, kurangi penundaan render, dan buat teks fallback tetap layak.
Keunggulan yang jelas: lebih sedikit file, type yang lebih ekspresif
Setup font statis tradisional biasanya terlihat seperti ini:
- Regular 400
- Italic 400
- Medium 500
- Semibold 600
- Bold 700
- Mungkin face display terpisah
Setiap file diunduh, di-cache, dan di-render secara terpisah. Jika halaman menggunakan beberapa weight di bagian awal layar, request cepat menumpuk.
Variable font dapat menggabungkan beberapa weight tersebut ke dalam satu file. Alih-alih memuat Inter-Regular.woff2, Inter-Medium.woff2, dan Inter-Bold.woff2, Anda memuat satu file variable dan menggunakan font-weight: 400 700 di sepanjang rentang kontinu.
Itu membuka manfaat nyata:
- Lebih sedikit file font untuk dikelola
- Interpolasi antar-weight yang lebih konsisten
- Tipografi responsif yang lebih presisi
- Sistem tema yang lebih mudah
- Penyelarasan design token yang lebih baik
Untuk sistem desain, kontrol ini sangat berguna. Label tombol dapat menggunakan 580 alih-alih dipaksa ke 500 atau 600. Judul kartu yang sempit dapat menggunakan axis width yang sedikit condensed jika font mendukungnya. Headline display dapat menggunakan optical sizing ketika tersedia.
Namun keberadaan kontrol tersebut bukan berarti Anda harus menggunakan semuanya.
Tradeoff tersembunyi pertama: satu file bisa lebih besar daripada file yang benar-benar Anda butuhkan
Variable font berisi data interpolasi untuk sebuah ruang desain. Ruang desain itu memiliki biaya. Satu file variable font bisa lebih besar daripada satu atau dua file font statis.
Itu bukan masalah ketika ia menggantikan banyak file. Itu menjadi masalah ketika ia menggantikan stack yang sudah terkendali.
Pertimbangkan dua kasus umum:
Kasus A: situs marketing dengan banyak weight
Situs menggunakan 300, 400, 500, 600, 700, dan italic di berbagai halaman. Variable font yang di-subset dengan cermat kemungkinan membantu. Ia mengurangi overhead request dan menyederhanakan pemeliharaan ke depan.
Kasus B: aplikasi produk dengan regular dan bold saja
Antarmuka menggunakan 400 dan 700, dengan system font sebagai fallback. Variable font mungkin menambah byte yang tidak perlu. Fleksibilitasnya menarik di Figma, tetapi tidak selalu berguna di browser.
Kesalahannya adalah membandingkan “satu file variable” dengan “banyak file statis teoretis”, bukan membandingkannya dengan file yang benar-benar digunakan halaman Anda saat ini.
Ukur byte font aktual yang dimuat pada template utama. Lalu uji versi variable dengan subset karakter yang sama dan strategi preload yang sama. Jangan berasumsi versi variable pasti menang.
Tradeoff kedua: subsetting menjadi lebih penting, bukan kurang penting
Variable font membuat subsetting lebih bernilai karena file dasarnya bisa berisi banyak hal: glyph, dukungan bahasa, fitur OpenType, beberapa axis, dan metadata.
Sebagian besar situs produksi tidak membutuhkan setiap glyph dalam sebuah font. Jika Anda hanya melayani bahasa Inggris, Anda mungkin tidak membutuhkan cakupan pan-Eropa penuh, Cyrillic, Greek, Vietnamese, dan setiap blok simbol. Jika Anda memang melayani banyak bahasa, Anda mungkin tetap menginginkan subset khusus bahasa alih-alih satu file universal.
Pendekatan praktisnya biasanya:
- Pertahankan subset Latin inti untuk sebagian besar pengguna.
- Tambahkan subset extended hanya ketika konten membutuhkannya.
- Gunakan
unicode-rangeagar browser memilih file yang tepat. - Pertahankan fallback statis untuk script yang jarang digunakan jika perlu.
Di sinilah variable font bisa menjadi canggung. Beberapa pipeline font mudah men-subset font statis tetapi salah menangani axis variable, hinting, atau metadata. Selalu verifikasi bahwa font keluaran tetap berperilaku benar di sepanjang rentang axis yang akan Anda gunakan.
Subset yang rusak lebih buruk daripada font besar. Ia gagal secara senyap: rendering aneh, glyph hilang, weight tidak konsisten, atau perubahan layout yang hanya muncul di locale tertentu.
Tradeoff ketiga: CSS bisa menjadi terlalu pintar
Variable font mengekspos axis melalui CSS. Axis standar seperti weight dan width dipetakan dengan rapi ke property seperti font-weight dan font-stretch. Axis kustom sering menggunakan font-variation-settings.
Kekuatan itu menggoda tim untuk menjadi terlalu cerdik:
.card-title {
font-variation-settings: "wght" 623, "wdth" 92;
}
Ini mungkin valid secara teknis, tetapi jarang menjadi interface sistem desain yang baik. Nilai axis acak yang tersebar di CSS sulit ditinjau, sulit di-refactor, dan mudah disalahgunakan.
Lebih baik gunakan design token atau utility bernama:
:root {
--font-weight-body: 400;
--font-weight-heading: 680;
--font-width-compact: 94;
}
.card-title {
font-weight: var(--font-weight-heading);
font-stretch: var(--font-width-compact);
}
Gunakan property CSS standar jika memungkinkan. Simpan font-variation-settings untuk axis yang tidak memiliki property tingkat lebih tinggi.
Berhati-hatilah juga dengan animasi. Menganimasikan weight atau width bisa terasa elegan dalam dosis kecil, tetapi juga dapat menyebabkan reflow, instabilitas visual, dan pekerjaan yang tidak perlu pada perangkat berdaya rendah. Tipografi tidak seharusnya menjadi taman bermain motion hanya karena font memungkinkannya.
Tradeoff keempat: perbedaan rendering tetap ada
Dukungan browser modern untuk variable font sudah kuat, tetapi rendering tidak identik di semua tempat. Rasterizer teks sistem operasi, engine browser, antialiasing, dan font hinting semuanya memengaruhi hasil.
Weight variable font 500 mungkin tidak tampak persis seperti file statis 500 dari family yang sama. Pada beberapa family, instance statis disetel secara manual, sementara instance variable hasil interpolasi dihasilkan secara matematis. Pada ukuran kecil, perbedaan itu bisa berarti.
Ini sangat relevan untuk body text, navigasi, tabel padat, dan label UI. Semakin berat antarmuka Anda pada teks, semakin penting menguji kondisi membaca nyata, bukan hanya tipografi hero.
Jika Anda meninjau ulang type system saat beralih ke variable font, mulailah dari keterbacaan, bukan kebaruan. Panduan praktis kami untuk type yang mudah dibaca di web modern membahas pilihan yang kurang glamor—panjang baris, ukuran, kontras, spacing—yang biasanya lebih penting daripada memiliki 1.000 weight font yang tersedia.
Tradeoff kelima: caching bisa menguntungkan atau merugikan
Satu file variable font dapat di-cache sekali dan digunakan ulang di berbagai halaman. Itu baik.
Namun jika file tersebut besar dan memblokir render, kunjungan pertama membayar biaya penuh di awal. Font statis kadang dapat dimuat lebih selektif: regular untuk body text terlebih dahulu, bold kemudian, display hanya di halaman yang membutuhkannya.
Tidak ada jawaban universal. Setup yang tepat bergantung pada pola traffic:
- Apakah pengguna mengunjungi banyak halaman per sesi? File variable bersama mungkin sepadan.
- Apakah pengguna masuk ke satu artikel lalu pergi? File statis yang lebih kecil mungkin lebih baik.
- Apakah homepage hanya membutuhkan satu weight? Jangan preload ruang desain besar untuk halaman mendatang.
- Apakah aplikasi berada di balik login dengan kunjungan ulang yang sering? Penggunaan ulang cache menjadi lebih bernilai.
Preloading juga membutuhkan kendali. Preload font yang dibutuhkan untuk teks di bagian awal layar, bukan setiap font yang mungkin digunakan. Preload adalah klaim prioritas. Terlalu banyak klaim prioritas berubah menjadi noise.
Tradeoff keenam: Lighthouse tidak akan menjelaskan seluruh cerita
Alat performa dapat menunjukkan byte font yang tidak terpakai, request yang memblokir render, layout shift, dan biaya jaringan. Alat itu tidak dapat memberi tahu apakah fleksibilitas visual sepadan dengan payload.
Migrasi variable font harus dinilai dengan beberapa sinyal:
- Total byte font yang ditransfer pada tampilan pertama
- Jumlah request font
- Dampak Largest Contentful Paint
- Cumulative Layout Shift akibat font swap
- Perilaku caching pada tampilan ulang
- Kecocokan visual dengan desain yang disetujui
- Keterbacaan pada ukuran umum
Jika sebuah laporan menjadi merah setelah migrasi font, jangan panik. Masalahnya mungkin urutan preload, metrik fallback, atau ketidakcocokan subset, bukan variable font itu sendiri. Panduan kami tentang cara membaca laporan Lighthouse tanpa panik relevan di sini: perlakukan skor lab sebagai petunjuk diagnostik, bukan vonis.
Checklist produksi yang praktis
Sebelum mengirim variable font, jawab pertanyaan-pertanyaan ini:
1. File statis apa yang digantikannya?
Daftar file aktual yang digunakan di produksi, bukan apa yang secara teoretis didukung sistem desain. Sertakan weight, style, set karakter, dan template halaman.
2. Axis mana yang akan Anda ekspos?
Sebagian besar tim sebaiknya mengekspos weight, mungkin width, dan jarang lebih dari itu. Optical size bisa berguna jika font mendukungnya dengan baik, tetapi uji terlebih dahulu. Axis kustom harus memiliki tujuan produk yang jelas.
3. Bisakah Anda melakukan subset dengan aman?
Jalankan pemeriksaan regresi visual setelah subsetting. Uji karakter beraksen, tanda baca, simbol mata uang, ikon jika disertakan, dan semua bahasa yang didukung.
4. Apakah metrik fallback sudah dikonfigurasi?
Gunakan alat CSS modern seperti size-adjust, ascent-override, descent-override, dan line-gap-override jika sesuai. Metrik fallback yang baik mengurangi layout shift selama pemuatan font.
5. Apakah font-display disengaja?
font-display: swap umum digunakan, tetapi tidak selalu sempurna. Ia meningkatkan visibilitas teks tetapi dapat membuat swap yang terlihat jelas jika metrik fallback buruk. optional dapat bekerja untuk font non-kritis ketika menghindari gangguan lebih penting daripada tipografi brand yang terjamin.
6. Apakah Anda sudah menguji perangkat kelas bawah?
Font yang terasa baik-baik saja di laptop developer mungkin di-render lambat di hardware Android murah. Uji setidaknya satu perangkat berdaya rendah atau profil yang di-throttle.
7. Apakah ada rencana rollback?
Perubahan font memengaruhi setiap halaman. Pertahankan setup statis lama cukup lama agar dapat kembali dengan cepat jika muncul masalah rendering, lokalisasi, atau performa.
Kapan variable font menjadi pilihan produksi yang baik
Variable font biasanya layak dipertimbangkan ketika:
- Anda menggunakan tiga weight atau lebih dari family yang sama.
- Anda memelihara sistem desain di banyak template.
- Anda membutuhkan tipografi responsif dengan kontrol width atau optical-size.
- Pengguna lazim menjelajahi beberapa halaman per sesi.
- Anda dapat melakukan subset dan menguji pipeline font dengan benar.
Variable font kurang meyakinkan ketika:
- Anda hanya membutuhkan regular dan bold.
- File variable jauh lebih besar daripada setup Anda saat ini.
- Font memiliki interpolasi yang buruk pada ukuran teks.
- Tim Anda akan menyebarkan nilai axis sembarang di CSS.
- Anda tidak dapat menguji lokalisasi dan perilaku fallback.
Pandangan yang jernih adalah ini: variable font adalah kapabilitas, bukan optimisasi secara default. Ia memberi imbalan kepada tim yang sudah mengelola font dengan cermat. Ia menghukum tim yang memperlakukan tipografi sebagai dekorasi dan pemuatan font sebagai renungan belakangan.
<!-- tool-cta:start -->
💡 Coba ini: Saat membuat subset dan mengemas font variabel untuk produksi, Webfont Generator menghasilkan keluaran WOFF2 dengan CSS yang sesuai.
<!-- tool-cta:end -->
Aturan praktis produksi
Gunakan variable font ketika ia mengurangi kompleksitas atau memungkinkan hasil desain yang jelas. Jangan menggunakannya hanya karena “satu file” terdengar lebih rapi.
Implementasi produksi terbaik cenderung membosankan: satu variable font yang di-subset dengan cermat, sejumlah kecil nilai axis yang disetujui, fallback yang masuk akal, preloading yang terkendali, dan pengujian di perangkat nyata. Itu tidak semenarik kemungkinan tipografis tanpa batas. Namun jauh lebih mungkin membuat situs Anda lebih baik.