Missed the action at the 2018 Chrome Dev Summit? Catch up with our playlist on the Google Chrome Developers channel on YouTube. Watch now.

Optimasi Font Web

Tipografi adalah hal mendasar bagi terciptanya desain, branding, keterbacaan, dan aksesibilitas yang baik. Webfont memungkinkan semua hal di atas dan juga yang lainnya: teks dapat dipilih, ditelusuri, di-zoom, dan ramah untuk DPI yang tinggi, menyediakan rendering teks yang konsisten dan tajam apa pun ukuran dan resolusinya. Webfont sangat penting bagi desain yang baik, UX, dan kinerja.

Optimalisasi webfont merupakan bagian penting dari strategi kinerja keseluruhan. Setiap font merupakan sumber daya tambahan, dan sebagian font mungkin memblokir rendering teks, namun karena laman menggunakan webfont tidak berarti bahwa laman harus merender lebih lambat. Sebaliknya, font yang dioptimalkan, dipadukan dengan strategi yang cermat mengenai cara webfont dimuat dan diterapkan pada laman akan dapat membantu mengurangi ukuran laman total, dan memperbaiki waktu rendering laman.

Anatomi webfont

TL;DR

  • Font Unicode dapat berisi ribuan glyph.
  • Ada empat format font: WOFF2, WOFF, EOT, dan TTF.
  • Sebagian format font membutuhkan penggunaan kompresi GZIP.

Webfont adalah sekumpulan glyph, dan masing-masing glyph merupakan bentuk vektor yang menggambarkan huruf atau simbol. Hasilnya, dua variabel sederhana menentukan file ukuran font tertentu: kompleksitas jalur vektor dari setiap glyph dan jumlah gylph dalam font tertentu. Misalnya, Open Sans, yang merupakan salah satu webfont terpopuler, mengandung 897 glyph, yang meliputi karakter Latin, Yunani, dan Cyrilic.

Tabel glyph font

Saat memilih font, penting untuk mempertimbangkan himpunan karakter apa yang didukung. Jika Anda perlu melokalkan materi laman Anda ke beberapa bahasa, Anda harus menggunakan font yang bisa menampilkan tampilan dan pengalaman yang konsisten ke pengguna. Misalnya, jenis font Noto dari Google bertujuan untuk mendukung semua bahasa dunia. Akan tetapi, ukuran total dari Noto dengan semua bahasa disertakan, menghasilkan unduhan 130 MB+ ZIP.

Jelaslah, menggunakan font pada web memerlukan rekayasa yang saksama guna memastikan bahwa tipografi tidak menghalangi kinerja. Syukurlah platform web menyediakan semua kenyamanan yang diperlukan, dan di bagian selanjutnya dari panduan ini memberikan pandangan langsung tentang cara terbaik memperoleh yang terbaik dari keduanya.

Format webfront

Dewasa ini ada empat format kontainer font yang digunakan di web: EOT, TTF, WOFF, dan WOFF2. Sayangnya meskipun terdapat berbagai pilihan yang luas, tidak ada satu format universal yang berfungsi di seluruh browser lama dan baru: EOT adalah hanya IE, TTF memiliki dukungan IE sebagian, WOFF menikmati dukungan terluas namun tidak tersedia di beberapa browser lawas, dan dukungan WOFF 2.0 merupakan karya yang masih terus dikembangkan untuk banyak browser.

Jadi, apa arti semua ini bagi kita? Tidak ada satu format tunggal yang berfungsi di semua browser, yang berarti bahwa kita perlu menyerahkan beberapa format untuk menghasilkan pengalaman yang konsisten:

  • Menyajikan varian WOFF 2.0 ke browser yang mendukungnya.
  • Menyajikan varian WOFF ke sebagian besar browser.
  • Menyajikan varian TTF ke browser Android lawas (di bawah 4.4).
  • Menyajikan varian EOT ke browser IE lawas (di bawah IE9).

