Mendesain Ulang Sistem Navigasi Tujuh Tingkat SGS: Studi Kasus

SGS (sebelumnya Societe Generale de Surveillance ) adalah organisasi layanan global dan penyedia layanan inspeksi, verifikasi, pengujian, dan sertifikasi di 14 industri. Situs web SGS (bersama dengan 60 situs web lokal) terutama mempromosikan layanan inti organisasi, serta menyediakan akses ke banyak layanan bermanfaat, konten tambahan, dan alat. Tujuan kami adalah mengubah sgs.com dari hanya desktop menjadi responsif.

Ini menghadirkan serangkaian tantangan unik, terutama di sekitar sistem navigasi lawas, yang di area memiliki kedalaman hingga tujuh tingkat (dibagi menjadi dua bagian) dan yang terdiri dari sekitar 12.000 item yang dapat dinavigasi individu .

Bacaan Lebih Lanjut di SmashingMag: Tautan

• Merancang Studi Kasus: Menampilkan Proses Desain yang Berpusat pada Manusia
• Beradaptasi Dengan Desain Responsif
• Studi Kasus Penyatuan Desain Produk
• 75 Studi Kasus Instruktif – Beginilah Kami Membangunnya

Reaksi alami kami saat melihat dan menggunakan sistem navigasi SGS untuk pertama kalinya adalah pasti arsitektur informasi (IA) harus disederhanakan karena banyaknya tautan dan konten yang dapat dinavigasi. Namun, mengingat navigasi telah dioptimalkan untuk mesin pencari dan IA sebelum proyek ini dan mengingat bahwa SGS menawarkan berbagai pilihan layanan di banyak industri (tercermin dalam volume konten), terbukti bahwa pemfaktoran ulang IA tidak akan berhasil. menjadi bagian dari solusi.

Sederhananya, struktur pohon navigasi harus tetap utuh. Meski begitu, itu tidak menghalangi kami untuk membuat beberapa penyesuaian kecil pada IA. Misalnya, "Berita, Media & Sumber Daya" dan "Kantor & Lab SGS" dipindahkan ke tingkat atas, untuk visibilitas yang lebih besar. Dengan yang pertama, penting untuk lebih jelas mencerminkan bahwa SGS secara teratur menerbitkan berita dan menyelenggarakan acara. Dengan yang terakhir, sangat penting bahwa itu, bersama dengan halaman kontak, mudah dijangkau dari mana saja dalam struktur situs web. Oleh karena itu, pertanyaan kuncinya adalah bagaimana sistem navigasi raksasa seperti itu dapat dibuat dengan mudah untuk bertransisi antara viewport yang berbeda sambil tetap dapat digunakan?

Menetapkan Kebijakan Proyek

Hubungan klien-perancang yang sehat sangat penting untuk keberhasilan setiap proyek. Menetapkan harapan yang jelas serta memberikan panduan yang efektif memastikan tidak hanya pemangku kepentingan utama tetap fokus, tetapi juga kepercayaan berkembang di antara semua pihak saat proyek berlangsung. Ini pasti kasus dengan proyek ini; kerjasama semua pihak dan saling menghargai peran dan keahlian masing-masing sungguh luar biasa.

Namun, untuk memastikan bahwa semua pihak tetap fokus, kami menetapkan pada pertemuan awal sejumlah pedoman dan persyaratan penting di mana kami juga dapat melatih kreativitas (beberapa di antaranya kami bersikeras, yang lain bersikeras oleh klien):

• Paritas konten . Konten harus dapat diakses di setiap perangkat dan platform dan dalam keadaan apa pun tidak boleh disembunyikan di seluler.
• Kinerja . Situs web harus berkinerja setidaknya 20% lebih cepat daripada situs web pesaing. Ini sangat berguna ketika memutuskan berapa banyak informasi yang harus masuk ke setiap halaman.
• Aksesibilitas . Situs web harus mematuhi pedoman aksesibilitas level-AA WCAG 2.0. Kami berhasil mencapai target ini, selain dari masalah kontras warna batas, karena branding perusahaan.
• Kegunaan . Tim internal harus memvalidasi konsep secara ekstensif dan melakukan pengujian kegunaan langsung dan jarak jauh.
• Bisnis tanpa gangguan . Desain ulang seharusnya tidak mengganggu bisnis perusahaan sama sekali. Jelas, tugasnya bukan untuk mengoptimalkan layanan perusahaan, melainkan untuk mengoptimalkan situs web, dengan mempertimbangkan proses bisnis yang telah ditetapkan. Misalnya, kami memiliki kebebasan untuk mengoptimalkan formulir web, tetapi struktur data dalam CRM harus tetap utuh.

