Mengapa tidak menyematkan gaya / skrip dalam HTML alih-alih menautkan?


41

Kami menggabungkan file CSS dan JavaScript untuk mengurangi jumlah permintaan HTTP, yang meningkatkan kinerja. Hasilnya adalah HTML seperti ini:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Jika kita punya logika sisi-server / build untuk melakukan semua ini untuk kita, mengapa tidak mengambil satu langkah lebih jauh dan menanamkan gaya dan skrip yang disatukan dalam HTML?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Itu dua permintaan HTTP lebih sedikit, namun saya belum melihat teknik ini dalam praktek. Kenapa tidak?


12
Saya menyalahkan caching.

Jawaban:


98

Karena menyimpan permintaan HTTP tidak banyak berguna ketika Anda mencapainya dengan memecah caching. Jika stylesheet dan skrip disajikan secara terpisah, mereka dapat di-cache dengan sangat baik dan diamortisasi pada banyak, banyak permintaan ke halaman yang sangat berbeda. Jika mereka di-bubur di halaman HTML yang sama, mereka harus ditransmisikan ulang dengan setiap. Tunggal. Permintaan.

HTML halaman ini, misalnya 13 KB sekarang. 180 KB CSS mencapai cache, dan begitu pula 360 KB JS. Kedua hit cache mengambil jumlah waktu yang sangat kecil dan praktis tidak menggunakan bandwidth. Keluarkan profiler jaringan browser Anda dan coba di beberapa situs lain.


1
Jika Anda melakukan situs gaya aplikasi satu halaman lalu di mana sebagian besar kode dikhususkan untuk satu halaman maka mungkin masih masuk akal?
JohnB

3
John: jika halaman dikunjungi hanya sekali, ya. Jika dikunjungi beberapa kali, semua barang yang disematkan akan dikirimkan beberapa kali, bukan hanya sekali dan di-cache.
Konerak

Catatan penting lainnya adalah bahwa dengan menyajikannya secara terpisah, Anda mengizinkan minifikasi sumber daya sehingga ukurannya lebih kecil.
maple_shaft

2
@maple_shaft Tolong jelaskan, mengapa Anda tidak dapat meminimalkan sumber daya seperti biasa dan kemudian memasukkannya?

1
@JohnB jangan lupa efek dari CDN atau caching lokal di ISP. Permintaan saya untuk javascript untuk google kemungkinan tidak pernah mencapai google bahkan jika saya memiliki cache yang hilang secara lokal karena orang lain yang menggunakan ISP yang sama akan telah menyebabkan ISP tersebut untuk men-cache data.

19

Hanya karena kinerja Web sangat penting! 99% kali ini akan memberi Anda waktu respons pengguna akhir yang lebih cepat.

Berikut adalah beberapa contoh dari Velocity Conf.

  • Bing - Halaman yang lebih lambat 2 detik menghasilkan penurunan pendapatan / pengguna 4,3%.
  • Google - Penundaan 400 milidetik menyebabkan penurunan 0,59% pada pencarian / pengguna.
  • Yahoo ! - Perlambatan 400 milidetik mengakibatkan penurunan lalu lintas halaman penuh 5-9%.
  • Shopzilla - Mempercepat situsnya hingga 5 detik meningkatkan tingkat konversi 7-12%, menggandakan jumlah sesi dari pemasaran mesin pencari, dan memotong setengah jumlah server yang diperlukan.
  • Mozilla - Mencukur 2,2 detik dari halaman arahan mereka meningkatkan konversi unduhan sebesar 15,4%, yang mereka perkirakan akan menghasilkan 60 juta lebih banyak unduhan Firefox per tahun.
  • Netflix - Mengadopsi optimasi tunggal, kompresi gzip, menghasilkan peningkatan kecepatan 13-25% dan memotong lalu lintas jaringan keluar sebesar 50%.

Dari Steve Souders, pelopor dalam Pengoptimalan Kinerja Web,

80-90% dari waktu respons pengguna akhir dihabiskan di frontend - Mulai di sini terlebih dahulu.

Menggunakan file eksternal menghasilkan halaman yang lebih cepat karena file JavaScript dan CSS di-cache oleh browser / jaringan / proksi (sebagaimana didefinisikan dalam protokol HTTP dengan header Cache). JavaScript dan CSS yang diuraikan dalam dokumen HTML dapat diunduh setiap kali dokumen HTML diminta. Ini mengurangi jumlah permintaan HTTP yang dibutuhkan, tetapi meningkatkan ukuran dokumen HTML. Jika Anda menggunakan skrip seperti Jquery, mudah untuk mereferensikan skrip 300 KB dan tidak percaya bahwa setiap orang memiliki bandwidth 100 MBit / s dengan latensi rendah, menjalankan satu aplikasi - peramban - dibuka di situs web Anda. 99% kali itu akan memberi Anda waktu respons pengguna akhir yang lebih cepat.