Mengurangi ukuran font dengan kompresi

Font merupakan koleksi glyph, masing-masing dengan seperangkat jalur yang menjelaskan format huruf. Masing-masing glyph berbeda namun bagaimana pun juga mengandung informasi serupa yang bisa dikompresikan dengan GZIP, atau kompresor yang kompatibel:

  • Format EOT dan TTF tidak dikompresi secara default. Pastikan bahwa server Anda telah dikonfigurasikan untuk menerapkan kompresi GZIP saat mengirimkan format ini.
  • WOFF memiliki kompresi bawaan. Pastikan bahwa kompresor WOFF Anda menggunakan setelan kompresi optimal.
  • WOFF2 menggunakan algoritme pra-pemrosesan dan kompresi khusus untuk mencapai ~30% pengurangan ukuran file dibandingkan format lain. Untuk informasi selengkapnya, lihat laporan evaluasi WOFF 2.0.

Terakhir, perlu diperhatikan bahwa sebagian format font mengandung metadata tambahan, misalnya informasi petunjuk font dan kerning mungkin tidak diperlukan di beberapa platform, yang memungkinkan optimalisasi ukuran file lebih lanjut. Lihatlah kompresor font Anda untuk opsi optimalisasi yang tersedia, dan jika Anda mengambil rute ini, pastikan bahwa Anda memiliki infrastruktur yang sesuai untuk menguji dan mengirimkan font yang telah dioptimalkan ini ke setiap browser. Misalnya, Google Fonts mempertahankan 30+ varian yang dioptimalkan untuk setiap font dan secara otomatis mendeteksi dan mengirimkan varian optimal untuk setiap platform dan browser.

Mendefinisikan jenis font dengan @font-face

TL;DR

  • Gunakan petunjuk format() untuk menetapkan format font.
  • Subset font Unicode besar untuk meningkatkan kinerja. Gunakan subset rentang unicode dan berikan fallback subset manual untuk browser yang lebih lawas.
  • Kurangi jumlah varian font gaya untuk meningkatkan kinerja rendering laman dan teks.

@font-face CSS at-rule memungkinkan Anda untuk mendefinisikan sumber daya lokasi font tertentu, karakteristik gayanya, dan titik kode Unicode yang harus digunakannya. Paduan deklarasi @font-face seperti itu dapat digunakan untuk mengonstruksikan "jenis font" yang akan digunakan browser untuk mengevaluasi sumber daya font mana yang harus diunduh dan diterapkan ke laman saat ini.

Pemilihan format

Setiap deklarasi @font-face menyediakan nama jenis font, yang bertindak sebagai grup logis dari beberapa deklarasi, properti font seperti gaya, bobot, dan regangan, serta deskriptor src yang menetapkan daftar lokasi prioritas untuk sumber daya font.

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome.woff2') format('woff2'), 
       url('/fonts/awesome.woff') format('woff'),
       url('/fonts/awesome.ttf') format('truetype'),
       url('/fonts/awesome.eot') format('embedded-opentype');
}

@font-face {
  font-family: 'Awesome Font';
  font-style: italic;
  font-weight: 400;
  src: local('Awesome Font Italic'),
       url('/fonts/awesome-i.woff2') format('woff2'), 
       url('/fonts/awesome-i.woff') format('woff'),
       url('/fonts/awesome-i.ttf') format('truetype'),
       url('/fonts/awesome-i.eot') format('embedded-opentype');
}

Pertama-tama, perhatikan bahwa contoh di atas menetapkan satu jenis Awesome Font dengan dua gaya (normal dan italic). masing-masing yang mengarahkan ke seperangkat sumber daya font. Pada gilirannya, setiap deskriptor src mengandung daftar prioritas, yang dipisah koma dari varian sumber daya:

  • Direktif local() memungkinkan kita untuk mereferensikan, membuat, dan menggunakan font yang dipasang secara lokal.
  • Direktif url() memungkinkan Anda untuk memuat font eksternal, dan dimungkinkan untuk petunjuk format() opsional yang mengindikasikan format dari font yang direferensikan oleh URL yang disediakan.