Tiga Tantangan Utama

Dengan pedoman utama yang ditetapkan dan mengetahui bahwa desain ulang navigasi tidak memerlukan perbaikan IA yang signifikan, kami membagi desain ulang menjadi tiga rangkaian aktivitas utama yang saling bergantung:

• Penempatan tata letak . Ini sebagian besar ditangani oleh tim internal, dengan kami menyarankan perbaikan dan memastikan setiap keputusan tidak akan memiliki implikasi radikal untuk aspek lain dari desain responsif baru.
• Interaksi dan kegunaan . Ini dikerjakan secara kolaboratif dengan tim desain SGS. Ide-ide dipertukarkan melalui email dan di lokakarya di tempat dan secara teratur divalidasi terhadap pengguna, pemangku kepentingan, dan persyaratan bisnis secara keseluruhan.
• Kinerja . Ini ditangani sendiri oleh kami, karena ini lebih merupakan tantangan teknis dan tidak memerlukan pengambilan keputusan strategis apa pun selain bagi kami untuk membuat situs web baru yang responsif dengan cepat.

Penempatan Tata Letak

Navigasi adalah elemen mendasar dari tata letak halaman, terlepas dari ukuran atau kompleksitas situs web. Meskipun pola di luar layar mungkin tampak menarik saat Anda berurusan dengan sistem navigasi skala besar, ingatlah bahwa mungkin ada masalah saat navigasi tidak terlihat oleh pengguna.

Tim desain SGS pada awalnya menguji berbagai konsep, karena mereka tidak hanya harus mengevaluasi interaksi navigasi, tetapi juga menciptakan keseimbangan yang tepat dengan sisa halaman dan menghindari kekacauan.

Memutuskan Konsep

Mengingat kompleksitas situs web, sangat penting bahwa navigasi selalu tetap terlihat dan memberi tahu pengguna di mana mereka berada dalam struktur pohon. Daripada membagi navigasi menjadi dua bagian di UI, kami ingin sistem navigasi baru menjadi mulus (dari tingkat atas sampai ke tingkat bawah). Oleh karena itu, itu harus memungkinkan pengguna untuk dengan mudah menelusuri ke atas dan ke bawah pohon navigasi, serta menyamping di bagian utama.

Untuk menguji dan memvalidasi semua kombinasi ini, kami mengembangkan prototipe untuk masing-masing dari delapan konsep navigasi awal. Prototipe mengkonfirmasi apa yang sudah dicurigai oleh tim internal: Opsi yang paling layak dalam hal kegunaan, pemeliharaan, pengalaman lintas layar, kekacauan visual, dan daya tarik adalah agar navigasi ditempatkan di bilah sisi pada layar besar dan tampil sebagai menu tarik-turun di layar kecil. Pada dasarnya, modul navigasi akan mandiri secara fungsional dan visual, terlepas dari ukuran layar.

Meskipun kami akan fokus pada keputusan interaksi spesifik dalam satu menit, perlu ditunjukkan bahwa prototipe interaktif tidak harus dibuang begitu konsep prototipe telah diuji dan divalidasi.

Membuat Prototipe Cerdas

Kami selalu mengembangkan prototipe langsung dalam HTML, CSS, dan JavaScript menggunakan markup semantik, dapat diakses, dan kuat, karena kami kemudian sering dapat menggunakan kembali prototipe awal nanti dalam proses desain. Ini berarti bahwa prototipe awal kami untuk sistem navigasi baru menjadi landasan untuk prototipe situs web lengkap, yang mencakup semua templat halaman dan modul.

