🕑 🚶🏼 🤴🏼 BFCache, atau Di sana dan kembali. Laporan Yandex 📕 👩🏿‍🤝‍👩🏽 👀

Orang sering menggunakan tombol kembali ke halaman sebelumnya di browser - mungkin lebih sering daripada yang Anda pikirkan. Dan jika demikian, lalu mengapa segera membuang halaman dari memori browser, dan setelah sedetik menghabiskan waktu dan lalu lintas membukanya kembali? Agar pengguna dapat kembali dengan cepat, teknologi BFCache diciptakan, yang penting untuk diingat ketika mengembangkan antarmuka. Victor Khomyakovpemenang-homyakov menemukan "caching bolak-balik" dan menyusun tabel kompatibilitas BFCache dengan API yang berbeda.

- Halo, nama saya Victor. Saya bekerja sebagai bagian dari tim yang cukup besar yang berhubungan dengan halaman pencarian.

Minimal, Anda sudah melihat halaman yang sama atau serupa di Google. Dan khususnya, saya menangani masalah kecepatan unduhan halaman ini - sehingga membuatnya di server secepat mungkin dan mengunduh dan menampilkan kepada klien secepat mungkin. Mengapa ini penting? Semakin sedikit klien yang menunggu halaman Anda dimuat, semakin kecil kemungkinan ia tidak akan menunggu dan meninggalkan Anda. Dan semakin besar kemungkinan klien akan berhasil mengonversi ke hal lain, semakin banyak akan menjadi skor promosi bersih. Artinya, klien akan dengan senang hati memberi tahu semua orang yang mereka tahu bahwa ini adalah halaman keren yang luar biasa - itu memuat dengan sangat cepat, sangat nyaman untuk digunakan. Dan pada akhirnya, semakin banyak uang yang bisa Anda peroleh. Atau perusahaan Anda, maka itu akan memberi Anda hadiah.

Saya akan memberikan sejumlah contoh dari perusahaan terkenal. Google melakukan percobaan. Mereka dengan sengaja menyematkan penundaan pada halaman pencarian dan mengukur bagaimana ini mempengaruhi kinerja. Ternyata rata-rata ada setengah persen lebih sedikit pencarian per pengguna. Apa itu setengah persen? Hitung: setengah persen dari ratusan juta pengguna Google adalah jumlah yang cukup besar.

Bing melakukan percobaan yang sama. Mereka tidak percaya Google, mereka memutuskan untuk mengecek. Mereka mendapat hasil yang serupa: pendapatan yang lebih sedikit per pengguna saat halaman melambat. Mengapa melambat? Karena lebih mudah untuk memperlambat halaman dengan jumlah persis milidetik sehingga dapat dengan mudah diproduksi ulang dalam produksi daripada mempercepatnya dengan jumlah yang sama.

Contoh dari AliExpress. Mereka mempercepat situs mereka sebesar 36% dan menerima lebih banyak pesanan dari pengguna. Pesanan adalah uang langsung. Secara umum, sudah jelas bagi semua orang bahwa kecepatan sangat penting, itu mempengaruhi, melalui sejumlah metrik tertentu, uang yang diperoleh.

Dan satu faktor lagi. Hari ini kita telah berbicara tentang pengoptimalan gambar. Dengan mengoptimalkan lalu lintas Anda, mengurangi jumlah unduhan, Anda membayar lebih sedikit uang kepada hoster Anda untuk lalu lintas keluar. Ini juga uang yang akan tetap di saku Anda. Bagaimana jika saya tiba-tiba menawarkan diskon 10% untuk lalu lintas dari host mana pun tanpa batasan dan ketentuan apa pun? Dan jika saya mengusulkan untuk memastikan bahwa pangsa halaman Anda - misalnya, sepuluh persen - dimuat oleh pengguna hampir secara instan? Tidak ada yang akan menolak.

Teknologi yang akan saya coba bicarakan hari ini adalah salah satu solusi yang memungkinkan yang memberlakukan beberapa batasan pada tumpukan mana Anda bekerja, teknologi mana, tetapi pada saat yang sama berjanji untuk memberi Anda keuntungan yang cukup signifikan.

Untuk mulai dengan, Google mengumpulkan statistik tentang bagaimana browser ini digunakan di browser mereka. Dan mereka menerbitkan nomor seperti itu: ternyata, rata-rata, dari semua pembukaan halaman, dari semua navigasi di mobile Chrome, sekitar 19% adalah gerakan bolak-balik melalui cerita. Pikirkan apa artinya itu? Jika Anda bulat, ternyata 20% dari navigasi bergerak ke halaman di mana pengguna baru saja.