Ketika browser menentukan bahwa font diperlukan, browser menyatakan melalui daftar sumber daya yang diberikan dalam urutan yang ditetapkan serta mencoba memuat sumber daya yang sesuai. Misalnya, mengikuti contoh di atas:

  1. Browser melakukan layout laman dan menentukan varian font yang dibutuhkan untuk merender teks khusus pada laman.
  2. Untuk setiap font yang dibutuhkan pada browser, periksa apakah font tersedia secara lokal.
  3. Jika file tidak tersedia secara lokal, browser akan menyatakan definisi eksternal:
    • Jika petunjuk format ada pada browser, periksa apakah petunjuk itu mendukungnya sebelum memulai unduhan. Jika browser tidak dapat mendukung petunjuk, browser akan melanjutkan ke yang berikutnya.
    • Jika tidak ada petunjuk format, browser akan mengunduh sumber daya.

Kombinasi direktif lokal dan eksternal dengan petunjuk format yang sesuai memungkinkan kita untuk menetapkan semua font yang tersedia dan membiarkan browser menangani yang tersisa. Browser menentukan sumber daya mana yang dibutuhkan dan akan memilih format yang optimal.

Men-subset rentang unicode

Selain properti font seperti gaya, bobot, dan regangan, aturan @font-face memungkinkan kita untuk mendefinisikan seperangkat titik kode Unicode yang didukung oleh setiap sumber daya. Ini memungkinkan kita untuk memisahkan font Unicode besar ke dalam subset yang lebih kecil (Misalnya, Latin, Cyrillic, Yunani) dan hanya mengunduh glyph yang dibutuhkan untuk merender teks pada laman tertentu.

Deskriptor rentang unicode memungkinkan Anda untuk menetapkan daftar yang berbatas koma dari nilai-nilai rentang, masing-masing dapat berupa salah satu dari tiga format berbeda:

  • Titik kode tunggal (misalnya, U+416)
  • Rentang interval (misalnya, U+400-4ff): mengindikasikan awal dan akhir titik kode dari sebuah rentang
  • Rentang karakter pengganti (misalnya, U+4??): karakter '?' mengindikasikan digit heksadesimal

Misalnya, Anda dapat memisahkan jenis Awesome Font ke dalam subset Latin dan Jepang, masing-masing akan diunduh oleh browser sesuai kebutuhan:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2'), 
       url('/fonts/awesome-l.woff') format('woff'),
       url('/fonts/awesome-l.ttf') format('truetype'),
       url('/fonts/awesome-l.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-jp.woff2') format('woff2'), 
       url('/fonts/awesome-jp.woff') format('woff'),
       url('/fonts/awesome-jp.ttf') format('truetype'),
       url('/fonts/awesome-jp.eot') format('embedded-opentype');
  unicode-range: U+3000-9FFF, U+ff??; /* Japanese glyphs */
}

Penggunaan subset rentang unicode, dan file terpisah untuk setiap varian bergaya dari font memungkinkan kita untuk mendefinisikan jenis font komposit yang sama-sama lebih cepat dan lebih efisien untuk diunduh. Pengunjung hanya mengunduh varian dan subset yang diperlukan, dan tidak dipaksa mengunduh subset yang mungkin tidak pernah mereka lihat atau gunakan di laman.

Dengan demikian, ada satu masalah kecil dengan rentang unicode: belum semua browser mendukungnya. Sebagian browser cukup mengabaikan petunjuk rentang unicode dan akan mengunduh semua varian, sementara browser lain tidak dapat memroses sama sekali deklarasi @font-face. Untuk menanganinya, kita perlu kembali ke "subset manual" untuk browser lawas.

