Topik temu duga representatif

Temu Duga Frontend: Bilakah HTTP 103 Early Hints Benar-benar Memperbaiki LCP?

FrontendSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Satu halaman merender HTML-nya melalui SSR dinamik. Bagaimanakah anda memutuskan sama ada HTTP 103 Early Hints akan menambah baik LCP?

Gesaan dan konteks

Anda memiliki laman utama e-dagang yang HTML bahagian atas lipatan (above-the-fold) mengambil masa untuk dijana. Cadangannya adalah untuk menghantar 103 Early Hints sebelum respons akhir supaya pelayar boleh memulakan CSS, fon, atau skrip kritikal. Terangkan bila ia membantu, cara mengelakkan muat turun pendua, dan cara mengesahkan perubahan LCP. Andaikan navigasi peringkat teratas melalui HTTP/2 atau HTTP/3, dengan pengepala Link yang betul masih dihantar pada respons akhir.

Perkara yang diuji oleh penemu duga

  • Sama ada anda menerangkan 103 sebagai petunjuk (hint) dan bukannya senarai sumber yang berwibawa: pelayar boleh menyambung atau membuat pramuat, sementara respons akhir kekal berwibawa.
  • Sama ada anda mengenal pasti masa berfikir pelayan sebagai tetingkap pertindihan; apabila pelayan boleh mengembalikan 200 dengan serta-merta, preload atau preconnect biasa pada respons utama adalah lebih mudah.
  • Sama ada anda merangkumi kestabilan sumber, caching, pengalihan silang asal (cross-origin redirect), sokongan pelayar, dan keperluan protokol.
  • Sama ada anda mengesahkan dengan LCP, penggunaan semula cache, permintaan pendua, dan ralat dan bukannya sekadar membaca kod status.

Soalan penjelasan sebelum menjawab

  1. Berapa lamakah masa pelayan sebelum bait pertama? Jika ia hampir sifar, terdapat sedikit pertindihan untuk diperoleh; optimumkan bahagian belakang atau petunjuk respons utama terlebih dahulu.
  2. Adakah sumber yang diberi petunjuk stabil dan perlu? Sumber yang bergantung kepada pengguna, eksperimen, atau kebenaran boleh dibazirkan apabila diteka terlalu awal.
  3. Adakah ini navigasi peringkat teratas melalui HTTP/2+? Pengendalian pelayar tertumpu pada navigasi, dan MDN mengesyorkan HTTP/2 atau lebih baharu.
  4. Adakah sumber boleh dicache? Pramuat yang tidak boleh dicache boleh dimuat turun semula selepas HTML tiba, mengubah petunjuk menjadi kerja tambahan.

Rangka kerja jawapan 30 saat

“Saya mula-mula mengesahkan bahawa halaman mempunyai masa berfikir pelayan yang bermakna dan ini adalah navigasi di mana klien menyokong 103. Saya kemudiannya hanya memberi petunjuk untuk CSS, fon, atau asal sambungan yang stabil dan boleh dicache, serta mengulangi pengepala Link yang betul dalam respons akhir. Saya mengelakkan petunjuk untuk sumber yang bergantung kepada eksperimen atau kebenaran. Sebelum dan selepas pelancaran, saya membandingkan pertindihan antara TTFB dan permintaan sumber, LCP, bait pendua, dan ralat; klien yang tidak menyokong 103 menggunakan laluan respons biasa.”

Jawapan mendalam langkah demi langkah

1. Kuantifikasikan tetingkap pertindihan

103 membolehkan pelayar menyambung atau mengambil sumber sementara pelayan menyediakan HTML akhir. Had atas yang berguna adalah kira-kira masa penyediaan pelayan ditolak masa di mana pelayar sebaliknya akan menemui sumber tersebut selepas respons akhir. Jika pelayan mengembalikan 200 dengan cepat, tetingkap tersebut hampir sifar; dalam kes itu Chrome mengesyorkan Link biasa atau link HTML.

2. Pilih sumber yang stabil daripada menyalin setiap petunjuk HTML

Early Hints tiba sebelum HTML akhir dan varian khusus pengguna diketahui. Calon yang baik termasuk CSS yang dikongsi, skrip biasa, fon, dan sambungan CDN kritikal. Imej diperibadikan, cabang eksperimen, dan sumber dengan kawalan kebenaran harus menunggu HTML. Bahagikan sumber kepada bahagian yang stabil untuk petunjuk dan bahagian dinamik untuk respons akhir apabila praktikal.

3. Anggap cache dan protokol sebagai syarat ketepatan

Halaman akhir mesti menggunakan semula sumber yang telah dipramuat. Jika ia tidak boleh dicache, pelayar mungkin memuat turunnya sekali daripada petunjuk dan sekali lagi selepas menghuraikan HTML. Fon silang asal juga memerlukan semantik crossorigin yang sepadan. MDN mengesyorkan menghantar 103 melalui HTTP/2 atau lebih baharu kerana klien lama dan perantara mungkin salah mengendalikan respons 1xx.

4. Kekalkan respons akhir sebagai berwibawa

Teruskan menghantar pengepala Link dalam respons akhir untuk klien yang mengabaikan 103 dan untuk sumber yang diketahui semasa merender HTML. Pengalihan silang asal boleh menyebabkan pelayar membuang sambungan dan sumber awal, jadi 103 bukanlah arahan muat turun yang tidak boleh dibatalkan.