Frekuensi dimana komponen eksternal JavaScript dan CSS di-cache relatif terhadap jumlah dokumen HTML yang diminta juga penting. Jika pengguna di situs Anda memiliki beberapa tampilan halaman per sesi dan banyak halaman Anda menggunakan kembali skrip dan stylesheet (bundel) yang sama, ada potensi manfaat yang lebih besar dari file eksternal yang di-cache.

Tetapi inlining kadang-kadang-lebih disukai untuk aplikasi satu halaman atau situs web dengan satu tampilan halaman per sesi. Tidak ada aturan emas, dan umumnya melupakannya karena menyangkut terutama situs web yang sangat spesifik yang benar-benar terlibat oleh kinerja pengguna akhir.

Anda dapat membaca di sini mengapa kinerja penting (Penafian: Saya adalah pembuatnya)


3

Versi terbaru HTTP dibuat pada tahun 1999. Pada tahun 1999, semua orang terhubung ke Internet dengan dial-up. Internet sangat lambat. 16 tahun kemudian, banyak hal telah berubah, tetapi protokol yang kami gunakan belum.

Jawaban yang tidak seharusnya kita sebaris 'karena mengganggu caching' sedikit menyesatkan, terutama di era internet super cepat. Ketika Anda benar-benar melakukan perhitungan, sering kali ada perbedaan yang dapat diabaikan antara waktu pemuatan dengan pengguna yang melakukan cache-warm dan cache-cold jika Anda telah melakukan inline. Fakta bahwa ada adalah perbedaan kecil tidak inheren karena Anda telah inline, tetapi karena desain fleksibel dari HTTP / 1.1.

Protokol SPDY mengimplementasikan sesuatu yang disebut server push . Ini pada dasarnya membawa keluar dari dokumen HTML itu sendiri, dan ke dalam protokol. Server cerdas akan tahu sumber daya apa yang sudah dimiliki klien. Server bodoh hanya akan mengirim semuanya terlepas - itu masih akan menjadi manfaat kinerja, tetapi mungkin biaya dalam hal bandwidth. Jika peramban memiliki konten di dalam cache, ia dapat dengan mudah membuang salinan yang masuk. Server menunggu hingga HTML dimuat sebelum mengirim sumber daya tambahan - secara teori browser dapat mengirim sinyal untuk membatalkan dorongan server.

HTTP / 2.0 didasarkan pada SPDY dan kemungkinan besar akan mengimplementasikan server push, tetapi secara teori Anda dapat mulai menggunakan SPDY hari ini. Jadi alasan sebenarnya kami tidak sebaris adalah salah satu warisan - protokol yang ada saat ini sudah tua dan tidak cukup fleksibel untuk mencapai 'inlining tingkat protokol'.


2
Jawaban yang menarik, tetapi daripada "warisan" alasan yang Anda berikan untuk tidak sebaris saat ini adalah karena itu yang paling sesuai dengan infrastruktur protokol Web saat ini. Ini akan menjadi warisan jika semua orang masih melakukan hal yang sama dalam waktu n tahun ketika HTTP / 2.0 / SPDY sepenuhnya dikerahkan ;-)
andybuckley

2
Bisakah Anda memberikan kutipan, membuat sketsa perhitungan, atau setidaknya memberikan nomor kasar untuk "super cepat"? Orang-orang di negara-negara dunia pertama yang beradab dengan jumlah yang cukup besar untuk dibelanjakan secara online (baca: pelanggan) terkadang masih - atau bahkan sering - menjelajah dengan bandwidth kurang dari ratusan megabyte per detik. I untuk satu jarang mencapai lebih dari tiga MB / s, sering kurang dari 700 KB / s. Sebagai titik terpisah, Anda tidak memberikan alasan untuk menyesuaikan cara OP menyarankan (pada kenyataannya, Anda memberi alasan untuk tidak ), Anda memberikan alasan untuk mengoptimalkan protokol.

1
Koneksi 3G saya tidak persis "super cepat", dan tagihan telepon saya tidak menghargai data yang tidak perlu. Jangan lupa - tidak semua penggunaan data seluler ada di ponsel dengan tablet / laptop yang ditambatkan dan 3G. Esp. dengan laptop asumsinya adalah wifi / ethernet pada koneksi broadband rumah. Tidak dihargai ketika menambatkan jarak jauh ...
AnonJr

3

Selain masalah caching dan retrieving yang diajukan oleh jawaban lain, saya ingin menyoroti masalah lain yang lebih tidak jelas: parsing .

JavaScript yang muncul dalam HTML dapat mengalami masalah penguraian, seperti dalam contoh ini:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... yang berarti Anda harus mengubah skrip Anda untuk keluar dari beberapa karakter yang memicu dalam HTML. Masalah ini hilang ketika Anda menyediakan CSS dan JavaScript sebagai sumber daya eksternal, karena mereka tidak lagi harus memasukkan konteks penguraian 'induk' ke dalam akun.

Jika Anda menyajikan konten Anda sebagai XML, Anda harus menyiasatinya dengan menggunakan bagian CDATA. Namun, CDATA hadir dengan masalah serupa:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Hati-hati inliners.


