Situs masih memuat terlalu lambat. Pada saat paling kritis dari proses pengunduhan, saluran seringkali hampir sepenuhnya tidak digunakan. Teknologi baru Fastly, yang diusulkan oleh insinyur Kazuho Oku, akan membantu memanfaatkan lebih baik beberapa detik pertama yang kritis ini.

Pernahkah Anda mengunduh situs web di ponsel Anda - dan mencari 10 detik pada halaman tanpa teks? Tidak ada yang suka duduk dan melihat layar kosong sementara beberapa font yang tidak biasa dimuat. Oleh karena itu, masuk akal untuk mentransfer pemuatan hal-hal penting sedemikian cepat mungkin. Preload Link rel = preload seharusnya menyelesaikan sebagian masalah. Pertama, browser mem-parsing header HTTP, jadi ini adalah tempat yang tepat untuk menunjuk ke preloading sumber daya yang Anda pasti akan butuhkan nanti.

Secara default, Internet lambat

Mari kita lihat apa yang terjadi jika Anda tidak menggunakan preload. Peramban hanya dapat mulai memuat sumber daya setelah diketahui bahwa ia membutuhkannya. Ini kemungkinan besar terjadi pada sumber daya yang ada di HTML selama parsing awal dokumen (misalnya, <script> , <link rel=stylesheet> dan <img> ).

Sumber daya yang terdeteksi setelah membangun pohon render diunduh lebih lambat (ini adalah tempat di mana halaman melambat karena pemuatan font, karena untuk memahami ini, Anda pertama-tama perlu memuat stylesheet, parsing, buat model objek CSS, dan kemudian pohon render).

Bahkan lebih lambat memuat sumber daya yang ditambahkan ke dokumen menggunakan JavaScript loader yang dipicu oleh peristiwa seperti DOMContentLoaded . Jika Anda menyatukan semuanya, kami mendapatkan air terjun yang tidak dioptimalkan dan agak tidak berarti. Sebagian besar saluran tidak digunakan, dan sumber daya dimuat lebih awal dari yang diperlukan atau terlambat:

Tautan rel = preload sangat membantu

Dalam beberapa tahun terakhir, situasinya telah membaik berkat Link rel = preload . Sebagai contoh:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Berkat arahan ini, browser dapat mulai memuat sumber daya segera setelah menerima tajuk dan sebelum memulai analisis tubuh HTML:



Ini adalah peningkatan yang signifikan, terutama untuk halaman besar dan sumber daya kritis yang kalau tidak akan ditemukan terlambat. Khusus untuk font, tetapi apa pun bisa menjadi sumber penting, seperti file data yang diperlukan untuk memuat aplikasi JavaScript.

Namun, kita bisa berbuat lebih banyak. Lagi pula, browser tidak melakukan apa pun antara saat ketika selesai mengirim permintaan, dan ketika menerima byte pertama dari respons (fragmen hijau besar pada permintaan awal lebih tinggi).

Kami menggunakan waktu "pemikiran server" dengan bantuan "kiat awal"

Di sisi lain, server benar-benar sibuk. Ini menghasilkan respons dan menentukan apakah berhasil atau tidak. Setelah mengakses database, panggilan API, otentikasi, dll. server dapat memutuskan bahwa kesalahan 404 adalah jawaban yang benar.

Kadang-kadang waktu meditasi server kurang dari latensi jaringan. Terkadang jauh lebih banyak. Tetapi penting untuk dipahami bahwa mereka tidak tumpang tindih. Sementara server berpikir, kami tidak mengirim data ke klien.

Tetapi menarik bahwa bahkan sebelum menghasilkan jawaban, Anda sudah tahu beberapa gaya dan font yang perlu Anda unduh untuk menampilkan halaman. Lagipula, halaman kesalahan biasanya menggunakan identitas dan desain perusahaan yang sama dengan halaman biasa. Akan sangat bagus untuk mengirim Link: rel=preload ini Link: rel=preload sebelum server bekerja . Itulah sebabnya standar Petunjuk Awal , disusun dalam RFC8297 oleh Kelompok Kerja HTTP, diciptakan oleh Fastly, rekan saya Kazuho Oku. Mengevaluasi keajaiban beberapa bilah status dalam satu jawaban :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

Server dapat merekam kode respons pertama yang disebut "informasi" , segera setelah menerima permintaan, dan mengirimkannya ke jaringan. Kemudian dia akan berurusan dengan definisi reaksi nyata dan generasinya. Sementara itu, di browser, Anda dapat mulai melakukan preloading lebih awal:



Tentu saja, ini akan memerlukan perubahan tertentu dalam pengoperasian browser, server dan CDN, dan pengembang dari beberapa browser telah menyatakan keberatan tentang kesulitan implementasi. Oleh karena itu, masih belum jelas kapan header ini dapat dioperasikan. Anda dapat melacak kemajuan dalam pelacak publik untuk Chrome dan Firefox .

Kami berharap bahwa pada akhirnya, Anda akan dapat mengeluarkan header Petunjuk Awal langsung dari Fastly, masih mengirimkan permintaan dengan cara standar. Kami belum memutuskan cara mengatur antarmuka melalui VCL, jadi beri tahu saya jika Anda memiliki keinginan tentang hal ini!

Tetapi bagaimana dengan HTTP / 2 Server Push?