Bagi kami, seperti untuk penulis halaman, ini berarti: bahkan jika pengguna meninggalkannya, ada kemungkinan besar ia akan kembali. Di satu sisi, ini mungkin justru masalah ponsel: semuanya kecil, mudah kehilangan jari, klik tautan dan tinggalkan halaman, lalu katakan: "Oh, sial! Saya ingin kembali ". Tetapi pada desktop, situasinya hampir sama: ada jumlahnya kurang, tetapi masih ada persentase pengembalian yang signifikan.

Apa yang sedang kita lakukan saat ini? Kami menghabiskan waktu dan lalu lintas pengguna secara tidak efektif. Artinya, kita mulai memuat kembali halaman yang sama, menguraikannya, membuat ulang DOM, menggambar ulang semua yang ada di layar, memuat, menjalankan JavaScript.

Browser adalah hal yang sangat kuat. Dia mencoba menggunakan cache sedapat mungkin. Dan sebagian besar sumber daya mungkin ada dalam cache-nya. Dia tidak akan menunggu mereka dari jaringan, tetapi akan mengambilnya langsung dari cache. Misalnya, dalam mesin V8, hasil parsing JavaScript juga di-cache. Yaitu, peramban tidak akan memuat ulang dan mem-parsing JS, dan dalam kebanyakan kasus diperlukan untuk segera menjalankannya. Tapi tetap saja, membangun kembali DOM, memuat ulang sumber daya yang tidak di-cache, dan menjalankan JS membutuhkan banyak waktu.

Solusinya menunjukkan sendiri. Apa yang kita lakukan? Kami, ketika pengguna meninggalkan halaman kami, jangan langsung membersihkannya. Kami cukup menyimpan kondisinya dan secara visual menyembunyikannya dari pengguna sehingga di bawah kapnya tetap ada di peramban.

Apa yang akan kita lakukan jika pengguna memutuskan untuk kembali? Cukup tunjukkan padanya halaman tersimpan yang sama. Itu dapat ditampilkan hampir secara instan.

Teknologi ini disebut back / forward cache, dari kata "bolak-balik". Pendek untuk bfcache.

Berikut adalah contoh bagaimana peramban yang sama, rakitan yang sama, berperilaku ketika bfcache mati dan hidup. Pembukaan halaman pertama sama lambatnya baik di sana maupun di sana. Tetapi lebih jauh lagi, ketika kita mulai bergerak bolak-balik melalui cerita, jeda terlihat di sebelah kiri, dan itu tidak di kanan. Di sebelah kiri, gerakan biasa melalui sejarah membutuhkan waktu yang nyata. Di sebelah kanan, semuanya terjadi sangat, sangat cepat.

Tampilkan GIF

Contoh serupa dari pencarian kami. Di sebelah kiri adalah Safari biasa di macOS dengan bfcache dinonaktifkan, di sebelah kanan adalah Safari yang sama dengan pengaturan default dan bfcache diaktifkan. Ini adalah kasus yang cukup umum: seseorang datang mencari, mungkin tidak tahu persis apa yang dia cari, mungkin bertanya beberapa opsi permintaan. Saya bertanya permintaan pertama - ada sesuatu yang tidak beres. Permintaan kedua tampaknya lebih baik. Ketiga - tidak, lebih buruk, kembali ke permintaan sebelumnya. Dan pada saat ini akan sangat baik untuk tidak membuatnya menunggu. Dia baru saja melihat permintaan sebelumnya, langsung tunjukkan.

Atau opsi kedua, jika Anda memiliki pagination dan beberapa halaman tentang masalah ini. Man membalik-balik masalah ini. Saya pergi ke halaman kedua, ketiga, keempat, melihat - tidak, ada sesuatu yang salah, saya akan kembali. Dan kami, sekali lagi, dapat menunjukkan halaman sebelumnya hampir secara instan.

Masalah penting adalah keamanan. Meskipun laman tempat pengguna tidak dalam kondisi tersembunyi, ia dapat mengakses berbagai API yang memungkinkan Anda membaca status perangkat keras ponsel atau komputer Anda. Berikut adalah daftar singkat dari apa yang langsung terlintas dalam pikiran: geolokasi, mengubah posisi perangkat Anda di ruang, akses ke kamera, dan suara dari mikrofon.