5. Ukur eksperimen sebenar

Rawakkan navigasi sebenar dengan dan tanpa Early Hints. Rekod masa berfikir pelayan, masa mula permintaan sumber, LCP, bait pendua, dan kadar ralat. Chrome DevTools mendedahkan pemula Early Hints dan penggunaan semula cache, tetapi cache mesti kekal didayakan semasa ujian. Jika LCP tidak bertambah baik, periksa sama ada sumber telah sedia dicache, petunjuk tiba terlalu lewat, pengalihan telah membuangnya, atau masa pelayan bukanlah kekangan utama (bottleneck).

6. Bezakan dengan HTTP/2 Push

103 membekalkan petunjuk dan menyerahkan kawalan pengambilan kepada pelayar; HTTP/2 Push menghantar sumber secara aktif dan sering menduplikasi item yang telah dicache oleh pelayar. Pertukarannya ialah Early Hints masih memerlukan perjalanan pergi balik (round trip) dan bergantung pada sokongan pelayar, tetapi ia mengelakkan daripada mengambil alih kawalan daripada klien.

Contoh jawapan berkualiti tinggi

Saya akan bermula dengan masa sebelum bait pertama. Jika SSR mengambil masa 300 milisaat dan CSS utama serta fon adalah stabil pada setiap navigasi, 103 boleh bertindih dengan sambungan dan muat turun mereka dalam tempoh 300 milisaat tersebut. Saya hanya akan memberi petunjuk untuk sumber stabil yang boleh dicache, memasukkan crossorigin yang betul untuk fon silang asal, dan membiarkan imej diperibadikan serta skrip eksperimen kepada respons akhir. Respons akhir masih akan menyertakan Link supaya klien yang tidak disokong mempunyai sandaran biasa.

Saya tidak akan mendakwa bahawa menambah kod status menjamin kejayaan. Saya akan menjalankan eksperimen navigasi terkawal dan membandingkan LCP, masa mula permintaan, bait pendua, dan kadar pengalihan silang asal. Jika pelayan telah mengembalikan 200 dengan cepat, sumber berada dalam cache, atau halaman akhir sering menolak petunjuk tersebut, petunjuk respons utama biasa—atau tiada pramuat—adalah lebih selamat. Jawapan tersebut mendedahkan tetingkap faedah, kos tekaan yang salah, dan mekanisma sandaran.

Kesilapan biasa

  • Kesilapan → Menganggap 103 setaraf dengan 200. Mengapa ia gagal: 103 adalah maklumat (informational); respons akhir menentukan hasil dan sumber. Pembetulan: nyatakan bahawa petunjuk boleh diabaikan dan kekalkan pengepala Link akhir.
  • Kesilapan → Menyalin setiap preload HTML ke dalam 103. Mengapa ia gagal: varian pengguna tidak diketahui pada masa petunjuk dihantar, jadi sumber dinamik membazirkan lebar jalur. Pembetulan: pilih sumber yang stabil dan berkeberangkalian tinggi sahaja.
  • Kesilapan → Mengukur LCP sahaja. Mengapa ia gagal: pramuat yang tidak boleh dicache atau atribut cross-origin yang salah boleh bermula lebih awal sambil meningkatkan jumlah bait keseluruhan. Pembetulan: ukur penggunaan semula cache, permintaan pendua, lebar jalur, dan ralat juga.
  • Kesilapan → Menghantarnya kepada setiap permintaan HTTP/1.1. Mengapa ia gagal: pengendalian 1xx berbeza-beza dan Early Hints menyasarkan navigasi. Pembetulan: tapis mengikut protokol, jenis permintaan, dan keupayaan klien, dengan sandaran respons biasa.

Soalan susulan dan respons

Respons akhir sering beralih ke asal yang lain. Adakah anda masih akan menghantar 103?

Hanya dengan berhati-hati. Panduan MDN dan Chrome menyatakan bahawa pengalihan silang asal boleh menyebabkan pelayar membuang sambungan dan sumber awal. Hadkan petunjuk kepada titik masuk akhir yang stabil atau sumber sama asal (same-origin) yang bertahan daripada pengalihan, dan tetapkan ambang kadar pengalihan.

CSS berbeza antara kumpulan eksperimen. Apakah yang boleh anda beri sebagai petunjuk?

Beri petunjuk hanya untuk CSS yang dikongsi oleh setiap kumpulan; serahkan bahagian khusus eksperimen kepada HTML akhir. Jika tiada persilangan yang stabil, jangan buat pramuat. Kos lebar jalur bagi tekaan yang salah boleh melebihi masa menunggu yang dijimatkan.

Bagaimanakah anda membuktikan perolehan berpunca daripada 103 dan bukannya cache yang telah dipanaskan (warmed cache)?

Rawakkan kumpulan dengan keadaan cache yang sepadan dan laporkan cache sejuk dan panas secara berasingan. Ukur pertindihan antara permintaan sumber dan masa berfikir pelayan, bukan hanya satu nilai LCP; periksa pemula Early Hints, capaian cache (cache hits), dan muat turun pendua.

Bagaimana jika pelayar tidak menyokong arahan Early Hints tertentu?

Kekalkan Link akhir dan deklarasi HTML sebagai sandaran. Mulakan dengan preconnect yang disokong secara meluas, lancarkan preload mengikut matriks pelayar sasaran, dan pantau ralat.

Sumber awam

Soalan berkaitan