Enam bulan lalu, Google memperkenalkan versi terbaru dari layanan emailnya. Terlepas dari kenyataan bahwa banyak pengguna tidak senang dengan desain ulang, termasuk di Habré , ini sekarang merupakan antarmuka utama bagi pengguna.
Di antara kekurangan lainnya, orang mengeluh tentang penurunan kinerja versi baru, terutama pada komputer yang lemah. Mari kita lihat mengapa ini terjadi dan apa yang bisa sangat sulit di antarmuka email. Di artikel ini, kami akan menggunakan alat pengembang di Google Chrome, jadi artikel ini juga akan menjadi pengingat peluang apa yang tersedia di sana.
Sumber data
Pertama, Anda perlu memahami apa yang sedang kita hadapi. Google Chrome Devtools memiliki alat Mercusuar bawaan yang membuat laporan kinerja sederhana dan mudah untuk situs Anda. Di dalamnya, Gmail mendapat deuce untuk kinerja (dari maksimal 100 poin!)
Sejujurnya, ini bukan hasil yang Anda harapkan dari produk Google. Namun demikian, mari kita lihat situasi ini secara lebih rinci. Matikan cache, dan muat antarmuka Gmail dengan devtools diaktifkan. Tab Jaringan akan menampilkan semua permintaan yang dibuat untuk mengunduh halaman ini. Ternyata 6,9 Mb. Ini adalah ukuran yang mengesankan, mengingat bahwa bahkan Youtube, layanan lain yang baru diperbarui, hanya memuat 2 MB sumber daya.
Perlu dicatat di sini bahwa layanan modern, termasuk Gmail, menggunakan Pekerja Layanan untuk peningkatan caching sumber daya. Oleh karena itu, untuk pengukuran awal yang dingin, mematikan cache tidak cukup, Anda juga perlu mengatur ulang Pekerja Layanan , yang juga memegang sumber daya. Hanya setelah ini, nomor unduhan dari awal akan menjadi nyata.
Sekarang mari kita coba melihat pemuatan halaman dalam gerakan lambat. Dokumentasi Google Chrome menjelaskan cara melakukan ini. Kami mendapatkan serangkaian tangkapan layar dari berbagai tahapan pemuatan halaman:
Di sini Anda dapat melihat bahwa halaman tersebut dimuat kurang lebih pada detik ke-9.
Dengan memuat ulang saat menggunakan cache, situasinya lebih baik. Halaman hanya membuat 250 Kb permintaan, tetapi ini tidak membuatnya lebih cepat, kita masih melihat layar splash selama hampir 10 detik. Intinya jelas bukan jumlah permintaan, sesuatu yang lain membuat halaman lebih lambat.
Kami memblokir sumber daya
Sekarang lihat daftar skrip yang dapat diunduh:
Mungkin beberapa dari mereka tidak begitu diperlukan untuk operasi normal antarmuka? Mari kita coba mematikannya satu per satu dan menguji halaman tanpa mereka. Ini mudah dilakukan dengan menggunakan fungsi bawaan devtools .
Secara empiris, ternyata permintaan untuk https://mail.google.com/_/scs/* sangat penting agar antarmuka berfungsi, tetapi permintaan berikut dapat diblokir:
www.gstatic.com/og/* - Pustaka Klien Google API , pustaka untuk permintaan layanan Googlessl.gstatic.com/inputtools/* - Google Input Tools - widget keyboard di layarhangouts.google.com - bertanggung jawab atas widget handgouts
Selain permintaan ini, AdBlock saya memasang permintaan yang sudah diblokir ke https://play.google.com/log , kami tidak memperhitungkannya, karena tidak dibuat bahkan sebelum eksperimen dengan kunci dimulai.
Kami menambahkan skrip ini ke daftar hitam dan melihat bahwa halaman mulai memuat dalam 4 detik, tetapi Anda masih dapat membaca dan menulis surat.
Kami mencari di profiler
Jadi, kami meminimalkan pemuatan sumber daya sebanyak yang kami bisa, tetapi halaman masih membutuhkan waktu lama untuk dimuat. Kita perlu melihat apa yang terjadi selama 4 detik ini. Di sini, profiler yang terpasang di Chrome akan membantu kami. Dia menunjukkan kepada kita gambar ini:
Di sini Anda dapat melihat bahwa selama ini browser sibuk dengan eksekusi Javascript. Sangat menarik bahwa hal yang penting dan sulit terjadi dalam kode ini. Untungnya, Javascript dimuat ke dalam browser hampir tidak berubah dan dapat dibaca.
Pertimbangkan kode yang tersisa
Mari kita baca kode Javascript yang tersedia untuk kita. Di sinilah peluang untuk memformat kode yang diperkecil agar lebih mudah dibaca.
Menurut hasil menonton, berikut ini ditemukan:
- Kode ini sangat dikaburkan. Kemungkinan besar, Google Closure Compiler digunakan dalam Mode Lanjutan . Artinya, pengembang Gmail telah memanfaatkan teknologi minifikasi modern secara maksimal.
- Metrik kinerja dikumpulkan dalam kode, jadi pengembang harus menyadari betapa lambatnya antarmuka pengguna dimuat.
- Sumber berisi polyfill untuk Promise, Map, Set, dan API modern lainnya yang mungkin tidak dimuat di browser modern.
- Kode Gmail ditulis dalam Google Closure Libary
Pada titik terakhir, ada baiknya berhenti lebih detail. Perpustakaan Penutupan adalah kerangka pengembangan antarmuka yang muncul pada tahun 2009, dan tidak banyak berubah sejak saat itu. Misalnya, Ajax melalui ActiveXObject masih didukung di sana : yang diperlukan hanya untuk IE6 dan lebih rendah, meskipun Gmail saat ini secara resmi hanya mendukung IE 10+.
Selain itu, UI Penutupan didasarkan pada hierarki kelas dalam tradisi GWT "terbaik" - pendekatan dengan banyak abstraksi verbose yang jelas memengaruhi kinerja rendering. Kerangka kerja UI modern (React atau Vue, misalnya) menawarkan abstraksi yang jauh lebih ringan - komponen - yang jauh lebih murah untuk disajikan.
Karena itu inisialisasi yang panjang: ribuan kelas dibuat dalam kode dan banyak abstraksi diinisialisasi sebelum benar-benar mulai memberikan antarmuka Gmail kepada kami.
Jadi, meskipun penampilannya diperbarui, Gmail menarik warisan teknologi lama, yang parahnya tidak dapat disembunyikan di balik kulit luarnya.
Kesimpulan
Saya harap setelah ulasan ini akan menjadi sedikit lebih jelas mengapa Gmail melambat. Sayangnya, itu tidak dalam kekuatan kami untuk membuat Google mempercepat layanan mereka, tetapi Anda setidaknya dapat mempelajari beberapa pelajaran untuk aplikasi Anda:
- Proyek lawas biasanya menemukan kode yang tidak perlu, seperti peretasan untuk peramban lawas. Tinjau sumber Anda dan singkirkan hal-hal yang telah menjadi tidak relevan.
- Abstraksi tidak gratis. Jika Anda ingin menyelesaikan masalah menggunakan pola arsitektur yang elegan, pertama-tama pikirkan apakah itu alat yang terlalu berat, mungkin ada opsi yang lebih mudah.
- Jangan unggah elemen sekunder ke halaman secara asli. Dalam hal ini, widget Hangouts mungkin tidak memblokir saluran, mengganggu pemuatan sumber daya Gmail utama, tetapi memuat di latar belakang, setelah merender fungsi utama.
- Jangan abaikan teknologi modern. Mereka mungkin berisi solusi fundamental baru untuk tugas Anda, lebih produktif dan nyaman. Sungguh aneh melihat pada tahun 2018 desain ulang layanan dari Google, yang tidak menggunakan komponen web , di mana Google begitu aktif tenggelam dalam konferensi .
- Nah, jangan lupa memperhatikan pengukuran kinerja untuk proyek Anda. Untuk ini, sekarang ada banyak alat yang mudah digunakan, baik berbasis browser dan untuk peluncuran di CI .