Meningkatkan kinerja situs web melalui unduhan CSS paralel?


15

Saya mengoptimalkan waktu pemuatan halaman situs web. Salah satu caranya adalah dengan menggabungkan beberapa permintaan HTTP untuk CSS menjadi satu permintaan HTTP gabungan. Tetapi salah satu pengulas mengajukan pertanyaan yang menarik: tidak akan melumpuhkan pengunduhan beberapa file CSS mengurangi waktu buka halaman?

Saya tidak pernah mempertimbangkan opsi ini, karena satu-satunya hal yang saya baca di internet adalah bahwa mengurangi jumlah (pemblokiran) permintaan HTTP adalah kunci untuk halaman web yang lebih cepat (meskipun Google Pagespeed Insights tampaknya tidak secara jelas menyatakan 1 ini ).

Saya melihat beberapa alasan mengapa parallellization tidak akan meningkatkan kinerja, atau hanya masalah yang sangat kecil (melebihi manfaat menggunakan lebih sedikit permintaan HTTP):

  • Menyiapkan koneksi baru itu mahal. Meskipun pengaturan beberapa koneksi dapat dilakukan secara paralel, browser akan menggunakan paling banyak sekitar 4-6 koneksi (tergantung pada browser), jadi mengunduh CSS secara paralel akan memblokir pengunduhan aset lain seperti JavaScript dan gambar.
  • Menyiapkan koneksi HTTPS membutuhkan beberapa data tambahan. Saya sudah membaca ini dengan mudah bisa menjadi beberapa KB data. Ini adalah beberapa data tambahan yang harus dikirim melalui kawat, bukan CSS yang sebenarnya ingin kami kirim.
  • Karena algoritma TCP Slow Start, semakin banyak data yang telah dikirim melalui koneksi, semakin cepat koneksi akan terjadi. Jadi koneksi yang bertahan lama sebenarnya mengirim data jauh lebih cepat daripada koneksi baru. Lihat misalnya protokol SPDY, yang menggunakan koneksi tunggal untuk meningkatkan waktu pemuatan halaman.
  • TCP adalah sebuah abstraksi: masih ada (biasanya) hanya satu koneksi yang mendasarinya. Jadi sementara banyak permintaan digunakan, data yang dikirim melalui kabel mungkin tidak perlu mendapat manfaat dari beberapa koneksi sama sekali untuk meningkatkan kecepatan.
  • Koneksi internet secara inheren tidak dapat diandalkan, terutama pada ponsel. Satu permintaan dapat diselesaikan secara signifikan lebih cepat dari yang lainnya. Menggunakan banyak permintaan untuk CSS berarti membuat halaman web diblokir sampai permintaan terakhir selesai, yang mungkin jauh lebih lambat daripada koneksi rata-rata.

Jadi, apakah ada manfaat sama sekali dalam memparalelkan permintaan HTTP untuk file CSS?

Catatan / perbarui: semua file CSS memblokir render. File CSS yang belum pernah dipindahkan di luar jalur kritis.


Saya melihat sesuatu pada kode etsy sebagai situs kerajinan di mana mereka merekomendasikan hanya menggunakan domain tanpa masak tunggal untuk objek statis (css, imgs, js). Ternyata browser modern melakukan pekerjaan luar biasa dengan unduhan paralel dari satu domain. Adapun beberapa file dari domain yang sama (file 10 css vs 1 besar), saya pikir Anda lebih baik menggabungkan dan memperkecil satu file besar dan hanya menjadikannya satu permintaan. Khususnya dengan CSS di mana situs Anda mungkin akan membutuhkan semua css agar terlihat benar.
Frank

Di satu sisi, browser sudah mengunduh secara paralel berdasarkan jumlah koneksi yang tersedia untuk digunakan. Ini didasarkan pada HTML yang sedang dibaca browser.
Sun

Jawaban:


14

File CSS yang ditautkan dari dokumen HTML ditambahkan ke antrian unduhan paralel saat HTML diurai; kuncinya adalah bahwa tautan JavaScript yang tidak sinkron memblokir parser HTML, mencegah tag yang kemudian ditambahkan ke antrian unduhan sampai JavaScript diunduh, diuraikan dan dieksekusi. [1]

Berikut adalah contoh yang memaksa browser untuk mengunduh tiga dari empat file secara berurutan (setidaknya tiga kali jalan-pulang):

<head>
  <script src="js/fizz.js"></script>
  <link rel="stylesheet" href="css/foo.css"/>
  <script src="js/buzz.js"></script>
  <link rel="stylesheet" href="css/bar.css"/>
</head>

Inilah contoh yang dikerjakan ulang sehingga semua 4 file diunduh secara paralel (setidaknya satu kali pulang pergi):

<head>
  <link rel="stylesheet" href="css/foo.css"/>
  <link rel="stylesheet" href="css/bar.css"/>
  <script async src="js/fizz.js"></script>
  <script src="js/buzz.js"></script>
</head>

Catatan lain: File CSS (secara default) render-blocking, bukan parser-blocking; halaman akan terus diuraikan dan DOM dibangun, tetapi render tidak akan dimulai sampai CSSOM dibangun.

Alasan utama untuk membagi CSS Anda, adalah untuk mendapatkan aturan minimum yang diperlukan untuk merender konten di atas ke klien dan diurai sesegera mungkin. Sisa aturan, untuk hal-hal yang tidak segera terlihat, dapat ditandai sebagai tidak-perlu-render-blok dengan mediakueri dalam tag tautan, atau ditambahkan ke halaman dengan memuat JavaScript yang tidak sinkron.

Jadi, tidak ada manfaat yang jelas untuk memparalelkan unduhan CSS Anda hanya untuk kepentingannya sendiri. Tapi seperti biasa, ukur dan uji!

Untuk bacaan lebih lanjut, saya merekomendasikan artikel ini pada 'Fundamentals Web: Mengoptimalkan Kinerja' dari Google: https://developers.google.com/web/fundamentals/performance/

[1]: Ini mengabaikan fitur Parsing Spekulatif dari beberapa browser:

https://docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=id-GB&forcehl=1

https://developer.mozilla.org/en-US/docs/Web/HTML/Optimizing_your_pages_for_speculative_parsing


1
Bacaan bagus lainnya, tentang cara menjaga agar skrip Anda tetap diunduh secara bersamaan, ada di sini: stackoverflow.com/questions/436411/…
joshreesjones

Perlu dicatat bahwa semua file .js harus ditautkan di akhir kode tepat sebelum tag penutup, dengan cara itu mereka tidak memblokir apa pun.
Chaoley

dapatkah Anda menjelaskan "Jadi, tidak ada manfaat yang jelas untuk memparalelkan unduhan CSS Anda hanya untuk kepentingannya sendiri"? Saya entah bagaimana tidak bisa mengetahuinya dari jawaban di atas
gaurav5430

@ gaurav5430 Tampaknya tidak ada alasan bagus untuk membelah file css, di luar mengoptimalkan waktu render di atas (dan mungkin optimasi cache?)
Robert K. Bell
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.