Kemudian, ketika halaman muncul, penting bahwa itu tidak mendapatkan akses ke semua peristiwa yang terjadi selama waktu itu disembunyikan. Jika tidak, saluran tambahan akan terbuka untuk memata-matai pengguna. Adalah penting bahwa dia tidak mendapatkan riwayat gerakan Anda selama ini dan rekaman mikrofon dan kamera. Pengembang peramban juga tidak boleh melupakan hal ini.

Dukungan API dan browser

Lebih dekat dengan topik. Misalkan saya sudah meyakinkan Anda, Anda adalah: "Ya, topik yang bagus, kita harus bekerja dengan ini." API apa yang kami miliki, apa yang dapat kami kerjakan jika kami setuju untuk mempertimbangkan bfcache, dan bagaimana hal ini didukung oleh browser?

Di mana bfcache sudah ada, di mana saya bisa melihatnya?

- Sudah lama diterapkan di browser Firefox, Safari (dan macOS, dan iOS), serta di Internet Explorer 11 (!). Biasanya kami memarahi pengembang Microsoft, tetapi di sini mereka hanya mencoba.

- Ini diterapkan di browser UC Browser 11/12, versi untuk Android.

- Tiba-tiba dia tidak ada di Chrome. Dan di Chromium fitur ini sedang dikembangkan.

Jadi, ketika mereka melakukan ini di Chromium, hampir semua browser ini (dan ini bukan daftar lengkap) cepat atau lambat akan mendapatkan fungsionalitas ini - gratis, tanpa SMS dan registrasi.

Apakah ada API? Saya ingin mengelola bfcache, saya ingin menghidupkan dan mematikannya langsung dari JavaScript, untuk mengetahui apakah ada halaman di bfcache atau tidak. Bagaimana dengan API semacam itu? Tidak ada API semacam itu. Dan ini dilakukan secara sadar: halaman seharusnya tidak ingin menghidupkan atau mematikan bfcache untuk semua orang dan untuk dirinya sendiri. Atau cari tahu apakah ada orang dalam bfcache ini atau tidak. Ini semua karena keamanan.

^{_{Tautan dari slide}}

Tetapi apa yang kita miliki? Jenis navigasi. Ada jenis tautan - prerender tautan, saat kami ingin merender halaman sebelumnya. Ada jenis navigasi khusus untuknya: halaman ini akan dibuka dengan "jenis prerender" NavigationType. Jika kita hanya membuka halaman di browser, maka akan ada "navigasi". Jika kita mengklik tombol "Perbarui", itu akan menjadi "memuat ulang".

Kami tertarik pada jenis navigasi "back_forward" di sini, ini jelas menunjukkan bahwa pengguna bergerak bolak-balik melalui cerita. Ini adalah jenis navigasi yang dapat digunakan oleh bfcache kami.

API lain adalah acara pageshow pagehide. Mereka sudah ada di browser. Dengan demikian, pageshow dipicu ketika halaman Anda ditampilkan di browser kepada pengguna, pagehide dipicu ketika halaman bersembunyi karena alasan apa pun. Dan mereka dilengkapi dengan bidang yang masih ada. Jika halaman bersembunyi dan pada saat yang sama akan ditempatkan dalam bfcache, maka bidang yang tetap ada akan benar. Jika halaman ditampilkan saat menaikkannya dari bfcache, maka bidang yang tetap ada akan kembali benar.

Dengan demikian, jika browser tidak akan melakukan cache halaman, maka pagehide akan tetap salah. Dan jika browser menampilkan halaman selama pemuatan normal, atau tidak menggunakan bfcache, maka pageshow juga akan tetap salah.

^{_{Tautan dari slide}}

Dukungan acara tersedia di hampir semua browser, bahkan yang belum mendukung bfcache.

^{_{Tautan dari slide}}

Hal yang sama berlaku untuk bidang yang ada. Itu sudah ada di Chrome, dan Chrome masih tidak mendukung bfcache. Artinya, bidang ini akan selalu ada di dalamnya, tetapi untuk saat ini akan salah.

Ketika saya menemukan fenomena ini, bfcache, saya harus mempelajarinya, mengetuk semua sisi, memperhatikan cara kerjanya. Saya langsung ingin melihat pada halaman saya ketika saya membuka apa nilai bidang yang bertahan di handler saya sama dengan.