Dalam memberikan prototipe lengkap, kami juga memastikan panduan gaya dibuat secara otomatis untuk tim SGS. Dengan membuat tim desain SGS berpikir dalam hal merancang dan mengembangkan modul, daripada halaman lengkap, panduan gaya yang dihasilkan akan memerlukan sedikit pemeliharaan berkelanjutan. Panduan gaya itu sendiri mengacu pada semua modul khusus yang digunakan, dengan setiap modul berisi deskripsi yang tepat, contoh kode, dan tautan yang dibuat secara otomatis ke templat halaman tempat modul itu digunakan. Teknologi pilihan kami untuk mengotomatisasi tugas dan fitur adalah PHP, tetapi otomatisasi dapat dicapai dengan menggunakan bahasa sisi server apa pun, selama outputnya adalah HTML semantik. (Kami mengembangkan kerangka kerja sistem file khusus untuk prototipe kami, tetapi itu adalah topik untuk kesempatan lain.) Nanti di artikel ini, kami akan menjelaskan bagaimana skrip sisi server membantu kami memelihara dan menguji beberapa versi navigasi.

Meskipun memulai dengan HTML semantik, dapat diakses, dan kuat sangat penting, prinsip "konten-pertama, navigasi-kedua" sama pentingnya karena membantu Anda memperhitungkan kemungkinan pengecualian di masa mendatang. Ada satu pengecualian untuk aturan "konten-pertama, navigasi-kedua" dalam proyek ini: halaman beranda. Kami menemukan, berdasarkan analitik, bahwa navigasi dipandang sebagai elemen terpenting di halaman beranda, yang berarti harus ada sebelum konten inti apa pun di halaman.

Interaksi Dan Kegunaan

Setelah keputusan dibuat untuk merancang dan mengembangkan modul navigasi agnostik ukuran layar mandiri, sudah waktunya untuk fokus pada interaksi navigasi. Mempertimbangkan bahwa kami telah mengadopsi pendekatan mobile-first untuk mendesain navigasi, modul navigasi itu sendiri tidak hanya akan berfungsi secara alami seperti yang diharapkan di area pandang yang kecil, tetapi juga akan dengan mudah menskalakan untuk bekerja di area pandang yang besar juga.

Tiga Versi Interaktif

Karena ukuran navigasi dan potensi jumlah level bersarang, kami harus menghilangkan beberapa pola navigasi seluler yang lebih umum sebagai opsi — misalnya, pilih dropdown dan pola prioritas+. Kami fokus pada pembuatan prototipe tiga versi navigasi interaktif: penggeser, akordeon, dan akordeon dan penggeser. Masing-masing memiliki pro dan kontra, yang tentu saja memengaruhi keputusan kami.

Akordeon

Akordeon mungkin adalah pola paling umum di ponsel. Ini mengungkapkan secara progresif, mengungkapkan informasi yang lebih rinci saat pengguna berkembang melalui topik atau tindakan. Ini juga memastikan pengguna tidak kewalahan, itulah sebabnya kami ingin menggunakannya sebagai solusi dasar.

Inilah kelebihan akordeon:

• Pengguna sudah akrab dengannya.
• Pengguna dapat memperluas seluruh pohon navigasi untuk melihat pratinjau beberapa opsi (bagaimanapun, tujuh tingkat navigasi bisa sedikit berlebihan).
• Ini berfungsi tanpa JavaScript, menggunakan kelas semu :target .
• Mengembangkannya mudah.

Dan kontra akordeon:

• Nenek moyang yang diperluas dari kategori tingkat dalam akan mendorong cakupan saat ini terlalu jauh dari bagian atas layar, sehingga membutuhkan banyak pengguliran.
• Tujuh tingkat navigasi membutuhkan tujuh derajat isyarat visual yang dipilih, apakah itu tujuh tingkat warna dasar (abu-abu), tujuh tingkat hierarki tipografi, atau tujuh tingkat lekukan.

Penggeser

Ini awalnya adalah solusi favorit kami, tetapi melewatkan satu elemen penting: memungkinkan penjelajahan yang benar-benar menyamping di seluruh bagian utama. Tidak akan menjadi masalah jika pengguna selalu mulai menjelajah dari halaman beranda, karena mereka akan menjadi semakin akrab dengan bagian utama. Namun, bagi pengguna yang mendarat di halaman jauh di dalam pohon navigasi, itu pasti akan menjadi masalah kegunaan. Misalnya, pengguna yang mendarat di tingkat ketiga, keempat atau kelima harus melintasi pohon untuk mencapai halaman kontak. Melintasi tujuh level bukanlah hal yang menyenangkan, tidak peduli seberapa termotivasi pengguna.

Pro penggeser:

