Ada audit teknis untuk memeriksa kecepatan situs dan mengidentifikasi penyebab keterlambatan. Dianjurkan untuk melakukannya meskipun sistem tampaknya berfungsi dengan baik dan tidak ada masalah kinerja. Faktanya adalah bahwa itu masih dapat ditingkatkan: pengoptimalan infrastruktur akan mempercepat pengiriman kode, dan pemfaktoran ulang basis kode akan membantu mengurangi biaya pemeliharaan.
Pada artikel ini, kami akan menunjukkan bagaimana audit teknis sebuah situs web menggunakan contoh sumber berita populer, yang dikunjungi oleh puluhan ribu pengguna per jam. Mari kita pertimbangkan tahap verifikasi dan analisis independen, sebagai hasilnya kami akan menunjukkan dengan jelas bagaimana Anda dapat meningkatkan proyek dan menghilangkan kemacetan yang memperlambat pemuatan halaman.
Kumpulan metrik dan analisis sumber daya situs statis
Pastikan untuk mengumpulkan metrik dan mengukur semua yang Anda bisa menggunakan alat siap pakai seperti Google Page Speed, Lighthouse, dan Web.dev. Ini adalah cara tercepat untuk mendapatkan metrik yang akan berfungsi sebagai titik awal untuk penelitian Anda. Dengan bantuan mereka, Anda akan memahami apa yang perlu diperhatikan sejak awal, apa yang dapat dioptimalkan.
Kami menyarankan Anda untuk menjalankan analisis dengan pemblokir iklan dihidupkan dan dimatikan. Hasilnya, Anda akan mengetahui seberapa cepat rendering konten pertama terjadi, dan berapa banyak skrip pihak ketiga yang terhubung di situs.
Pada tahap ini, Anda juga akan melihat berapa banyak operasi dasar yang terjadi saat merender situs:
Metrik yang dikumpulkan cenderung menunjukkan ruang untuk meningkatkan aset situs statis: gambar, video, skrip, gaya, dan font. Analisis data ini dan pastikan Anda mengikuti praktik sumber daya statis umum. Namun, ingatlah bahwa ini hanya pedoman, bukan persyaratan ketat.
Dalam contoh kami, semua gambar disimpan dalam format jpg. Jika Anda menggunakan webp, yang didukung browser dengan sempurna, ukuran file akan berkurang rata-rata 20%. Anda dapat mengkonfigurasi kompresi webp otomatis hanya untuk gambar beresolusi tinggi. Video resolusi tinggi direkomendasikan untuk dikonversi ke webm untuk browser yang mendukung format ini. Untuk mengurangi beban pada jaringan, disarankan untuk menonaktifkan putar otomatis video yang tidak terlihat. Ini dapat dilakukan dengan menggunakan Intersection Observer API.
Pastikan situs Anda memiliki unduhan progresif dan tambahkan kompresi di mana-mana jika memungkinkan. Pastikan untuk menggunakan teknik kompresi skrip modern seperti brotli, gzip, dan deflate.
Jangan memuat apa yang tidak digunakan. Ini dapat diterapkan pada kode, gaya, simbol, gambar. Jika, misalnya, situs web memiliki tombol yang muncul di salah satu dari seribu kasus, maka skrip yang memprosesnya harus terhubung hanya jika diminta.
Dalam contoh di atas, Anda dapat melihat bahwa ~ 93% dari total kode tidak digunakan (~ 340 kb.) Bundel dengan kode dianggap ideal jika cakupannya 100% sambil mencakup semua kasus tanpa memuat ulang halaman. Hal ini dapat terjadi jika kode tidak digunakan sama sekali atau jika pemisahan kode tidak dikonfigurasi dengan benar, atau digunakan, tetapi di halaman lain, atau ketika skenario tertentu tercapai.
Solusi untuk masalah ini adalah dengan memindahkan komponen yang dapat digunakan kembali ke dalam file terpisah (potongan), yang kemudian dihubungkan hanya di tempat-tempat yang dibutuhkan.
Seperti yang kami katakan, persyaratan ini opsional, tetapi pengoptimalan sumber daya statis itu penting, karena pengguna mengetahuinya terlebih dahulu.
Mari kita ambil font sebagai contoh - pada proyek ini mereka membutuhkan waktu terlalu lama untuk dimuat. Karena kami tidak ingin pengguna melihat font standar, kami memuatnya di awal, di bagian critical-css. Bagaimana cara mengatasi masalah ini? Anda dapat mengoptimalkan font di level kode, mengubah urutan koneksi, mengganti ttf dengan woff2.
Anda juga dapat mencoba mengurangi jumlah font yang digunakan, yang memerlukan desain ulang desain, tetapi ini tidak selalu bisa dibenarkan. Jika situs menggunakan pustaka Google Fonts, kemudian hapus karakter yang tidak digunakan dari file, ini tidak dilarang oleh hak cipta.
Tetapi terkadang lebih mudah untuk membiarkan hal-hal apa adanya dan fokus pada kemungkinan lain.
Memeriksa permintaan HTTP
Pada tahap ini, kami memeriksa apakah front-end berinteraksi dengan back-end dengan benar, yaitu:
- kompresi yang dikonfigurasi untuk permintaan API;
- tidak ada pertanyaan parasit yang memuat koneksi, yang hasilnya tidak digunakan di mana pun;
- tidak ada permintaan yang dikembalikan dengan kesalahan tanpa pengguna menyelesaikan kasus bisnis tertentu;
- saat halaman pertama kali dimuat, browser tidak mengirim permintaan ke API (jika situs menggunakan rendering sisi server, seperti dalam contoh kami);
- tidak ada permintaan duplikat. Jika permintaan dibuat saat membuka halaman mana pun, lebih baik mengirimkannya sekali dan menyimpan data untuk digunakan kembali;
- pending , . , , , . , — , .
Permintaan yang diblokir ditandai dengan warna merah, tetapi situs tetap berfungsi.
Selain itu, saat menganalisis permintaan, Anda mungkin menemukan bug. Ini adalah bagaimana kami menemukan operasi yang salah dari aplikasi frontend, yang dapat mengirim lebih dari 100 permintaan per detik, yang sangat memuat server. Pada saat yang sama, layar berkedip, loader berputar tanpa henti, dll. Alasannya tersembunyi di gulungan yang diterapkan dengan tidak benar. Browser mempertahankan posisinya di bagian bawah halaman saat elemen baru muncul. Artinya, saat menggulir halaman, pemuat diluncurkan, yang menyebabkan halaman didorong ke bawah. Penangan Javascript mengirim ulang permintaan, yang pada gilirannya menyebabkan animasi pemuat lagi, yang menyebabkan ukuran halaman berubah, dan seterusnya ad infinitum.
Karena operasi loader yang salah, jumlah permintaan bertambah tanpa batas
Analisis skrip dan sumber daya eksternal
Pada tahap ini, Anda harus menentukan sumber daya mana dari situs pihak ketiga yang membutuhkan waktu paling lama untuk dimuat.
Web modern memungkinkan Anda memprioritaskan unduhan apa pun. Seringkali, metrik dan iklan dimuat sebelum halaman ditampilkan, yang tidak masuk akal, karena pengguna tetap tidak dapat melihat iklan, tetapi situs akan membutuhkan waktu lebih lama untuk memuat. Sebaiknya tampilkan iklan segera setelah situs merender, yang tidak akan memengaruhi statistik dengan cara apa pun - jika tidak, pengguna akan melihat layar putih untuk beberapa waktu.
Halaman profil
Gunakan alat chrome dev untuk membuat profil halaman situs Anda guna melacak permintaan yang lama dan peningkatan penggunaan CPU. Hasilnya, Anda akan melihat apa yang memuat situs dengan jelas.
Tangkapan layar menunjukkan bahwa dibutuhkan 19 milidetik untuk memuat Jquery, yang tidak diperlukan saat ini. Lebih baik memuat jquery setelah sumber daya utama, sebaiknya setelah peristiwa pemuatan berhasil (mis. Onload, domcontentloaded.)
Analisis jumlah dan durasi permintaan
Pada tahap ini, kita akan mengeksplorasi bagaimana frontend berinteraksi dengan backend. Untuk melakukan ini, Anda perlu menganalisis jumlah dan durasi semua permintaan. Untuk mendapatkan gambaran yang lebih lengkap, Anda perlu mengukur waktu respons rata-rata untuk satu permintaan dan untuk permintaan paralel.
Untuk kejelasan, gabungkan data yang diperoleh ke dalam bagan ringkasan. Dengan cara ini, Anda dapat dengan cepat mengidentifikasi kueri mana yang membutuhkan waktu lebih lama daripada yang lain.
Jika situs diinstal pada server yang kuat, maka waktu eksekusi untuk 100 permintaan paralel tidak boleh melebihi waktu eksekusi untuk satu permintaan. Dalam contoh, kita melihat perbedaan sebanyak 30 kali. Kueri terpanjang harus diselidiki terlebih dahulu.
Dalam proyek ini, untuk beberapa permintaan, waktu tunggu gerbang terjadi, yaitu tanggapan dari server tidak datang sama sekali.
Overhead dalam proyek beban tinggi adalah normal. Namun, jika memungkinkan, Anda harus mencoba memecah permintaan menjadi bagian-bagian komponennya jika satu permintaan bertanggung jawab atas beberapa tindakan. Jalankan bagian ini dalam utas paralel.
Apa yang dapat dilakukan untuk meningkatkan server? Hubungkan perpustakaan untuk memantau server dan memulai ulang aplikasi (dalam kasus node.js, ini adalah pm2). Juga disarankan untuk menghubungkan alat pemantau kesalahan seperti Sentry. Konfigurasikan keluaran kesalahan dan pencatatan kerusakan. Dengan cara ini Anda dapat melacak waktu henti aplikasi Anda.
Idealnya, siapkan logger asinkron untuk memantau aktivitas apa pun di situs (permintaan API, permintaan ke database, API eksternal, ke sistem file atau layanan untuk bekerja dengan sistem file), yang akan memasukkannya ke database terpisah.
Analisis statis kode sumber
Analisis ini dilakukan oleh utilitas yang akan menunjukkan kode yang salah dan membantu menyingkirkan "kode mati". Perlu dicatat bahwa alat ini harus digunakan secara otomatis selama pengembangan, tetapi Anda tidak selalu harus bergantung pada integritas pengembang, jadi sebaiknya jangan melewati pemeriksaan ini.
Untuk melakukan analisis statis, Anda perlu menggunakan linters eslint dan utilitas pemformatan kode lainnya seperti prettier dan sonar yang melacak pelanggaran kode.
Akibatnya, berdasarkan pelanggaran yang teridentifikasi, Anda dapat menyusun dokumen:
Biasanya, pelanggaran semacam itu tidak memengaruhi performa situs, tetapi mempersulit pembacaan dan penulisan kode, yang artinya akan lebih mahal biaya pemeliharaannya. Misalnya, dalam proyek ini, kami menemukan fungsi di mana ada tiga argumen, salah satunya tidak digunakan - hal-hal sepele seperti itu secara bersama-sama meningkatkan hutang teknis proyek.
Analisis semantik kode sumber
Pada titik ini, pemrogram perlu memeriksa file proyek secara manual. Perlu dicatat bahwa hanya mungkin untuk mengevaluasi kesalahan yang jelas dalam perilaku kode sumber; untuk analisis yang lebih dalam, Anda perlu mengetahui logika proyek dengan baik. Pada tahap ini, Anda dapat menemukan kode berulang yang dapat diletakkan di satu tempat (kelas, fungsi, atau konstanta) untuk mengurangi jumlah baris dan mengurangi kemungkinan bug.
Terkadang analisis ini akan membantu menentukan apakah tim pengembangan mengalami masalah. Dari baris kode dari Git, Anda dapat menentukan siapa penulisnya dan menentukan kinerja masing-masing karyawan. Anda mungkin menemukan bahwa lebih dari setengah komentar merujuk ke satu pengembang.
Misalnya, di sini kami telah mengidentifikasi sepuluh operasi asinkron yang memperbarui database, tetapi dilakukan satu per satu, tanpa terhubung satu sama lain. Ini berarti bahwa kinerjanya dapat digandakan dengan menjalankannya secara paralel. Gunakan paralelisme jika memungkinkan, karena bahkan dalam versi PHP saat ini, Anda dapat menyetel paralelisme buatan untuk meningkatkan kinerja sistem.
Hasil
Pengembangan perangkat lunak melibatkan banyak risiko, dan pada kenyataannya, Anda sering harus berkompromi agar proyek dapat berjalan dan berjalan tepat waktu. Oleh karena itu, dokumentasi biasanya disiapkan secara retroaktif, dan pengoptimalan situs ditunda hingga saat-saat terakhir.
Namun, tidak ada kata terlambat untuk menangani peningkatan kinerja. Mempercepat situs web Anda akan meningkatkan pengalaman pengguna dan memberikan respons audiens yang positif. Dengan bantuan audit teknis, Anda dapat menentukan apa yang menyebabkan penundaan dalam pekerjaan situs - aplikasi front-end atau back-end. Berikut telah dikumpulkan rekomendasi tentang bagaimana melakukan audit frontend. Mereka bersifat umum dan cocok untuk menguji situs mana pun.
Kami akan segera memberi tahu Anda cara melakukan audit teknis untuk backend di publikasi kami berikutnya.