Tampaknya semuanya cukup sederhana. Saya menulis handler dan output ke console.log () apa yang datang kepada saya. Tetapi ketika membuka DevTools di beberapa browser, bfcache mungkin tiba-tiba mati. Yaitu, saya membuka DevTools, saya bolak-balik menelusuri halaman-halaman itu, dan ketekunan saya selalu salah, halaman itu tidak masuk ke bfcache. Oke, saya punya alat kuat lainnya - waspada.

Tapi tidak. Peramban modern saat membongkar sebuah halaman di halamanhide, sebelumunload dan unload handler mengabaikan peringatan, itu hanya tidak berfungsi di sana. Dan lagi, saya tidak melihat apa yang saya inginkan.

Oke, saya punya produk yang lebih mematikan. Saya berada di blok tepat di halaman saya sendiri, yang saya jelajahi, hanya menambahkan teks dari isi acara saya dan dengan demikian mencatat semuanya. Metode ini berhasil.

Semuanya, tolong, bisa digunakan. Saya mendebug kode saya, itu berfungsi untuk saya, saya dapat terus melanjutkannya. Tentu saja, saya tidak lupa bahwa bagaimanapun juga, skrip statis eksternal lebih cocok agar tidak memuat kode inline yang sama pada halaman, tetapi menggunakan caching file.

Saya menempatkan kode ini dalam skrip eksternal.

Tapi tidak, penangan halaman jaga pageshow jatuh di Safari! Untuk beberapa alasan, mereka tidak bekerja dari skrip eksternal.

Oke, saya sudah memiliki versi yang berfungsi. Saya harus membiarkannya seperti itu.

Saya akan menuliskan secara singkat apa yang berhasil saya tapak hanya dalam satu hari. Pertama, DevTools dapat menonaktifkan caching. Anda mungkin ingat bahwa di DevTools pada tab Jaringan di Chrome ada kotak centang "Nonaktifkan cache". Ini menonaktifkan cache jaringan, mungkin tidak memengaruhi bfcache, atau mungkin. Analoginya jelas: kami membuka DevTools, yang berarti kami sedang berkembang dan kami mungkin tidak perlu caching. Mungkin itu mengganggu kita.

Fitur kedua adalah waspada. Firefox dan Safari akan mengabaikannya secara diam-diam dan terus mengeksekusi penangan lebih lanjut, seolah-olah tidak ada peringatan. Dan hanya satu Chrome tua-baik di konsol akan menulis kesalahan dengan warna merah - Anda memiliki peringatan, saya memblokirnya, tahu tentang itu!

Sekali lagi saya mengingatkan Anda bahwa penangan dari skrip eksternal di Safari mungkin tidak dipanggil, ini sangat aneh.

Dan satu lagi berita penting. Jika halaman Anda di-cache, yaitu, Anda menerima acara pagehide, dan dikatakan tetap benar, dan browser mengatakan kepada Anda: "Ya, saya memasukkannya ke dalam cache" - ini tidak memberikan jaminan bahwa halaman itu akan menjadi nanti dari cache ini dinaikkan dan ditampilkan kembali ke pengguna. Karena browser dapat memutuskan untuk menghapus cache ini jika kehabisan memori. Karena pengguna dapat menutup browser dan tidak bernavigasi ke mana pun. Ingat ini.

Fitur Implementasi

Saya mulai mempelajari dokumentasi lebih lanjut, untuk meneliti bagaimana saya bisa hidup dengan pengetahuan ini. Anehnya, dokumentasi itu. Artinya, Anda dapat menggali di internet deskripsi tentang cara kerja bfcache di browser. Tetapi, semakin saya membaca, semakin banyak perbedaan yang terakumulasi di antara berbagai browser.

Dalam satu, ia bekerja seperti ini, yang lain bekerja. Dalam satu, satu mengganggu, yang lain tidak mengganggu. Pengembang tidak tahu bagaimana memproses sejumlah API dengan benar saat menempatkan halaman di bfcache. Mereka berkata: ok, jika halaman menggunakan API ini, maka saya abaikan saja, jangan pernah masukkan ke dalam cache dalam keadaan apa pun. Dan daftar ini berbeda di browser yang berbeda, masing-masing sesuai dengan keinginannya.

Dan kemudian saya mulai menggabungkan apa yang saya pelajari menjadi satu tabel. Saya mendapat sesuatu seperti berikut:

Saya membaca dokumentasi untuk browser - untuk Firefox, Safari, keluarga Chromium. Ada dokumentasi yang tersedia di IE, meskipun sudah ketinggalan zaman. Kami programmer tidak suka memperbarui dokumentasi setelah perubahan di browser? Ketika saya menyadari bahwa informasi itu ketinggalan zaman, saya mulai menguji halaman kecil saya di browser dan memeriksa API mana yang berfungsi dan mana yang tidak.