Karena browser lawas tidak cukup cerdas untuk memilih hanya subset yang diperlukan dan tidak dapat mengonstruksikan font komposit, Anda harus kembali untuk menyediakan satu sumber daya font yang berisi semua subset yang diperlukan dan menyembunyikan yang lainnya dari browser. Misalnya, jika laman hanya menggunakan karakter Latin, maka Anda bisa melepaskan glyph lain dan menyediakan subset khusus itu sebagai sumber daya yang berdiri sendiri.

  1. Bagaimana cara Anda menentukan subset yang diperlukan?
    • Jika browser mendukung subset rentang unicode, maka browser secara otomatis akan memilih subset yang tepat. Laman hanya perlu menyediakan file subset dan menetapkan rentang-unicode dalam aturan @font-face.
    • Jika browser tidak mendukung subset rentang unicode, maka laman harus menyembunyikan semua subset yang tidak perlu; yaitu, developer harus menyebutkan subset yang diperlukan.
  2. Bagaimana Anda menghasilkan subset font?
    • Gunakan sumber-terbuka alat (bantu) pyftsubset untuk men-subset dan mengoptimalkan font Anda.
    • Beberapa layanan font memungkinkan subset manual lewat parameter kueri khusus, yang dapat Anda gunakan untuk menetapkan secara manual subset yang dibutuhkan untuk laman Anda. Lihat dokumentasi dari penyedia font Anda.

Pemilihan dan sintesis font

Masing-masing jenis font terdiri dari beberapa varian bergaya (reguler, tebal, miring) dan beberapa bobot untuk setiap gaya, yang masing-masing dapat berisi bentuk glyph berbeda—Misalnya, spasi, ukuran berbeda, atau bentuk berbeda bersama.

Bobot font

Misalnya, diagram di atas menggambarkan jenis font yang menawarkan tiga bobot ketebalan berbeda: 400 (reguler), 700 (tebal), dan 900 (ekstra tebal). Semua varian antara (diindikasikan dalam warna kelabu) otomatis dipetakan ke varian terdekat oleh browser.

Ketika bobot ditetapkan untuk yang tidak memiliki wajah, wajah dengan bobot di sekitar bobot digunakan. Secara umum, bobot tebal memetakan ke wajah dengan bobot lebih berat dan bobot lebih ringan.

font CSS3 cocok dengan algoritme