• Hirarkinya jelas.
• Animasinya licin.
• Ini mengikuti konvensi seluler.
• Hal ini relatif mudah untuk dikembangkan.

Kontra penggeser:

• Menjelajah ke samping tidak dimungkinkan.
• Animasinya tidak performans.

Hibrida (akordeon dan penggeser)

Kami benar-benar ingin mempertahankan daya tarik bilah geser, sambil tetap memungkinkan penjelajahan menyamping. Oleh karena itu, kami mengembangkan solusi hibrida yang menggabungkan elemen terbaik dari dua pola navigasi. Kebetulan, itu juga solusi yang kami tentukan.

Pro hibrida:

• Penjelajahan menyamping dimungkinkan.
• Animasinya licin.
• Hirarkinya jelas.

Kontra hibrida:

• Ini membutuhkan beberapa pembelajaran awal.
• Ini rumit untuk dikembangkan, dengan banyak bagian yang bergerak untuk dipertimbangkan.
• Ini memiliki beberapa masalah kinerja.

Seperti disebutkan, pengguna harus dapat menelusuri ke atas dan ke bawah pohon navigasi, selalu sadar dari mana mereka berasal dan ke mana navigasi akan membawa mereka selanjutnya. Namun, itu hanya interaksi dasar — ​​kami harus mengatasi beberapa masalah tambahan untuk mengembangkan sistem navigasi yang dapat digunakan.

Delapan Jenis Tautan yang Khas

Terlepas dari item navigasi saat ini dan pendahulunya yang berbeda dalam desain (yang sekarang, untungnya, praktik yang mapan), kami lebih lanjut meningkatkan navigasi dan kegunaan umum dengan membantu pengguna untuk memahami di mana mereka berada dan apa yang mereka jelajahi. Membantu pengguna untuk memahami halaman saat ini dan orang tuanya, serta hubungan anak-anak yang relevan, masih jauh dari cukup. Tindakan penting lainnya diperlukan:

• bisa langsung ke halaman induk;
• dapat melihat pratinjau tingkat orang tua dan anak-anak, semuanya tetap pada URL asli;
• dengan cepat memahami posisi penjelajahan mereka saat ini, sambil dapat menjelajahi navigasi.
• cepat memahami posisi mereka saat ini di halaman.
  

Catatan: Kami menggunakan remah roti untuk memastikan bahwa posisi halaman saat ini selalu jelas bagi pengguna. Karena kami ingin menghindari melompati level sama sekali, informasi dalam remah roti dan navigasi harus cocok satu per satu, bahkan dengan level semu (yaitu level yang tidak memiliki halaman sebenarnya).

Persyaratan pengguna di atas menghasilkan lima jenis item navigasi yang berbeda secara semantik, dengan tautan pembantu tambahan yang memungkinkan pengguna untuk melintasi pohon tanpa harus meninggalkan halaman saat ini. Anda dapat membayangkan kerumitan dan saling ketergantungan yang menyertai begitu banyak bagian yang bergerak.

Detail Animasi

Semua elemen dalam navigasi dianimasikan menggunakan CSS, dengan setiap animasi memiliki dua bagian berbeda:

• level animasi horizontal,
• pembungkus animasi vertikal.

Pertama, tingkat pohon yang berbeda di penggeser diaktifkan dengan mengubah kelas pembungkus master. Misalnya, pembungkus navigasi tertutup memiliki kelas .depth-0 . Saat item tingkat atas diperluas, kelas berubah menjadi .depth-1 . Saat item tingkat kedua dari dalam item tingkat atas dipilih, kelas berubah menjadi .depth-2 , dan seterusnya. Ini menghasilkan seperangkat aturan CSS yang cukup sederhana yang diterapkan ke satu elemen — daftar urutan paling atas dalam penggeser:

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

Dalam contoh di atas, .l-0 sesuai dengan item daftar level nol, dan .nav-open toggle setiap kali akordeon disetel ke open . Ini berarti bahwa daftar berurutan dari anak langsung dalam item daftar akordeon open benar-benar diimbangi ke posisi kiri-negatif.

Kedua, mengingat bahwa setiap level berisi sejumlah variabel item daftar, transisi antara dua level yang berdekatan harus mulus.