Ini juga tidak cukup: Saya tidak tahu API mana yang harus dilihat secara prinsip, tetapi tidak memilah-milah semuanya? Dan saya harus melihat ke dalam kode sumber mesin browser itu sendiri, yaitu, kode itu ternyata menjadi sumber pengetahuan yang paling akurat dan dapat diandalkan. Saat ini, pelat ini (di depan Anda adalah bagian dari itu, di sini adalah tautan ke versi lengkap) adalah kumpulan pengetahuan paling komprehensif tentang API yang mengizinkan atau melarang bfcache dari bekerja di browser.

API yang tidak mengganggu tanda centang dan warna hijau, yang pasti akan mencegah halaman masuk ke bfcache ditandai dengan warna merah. Bidang putih adalah ruang yang tidak dijelaskan di mana pun.

Firefox

Berikut ini beberapa detail menarik dari browser tertentu. Saya akan mulai dengan Firefox, dia adalah orang pertama yang melakukan semuanya.

^{_{Tautan dari slide}}

Hal terpenting yang saya pelajari dari sumber-sumber Firefox adalah bahwa ketika bekerja dengan bfcache, ia dapat menulis ke teks log pada disk semua alasan mengapa ia tidak dapat meletakkan halaman di cache.

^{_{Tautan dari slide}}

Dan saya bahkan berhasil menemukan cara membuatnya melakukannya. Ada dua variabel lingkungan rahasia: dalam satu kita menunjukkan apa yang akan dicatat, yang kedua - dalam file apa yang akan menulis log. Setelah itu, kami meluncurkan biner, dan voila! Kita akan melihat kira-kira bahwa pada slide sebelumnya, garis-garis dari bentuk "html tersebut tidak dapat di-cache untuk alasan seperti itu, seperti untuk alasan yang berbeda". Kita dapat membacanya segera, sangat nyaman.

Jika Anda ingin bereksperimen sekali, Anda dapat membuka halaman about: networking di Firefox. Di sana Anda dapat memasukkan bidang yang sama di bagian "Jurnal". Kami dapat menunjukkan dalam dua bidang apa dan di mana untuk log, dan dengan tombol memulai dan menghentikan log.

^{_{Tautan dari slide}}

Kapan Firefox menolak untuk me-cache halaman? Jika Anda memiliki permintaan yang tidak lengkap, termasuk permintaan AJAX atau permintaan sumber daya seperti gambar, maka dia akan menolak untuk meletakkan halaman di bfcache. Dia yakin itu belum selesai, belum selesai mengunduh, ada semacam aktivitas mencurigakan. Tetapi semua ini tidak berlaku untuk favicon. Jika Anda lupa favicon, jika tidak memuat, ia berpikir baik-baik saja, ia akan melakukannya, itu normal untuk situs Anda.

Jika Anda memiliki skrip yang sudah berjalan lama, browser akan bertanya: karena butuh waktu, memblokir UI, mungkin mengalahkannya? Dan jika Anda setuju, maka halaman seperti itu dianggap agak salah, dan kami tidak menyimpannya.

Jika Anda menggunakan IndexedDB ... Ini adalah cerita yang instruktif. Sebelumnya, dalam implementasi pertama, mereka melihat: jika Anda memiliki IndexedDB dan ada transaksi yang tidak lengkap, maka halaman tersebut tidak di-cache, karena tidak jelas bagaimana cara menggunakannya (kami mencoba menyembunyikannya tepat di tengah-tengah transaksi). Tapi kemudian mereka kehilangan kode ini saat refactoring. Dan seperti yang Anda bayangkan, mereka tidak memiliki tes untuk ini. Mereka bahkan memiliki bug di bugtracker. Dia sudah berusia dua tahun dengan sesuatu. Orang-orang menulis: "Bfcache saya dengan IndexedDB tidak berfungsi dengan benar, apa yang harus saya lakukan?" Pengembang Firefox menjawab - ini benar-benar rusak, kami baru saja kehilangan bagian teks ini saat refactoring, oke, biarkan terus. Moral: tes menulis, bahkan jika Anda menulis Firefox, jika tidak semuanya bisa berakhir dengan sedih.

Dan satu faktor lagi yang tidak menarik di bfcache - jika konten campuran diizinkan secara eksplisit. Apa itu?

^{_{Tautan dari slide}}

