Pelajaran yang saya dapatkan dari #WWWIDChallenge

Kurang lebih 1 bulan semenjak WWWID membuat tantangan membuat web yang tampil dan bisa digunakan kurang dari 5 detik. Saya tertantang untuk mencobanya dan berikut saya akan jelaskan apa yang saya dapatkan dari tantangan ini.

Tools yang digunakan

  1. Mini CSS untuk membuat tampilan layout.
  2. Vanilla JavaScript.
  3. Lazy size sebagai library lazy load image.
  4. Cloudinary untuk menarik data berupa gambar atau video dari REST API.
  5. Hosting: share hosting, Github dan Firebase.

Saya sengaja menggunakan vanilla JS karena ingin menguji diri sendiri sejauh mana memahami JavaScript dan membuat Service Worker dengan vanilla JS.

Percobaan pertama

Saya melakukan percobaan dengan menggunakan share hosting dan tanpa menggunakan library lazy load. Percobaan saya lakukan pada 27 Februari 2018 pada jam 07:58 WITA menggunakan WebPageTest dengan mode easy. Hasilnya seperti gambar di bawah.

image

Skor yang ditampilkan oleh Light house pada percobaan pertama

**Sesuai tantangan WWWID bahwa nilai untuk performance dan PWA harus di atas 90. **Seperti yang bisa anda tebak bahwa nilai performance saya kurang dari 90. Namun, dengan bantuan Lighthouse melalui WebPageTest mode easy, saya diberikan petunjuk hal-hal apa saja yang harus saya lakukan untuk menaikkan nilai performance saya agar bisa mencapai nilai di atas 90.

Performance

Metrics

image

Pada gambar di atas, konten muncul pada detik 3,7 dan interaktif (scroll atas bawah dan sebagainya) pada detik 5,8. Yang menarik adalah gambar baru muncul pada detik 29,6.

Opportunities

image

Pada gambar di atas, terdapat banyak peluang untuk meningkatkan nilai performa PWA. Saya akan jabarkan beberapa yang saya anggap penting.

Offscreen images

image

Pada gambar di atas menjelaskan bahwa pada saat website ditampilkan, semua gambar harus tampil saat konten tersebut berada di hadapan layar dan di bawah layar . Lighthouse menyarankan agar kita menggunakan prinsip lazy-load sehingga gambar yang diload hanyalah yang berada di hadapan layar saja. Solusinya adalah menggunakan intersection observer atau library yang mendukung lazy-load. Untuk saat ini saya menggunakan library lazy-load karena saya masih kesulitan mengimplementasikan intersection observer.

Serve in next-gen formats

image

Pada gambar di atas, Lighthouse menyarankan agar kita menyajikan gambar dalam format yang lebih baik dari sisi kompresinya dalam bentuk JPEG 2000, JPEG XR, dan WebP. Solusinya adalah mengkonversi gambar yang ada dari API dengan pihak ketiga salah satunya adalah Cloudinary bagian fetch remote images.

Saat ini, WebP hanya didukung oleh Chrome dan Opera. JPEG XR hanya didukung oleh Edge dan IE. JPEG 2000 hanya didukung oleh Safari. Jadi, saya putuskan untuk tidak menggunakan ketiganya. Anda bisa mengeceknya di website caniuse.com.

Reduce render-blocking stylesheets

image

CSS bersifat render-blocking singkatnya ia akan menghambat jalan browser untuk menampilkan halaman website. Oleh karena itu, disarankan untuk mengirimkan CSS yang bersifat critical via <style> atau membuat <link> kita lebih spesifik seperti menampilkannya di ukuran tertentu: &lt;link href=&#34;whatever.css&#34; rel=&#34;stylesheet&#34; media=&#34;(min-width: 40em)&#34;&gt;

Unused CSS rules

image

Tidak semua style CSS dipakai dalam tag HTML. Saya ambil contoh membuat sebuah form menggunakan Bootstrap biasanya hanya memanggil class row, container, col-md, form-group, form-control, btn. Jadi, saya hanya perlu gunakan style CSS yang dipakai. Solusinya adalah menggunakan purgecss. Saya menggunakan opsi CLI can menjalankan perintah purgecss --css mini-default.css --content [index.html, category.html, post.html]

Catatan: Pastikan style CSS dalam kondisi un-minified. Hal ini dikarenakan pada saat di minified, purgecss tidak memangkas style CSS yang tidak penting.

Untuk contoh penggunaan purgecss bisa klik link ini.

Keep server response time low (TTFB)

image

Kondisi ini artinya respon dari server mengirimkan sesuatu (entah HTML, CSS, JS, atau aset lainnya) dalam bentuk byte ke browser. Sekitar 0.7 detik untuk server memberikan respon berupa byte pertama ke browser dan hal tersebut juga berpengaruh pada loading website. Umumnya ini terjadi pada server dengan share hosting atau koneksi internet yang tidak stabil saat server mengirimkan respon. Pernyataan ini adalah murni dari pendapat dan pengamatan saya.

Diagnostics

image

Critical Request Chains 😱

image

Browser menganggap ada beberapa resource sebagai prioritas utama saat menampilkan website dan berdampak pada loading website. Lighthouse menyarankan untuk mengurangi jumlah resource atau menunda (defer) resource saat menampilkan website. Saya memilih opsi menunda (defer) dan saya tempatkan pada main.js, sw-controller.js, dan lazysize.min.js.

Waktunya perbaikan

Setelah melakukan perbaikan berdasarkan Lighthouse report, hasil yang saya dapatkan sebagai berikut

image

