Memuat CSS pada halaman adalah operasi pemblokiran. Jika pemuatan JavaScript yang tidak sinkron mungkin tidak terlihat oleh pengguna, maka penampilan gaya yang lambat dapat mendorong tamu yang tidak sabar dari situs. Bagaimana cara memuat CSS seefisien dan semulus mungkin bagi pengguna? Nikita Dubko berusaha mencari tahuDarkMeFoDy dari grup antarmuka pencarian Yandex di Minsk.- Halo semuanya. Saya akan bercerita tentang gaya. Semua orang berbicara tentang TypeScript dan TypeScript hari ini. Dan saya akan berbicara tentang skrip gaya Cascade.Tak lama tentang diriku. Saya seorang pengembang Belarusia - setelah film Dudya saya akan mengatakan itu di mana-mana. Anda mungkin pernah mendengar suara saya di podcast Standar Web, dan jika Anda melihat kesalahan ketik di umpan berita Standar Web, itu mungkin saya juga.Penafian kecil. Akan ada beberapa kegilaan dalam laporan ini - perlakukan semua yang saya katakan dengan kritik besar. Pikirkan tentang mengapa Anda dapat menggunakan teknik seperti itu, dan mengapa Anda tidak membutuhkannya. Beberapa hal akan menjadi sangat gila. Pergilah.Untuk apa?
Untuk mulai dengan - mengapa berbicara tentang optimasi CSS sama sekali?Jika Anda mulai mencari di mesin pencari untuk unduhan JS cepat, ada banyak hasil. Jika Anda mencari pemuatan CSS cepat, maka bagian atas bahkan tidak menampilkan CSS yang Anda butuhkan.
Jika Anda melihat Google, ada 111 juta hasil tentang JS, dan tentang CSS hanya 26 juta.Jadi mungkin ini tidak masalah? Mengapa membicarakannya? Jika Anda mencari laporan kinerja JS, Anda akan menemukan banyak di antaranya. Ada tentang React, tentang segala macam kerangka kerja lain, tentang Vanilla, dll. Tetapi tentang CSS, saya hanya menemukan satu laporan. Harry Roberts pada 2018 membaca laporan keren tentang kinerja CSS. Saya pikir saya menemukan laporan keduaoleh Roma Dvornova, “Parsim CSS: tips & trik kinerja”. Tetapi ternyata menjadi laporan JS yang mem-parsing CSS. Bukan yang kita butuhkan.Ternyata mereka tidak terlalu memikirkan CSS. Memalukan.Tetapi ketika saya pergi ke web, saya biasanya melihat HTML. Dan saya juga melihat CSS yang menyesuaikan tampilan halaman. Tapi saya tidak melihat JS. JS adalah hal yang menggerakkan CSS dan HTML pada sebuah halaman untuk membuat semuanya terlihat indah. Ini skrip. Dan jika JS tidak memuat, itu tidak seburuk jika CSS tidak memuat.Kesalahan dalam JS jatuh ke konsol. Dan rata-rata pengguna tidak mungkin masuk ke DevTools untuk melihat: "Oh, Anda memilikinya di sana, kesalahan di konsol." Tetapi jika CSS tidak memuat, maka Anda mungkin tidak melihat semua yang Anda butuhkan sama sekali.Ngomong-ngomong, ada penelitian tentang fakta bahwa hal utama adalah membuat kesan pertama.38% pengguna dapat pergi ke situs, dan jika mereka melihat itu menjijikkan, mereka akan segera pergi. Dan 88% akan mentolerir, menggunakannya sekali, dan kemudian mereka tidak akan pernah kembali dan tidak mungkin memberi saran situs Anda.Sekarang kita semua duduk di rumah, lalu lintas internet telah berkembang. Dan kita perlu memikirkan cara memberikan sumber daya secara efisien kepada pengguna.Mari kita coba hitung dari sudut pandang Yandex. Jika kami dapat mengoptimalkan setiap pengiriman Yandex selama 100 ms dan memberi, katakanlah, 200 juta halaman per hari (saya tidak tahu angka pastinya), maka hari ini kami akan menghemat 0,1 s * 200 juta = 232 orang-hari. Hanya dengan mengoptimalkan output selama 100 milidetik. Dan CSS juga melakukannya.Mari kita mainkan sedikit detektif dan mencari tahu cara memaksimalkan gaya pemuatan.Mengukur!
Nasihat pertama adalah selalu mengukur segalanya. Tidak ada gunanya melakukan optimasi secara teoritis. Anda dapat mengasumsikan bahwa optimasi berfungsi dalam kasus Anda, tetapi pengukuran nyata akan menunjukkan bahwa tidak ada yang sejenis. Ini adalah aturan paling penting dari optimasi apa pun. Andrei Prokopyuk dari tim Kecepatan SERP di HolyJS berbicara dengan sangat baik tentang bagaimana kita melakukan ini , saya tidak akan mengulangi lagi.Apa alat pengukuran yang ada?- Jika Anda ingin mengukur lebih atau kurang pada perangkat nyata, lambat, tidak sekeren milik Anda, gunakan WebPageTest . Saya biasanya melakukan pengukuran di sana.- Anda memiliki Mercusuar jika Anda menggunakan browser berbasis Chromium. Dia, seperti pengukuran lokal, menunjukkan hal-hal yang cukup bagus.- Jika Anda yakin dapat melakukan semuanya sendiri, buka DevTools, ke tab Performance. Ini memiliki banyak detail, Anda dapat memulai metrik Anda sendiri dan menganalisisnya.
Secara alami, dalam Kinerja perlu mengatur kondisi nyata. Anda duduk di laptop keren Anda dengan Internet keren di kantor, semuanya luar biasa di sini, tetapi mereka datang kepada Anda dan berkata: "Saya lambat." Dan Anda berkata: "Semuanya bekerja untuk saya." Jangan lakukan seperti ini.Selalu mencoba untuk memeriksa bagaimana pengguna dalam kondisi kereta bawah tanah atau di tempat lain akan menggunakan situs Anda. Untuk melakukan ini, Anda perlu mengatur Internet yang sangat lambat. Dianjurkan untuk memperlambat CPU, karena seseorang dapat datang kepada Anda dari beberapa Nokia 3110. Dia juga perlu menunjukkan situs tersebut.Paling penting: ukur pada pengguna nyata. Ada metrik seperti itu, lebih tepatnya, serangkaian metrik - RUM, Pemantauan Pengguna Nyata. Ini adalah saat Anda mengukur bukan apa yang secara sintetis terjadi dalam kode Anda, tetapi metrik pada pengguna nyata dalam produksi. Misalnya, dari memuat halaman ke tindakan. Tindakan adalah, misalnya, sesuatu yang berfungsi di browser atau bahkan klik pada beberapa elemen penting.Ingatlah bahwa Anda tidak berkembang untuk robot. Sotka di Mercusuar - sangat bagus, sangat bagus. Jadi, Anda memenuhi setidaknya persyaratan yang ditetapkan Mercusuar. Tetapi ada pengguna nyata, dan jika pengguna tidak dapat melihat halaman saat naik-turun di Mercusuar, maka Anda melakukan sesuatu yang salah.
Ada metrik yang penting untuk difokuskan. Ini adalah Cat Contentful Pertama, ketika konten pertama muncul di halaman Anda dengan mana Anda dapat melakukan sesuatu, baca. Metrik ini dikirim di browser Chromium, Anda bisa mendapatkannya.
Baru-baru ini, Anda masih dapat melihat Cat Konten Terbesar. Sering terjadi bahwa Anda memiliki halaman media, dan penting, misalnya, untuk melihat foto di atasnya. Maka Anda perlu metrik khusus ini.Pemuatan CSS
Mari kita beralih ke CSS, bagaimana CSS dimuat. Resepsi sudah lama dikenal. Ada Jalur Rendering Kritis, jalur render kritis. Ini tentang apa yang dilakukan browser dari saat mengirim permintaan sumber daya hingga saat piksel ditampilkan di layar pengguna. Tentang ini juga, ada banyak artikel dan laporan. Tapi mari kita lihat bagaimana browser ini melakukannya.<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CSS — </title>
<link rel="stylesheet" href="/main.ac74gsac.css">
</head>
Dia mulai mengunduh HTML, melihat tag. Dia secara bertahap mengurai mereka, mengerti apa yang harus dilakukan dengan mereka. Banyak. Datang melintasi tautan. Itu harus digunakan. Tapi bagaimana caranya? Pertama, Anda perlu mengunduhnya. Pengunduhan berjalan lambat. Saat dimuat, itu mulai mengurai halaman lebih lanjut. <!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CSS — </title>
<link rel="stylesheet" href="/main.ac74gsac.css">
</head>
<body>
<h1>-!</h1>
</body>
</html>
Jika tersandung pada tautan lain, itu diblokir lagi dan tidak memungkinkan eksekusi. Blok JS, blok parsing. Dan sampai sepatu itu menyala, ia tidak melakukan apa pun. Tapi kemudian mulai bekerja lebih jauh.<link>
Mari kita menggali lebih dalam - apa yang terjadi ketika Anda mengakses tautan?
Merekam kemana kita pergi adalah standar. Ada gaya CSS yang terletak di suatu tempat. Sekarang modis untuk meletakkan semua statika di CDN.Ke mana harus pergi?
Pertama, browser perlu memahami ke mana harus pergi.
Dia melihat URL, dan dia perlu memahami URL ini - tentang apa ini? Kami terbiasa dengan fakta bahwa URL adalah pengidentifikasi situs.
Tetapi secara fisik kita perlu mendapatkan alamat IP dari URL ini dan pergi ke mesin fisik yang sebenarnya di alamat IP.
Untuk CDN Anda, itu akan menerima catatan dalam DNS dan benar-benar akan langsung menuju ke alamat IP. Bagaimana seseorang bisa mempercepat dalam kasus ini?
Gagasan gila adalah mengurangi jarak dari pengguna ke server DNS. Ambil dan transplantasi pengguna. Misalnya, untuk menampilkan pesan: "Duduk lebih dekat" atau "Bergerak lebih dekat".Anda dapat segera menentukan alamat IP di tautan. Mengapa kita perlu mencari DNS, menyelesaikan domain, jika Anda dapat segera memberikan hasilnya dengan alamat IP? Ini adalah cara yang gila, tetapi dalam kasus server DNS global DDoS itu bahkan dapat menyelamatkan Anda.Dan kita dapat menyingkirkan mendapatkan alamat IP.
Beralih ke index.html Anda atau ke file lain, Anda sudah tahu alamat domain ke mana Anda pergi. Inilah yang terjadi ketika, alih-alih menyimpan statika pada domain atau subdomain terpisah, Anda dapat menempatkan statika lebih dekat ke domain Anda, yaitu domain ini sendiri. Maka DNS tidak perlu diselesaikan, itu sudah ada.
Kami tahu ke mana harus pergi. Tetapi kita dapat melakukan hal-hal seperti itu untuk browser terlebih dahulu. Jika, misalnya, style sheet Anda dimuat jauh kemudian melalui pohon DOM, Anda dapat memberi tahu browser menggunakan <link rel = "dns-prefetch"> bahwa "Saya belum pergi ke sana, tetapi Anda akan menghangatkan sumber dayanya, saya pasti akan membutuhkannya nanti ".Dengan entri ini, Anda memberi tahu browser untuk turun dan mendapatkan DNS ini. Saat tautan muncul dalam kode, peramban akan tahu alamat IP dari domain ini. Anda dapat melakukan hal-hal pendahuluan seperti itu. Hal yang sama, misalnya, sebelum memasuki halaman berikutnya, ke mana Anda pasti akan pergi.Oke, browser tahu ke mana harus pergi. Dia perlu mengerti bagaimana cara pergi.Bagaimana untuk pergi
Kami mengawasi protokolnya. Sekarang, tentu saja, https adalah persyaratan langsung. Termasuk mesin pencari akan menandai situs Anda tidak di https dengan formulir sebagai tidak sepenuhnya aman.Saya menemukan serangkaian komik yang luar biasa tentang cara kerja papan https. Tapi kami adalah orang-orang IT, kami suka diagram yang rumit, dan komik lucu terlalu mudah.
Di sini saya telah merumuskan dengan kata-kata saya sendiri cara kerja https. Pertama, Anda mendapatkan sertifikat SSL dari server Anda. Maka Anda harus memeriksa sertifikat di otoritas sertifikasi. Ini adalah server khusus yang tahu apa yang valid dan apa yang tidak, dan dapat meminta browser: "ya, semuanya baik-baik saja di sini, gunakan sertifikat ini".Berikutnya adalah generasi kunci untuk komunikasi antara server dan klien, enkripsi, dekripsi menggunakan kunci yang berbeda. Prosesnya menarik jika Anda melihatnya dari segi kriptografi. Tapi kami ingin mempercepat. Bagaimana?
Kami dapat kembali mentransfer pengguna lebih dekat ke server. Kami sudah memiliki DNS, sekarang kami bisa mendekatkannya ke otoritas sertifikasi. Dan untuk menempatkan antara server ini akan menjadi sempurna.Anda dapat memilih keluar dari https, mengapa kami membutuhkannya? Kami menghabiskan waktu untuk mendapatkan sertifikat, mengenkripsi, mendekripsi. Tidak juga. Ini adalah saran paling berbahaya dalam laporan, jangan lakukan itu. https adalah perlindungan data pengguna, dan http / 2 tidak akan berfungsi tanpa https, dan http / 2 adalah cara lain untuk mempercepat.Ada juga teknologi Stapling OCSP. Anda dapat memverifikasi sertifikat tanpa otoritas sertifikasi. Ini mungkin lebih dekat ke DevOps. Anda perlu mengonfigurasi server Anda dengan cara tertentu sehingga dapat menembolok respons Otoritas Sertifikasi dan mengeluarkan masalah kepada pengguna: "Percayalah, sertifikat saya benar-benar nyata." Dengan demikian, setidaknya kami dapat menyimpan langkah yang kami lakukan kepada Otoritas Sertifikasi.Tetapi ada nuansa - di Chrome ini tidak berfungsi, dan untuk waktu yang lama. Tetapi untuk pengguna browser lain, Anda dapat mempercepat proses ini.Saya sudah mengatakan dua kali bahwa perlu untuk mentransplantasi pengguna, dan idenya melayang di udara - untuk memindahkan server lebih dekat ke pengguna. Saya belum menemukan sesuatu yang baru untuk Anda. Ini adalah CDN, jaringan pengiriman konten yang didistribusikan. Idenya adalah bahwa Anda dapat menggunakan sidienki yang sudah jadi, secara mandiri membuat infrastruktur Anda sendiri dan menempatkan banyak server di seluruh dunia, sejauh uang dan peluang memungkinkan Anda. Tetapi Anda perlu mengatur server sehingga pengguna dari Australia pergi ke server Australia. Di sini kecepatan cahaya bermain pada Anda, semakin kecil jaraknya, semakin cepat elektron melewatinya.Mari menggali lebih dalam. Apa lagi yang terjadi dalam permintaan? Sebenarnya, https hanyalah pembungkus dari http. Bukan hanya pembungkus keren. Dan jika itu bahkan lebih dalam, maka http adalah permintaan dari keluarga TCP / IP.
Bagaimana paket dan byte dikirim pada jaringan sehingga semua browser, klien, dan server saling berkomunikasi? Hal pertama yang dilakukan klien / server melalui koneksi TCP / IP adalah jabat tangan.Namun pada tahun 2020, WHO merekomendasikan menghindari jabat tangan. Ada teknologi TCP Fast Open yang keren. Anda dapat, pada saat jabat tangan, menghindari seluruh rantai "Halo, saya seorang klien" - "Halo, saya seorang server" - "Saya percaya Anda" - "Dan saya percaya Anda. Pergilah". Anda sudah dapat mengirim data berguna saat ini. Dan jika jabat tangan itu berhasil, maka sebagian dari data berguna telah berlalu. Ini TCP Fast Open.Apa yang harus dijemput?
Mari kita cari tahu apa yang harus diambil klien dari server. Yang utama bukanlah klien mengambil sesuatu dari server, tetapi server memberikan data kepada klien. Maka Anda mungkin berpikir: User-Agent. Saya bisa mendapatkan Agen-Pengguna dari klien, mencari tahu di browser mana pengguna telah login. Cari tahu kira-kira jika itu tidak menipu saya, browser ini..example {
display: -ms-grid;
display: grid;
-webkit-transition: all .5s;
-o-transition: all .5s;
transition: all .5s;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
background: -webkit-gradient(linear, left top, left bottom, from(white), to(black));
background: -o-linear-gradient(top, white, black);
background: linear-gradient(to bottom, white, black);
}
Katakanlah dia masuk dari Firefox. Saya, seperti biasa, memiliki perakitan di mana autoprefixer terhubung dangkal, ia telah menghasilkan banyak kode untuk saya. Ya, ini adalah pendekatan keren bahwa semuanya akan bekerja di mana saja. Tapi saya sudah tahu bahwa pengguna telah masuk dari Firefox.Mengapa tidak mematikan semua kelebihannya? Setuju, ada lebih sedikit garis, kami mengirim lebih sedikit byte, ini keren.Kami memiliki versi lite SERP, Nenek. Vitaly Kharisov membicarakannyavithar, laporan kelas pada Hari Standar Web. Ia menggunakan pendekatan ini dengan tepat. Kami dapat menghasilkan beberapa bundel dan memberikannya kepada klien yang berbeda dengan cara yang berbeda. Bobotnya jauh lebih sedikit, karena Firefox mendapatkan miliknya sendiri, WebKit mendapatkan miliknya sendiri, dan ia berfungsi, itu diverifikasi.
Lebih lanjut. Kami kemungkinan besar memproses permintaan pengguna, kami tahu bahwa orang tersebut berwenang dan menggunakan beberapa informasi pribadi untuknya. Adalah logis bahwa kita harus mendapatkan sesuatu dari basis data. Tapi tidak semua! Ada hal-hal statis yang tidak berbeda untuk salah satu pengguna, mereka persis sama.James Akvuh membaca laporan keren tentang itu“Rendering Sisi-Server. Lakukan sendiri". Apa intinya? Anda sudah tahu bahwa Anda memiliki HTML dan beberapa jenis CSS yang sama untuk semua pengguna. Sebelum Anda mencari data apa pun, Anda dapat menghasilkan output dari data statis ini, segera kirim yang paling berguna dalam aliran dari server. Dan setelah itu - cari datanya, cepat terima, ubah menjadi templat dan berikan ke klien. Dan pengguna sudah akan melihat sesuatu yang bermanfaat.
Itu tidak sulit. Anda perlu mengonfigurasi beberapa tajuk di server, dan semuanya akan mulai berfungsi. Jika browser tidak tahu judul ini, tidak ada yang akan pecah, ini yang paling indah. Mari kita menggali lebih jauh. TCP Kami sudah membicarakan ini: jabat tangan, byte dikirim.
Cuci tangan setelah berjabat tangan. Namun dalam hal TCP, kami mulai meneruskan byte, dan algoritmanya cukup optimal sehingga server klien tidak siaga.Oleh karena itu, segmen data tertentu dikirim terlebih dahulu. Secara default, (ini Anda dapat mengubah dalam pengaturan) adalah 1460 byte. Server tidak mengirim informasi pada satu segmen. Dia mengirim windows.Jendela pertama adalah 14600 byte, sepuluh segmen. Lalu, jika koneksinya baik, ia mulai memperbesar windows. Jika koneksi buruk, ini dapat mengurangi jendela. Apa yang penting untuk dipahami? Ada jendela pertama dari sepuluh segmen, di mana Anda harus masuk ke seluruh situs, jika Anda mau. Dan kemudian akan ada kecepatan maksimum penampilan konten. Vitaliy Kharisov juga membaca laporan tentang ini . Dan ya, memungkinkan untuk mencocokkan situs dengan semua yang Anda butuhkan dalam satu jendela jika Anda mematikan, misalnya, JS.Nuansa yang penting. Saat Anda mengisi seluruh segmen, itu adalah satu segmen. Tetapi jika Anda mengirim hanya satu byte tambahan, server masih akan mengirim seluruh segmen ekstra.
Anda dapat melakukan optimasi yang keren, mengurangi output dengan satu kilobyte, tetapi Anda tidak akan melihat apa pun pada pengukuran Anda - mungkin karena ini. Coba lakukan optimasi secara normal pada beberapa segmen.Aneh: Saya seorang penata huruf, dan saya memberi tahu hal-hal server yang sedemikian rumit. Mari kita lebih dekat ke CSS nyata.Kirim lebih sedikit
Jadi, kami mengirim lebih sedikit ke pengguna, segmen lebih sedikit, datang lebih cepat, pengguna senang.
Minifikasi. Dia siap di proyek-proyeknya. Ada banyak alat keren, plugin webpack, pengaturan tegukan - secara umum, Anda akan mengetahuinya sendiri. Anda dapat menyesuaikannya dengan tangan, tetapi tampaknya hanya ketika Anda yakin bahwa Anda dapat mengompres pendingin CSS Anda daripada CSSO mana pun.Ingatlah untuk mengaktifkan kompresi. Jika setidaknya gzip tidak dihidupkan pada tahun 2020, Anda pasti melakukan sesuatu yang salah, karena ini adalah teknik kompresi kuno. Secara umum, pada tahun 2020, saatnya menggunakan brotli. Ini adalah cara yang baik untuk sedikit mengurangi output di browser Chromium. Atau, jika Anda tidak ingin mendukung brotli, maka setidaknya Anda dapat mencoba zopfli.Ini adalah algoritma kompresi yang cukup lambat untuk gzip, yang hanya memberikan hasil kompresi terbaik dan mendekompresi secepat gzip biasa. Karena itu, zopfli perlu dikonfigurasi dengan bijak dan digunakan hanya ketika Anda tidak perlu menampilkan data dengan cepat. Anda dapat mengonfigurasi pengarsip gzip yang akan dikumpulkan selama perakitan menggunakan algoritma zopfli, dan sudah dikirim secara statis, pada kenyataannya, tidak berjalan dengan cepat. Ini dapat membantu Anda. Tetapi juga mengukur hasilnya.
Semua algoritma ini menggunakan beberapa jenis kamus: kamus dibangun berdasarkan pengulangan fragmen kode. Tetapi kadang-kadang mereka mengatakan: perlu untuk sebaris, jika kita sebaris, maka kita menyingkirkan permintaan. Menghubungkan semua CSS dalam HTML akan sangat cepat. Kuncinya adalah bahwa gzip bekerja sedikit lebih efisien ketika Anda memecah gaya dan HTML, karena kamusnya berbeda, lebih efisien.Dalam kasus saya, saya hanya mengambil halaman bootstrap, menghubungkan bootstrap di sana dan membandingkan dua versi. Gzip atas sumber daya individual kurang dari 150 byte. Ya, keuntungannya sangat kecil. Di sini, Anda juga perlu mengukur semuanya. Tetapi dalam kasus Anda, ini dapat, misalnya, mengurangi jumlah segmen dengan satu.Bagaimana cara mengoptimalkan kode? Saya tidak berbicara tentang minifikasi. Singkirkan apa yang tidak Anda gunakan dalam proyek. Kemungkinan besar Anda memiliki kode yang tidak akan pernah dijalankan pada klien. Untuk apa?
Agar Anda dapat mengotomatisasi ini, tab khusus dibangun ke dalam browser, misalnya, di Chrome DevTools, ini adalah Cakupan, yang memberi tahu Anda: "Saya tidak menggunakan CSS ini atau JS ini, Anda bisa hentikan itu."Tetapi Anda mungkin telah mengarahkan, fokus, aktif, sesuatu diinstal menggunakan JS. Anda perlu mensimulasikan semua tindakan yang mungkin di situs, hanya dengan begitu Anda akan yakin bahwa CSS ini dapat dipotong. Chris Coyer memiliki artikel ulasan bagus tentang alat otomatis yang mencoba melakukan semuanya dengan mengarahkan dan fokus. Tetapi dia sampai pada kesimpulan bahwa tidak mungkin untuk mengotomatisasi ini. Itu belum berhasil.Ada laporan bagus oleh Anton Kholkin dari Booking.com, di mana mereka juga mencoba untuk menghapus tumpukan kode lama. Tetapi mereka memiliki kekhasan: kode warisan yang berasal dari proyek eksternal. Itu perlu untuk menghapusnya. Lihat solusi menarik apa yang mereka temui.Anda sendiri dapat mencoba bermain dengan Dalang yang sama, seperti Chrome. Anda dapat melakukan tes yang secara otomatis melewati semuanya, coba lakukan melayang, fokus. Dan gunakan Cakupan yang sama ini.Rekan saya Vitya Khomyakovpemenang-homyakovmembuat skrip saya sendiri , seperti menemukan duplikat dan gaya pada halaman. Cukup ambil, salin dan tempel. Dia akan menulis kepada Anda di konsol: "pemilih ini, tampaknya, Anda tidak perlu." Sampai pada titik yang baru saja masuk di DevTools. Itu mengagumkan.
Fitur yang sangat saya sukai tentang alat-alat pengembang Firefox: kesempatan untuk melihat gaya yang tampaknya digunakan, tetapi pada kenyataannya browser tidak menerapkannya.Misalnya, Anda dapat mengatur tampilan: inline, dan sepertinya tampilan ini: inline tidak masuk akal untuk mengatur ukuran. Atau vertikal-align, ini hanya berfungsi untuk inline atau table-cell. Sejauh ini, saya hanya melihat di Firefox yang dapat menyoroti: "Anda tidak perlu baris ini."Di sini, Anda juga perlu berhati-hati: mungkin Anda menggunakan gaya ini untuk menempelkan kelas nanti. Namun menurut saya, fitur yang keren.Tanyakan pada diri Anda pertanyaan sekarang: apakah Anda memerlukan seluruh Bootstrap pada proyek? Tempatkan kerangka kerja CSS yang Anda gunakan alih-alih Bootstrap. Kemungkinan besar, Anda menggunakan Bootstrap untuk kisi-kisi dan elemen yang kurang lebih umum, dan setengah dari Bootstrap yang tidak Anda butuhkan.Coba gunakan unit dengan benar. Hampir semua kerangka kerja CSS modern memungkinkan Anda untuk menggunakan kode sumber untuk perakitan dan hanya memilih apa yang Anda butuhkan. Ini secara drastis dapat mengurangi ukuran bundel CSS.Jangan berikan yang tidak digunakan. Alih-alih mencari warisan saya, Anda dapat menggunakan pemahaman tingkat-bangun bahwa halaman ini tidak akan menggunakan CSS ini.Misalnya, tumpukan BEM penuh memungkinkan Anda untuk membuat perakitan sehingga Anda, yang sudah memberikan halaman, dapat membangun pohon dari semua komponen blok BEM yang akan ada di halaman. BEM memungkinkan Anda untuk menentukan bahwa jika blok ini tidak ada di halaman, tidak perlu memuat CSS ini. Kirimkan hanya yang diperlukan.Bahkan orang-orang dari Google mengatakan : gunakan BEM, itu bisa sangat membantu Anda untuk optimasi.Saya tidak percaya bahwa saya mengatakan ini dengan lantang, tetapi dalam hal ini CSS-in-JS tampaknya menjadi pendekatan yang baik. Saat Anda menulis komponen independen independen dan dengan hati-hati mengonfigurasi perakitan atau menentukan dalam runtime blok mana yang digunakan dan mana yang tidak, Anda dapat menyingkirkan masalah menemukan kode lawas dengan hanya tidak mengirim kode ini ke klien. Kedengarannya mudah, tetapi disiplin diperlukan. Pikirkan terlebih dahulu di awal proyek.
Opsi apa lagi yang ada? Sedikit gila. Dalam kode ini, tampaknya gaya tidak diperlukan, karena kami menggunakan div - standarnya sudah ditampilkan: blok. Dan mari kita hapus semua default? Jika dalam proyek Anda, Anda tahu pasti bahwa markup HTML tidak akan pernah berubah lagi - telusuri nilai default yang sudah disediakan browser dan hapus.Kurang gaya - hebat! Tapi sekali lagi ini ide gila. CSS tidak perlu tahu tentang HTML, karena itu gaya. Ini cukup independen, Anda harus menghubungkannya ke proyek lain, itu harus bekerja di sana. Dan ya, sulit untuk mempertahankannya. Ubah tag - semuanya rusak. Gagasan gila seperti yang dijanjikan.Gunakan variabel. CSS memiliki variabel yang sangat lama seperti currentColor.
Seringkali ada pola: Anda ingin, misalnya, untuk membuat tombol yang teks dan tepinya sama warnanya. Dan dengan mengarahkan kita mengubah keduanya. Untuk apa?
Ada variabel currentColor yang mengambil nilai dari warna, dan Anda meletakkannya, misalnya, di perbatasan, proksi properti ini dan ubah hanya satu baris dengan mengarahkan, dengan fokus, dengan aktif, apa pun yang Anda inginkan. Ini sepertinya nyaman, dan kodenya menjadi satu baris lebih sedikit. Anda bisa mengoptimalkan. Ngomong-ngomong, dalam contoh ini, Anda tidak dapat menggunakan tugas border-color sama sekali, karena secara default sudah mengambil nilai dari properti warna.Terkadang sangat menyedihkan menyaksikan bagaimana base64 digunakan. Di CSS, disarankan secara aktif sebelumnya: gunakan base64 untuk menyuntikkan ikon kecil. Jika cocok dalam satu segmen melalui TCP, itu bagus untuk Anda.
Tapi Harry Roberts jugaMelakukan studi berkelas tentang bagaimana base64 memengaruhi pemuatan halaman. Ya, ada lebih sedikit permintaan, tetapi gaya seperti itu diurai pada waktu lebih lambat.Oke, parsing adalah operasi yang sangat cepat, kemungkinan besar pengguna tidak akan menyadarinya. Tetapi kami memiliki metrik penting - rendering pertama, sehingga pengguna melihat sesuatu di halaman. Pada ponsel, rendering pertama, menurut sebuah studi oleh Harry Roberts, terjadi sepuluh kali kemudian. Pikirkan apakah Anda membutuhkan base64? Ya, ada lebih sedikit permintaan, tetapi apakah itu berpengaruh?Dan tolong jangan gunakan base64 untuk SVG. Karena SVG bagus untuk menggunakan URL-encoder. Julia Bukhvalova memiliki alat keren: Masuk, tempel SVG Anda dan itu akan memberikan CSS dalam bentuk siap-tempel. Anda mungkin memperhatikan bahwa tidak ada base64, tetapi ada beberapa hal yang lolos sehingga dalam CSS mungkin tidak dirasakan dengan benar. Itu jauh lebih efisien.Rata-rata, base64 memberi nilai plus 30% untuk ukuran yang Anda kompres. Untuk apa?Gunakan teknologi modern. Kami mungkin perlu mendukung Internet Explorer - argumen yang biasa ketika berbicara tentang kisi.
Tapi coba pikirkan: jika Anda tidak memiliki dukungan IE, dan Anda masih mengetik di float atau tabel, Anda dapat menggunakan kisi untuk membuat tata letak tiga kolom dengan celah 20-piksel - ini adalah jarak antar kolom. Tiga baris. Nah, lima, mengingat pengumuman itu sendiri.Coba ini di atas kendaraan hias. Dan maksud saya kita mengubah tiga baris, termasuk nama kelas, jika Anda menyentuh HTML. Saya tidak menemukan cara untuk melakukan hal yang sama keren di atas kendaraan hias. Lepaskan keputusan Anda. Tetapi gunakan teknologi modern. Mereka memungkinkan Anda untuk menunjukkan markup secara lebih kompak.
Anda dapat mencoba Atomic CSS. Apa itu? Anda menulis nama-nama kelas yang sedikit gila ini. Dan setelah beberapa waktu Anda mulai memahami bahwa Andalah yang mengatur warna latar belakang atau hanya warna. Ini adalah "fitur" untuk CSS. Tetapi Anda memiliki set CSS tetap yang kemudian Anda gunakan dalam HTML sebagai indikasi gaya. Dan CSS tiba-tiba semakin kecil. Untuk proyek besar, itu benar-benar akan menjadi lebih kecil, karena ada lebih sedikit gaya unik. Tetapi Anda mengembangkan HTML.
Anda dapat melihat ke arah CSS Tailwind, yang sekarang mulai populer. Ini bukan Atomic CSS, ini tentang kelas utilitas, mirip dengan Bootstrap, hanya lebih bermanfaat. Anda dapat menggunakan set tertentu. Cukup sudah cukup untukmu. Satu set kelas yang menjalankan fungsinya. Anda juga bisa mencoba, tetapi jangan berlebihan.
Gagasan gila lainnya - mengapa kita perlu nama kelas secara keseluruhan pada klien? Ya, itu nyaman untuk pengembangan dan debugging, tapi mari kita ambil semua nama kelas dan buat satu huruf. Itu akan lebih sedikit.Berikut ini adalah artikel tentang cara melakukan ini. Anda dapat mengonfigurasi webpack atau plugin lain saat membuat. Tapi itu tidak lepas landas dari kami. Kami sudah mencoba.Ternyata gzip sangat keren sehingga semuanya dioptimalkan dengan baik untuk kami, dan BEM dan gzip sangat ramah. Karena konstruksi teks diulang untuk menggambarkan blok dan elemen dalam kode.Secara umum, ini memberi kami hampir tidak ada untung. Tetapi jika, misalnya, Anda tidak memiliki BEM dan banyak kelas yang berbeda, Anda dapat mencoba.Penting: ukur. Ukur semua potongan eksperimental tersebut. Mungkin sekarang ini bekerja untuk Anda, dan kemudian Anda sedikit mengubah arsitektur proyek, itu mulai berkumpul dengan cara yang berbeda dan semuanya melambat.Unduh itu!
Sejauh ini, saya hanya berbicara tentang cara mengunduh file. Kami mengunduhnya. Apa yang telah dilihat pengguna selama ini?
Dia melihat layar yang luar biasa. Saat kami mengunduh, layarnya kosong. Kami mengunduh, dan browser memulai enam langkah lagi. Bersabarlah sedikit, saya akan berbicara tentang mereka sedikit lebih cepat daripada tentang mengunduh.
Mari kita mulai dengan penguraian. Parsing adalah saat browser mengunduh unduhan byte, dan mulai memecahnya menjadi entitas yang dimengerti.
Misalnya, ia menemukan impor. Ini lagi harus diunduh. Baca bagian pertama dari laporan itu lagi? impor adalah operasi pemblokiran. Tetapi browser itu pintar. Mereka memiliki Preload Scanner. Saya mengatakan bahwa semuanya diblokir di sana, ini tidak benar. Peramban tahu bahwa, misalnya, jika ada tiga tag tautan dalam satu baris yang mengikuti gaya, maka ketika saya mengunduh yang pertama, Anda dapat mulai mengunduh yang kedua dan ketiga. Tidak dapat menguraikan, karena seluruh struktur penguraian rusak. Tapi unduh di muka - itu bisa.
Jadi impor adalah hal yang buruk. Jika gaya konsisten dalam HTML, browser akan melihat bahwa kami akan melangkah lebih jauh untuk file lain.
Dan jika Anda memasukkannya langsung ke impor, itu harus terlebih dahulu mengunduh style.css Anda, kemudian lihat impor di dalamnya. Dia mulai mengurai CSS ini ... Ya, kami memblokir semuanya dengan cara baru dan mencari file! Jadi Anda bisa membuat air terjun yang sejuk dengan deoptimisasi di situs.Lupakan impor, atau konfigurasikan sehingga tidak ada impor setelah build. Untuk lingkungan dev, ok, tapi tidak untuk pengguna.
Selanjutnya kita melalui tahapan membangun pohon, menggunakan Cascade.
Semua ini juga dijelaskan untuk waktu yang lama. CSS Object Model dibangun - pohon khusus tentang cara browser memetakan tag, kelas ke gaya. Ia menghubungkan semuanya dengan DOM dan membuat koneksi ini dengan sangat cepat. Ketika Anda mengubah sesuatu, itu sudah cukup baginya untuk mengubahnya di dalam pohon.
Semakin besar pemilih, semakin sulit bagi browser untuk menggambar pohon. Dia perlu mengurai pemilih, mengubahnya menjadi struktur pohon. Dan jika Anda memasukkan! Penting di sana, maka ia harus mempertimbangkan ini.
Sepertinya sudah waktunya untuk berbicara tentang BEM lagi. Tetapi BEM tidak diperlukan jika Anda tahu cara menggunakan kelas utilitas, jika satu kelas bertanggung jawab untuk satu fungsi dan mereka tidak saling mengganggu. Maka membangun pohon itu sangat sederhana. Anda memiliki struktur yang cukup datar dan kemudian browser harus menautkannya dengan benar ke DOM.
Jika Anda melakukan ini, maka mereka mengatakan penyeleksi seperti memperlambat parsing CSS. Tapi ini adalah legenda lama, perbedaannya sangat kecil untuk browser sehingga dalam proyek rata-rata Anda tidak akan melihatnya jika Anda mengoptimalkan penyeleksi dengan tanda bintang. Tetapi apakah Anda ingin mengembangkan dan memelihara kode seperti itu?
Saya terbiasa mendengar tip: coba letakkan semuanya di jalan pintas. background adalah jalan pintas untuk banyak properti lainnya. Kami menempatkan semuanya dalam satu properti, dan itu menjadi optimal.Dengan byte, ya, semakin kecil. Tetapi jika Anda ingin mengoptimalkan komposisi CSS OM, maka browser akan tetap membuat semua properti ini di luar latar belakang. Browser untuk setiap elemen DOM membangun tabel dari semua properti yang dapat dimilikinya. Ketika Anda melihat nilai yang dihitung DevTools, mereka tidak ada di sana karena browser menghitungnya sesuai dengan kebutuhan Anda. Ini menyimpan ini dalam memori, karena jauh lebih mudah untuk menulis ulang satu properti dan semuanya berfungsi.Ini juga saran yang sangat aneh, tetapi jika Anda ingin membuat CSS OM lebih cepat, Anda dapat segera mengatur semua properti satu per satu. Itu mungkin berhasil. Tetapi ukuran bundel akan sangat meningkat. Anda perlu mengukur. Saya ragu itu akan memberi untung, tapi tiba-tiba!Ketika CSS OM dibangun, JS juga terkunci pada titik ini. Jika membangun OM CSS membutuhkan waktu dua detik, JS gagal. Meskipun saya tidak bisa membayangkan bagaimana Anda bisa menulis begitu banyak dalam CSS sehingga pohon dibangun selama dua detik.
Selanjutnya browser melakukan Layout. Ini adalah lokasi dari semua elemen DOM, penggunaan posisi. Dia mengerti di mana elemen harus ditempatkan dan dengan dimensi apa. Tampaknya pada tahap ini pengguna seharusnya sudah melihat beberapa jenis gambar. Tapi dia melihat semua yang ada di viewport, bisa melihat melalui jendela terbatas. Jika ada sesuatu yang tidak beres dari bawah, ia tidak akan melihatnya.
Idenya disebut Critical CSS, dan itu juga sudah cukup tua. Anda memasukkan beberapa hal penting untuk layar pertama di awal unduhan. Misalnya, sebaris dalam HTML Anda, singkirkan semua permintaan tambahan. Pengguna melihat layar ini terlebih dahulu, lalu unduh sesuka Anda. Kemungkinan besar, dia akan mulai menggulir ketika Anda punya waktu untuk memuatnya.
Ini dilakukan secara sederhana. Ada alat yang mengotomatisasi semua ini, termasuk plugin untuk webpack dan Bereaksi. Cukup cari dan konfigurasikan dengan benar.- github.com/addyosmani/critical- github.com/pocketjoso/penthouse- github.com/anthonygore/html-critical-webpack-plugin- github.com/GoogleChromeLabs/critters
Semoga memiliki pendekatan yang baikdari Filament Group - cara memuat secara tidak sinkron tanpa memblokir CSS. Semuanya cukup sederhana.Ketika Anda meletakkan <link rel = preload>, maka beri tahu browser: "Saya akan membutuhkan gaya ini, tetapi sekarang kami tidak memblokir apa pun. Anda mengunduhnya sekarang, menyimpannya, dan ketika saya membukanya, mulailah membangun CSS OM. " Dan Anda hanya perlu memakai onload dan memprosesnya "ok, sejak saya unduh, lakukan rel = stylesheet, aktifkan penguraian."Pendekatan yang cukup sederhana, tetapi gunakan dengan bijak juga. Jika Anda memiliki terlalu banyak preload, Anda dapat melakukan lebih buruk.
Anda juga dapat bermain dengan ekspresi media. Rekatkan dan beri tahu browser: "gaya ini tidak diperlukan sekarang, tetapi ketika ekspresi media ini berfungsi, itu akan diperlukan." Browser juga akan mengunduh secara proaktif, tetapi dengan prioritas lebih rendah dan tanpa pemblokiran.
Pendekatan gila lain, tapi tidak terlalu gila - ketika Anda memiliki http / 2 push. Anda dapat menyematkan CSS tepat di depan blok. Tanpa CSS, blok Anda tidak akan terlihat sangat bagus. Jadi mengapa tidak sebaris CSS yang Anda butuhkan untuk blok berikutnya sebelum blok ini? Ini logis, dan dorongan http / 2 akan memungkinkan Anda untuk mengoptimalkannya.Pendekatan sederhana. Jika Anda mengembangkannya, gunakan lazy loading. Mengapa pengguna harus mengunduh sesuatu yang tidak akan ia gunakan? Anda dapat mengonfigurasi komponen Bereaksi sehingga jika belum pernah mencapai area visibilitas halaman, mengapa harus mengunduh gaya untuk dirinya sendiri?Jelajahi API Pengamat titik-temu dan Anda mungkin dapat mempercepat halaman Anda secara dramatis.
Langkah terakhir adalah menggambar dan menerapkan ke lapisan komposit, menempelkannya dan sebagainya.
Browser menciptakan lapisan komposit dalam sejumlah besar kasus. Menurut pendapat saya, hanya seperempat dari kode sumber Chromium yang cocok di sini . Anda dapat melihat sendiri ketika membuat lapisan komposit dalam kode browser.Memori video terbatas, terutama pada ponsel. Jika Anda membawa semuanya ke layer baru untuk mengoptimalkan animasi menggunakan will-change: transform atau sesuatu yang lain, maka Anda mungkin melakukan lebih buruk.Buat lebih sedikit layer - persis sebanyak yang Anda butuhkan untuk optimasi saat ini.Hebat, kita semua diuraikan.Dan jika saya kembali?
Dan bagaimana jika saya kembali ke halaman? Ini baru pertama kali saya pergi.Kembali ke halaman, saya sepertinya dapat mengunduh semuanya secara instan. Saya sudah mengunduh semua sumber daya, mengapa tidak menggunakannya untuk kedua kalinya?
Jika server tidak memberikan header Kontrol-Cache, browser akan mencoba untuk men-cache file Anda untuk menggunakannya kembali. Anda dapat mengkonfigurasi server Anda secara default, katakan: "cache file ini selama satu tahun penuh." Tidak akan berubah Tetapi jika demikian, Anda harus berurusan dengan masalah pembatalan cache global. Tetapi ini adalah topik dari laporan terpisah.Gunakan Pekerja Layanan! 2020, saatnya, Aplikasi Web Progresif! Kirill Chugainov punya laporan bagustentang bagaimana Pekerja Layanan dapat digunakan untuk berbagai kesempatan. Dalam hal ini, Anda mencegat permintaan CSS, menyimpannya, dan jika browser mengikuti gaya ini untuk kedua kalinya, berikan menjauh dari cache.Tetapi browser tidak menjanjikan apa pun kepada Anda. Anda selalu dapat menghadapi kenyataan bahwa browser kehabisan memori. Dia akan mencoba untuk melakukan cache, tetapi tidak ada memori. Caching tidak seratus persen. Selalu menangani situasi seperti itu.Anda dapat mencoba menggunakan Penyimpanan Lokal. Tapi dia sangat lambat. Mengunduh file terkadang lebih cepat daripada pergi ke API Penyimpanan Lokal.Anda dapat mencoba basis data browser bawaan. Tapi ukurlah. Mungkin perjalanan ke JS akan membawa Anda lebih lama karena prosesor yang lemah.Anda juga dapat memberi tahu browser terlebih dahulu bahwa Anda akan mengunduh sesuatu.
<link rel> - pelajari cara kerja atribut ini. Ada preconnect, prefetch, prerender - Saya ingin membicarakannya secara terpisah. Dia berkata, “Saya ada di halaman ini sekarang, dan kemudian saya akan pergi ke halaman berikutnya. Unduh semuanya untuk halaman ini di tab latar belakang dan gambar. " Hal yang keren. Tidak bekerja dimanapun.
Dalam arti, itu didukung di IE dan Edge. Di Chrome, itu tidak benar-benar melakukan ini, itu tidak membuat. Ini berfungsi seperti prefetch: mengunduh file dan cache ini. Sayangnya, prerender lengkap tidak bekerja di mana pun.Tetapi Anda dapat mengembangkan ide ini. Misalnya, dalam aplikasi Yandex - tentu saja, tidak menggunakan CSS - prerender dibuat. Ketika Anda mencari sesuatu, kemungkinan Anda bisa mendapatkan hasil Anda secara instan. Kami dapat memprediksi ke mana Anda akan pergi, dan sebelumnya dengan metode kami sendiri, pergi dan dapatkan semua sumber daya yang diperlukan.Apa berikutnya? Ada banyak tautan. Saya juga menyarankan Anda untuk melihat koleksi optimalisasi segalanya dari Vanya Akuloviamakulov. Lihat cara mengoptimalkan HTML, dan JS, dan perakitan.Dan jangan lupa untuk membereskannya. Sekarang saran saya benar-benar berfungsi, menyarankan cara melakukannya dengan cepat, tetapi kemungkinan besar, setelah lima tahun, mereka bahkan akan berbahaya. Akan ada beberapa jenis teknologi yang tidak sesuai dengan mereka. Lacak ini dan cobalah untuk menjaga kode Anda optimal, termasuk setelah beberapa saat. Terimakasih atas perhatiannya.