Misalkan halaman Anda terbuka melalui HTTPS, tetapi Anda masih memuat beberapa sumber daya melalui HTTP, terutama skrip. Artinya, Anda memiliki skrip non-keamanan, dapat dimodifikasi oleh siapa saja.

^{_{Tautan dari slide}}

Secara default, Firefox, seperti browser lain, tidak menjalankan skrip non-keamanan seperti itu sekarang. Tetapi jika itu sangat penting bagi Anda, Anda masuk ke pengaturan dan membiarkannya dieksekusi, maka, karenanya, itu tidak akan menembolok halaman seperti itu. Dia akan berkata - baik, Anda mengatakan kepada saya untuk tidak mengeksekusi kode, tapi kemudian tidak, tidak!

Tweak lain adalah ukuran bfcache itu sendiri. Di sini, standarnya adalah minus satu. Itu berarti berapa banyak memori yang dimiliki Firefox, begitu banyak halaman yang coba di-cache. Tetapi kami dapat secara paksa menonaktifkan cache dengan meletakkan angka nol, atau secara eksplisit menetapkan angka - misalnya, ingat tidak lebih dari lima halaman.

Peringatan: slide berikutnya berisi kode sampel dalam bahasa C ++ yang menakutkan, ini bisa berbahaya pada konferensi front-end. Jangan mencoba menyalinnya, jalankan di konsol browser. Disk Anda mungkin diformat, layar dapat meledak, atau bitcoin dapat ditambang. Aku sudah memperingatkanmu.

^{_{Tautan dari slide}}

Jadi, kode tokek. Itu dapat dibuka, dibaca, dilihat secara gratis di Internet. Dan saya mencari-cari. Ada metode yang paling penting - CanSavePresentation (), ini menjawab pertanyaan: apakah mungkin untuk men-cache dokumen ini? Artinya, ini adalah sumber kebenaran tertinggi tentang apa yang sekarang diterapkan di Firefox. Namun - dari sanalah saya belajar bahwa Anda dapat membaca log. Ada variabel seperti itu - gPageCacheLog. Ini adalah log di mana semuanya ditulis. Berikut ini adalah kisah yang menarik tentang kunjungan ke C ++.

Artinya, Anda membuka tautan, melihat kode, mencari (ada pencarian yang mudah dan, lebih lagi, cepat) dan Anda dapat mengetahui detail implementasi aktual di versi terbaru browser - yang hanya hilang dari dokumentasi.

Safari

Hal paling kejam yang dilakukan Safari ketika sebuah halaman menyentuh bfcache: jika Anda memiliki permintaan AJAX yang tertunda, Safari hanya membunuhnya.

Bahkan jika Anda overlay dengan penangan kesalahan dan mencoba memeriksa semuanya, perbaiki - sepertinya permintaan itu tidak ada sama sekali. Setelah pulih dari bfcache, Anda tidak akan memiliki kesalahan, tidak ada "OK", tidak ada sama sekali.

Penangan pageshow pagehide, seperti yang saya katakan, di Safari dipanggil hanya jika mereka ditulis dalam skrip yang sesuai dengan halaman. Dari skrip eksternal, mereka mungkin atau mungkin tidak berfungsi - betapa beruntungnya. Tapi aku sudah memperingatkanmu.

Perbedaan menarik lainnya: beforeunload dan unload handler tidak mengganggu halaman masuk ke bfcache. Dalam hal ini, beforeunload selalu dipanggil, dan ketika masuk ke cache, dan ketika tidak menekan. Tetapi membongkar ketika halaman hits cache tidak dipanggil. Dan di sini terdapat rake lain: halaman mungkin menuju ke cache dan tidak pernah muncul darinya, dan jika Anda menulis beberapa kode penting dalam unload, itu mungkin tidak pernah dipanggil, walaupun tidak ada satu kesalahan terjadi pada halaman tersebut. Artinya, ia dengan benar pergi ke cache, dan dari sana ke mana-mana, dan pembongkaran Anda tidak akan pernah dipanggil.

Poin menarik lainnya. Seperti yang Anda ketahui, Anda dapat membuka beberapa jendela melalui window.open (). Dan pada saat yang sama, windows ini memiliki tautan satu sama lain. Artinya, mereka secara bersamaan dapat naik ke jendela masing-masing, membaca / menulis properti yang berbeda. Pembukaan windows anak ini tidak mengganggu bfcache. Dan di sini, kemungkinan besar, Safari sama kejamnya dengan permintaan AJAX, yaitu, semuanya susah payah, dan selamat tinggal. Pengembang Apple menyukainya lebih keras.