Untuk mencapai ini, kami memastikan selalu ada ruang vertikal yang cukup agar animasi horizontal dapat berjalan dengan lancar. Ketinggian dihitung dan diterapkan dengan cepat dengan mengambil offset vertikal dari elemen yang akan memasuki layar. Ini berarti kami harus memperhitungkan total empat skenario yang mungkin, tetapi sebenarnya hanya perlu menyelesaikan dua, masing-masing dengan urutan eksekusi yang sedikit berbeda:

• Item daftar pendek ke item daftar yang lebih panjang . Animasi horizontal dan vertikal dimulai secara bersamaan.
• Daftar item yang panjang ke item daftar yang lebih pendek . Setelah navigasi berhenti meluncur secara horizontal, animasi vertikal dimulai.

Kedua animasi dimulai pada saat yang sama, tetapi animasi kedua dimulai setelah penundaan 300 milidetik, yang merupakan durasi animasi pertama (ditentukan dalam CSS menggunakan properti transition-duration ). Alasan untuk ini adalah kinerja animasi yang kurang optimal pada perangkat yang kurang mampu ketika beberapa lapisan tumpang tindih sebelum menghilang "di balik tirai." Kode yang disederhanakan terlihat seperti ini:

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

Perbaikan Lebih Lanjut

Sudah dihadapkan dengan serangkaian saling ketergantungan yang kompleks, kami menyadari setelah menguji navigasi bahwa ada ruang untuk perbaikan.

Pertama, karena font web terkadang dimuat sedikit lebih lambat dari halaman lainnya, beberapa string teks dalam navigasi yang dimaksudkan untuk berada di satu baris akan diperluas ke baris kedua sebelum font web dimuat sepenuhnya. Misalnya, tautan bagian tingkat atas "Berita, Media, dan Sumber Daya" jatuh ke dua baris saat dirender dalam font cadangan.

Karena semuanya harus benar-benar kompak (karena kami harus menggunakan posisi absolut untuk animasi geser), satu-satunya solusi adalah mengatur ulang ketinggian elemen yang terpengaruh setelah font web dimuat. Ini dilakukan dengan menggunakan Web Font Loader, yang dikembangkan oleh Bram Stein untuk Adobe Typekit dan Google Fonts.

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

Catatan: Apakah Anda memperhatikan bagaimana kami menggunakan batas waktu 5 detik? Dalam pengujian kami, kami menemukan ini sebagai sweet spot yang membuatnya bekerja pada koneksi "2G" (450 KB per detik) dasar kami!

Kedua, karena kami memutuskan untuk memuat node navigasi secara kondisional untuk meningkatkan kinerja pemuatan awal (lebih lanjut tentang itu di bagian berikutnya), kami ingin pengguna tetap mengetahui berapa banyak item navigasi yang tersedia, jika ada penundaan dalam memuat cabang pohon navigasi. Kami melakukan ini dengan mengulangi gambar latar placeholder yang menyerupai string teks.

Terakhir, kami menambahkan kode placeholder di DOM dengan JavaScript sebelum meminta cabang navigasi. Ini membuat DOM sebersih mungkin.

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

Pertunjukan

Jika Anda ingat, salah satu target utama kami dalam proyek ini adalah agar situs web berkinerja setidaknya 20% lebih baik daripada situs web pesaing. Kami tidak hanya mencapai target ini, tetapi dengan melakukan itu, kami membantu SGS untuk secara signifikan mengurangi bobot halaman dan waktu pemuatan secara keseluruhan. Lihatlah statistik sebelum dan sesudah berikut:

Tahukah Anda Bahwa 12.000 Link Sama Dengan 3 MB HTML?

Itu benar! Ketika kami merender pohon navigasi penuh untuk pertama kalinya dalam prototipe kami, itu berjumlah 3 MB HTML kosong. Tanpa header, footer, dan konten — hanya struktur navigasi yang terdiri dari 12.000 tautan individual.

Sebelum desain ulang, setiap halaman berisi pohon navigasi inti, dan setiap halaman industri juga menyertakan pohon navigasi khusus industri, yang diimplementasikan sebagai modul terpisah. Namun, desain yang dioptimalkan untuk desktop membuat navigasi inti atau khusus industri tidak hanya sulit digunakan pada area pandang kecil, tetapi juga sulit untuk dirawat. Itulah mengapa salah satu tujuan utama dari desain ulang adalah untuk mengkonsolidasikan pohon menjadi modul tunggal dan mudah dirawat.