Dengan HTTP / 2, ada teknologi baru yang disebut Server Push yang tampaknya menyelesaikan masalah yang sama dengan Link rel = preload dalam jawaban Early Petunjuk. Meskipun ini benar-benar berfungsi (dan Anda bahkan dapat dengan cepat menghasilkan push kustom dari server tepi dalam Fastly), ada perbedaan signifikan pada beberapa poin:

• Server tidak tahu tentang ketersediaan sumber daya pada klien, sehingga sering mendorongnya secara tidak perlu. Karena buffer jaringan dan latensi, klien biasanya tidak dapat membatalkan pengiriman sebelum menerima semua konten. (Meskipun ada solusi yang mungkin untuk masalah ini, dalam bentuk usulan Cache Digest , yang sedang dikerjakan Kazuho dengan Joam Weiss dari Akamai).
• Sumber daya yang dialirkan terkait dengan koneksi, sehingga mudah untuk memulai sumber daya yang tidak digunakan klien, karena mencoba untuk mendapatkannya melalui koneksi lain. Klien mungkin perlu menggunakan koneksi yang berbeda karena sumber daya berada di sumber yang berbeda dengan sertifikat TLS yang berbeda atau karena diambil dalam mode kredensial yang berbeda.
• H2 Push tidak terlalu konsisten diimplementasikan di browser yang berbeda. Karena itu, sulit untuk memprediksi apakah itu akan berhasil atau tidak dalam kasus khusus Anda.

Dengan satu atau lain cara, Petunjuk Awal dan Server Push menawarkan pengorbanan yang berbeda. Petunjuk awal memberikan penggunaan jaringan yang lebih efisien dalam pertukaran untuk pertukaran paket tambahan. Jika Anda mengharapkan latensi jaringan kecil dan waktu yang lama untuk memikirkan server, maka Petunjuk Awal adalah solusi yang tepat.

Namun, ini tidak selalu terjadi. Mari kita optimis dan bayangkan bahwa orang akan segera menetap di Mars. Mereka akan menelusuri web dengan penundaan selama 20-45 menit untuk setiap pertukaran paket, sehingga pertukaran tambahan itu sangat menyakitkan, dan waktu server dapat diabaikan dibandingkan dengan itu. Server Push dengan mudah menang di sini. Tetapi jika kita pernah melihat halaman web dari Mars, kita lebih cenderung mengunduh beberapa jenis paket data, sesuatu seperti paket web sekarang ditawarkan dan menandatangani pertukaran .

Bonus Ekstra: Permintaan Runtuh Lebih Cepat

Meskipun Early Hints seharusnya digunakan terutama di browser, ada manfaat potensial yang menarik untuk CDN. Ketika Fastly menerima banyak permintaan untuk sumber daya yang sama, kami biasanya hanya mengirim satu dari mereka ke sumber, dan menempatkan sisanya dalam antrian menunggu. Proses ini dikenal sebagai permintaan runtuh . Jika respons dari sumber menyertakan Cache-Control: private , maka Anda harus menghapus semua permintaan dari antrian dan mengirimkannya secara terpisah ke sumber, karena kami tidak dapat menggunakan satu jawaban untuk memenuhi beberapa permintaan.

Kami tidak dapat membuat keputusan sampai respons diterima untuk permintaan pertama, tetapi dalam kasus dukungan Petunjuk Awal, jika server mengembalikan respons Petunjuk Awal dengan tajuk Kontrol Tembolok, kami akan tahu jauh sebelumnya bahwa antrian tidak dapat diciutkan menjadi satu permintaan, tetapi sebagai gantinya segera kirimkan semua permintaan dari antrian ke sumber.

Pesan konten yang kurang penting dengan tips prioritas

Kiat awal adalah cara yang bagus untuk mengakses beberapa objek paling berharga dalam antrian (air terjun): ketika jaringan diam, pengguna menunggu, hanya ada satu permintaan di jalan, dan tidak ada apa pun di layar. Tetapi segera setelah HTML dimuat dan halaman dianalisis, jumlah sumber daya yang perlu dimuat meningkat secara dramatis. Sekarang penting untuk tidak memuat sumber daya secepat mungkin, tetapi untuk memuatnya dalam urutan yang benar. Peramban menggunakan susunan heuristik yang sangat kompleks untuk secara independen menentukan prioritas unduhan, tetapi jika Anda ingin mendefinisikannya kembali, maka di masa depan ini dapat dilakukan dengan menggunakan Petunjuk Prioritas :

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

Dengan atribut baru yang penting ini, pengembang dapat mengontrol urutan muatan sumber daya jika terjadi persaingan untuk jaringan. Mungkin sumber daya prioritas rendah dapat ditunda hingga prosesor dan jaringan bebas, atau tergantung pada jenis perangkat.

Bisakah ini digunakan?

Baik petunjuk awal maupun petunjuk prioritas belum menjadi standar. Baru-baru ini, H2O, server HTTP / 2 yang digunakan dan didukung oleh Fastly, mulai menggunakan Petunjuk Awal (lihat PR 1727 dan 1767 ), dan ada niat untuk mengimplementasikan Petunjuk Prioritas di Chrome , serta secara aktif melacak respons 1xx. Pada saat yang sama, tidak ada salahnya mulai mengirim Petunjuk Awal sekarang - dan jika Anda ingin maju dari tren, maka pergilah!