1

Pemisahan konten dari penataan presentasi biasanya merupakan keuntungan yang lebih besar daripada permintaan http lebih sedikit.

Memisahkan semua gaya memungkinkan dan mendorong penggunaan kembali dan berbagi file.

Isi file juga akan lebih statis dan tersedia untuk caching di kedua server dan klien untuk halaman itu dan halaman lain yang dikunjungi.

Untuk Anda pertanyaan khusus ... Jika server dibuat untuk melakukan minifikasi sendiri, itu membuat aset lebih sulit untuk mempertahankan dan men-debug masalah. Namun banyak kerangka kerja sekarang melakukan ini di tingkat file, misalnya semua cs dan semua js. Misalnya kerangka ruby ​​on rails sekarang mengecilkan asetnya untuk produksi. 5-10 permintaan http tambahan biasanya bukan hambatan, lebih dari itu jika ada 100 permintaan http (yang sering Anda dapatkan dengan gambar).

Langkah ekstra sebenarnya termasuk kode di halaman itu sendiri akan memiliki kerugian dari halaman yang lebih besar bahwa Anda harus mengelola urutan unduhan dengan hati-hati dan halaman tidak dapat menampilkan konten sering tanpa sisa halaman (sekarang besar) sedang diunduh.


Untuk memperjelas, apakah Anda mengatakan pemisahan gaya dan konten bermanfaat bagi pengembang, atau manfaat kinerja di browser pengguna akhir?

Saya mengatakan bahwa manfaat keseluruhan bagi perusahaan biasanya merupakan kemenangan yang lebih besar daripada pengurangan permintaan dalam hal bisnis.
Michael Durrant

3
Anda benar-benar menyadari bahwa OP menganjurkan pengembangan dengan file-file terpisah dan hanya digabungkan selama penyebaran, bersama dengan minifikasi, kebingungan dan gabungan "biasa"? Anda dapat memiliki basis kode yang dapat dipelihara dan memakan manfaat kinerja juga. Ini adalah praktik umum dengan optimisasi pengelolaan kode lainnya, seperti memperkecil kode sumber dan menggabungkan beberapa file JS / CSS menjadi satu.

Saya tidak menyadarinya. Kata-kata "sematkan gaya dan skrip yang digabungkan itu dalam HTML?" membuatku bingung.
Michael Durrant

Untuk lebih jelasnya, saya memang bermaksud menyarankan apa yang telah @delnan jelaskan atas nama saya dalam komentarnya. Maaf jika frasa pertanyaan saya tidak jelas.
GladstoneKeep

1
  1. Minimalkan pengkodean duplikat. untuk menghemat waktu (Anda dapat menggunakan kembali gaya dan fungsi kode JS untuk satu halaman).
  2. Minimalkan upaya perubahan. (Jika klien Anda meminta Anda untuk mengubah warna tombol situs web. Anda harus membuka satu halaman per satu).
  3. Kurangi waktu buka (Jika duplikat CSS dan JS Anda berarti peningkatan ukuran halaman individual dan waktu yang diperlukan untuk mengunduh. Tetapi CSS JS umum tidak perlu diunduh lagi dan lagi).
  4. Penggunaan jarak jauh. (Anda dapat menempatkan CSS umum JS JS di tempat terpencil. bukan server yang dihosting sama)
  5. Kurangi waktu perbaikan Bug. Jika ada bug dalam satu fungsi Anda harus pergi halaman demi halaman untuk memperbaiki bug di JS dan CSS tertanam.
  6. Untuk meningkatkan SEO (cukup pisahkan konten dengan data meta)
  7. Lebih bersih dan dapat dimengerti kode (Jika Anda memasukkan semua file dalam satu debug file dan kejelasan kode hilang. Dan setiap halaman akan menjadi halaman yang sangat panjang).
  8. Selain itu, ini akan membantu Anda mengurangi ukuran produk.
  9. Tapi tetap saja Anda bisa mempertimbangkan untuk menanamkan hal paling unik di halaman yang sama.

0

Kita tidak boleh menanamkan gaya / skrip ke HTML karena

Gaya / skrip tersemat harus diunduh dengan setiap permintaan halaman:

Gaya ini tidak bisa di-cache oleh browser dan digunakan kembali untuk halaman lain. Karena itu, disarankan untuk menyematkan jumlah minimal CSS / JS.

alih-alih, kami menggunakan tautan karena kami menggunakan tautan untuk mengikat css / skrip

Kecepatan situs meningkat untuk permintaan beberapa halaman:

Ketika seseorang pertama kali mengunjungi situs web Anda, peramban mereka mengunduh HTML dari halaman saat ini plus file CSS dan JS yang ditautkan. Ketika mereka menavigasi ke halaman lain, browser mereka hanya perlu mengunduh HTML dari halaman baru, file CSS / JS di-cache sehingga tidak perlu diunduh lagi. Ini dapat membuat perbedaan besar terutama jika Anda memiliki file gaya dan skrip yang besar.

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.