Menjelajahi Pilihan untuk Meningkatkan Kinerja

Untuk menguji secara menyeluruh masing-masing dari tiga versi navigasi interaktif, serta mengevaluasi kinerjanya, lingkungan pengujian yang fleksibel sangat penting. Ini akan memungkinkan kami untuk membuat perubahan dengan cepat, serta mempertahankan versi yang bersamaan sehingga kami dapat dengan mudah membandingkannya satu sama lain.

Mempertimbangkan ukuran pohon navigasi lengkap (kedalaman hingga tujuh level dan 12.000 tautan yang dapat dinavigasi), kemampuan untuk menguji bagian-bagian dari pohon navigasi serta pohon lengkap itu sendiri adalah penting. Pengembang internal SGS dapat mengekspor struktur navigasi lengkap sebagai file CSV dari sistem manajemen konten mereka, yang memungkinkan kami untuk membuat fungsi PHP yang mudah dikonfigurasi untuk menampilkan pohon lengkap atau sebagian, tergantung pada apa yang kami butuhkan untuk mengetes.

Fungsi PHP kami juga menyederhanakan pemeliharaan HTML dari struktur pohon navigasi, karena markup tautan dan nama kelas yang disebutkan di atas dapat dengan mudah diubah di satu tempat. Menggunakan bahasa sisi server untuk menghindari keharusan mengulang kode mungkin terdengar jelas, tetapi menciptakan jenis lingkungan ini bukan hanya tambahan yang disambut baik, tetapi sebenarnya misi penting, karena itu adalah prasyarat untuk eksperimen dan pengujian yang gesit.

Memuat Tautan Bersyarat

Kami menyebutkan bahwa kami harus memuat node navigasi secara kondisional untuk meningkatkan kinerja pemuatan awal. Pertanyaan yang kemudian perlu dijawab adalah, Berapa banyak pohon navigasi yang harus dimuat pada awalnya dan berapa banyak yang harus dimuat kemudian, dan kapan? Setelah menguji dan membandingkan bobot dan ukuran cabang pohon navigasi yang berbeda, serta mempelajari perilaku pengguna di situs web langsung yang ada, beberapa kesimpulan menarik muncul.

Pertama, pengunjung yang hanya tertarik pada satu jenis industri jarang mengunjungi industri lain. Setelah menelusuri kategori industri yang mereka pilih, setiap pengunjung biasanya akan terus menjelajahi hanya beberapa halaman lain.

Kedua (dan seperti yang kami duga sebelumnya), cabang khusus industri menyebabkan sebagian besar overhead kinerja. Ketika kami menghapus semua cabang industri, HTML dikurangi menjadi 70 KB, yang jauh lebih baik daripada 3 MB! Namun, itu berarti bahwa masing-masing dari 14 cabang industri memiliki berat antara 300 dan 500 KB. Ketika kami memecah setiap cabang layanan lebih lanjut, kami menemukan bahwa setiap tingkat berikutnya akan memiliki berat rata-rata sekitar 24 KB.

Meskipun kami menyadari bahwa HTML dapat dikurangi lebih lanjut dengan mengoptimalkan nama kelas dan menambahkan node DOM melalui JavaScript (lebih lanjut tentang itu dalam satu menit), kami masih harus menentukan apakah yang terbaik untuk memulai permintaan HTTP tunggal sekitar 300 hingga 500 KB atau untuk memulai permintaan HTTP sekitar 24 KB di setiap level. Awalnya, tampaknya mengirim permintaan 24 KB setiap kali pengguna melanjutkan lebih jauh ke bawah pohon navigasi akan lebih bermanfaat. Namun, ini akan menghasilkan beberapa permintaan HTTP yang dikirim melalui jaringan, yang jauh dari ideal, mengingat latensi jaringan sering menjadi salah satu hambatan terbesar untuk kinerja situs web. Juga tidak masuk akal untuk memprediksi pemuatan cabang industri mana pun, kecuali ketika pengguna menunjukkan niat dengan mengarahkan kursor ke tautan industri.

Karena kerumitan navigasi dan jumlah tautan, pengaturan berikut ini menawarkan kompromi terbaik:

• Muat tiga level pertama secara default dalam HTML.
• Muat navigasi industri dengan JavaScript saat maksud ditampilkan, terdeteksi menggunakan acara mouseover .
• Cache cabang yang dimuat untuk mempercepat pemuatan pada pemuatan halaman berturut-turut.