Lagi, satu menit, C ++! Sumber-sumber WebKit juga bukan rahasia, mereka juga dapat dibuka, dibaca dan dipelajari.

^{_{Tautan dari slide}}

Mereka ada di GitHub, di sana saya menyoroti dua fungsi penting:

- canCacheFrame () - periksa apakah frame ini dapat di-cache.
- Dalam objek yang berbeda pada halaman, seperti elemen atau font HTML, ada metode canSuspendForDocumentSuspension (). Objek ini bertanggung jawab atas apakah bisa melakukan cache, membeku, atau tidak.

Dan satu lagi aspek penting: WebKit memiliki tes yang sangat nyaman. Di sana, tepat di folder LayoutTests / fast / history, dalam bentuk html kecil, ringkas, ringkas, ada tes untuk pekerjaan API yang berbeda yang diterapkan di Safari dengan bfcache. Ini adalah contoh nyata tentang bagaimana Anda dapat menulis kode di Safari dengan API ini dan bagaimana mereka memengaruhi atau tidak memengaruhi apakah mereka mengizinkan atau tidak hit bfcache. Sangat menarik untuk dilihat.

Dari sana saya belajar bahwa Safari juga menulis semua pengetahuannya tentang bfcache, semua fitur, ke log teks. Tapi, sayangnya, saya tidak pernah menemukan cara mengaktifkan pencatatan ini atau, jika diaktifkan, di mana menemukan file ini di disk. Jika ada yang tahu, katakan padaku, aku akan sangat berterima kasih.

Chromium.

Seperti yang sudah saya katakan, masih ada pekerjaan yang sedang berlangsung, semuanya ditutup di bawah bendera. Anda dapat mengunduh Chrome Canary yang baru, buka benderanya. Pengaturan disembunyikan di sana - Anda dapat mencoba bermain dengannya. Anda mungkin melihat sesuatu.

Dari yang menarik - saya sudah berbicara tentang membuka halaman melalui window.open (). Di Chromium, halaman tersebut sejauh ini tidak di-cache. Mereka tidak menemukan cara menyelesaikan semua ini dengan benar, dan tanpa malu memotongnya, seperti di Safari, hati nurani mereka tidak memungkinkan mereka.

Jika DOMContentLoaded tidak terjadi, maka halaman tersebut juga tidak akan di-cache.

Ada banyak API baru yang dimulai dengan "Web" - itu juga sulit dan tidak bisa dipahami dengan mereka, dan sejauh ini semuanya mematikan bfcache secara default. Artinya, jika sesuatu yang trendi, baru digunakan pada halaman, seperti WebGL, WebVR, WebUSB, WebBluetooth, dll., Halaman seperti itu tidak akan masuk ke bfcache.

Pekerja Servis. Kami juga belum menyimpan halaman seperti itu, tetapi kami berencana untuk memprosesnya dengan benar dan menyembunyikannya dari pandangan tajam dari Pekerja Servis.

Jika geolokasi diaktifkan, kami juga belum menyimpannya. Sangat sederhana untuk saat ini.

Jika selama ini halaman dalam cache, cookie itu busuk, kami yakin bahwa beberapa jenis otorisasi telah kedaluwarsa. Mungkin itu perbankan online atau yang lainnya. Ini berarti bahwa halaman tersebut tidak lagi valid - kami menghapusnya dari cache.

^{_{Tautan dari slide}}

Orang-orang Google bahkan melangkah lebih jauh. Mereka menyarankan agar kami menyatukan semua yang diformalkan, menyatukan di semua browser, mengusulkan spesifikasi siklus hidup halaman untuk semua negara bagian, menyarankan menambahkan acara baru ke transisi antara berbagai negara. Anda dapat melihat tautan yang mereka pikir ada di sana.

^{_{Tautan dari slide}}

Sumber. Seperti yang Anda ketahui, sumber Chromium juga tersedia. Semua ini terletak pada kelas yang disebut BackForwardCacheImpl - penamaan yang sangat bagus, hampir tidak perlu terlihat. Metode utama yang memeriksa apakah suatu dokumen dapat disimpan disebut CanStoreDocument (). Ada juga metode GetDisallowedFeatures (), yang hanya mencantumkan semua fitur dan API baru yang tidak didukung di bfcache. Sangat mudah: terkonsentrasi di satu tempat, membaca dan menyadari apa yang saat ini mungkin dan apa yang tidak dapat digunakan.