Logika serupa berlaku untuk varian italic. Desainer font mengontrol varian mana yang mereka akan produksi, dan kita mengontrol varian yang akan kita gunakan pada laman. Karena setiap varian merupakan unduhan berbeda, merupakan ide yang baik untuk menjaga jumlah varian tetap kecil. Misalnya, Anda dapat mendefinisikan dua varian tebal bagi jenis Awesome Font:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2'), 
       url('/fonts/awesome-l.woff') format('woff'),
       url('/fonts/awesome-l.ttf') format('truetype'),
       url('/fonts/awesome-l.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 700;
  src: local('Awesome Font'),
       url('/fonts/awesome-l-700.woff2') format('woff2'), 
       url('/fonts/awesome-l-700.woff') format('woff'),
       url('/fonts/awesome-l-700.ttf') format('truetype'),
       url('/fonts/awesome-l-700.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

Contoh di atas mendeklarasikan jenis Awesome Font yang terdiri dari dua sumber daya glyph (U+000-5FF) namun menawarkan "bobot" berbeda: normal (400), dan tebal (700). Akan tetapi, apa yang terjadi jika salah satu aturan CSS kami menetapkan bobot font berbeda, atau menetapkan properti gaya-font ke miring?

  • Jika font yang benar-benar sama tidak tersedia, browser akan mengganti dengan yang paling cocok terdekat.
  • Jika tidak ditemukan gaya yang cocok (Misalnya, kita tidak mendeklarasikan varian miring apa pun dalam contoh di atas) maka browser akan mensintesiskan varian font-nya sendiri.

Sintesis font

Penulis juga harus menyadari bahwa pendekatan yang disintesis mungkin tidak cocok untuk skrip seperti Cyrillic, yang mana format miring sangat berbeda bentuknya. Selalu lebih baik untuk menggunakan font miring daripada mengandalkan versi sintetik.

gaya-font CSS3

Contoh di atas menggambarkan perbedaan di antara hasil font aktual vs. disintesiskan untuk Open-Sans. Semua varian yang disintesiskan dihasilkan dari font 400-bobot. Seperti yang Anda bisa lihat, ada perbedaan yang mencolok dalam hasilnya. Detail mengenai cara menghasilkan varian tebal dan miring tidak ditetapkan. Oleh karena itu, hasilnya bervariasi dari browser ke browser, dan sangat bergantung pada font.

Mengoptimalkan pemuatan dan rendering

TL;DR

  • Permintaan font ditunda sampai pohon render dikonstruksikan, yang dapat mengakibatkan tertundanya rendering teks.
  • Font Loading API memungkinkan Anda untuk mengimplementasikan pemuatan font khusus dan strategi rendering yang mengganti pemuatan font lazyload default.
  • Penyisipan font memungkinkan Anda untuk mengganti pemuatan font lazyload default di browser yang lebih lawas.

Webfont "penuh" yang mencakup semua varian bergaya, yang mungkin tidak Anda perlukan, plus semua glyph, yang mungkin tidak akan terpakai, dapat dengan mudah menghasilkan unduhan multi-megabyte. Untuk menangani hal ini, aturan CSS @font-face secara spesifik dirancang untuk memungkinkan Anda memisahkan jenis font ke dalam sekumpulan sumber daya: subset unicode, varian gaya berbeda, dst.

Mengingat deklarasi ini, browser menghitung subset yang diperlukan dan varian serta mengunduh set minimum yang diperlukan untuk merender teks, yang sangat nyaman. Namun, jika kita tidak berhati-hati, hal itu dapat pula menciptakan bottleneck kinerja dalam jalur rendering penting dan menunda rendering teks.

Webfonts dan jalur rendering penting

Pemuatan yang lambat dari font membawa implikasi tersembunyi penting yang mungkin menunda rendering: browser harus mengonstruksikan pohon render, yang bergantung pada pohon DOM dan CSSOM, sebelum mengetahui sumber daya font mana yang diperlukan untuk merender teks. Akibatnya, permintaan font tertunda setelah sumber daya penting lain, dan browser dapat diblokir dari merender teks sampai sumber daya diambil.

Jalur rendering penting font

  1. Browser meminta dokumen HTML.
  2. Browser mulai mem-parsing respons HTML dan mengkonstruksi DOM.
  3. Browser menemukan CSS, JS dan sumber daya lainnya serta mengirimkan permintaan.
  4. Browser mengkonstruksi CSSOM setelah semua materi CSS diterima dan menggabungkannya dengan pohon DOM untuk mengkonstruksikan pohon render.
    • Permintaan font dikirimkan setelah pohon render menunjukkan varian font mana yang dibutuhkan untuk merender teks yang ditentukan pada laman.
  5. Browser melakukan layout dan menggambar materi ke layar.
    • Jika font belum tersedia, browser mungkin tidak merender piksel teks apa pun.
    • Setelah font tersedia, browser akan menggambar piksel teks.

"Balapan" antara penggambaran pertama pada materi laman, yang dapat dilakukan segera setelah pohon render dibangun, dan permintaan untuk sumber daya font adalah yang membuat "masalah teks kosong" tempat browser mungkin merender layout laman tetapi menghilangkan setiap teks. Perilaku sebenarnya berbeda antar berbagai browser:

  • Safari menunda rendering teks sampai unduhan font selesai.
  • Chrome dan Firefox menunda rendering font hingga 3 detik, setelah keduanya menggunakan font fallback. Setelah unduhan font selesai, keduanya merender ulang teks dengan font yang diunduh.
  • IE segera merender dengan font fallback jika font yang diminta belum tersedia, dan merender ulang setelah unduhan font selesai.

Ada argumentasi yang mendukung dan menentang strategi rendering berbeda. Sebagian orang merasa rendering ulang tidak menyenangkan, sementara yang lain lebih suka melihat hasilnya segera dan tidak keberatan untuk mengalirkan kembali laman setelah unduhan font selesai - kita tidak akan turut dalam argumentasi ini. Poin pentingnya adalah pemuatan yang lambat mengurangi jumlah byte, namun juga berpotensi menunda rendering teks. Bagian berikutnya menjelaskan bagaimana Anda bisa mengoptimalkan perilaku ini.

Mengoptimalkan rendering font dengan Font Loading API

Font Loading API menyediakan antarmuka skrip untuk mendefinisikan dan memanipulasi wajah font CSS, melacak kemajuan unduhannya, dan mengesampingkan perilaku lazyload default. Misalnya jika Anda merasa yakin bahwa varian font tertentu akan dibutuhkan, kita dapat mendefinisikannya dan memberi tahu browser untuk memulai sumber daya font:

var font = new FontFace("Awesome Font", "url(/fonts/awesome.woff2)", {
  style: 'normal', unicodeRange: 'U+000-5FF', weight: '400'
});

font.load(); // don't wait for the render tree, initiate an immediate fetch!

font.ready().then(function() {
  // apply the font (which may re-render text and cause a page reflow)
  // after the font has finished downloading
  document.fonts.add(font);
  document.body.style.fontFamily = "Awesome Font, serif";

  // OR... by default the content is hidden, 
  // and it's rendered after the font is available
  var content = document.getElementById("content");
  content.style.visibility = "visible";

  // OR... apply your own render strategy here... 
});

Selanjutnya, karena kita dapat memeriksa status font (lewat metode check()) dan melacak kemajuan unduhannya, kita juga dapat mendefinisikan strategi khusus untuk merender teks pada laman kita:

  • Anda dapat menahan semua rendering teks hingga font tersedia.
  • Anda dapat mengimplementasikan waktu tunggu khusus untuk setiap font.
  • Anda bisa menggunakan font fallback untuk membuka blokir rendering dan menginjeksi gaya baru yang menggunakan font yang diinginkan setelah font tersedia.

Bagusnya, Anda bisa memadu-madankan strategi di atas untuk berbagai materi di laman. Misalnya, Anda bisa menunda rendering teks pada beberapa bagian sampai font tersedia, gunakan font fallback, lalu merender ulang setelah unduhan font selesai, menetapkan berbagai waktu tunggu, dan sebagainya.

Mengoptimalkan rendering font dengan penyisipan

Alternatif sederhana untuk menggunakan Font Loading API untuk meniadakan "masalah teks kosong" adalah untuk menyisipkan materi font ke dalam style sheet CSS:

  • Browser otomatis mengunduh, dengan prioritas tinggi, style sheet CSS dengan kueri media yang sesuai karena mengonstruksi CSSOM memang membutuhkannya.
  • Menyisipkan data ke dalam style sheet CSS memaksa browser untuk mengunduh font dengan prioritas tinggi dan tanpa menunggu pohon render. Yaitu, ini bertindak sebagai pengganti manual pada perilaku lazyload default.

Strategi penyisipan tidak sama fleksibelnya dan tidak memungkinkan Anda untuk mendefinisikan waktu tunggu khusus atau strategi rendering untuk materi berbeda, namun hal itu merupakan solusi sederhana dan ampuh yang bekerja di seluruh browser. Untuk hasil terbaik, pisahkan font yang disisipkan ke dalam style sheet yang berdiri sendiri serta berikan umur maksimal yang panjang. Dengan demikian, ketika CSS diperbarui, Anda tidak memaksa pengunjung Anda untuk mengunduh kembali font.

Mengoptimalkan penggunaan kembali font dengan caching HTTP

Sumber daya font biasanya merupakan sumber daya statis yang tidak mengalami pembaruan berkala. Akibatnya, sumber daya ini biasanya cocok untuk yang masa kedaluwarsa umur yang panjang - pastikan Anda menetapkan baik header ETag bersyarat, dan kebijakan Cache-Control yang optimal untuk semua sumber daya font.

Tidak perlu menyimpan font di localStorage atau lewat mekanisme lain; masing-masing yang telah menetapkan penemuan kinerjanya. Cache HTTP browser, bersama dengan Font Loading API atau pustaka webfontloader, menyediakan mekanisme terbaik dan paling tangguh untuk menyampaikan sumber daya font ke browser.

Daftar periksa optimalisasi

Berbeda dari yang banyak dipercaya, penggunaan webfont tidak perlu menunda laman atau berdampak negatif pada metrik kinerja lainnya. Penggunaan font yang dioptimalkan dengan baik dapat menghasilkan pengalaman pengguna keseluruhan yang lebih baik: branding yang hebat, keterbacaan yang lebih ditingkatkan, kegunaan, dan kemampuan dapat dicari, semuanya sembari mencapai solusi multiresolusi skalabel yang beradaptasi dengan baik pada format layar dan resolusi. Jangan takut menggunakan webfont!

Dengan demikian, implementasi asli dapat mengakibatkan unduhan berjumlah besar dan penundaan yang tidak perlu. Anda perlu membantu browser dengan mengoptimalkan aset fontnya sendiri dan caranya diambil serta digunakan di laman Anda.

  • Audit dan pantau penggunaan font Anda: jangan gunakan terlalu banyak font di laman Anda, dan untuk setiap font, minimalkan jumlah varian yang digunakan. Ini akan membantu mencapai pengalaman yang lebih konsisten dan lebih cepat bagi pengguna.
  • Subset sumber daya font Anda: banyak font dapat menjadi subset, atau dibagi menjadi beberapa rentang-unicode untuk menghasilkan hanya glyph yang diperlukan oleh laman tertentu. Ini mengurangi ukuran file dan meningkatkan kecepatan unduhan sumber daya. Akan tetapi, ketika mendefinisikan subset, berhati-hatilah untuk mengoptimalkan bagi font yang akan digunakan kembali. Misalnya, Anda tidak ingin mengunduh set karakter berbeda namun tumpang tindih pada setiap laman. Praktik yang baik adalah men-subset berdasarkan skrip: misalnya, Latin, Cyrillic, dan seterusnya.
  • Menyerahkan format font yang dioptimalkan ke setiap browser: setiap font harus diberikan dalam format WOFF2, WOFF, EOT, dan TTF. Pastikan untuk menerapkan kompresi GZIP ke format EOT dan TTF, karena keduanya tidak dikompresikan secara default.
  • Tetapkan validasi ulang dan kebijakan caching yang optimal: font adalah sumber daya statis yang jarang diperbarui. Pastikan bahwa server Anda menyajikan stempel waktu umur maksimal yang panjang, dan token validasi ulang, untuk mengizinkan penggunaan kembali waktu yang efisien dari berbagai laman berbeda.
  • Penggunaan Font Loading API untuk mengoptimalkan Jalur Rendering Penting: perilaku pemuatan lambat default dapat mengakibatkan rendering teks yang tertunda. Font Loading API memungkinkan Anda untuk mengganti perilaku ini untuk font tertentu, dan menetapkan strategi rendering khusus dan waktu tunggu yang sesuai untuk berbagai materi pada laman. Untuk browser lawas yang tidak mendukung API, Anda bisa menggunakan pustaka JavaScript Web Front Loader atau menggunakan strategi penyisipan CSS.