Logika untuk halaman yang lebih dalam agak berbeda, karena navigasi harus dapat diakses tanpa JavaScript diaktifkan. Oleh karena itu, jika pengguna (atau bahkan bot mesin telusur) masuk ke halaman yang dalam, hal berikut akan terjadi:

1. Render tiga tingkat pertama dan cabang ancestor halaman saat ini dan saudara halaman dalam HTML, sehingga memungkinkan pengguna untuk dengan mudah mengakses halaman induk, ancestor dan saudara, sementara juga dapat mengakses bagian lain dari situs web mengikuti logika yang sama.
2. Muat cabang saat ini dengan JavaScript, dan ganti cabang ancestor halaman saat ini yang awalnya dimuat.

Mengoptimalkan HTML

Jika Anda benar-benar ingin mengoptimalkan HTML Anda, semua item yang tidak penting harus diturunkan ke CSS dan JavaScript. Kami memangkas semuanya dengan ketat kecuali daftar yang dipesan, item daftarnya, dan tautannya masing-masing. Semua tautan yang tidak penting (yaitu alat bantu navigasi) juga dihapus dari HTML dan dimasukkan kembali ke dalam DOM menggunakan JavaScript (karena bagaimanapun tidak efektif tanpa JavaScript). Tautan yang tidak penting ini memungkinkan pengguna melakukan beberapa hal:

• buka level berikutnya (secara internal, kami menyebutnya "ekspander");
• naik satu tingkat (kami menamakan ini "pendukung" - menunjukkan kurangnya imajinasi).

Sementara DOM yang dihasilkan masih sangat besar, alat bantu navigasi tidak lagi perlu ditransfer satu per satu melalui jaringan.

Terakhir, pengoptimalan terakhir yang kami lakukan adalah mengurangi jumlah kelas, serta memperpendek panjang nama kelas; misalnya, .very-long-class-name menjadi .vlcn . Sementara yang terakhir menghasilkan keuntungan terbesar, pengoptimalan seperti itu sulit untuk dibenarkan karena biasanya tidak secara signifikan memangkas ukuran file HTML, dan, yang lebih penting, itu mengurangi kejelasan kode, sehingga mungkin membuat pemeliharaan lebih sulit. Namun, mencukur bahkan satu byte dari masing-masing 12.000 item daftar menjadikannya latihan yang bermanfaat dan pertukaran yang dapat diterima.

Hasil? Sebuah rejan 40 KB atau lebih dari HTML awal (8 hingga 9 KB saat dikompresi dan ditransfer melalui jaringan), dan 200 hingga 300 KB HTML untuk setiap industri (15 hingga 25 KB saat dikompresi dan ditransfer).

Kesimpulan: Keuntungan Marginal Penting

Kami suka menggunakan analogi dari dunia olahraga: Meningkatkan setiap hal kecil sebesar 1% secara dramatis meningkatkan kinerja. Ini berlaku untuk apa yang kami lakukan dalam proyek SGS dan navigasinya yang rumit. Dengan berfokus pada detail yang lebih halus, meningkatkan setiap detail sedikit demi sedikit, kami secara signifikan mengurangi kerumitan navigasi dan meningkatkan waktu pemuatan, sekaligus menjaga navigasi tetap menarik dan menarik bagi pengguna. Apa yang bisa menjadi mimpi buruk dan sulit dipecahkan berubah menjadi solusi yang relevan secara teknis dan interaktif, cukup fleksibel untuk mengakomodasi peningkatan lebih lanjut.

Yang terpenting, proses desain untuk terus membuat prototipe, menyelidiki opsi, dan menyempurnakan solusi terbaik terbukti sangat efektif — sedemikian rupa sehingga memberikan alasan yang kuat bagi tim internal untuk menerapkan prinsip dasar yang sama saat mengembangkan produk lain. dalam organisasi, belum lagi akan membantu tim untuk terus menyempurnakan dan mengoptimalkan sistem navigasi baru. Tidak ada proyek web yang benar-benar lengkap; selalu ada beberapa hal lagi di daftar tugas. Tidak apa-apa, selama kami terus menguji, menyempurnakan, dan memberikan pengalaman terbaik bagi pengguna.