Internet Explorer 11

Sebuah perjalanan ke dalam sejarah bagi mereka yang masih memiliki IE 11. Bagi mereka yang memiliki segalanya buruk.

Ada bfcache di sana, dan ini adalah masalah utama, karena Anda harus menghadapinya. Dokumentasi mengatakan bahwa bfcache seharusnya hanya berfungsi melalui HTTP. Bahkan, dalam produksi, ini juga berfungsi pada HTTPS karena beberapa alasan. Moral: jika Anda seorang pengembang, harap perhatikan dokumentasi Anda. Maka Anda harus menderita karena dia.

Jika ada handler sebelumunload, maka itu akan mencegahnya masuk ke cache. Mereka tidak mengatakan apa-apa tentang pembongkaran dalam dokumentasi - mungkin mereka tidak tahu atau melupakannya.

Jika halaman belum selesai memuat, itu juga tidak di-cache. Jika seseorang menggunakan komponen ActiveX, kami juga tidak melakukan cache. Dan jika DevTools juga terbuka di sana. Ini poin penting.

Bagaimana tanpa bug? Menambahkan bidang yang bertahan, tetapi terkadang tidak berhasil. Artinya, halaman tersebut benar-benar masuk ke cache, kembali dari sana, dan bertahan tidak disetel ke true. Apa yang harus dilakukan?

Kami memiliki kode cantik yang menentukan apakah kami kembali dari cache atau memuat ulang dari server.

Sekarang harus dilengkapi dengan kruk untuk IE. Kami menentukan bahwa kami memiliki IE, dan dalam beberapa penyelesaian kami memahami bahwa halaman tersebut bagaimanapun diambil dari cache dan pada saat yang sama kami memiliki navigasi sejarah (back_forward).

Selain itu, bagaimana Anda tahu jika sebuah halaman di-cache? Kami mengambil waktu pengambilannya. Jika dimuat dari server dalam 50 milidetik atau lebih cepat, maka ini pada dasarnya tidak bisa di IE - itu artinya dari cache! :)

Saya sudah menyebutkan navigasi melalui sejarah. Jika kita memiliki tipe navigasi back_forward, maka kita telah melewati histori, dan jika halaman tersebut dari cache, itu berarti bfcache, tidak ada opsi lain di IE.

Apa berikutnya?

Apa yang harus dilakukan selanjutnya dengan pengetahuan ini? Saya tidak ingin Anda keluar dan melupakan semua ini seperti mimpi buruk.

- Pertama, di sini adalah hal paling berharga yang saya temui dan apa yang ingin saya dorong Anda: gunakan browser open source! Dalam akses terbuka ke Internet saat ini adalah kode sumber dari semua browser terkemuka yang digunakan pelanggan kami. Dan ini adalah dokumentasi yang paling relevan tentang bagaimana dan bagaimana itu didukung, di mana dan bagaimana cara kerjanya. Termasuk ada tes yang langsung ditulis dalam HTML dan JS. Gunakan, lihat!

- Kedua, pertimbangkan dalam aplikasi yang sudah ada bahwa mereka dapat mengalami bfcache. Beri tahu penguji Anda tentang hal ini sehingga ketika mereka memeriksa navigasi, mereka tahu bahwa saat menavigasi melalui sejarah, halaman dapat dibuka baik dari server maupun dari bfcache. Ini adalah video bug nyata yang kami perbaiki ketika bfcache bekerja untuk kami:

Buka GIF

Pengguna memasukkan empat permintaan, melihat empat masalah. Setelah itu, ia kembali, melihat masalah 3 dan permintaan 4. Masalah sebelumnya lainnya adalah 2 dan permintaan 3. Artinya, ia memiliki keadaan halaman yang tidak cocok - konten string pencarian dan pencarian saling bertentangan. Ingatlah ini di aplikasi Anda.

- Dan ketiga, jika Anda menulis kode baru, pikirkan apakah Anda perlu bfcache. Jika demikian, gunakan tabel kompatibilitas API. Jika tidak, jangan gunakan, tetapi jika Anda secara tidak sengaja masuk ke bfcache, pertimbangkan fitur Safari dan peramban lain yang saya sebutkan. Beberapa hal dapat robek dengan tidak sopan, dan Anda tidak akan dapat memahami mengapa hal ini terjadi.

Seperti yang dijanjikan, tautan ke materi.

BFCache, atau Di sana dan kembali. Laporan Yandex