Yang telah saya lakukan

  1. Menunda script yang berjalan dengan memberikan tag defer agar browser bisa mencetak DOM (Document Object Model) lebih cepat.
  2. Menggunakan purgecss untuk memangkas style CSS yang tidak diperlukan.
  3. Menggunakan tag <link> yang lebih spesifik saat menampilkan CSS.
  4. Menggunakan Cloudinary untuk mengkonversi gambar dari yang ada dari API.
  5. Menggunakan library lazy-size untuk menerapkan lazy-load.

Ekstra

  1. Menggunakan preload untuk memaksa browser untuk memprioritaskan aset yang saya perlukan sebelum halaman di load. Preload hanya berguna untuk first view dan first render tetapi tidak untuk first to interactive.
  2. Menggunakan dns-prefetch untuk mempercepat loading halaman web dengan pre-resolving DNS. Saya gunakan pada CDN image di Medium.
  3. Menggunakan preconnect untuk memberikan isyarat kepada browser untuk memulai koneksi handshake (DNS, TCP, TLS) di balik layar untuk meningkatkan performa.

Kepingan kodingnya ada disini.

Saya telah menggunakan preload dan dns-prefetch pada testing tadi. Setelah menambahkan preconnect, nilai performance naik sebesar 1 poin.

image

image

Tanpa preconnect

image

Dengan preconnect

Dengan adanya preconnect, koneksi handshake mulai lebih awal di balik layar dan akan meningkatkan performa secara tidak langsung. 😁

Percobaan berikutnya

Saya merasa belum puas dengan angka ini dan saya memiliki dugaan bahwa share hosting cenderung tidak stabil saat menampilkan halaman website dalam koneksi 3G slow. Jadi, saya putuskan untuk mencobanya dengan hosting Github dan Firebase.

Github

image

Firebase

image

Dari hal di atas, hosting di Github dan Firebase cenderung stabil dibandingkan share hosting. Hail Github and Firebase!!! πŸŽ‰

Kesulitan saat mengerjakan RSS WWWID

Yang namanya belajar pasti ada saja kesulitan yang saya alami. Apa saja kesulitannya:

  1. Di halaman utama kita harus menampilkan satu paragraf saja di setiap artikel. Solusinya: regex. Trims mas Irfan Maulana. πŸ™
  2. Ketika user mengklik sebuah artikel kita harus isi artikel alias detail artikelnya. Solusinya: mainkan url dan filter di JavaScript. Trims mas Irfan Maulana. πŸ™
  3. Kesulitan menggunakan Service Worker karena belum terbiasa pakai. Solusinya: cari contekan yang berfaedah salah satunya punya bung Osby 😁. Artikelnya di sini: Progressive Web App bagian 2
  4. Mencari cara agar bisa menghapus style CSS yang tidak perlu. Solusinya: menggunakan purgecss. Trims mas Adysurya Agus (rinJrz). πŸ™
  5. Mengimplementasikan lazy-load image. Solusinya pakai intersection observer atau library lazy load. Untuk sementara saya ambil solusi library lazy load karena saya masih agak kesulitan mengimplementasikan intersection observer. Librarynya adalah lazy-size. Trims om Kucing (Rian Yulianto). πŸ±πŸ™
  6. Mengimplementasikan dns-prefetch untuk meresolve koneksi dengan konten seperti CDN. Trims mas Teno Siswono. πŸ™
  7. Mengimplementasikan preconnect untuk memaksa koneksi handshake dibalik layar demi menaikkan nilai performa web. Trims bli Surya Darma. πŸ™
  8. Menyajikan gambar dalam bentuk format yang lebih baik. Solusinya adalah Cloudinary. Trims mas Imam Susanto. πŸ™
  9. Mencari solusi agar bisa menggunakan Service Worker di Github page. Solusinya adalah contekan berfaedah dari Mariko Kosaka (Dev. Relation dari Chrome team). 😁 Contekannya di sini: Service Worker in Github Page.

Halβ€Šβ€”β€Šhal yang belum saya coba

  1. Menggunakan WebPack.
  2. Menggunakan cloud function untuk mengimprove performa. Karena saat saya menarik data tidak satu jalur dengan domain yang saya pakai untuk hosting.
  3. Menggunakan Intersection Observer. Sebenarnya masih banyak cara ketika berhadapan dengan image. Kalian bisa baca di Image Guide buatan Addy Osmani dan kontributor yang terlibat.
  4. Ada lagi? Feel free untuk lempar issue di sini: RSS-WWWID PenjelajahTekno issue.

Ucapan terima kasih

Terima kasih untuk teman-teman WWWID yang sudah membantu sharing solusi” yang bisa saya terapkan dalam tantangan ini. Walaupun belum mencapai nilai di atas 90 di sisi performance paling tidak ada ilmu yang saya dapatkan, salah satunya adalah Web Performance. Terima kasih juga untuk mas Yohan Totting sudah bersedia menyediakan tantangan ini dalam bentuk studi kasus. Untuk kalian yang ingin tahu detail tantangannya silahkan cari di Medium WWWIDβ€Šβ€”β€ŠTantangan Web Developer untuk membuat web yang bisa ditampilkan kurang dari 5 detik.

P.S.: Tak jarang saya dan teman” di grup Telegram saling oprek di tengah-tengah jam kerja. 😝

Project RSS-WWWID

penjelajahtekno/rss-wwwid

Untuk melihat hasil tantangan dari teman-teman yang lainnya kalian bisa cari dengan keyword WWWID atau WWWID Challenge.

Link Demo

  1. RSS-WWWID (Share hosting)
  2. RSS-WWWID (Github)
  3. RSS-WWWID (Firebase)