Mendesain DevTools: Penggunaan token yang efisien dalam bantuan AI

Alina Varkki

Dipublikasikan: 30 Januari 2026

Saat membangun bantuan AI untuk Performa, tantangan utama dalam bidang teknik adalah membuat Gemini bekerja dengan baik dengan rekaman aktivitas performa yang direkam di DevTools.

Model Bahasa Besar (LLM) beroperasi dalam 'jendela konteks' yang mengacu pada batas ketat jumlah informasi yang dapat diprosesnya sekaligus. Kapasitas ini diukur dalam token. Untuk model Gemini, satu token kira-kira adalah kelompok empat karakter.

Rekaman aktivitas performa adalah file JSON besar, yang sering kali terdiri dari beberapa megabyte. Mengirim rekaman aktivitas mentah akan langsung menghabiskan jendela konteks model dan tidak menyisakan ruang untuk pertanyaan Anda.

Untuk memungkinkan bantuan AI untuk Performa, kami harus merancang sistem yang memaksimalkan jumlah data yang berguna untuk LLM dengan penggunaan token minimum. Dalam blog ini, Anda dapat mempelajari teknik yang kami gunakan untuk melakukannya dan menerapkannya untuk project Anda sendiri.

Menyesuaikan konteks awal

Melakukan debug performa situs adalah tugas yang rumit. Developer dapat melihat seluruh rekaman aktivitas untuk mendapatkan konteks, atau berfokus pada Core Web Vitals dan rentang waktu rekaman aktivitas yang terkait, atau bahkan melihat detail dan berfokus pada setiap peristiwa seperti klik atau scroll dan stack panggilan terkait.

Untuk membantu proses debug, bantuan AI DevTools harus sesuai dengan perjalanan developer tersebut dan hanya berfungsi dengan data yang relevan untuk memberikan saran khusus yang sesuai dengan fokus developer. Jadi, alih-alih selalu mengirimkan rekaman aktivitas lengkap, kami membuat bantuan AI untuk membagi data berdasarkan tugas penelusuran bug Anda:

Ringkasan rekaman aktivitas hampir selalu dikirim untuk memberikan konteks awal kepada Gemini, model dasar bantuan AI. Untuk anotasi buatan AI, anotasi tersebut tidak disertakan.

Memberikan alat kepada AI

Bantuan AI di DevTools berfungsi sebagai agen. Artinya, model dapat secara mandiri mengirimkan kueri untuk mendapatkan lebih banyak data, berdasarkan perintah awal developer dan konteks awal yang dibagikan kepadanya. Untuk mengkueri lebih banyak data, kami memberi bantuan AI serangkaian fungsi yang telah ditentukan sebelumnya yang dapat dipanggilnya. Pola yang dikenal sebagai Panggilan Fungsi, atau Penggunaan alat.

Berdasarkan perjalanan proses debug yang diuraikan sebelumnya, kami menentukan serangkaian fungsi terperinci untuk agen. Fungsi ini mempelajari secara mendalam spesifikasi yang dianggap penting berdasarkan konteks awal, mirip dengan cara developer manusia mendekati proses penelusuran bug performa. Kumpulan fungsinya adalah sebagai berikut:

Dengan membatasi pengambilan data secara ketat pada panggilan fungsi ini, kita memastikan bahwa hanya informasi yang relevan yang masuk ke jendela konteks dalam format yang ditentukan dengan baik, sehingga mengoptimalkan penggunaan token.

Contoh operasi agen

Mari kita lihat contoh praktis cara bantuan AI menggunakan panggilan fungsi untuk mengambil informasi selengkapnya. Setelah perintah awal "Mengapa permintaan ini lambat?", Bantuan AI dapat memanggil fungsi berikut secara inkremental:

1. getEventByKey: Mengambil perincian waktu yang mendetail (TTFB, waktu download) dari permintaan spesifik yang dipilih oleh pengguna.
2. getMainThreadTrackSummary: Periksa apakah thread utama sibuk (diblokir) saat permintaan seharusnya dimulai.
3. getNetworkTrackSummary: Analisis apakah resource lain bersaing untuk mendapatkan bandwidth pada waktu yang sama.
4. getInsightDetails: Periksa apakah Ringkasan Aktivitas sudah menyebutkan insight, yang terkait dengan permintaan ini sebagai bottleneck.

Dengan menggabungkan hasil panggilan ini, bantuan AI kemudian dapat memberikan diagnosis dan menyarankan langkah-langkah yang dapat ditindaklanjuti, seperti menyarankan peningkatan kode menggunakan getFunctionCode atau mengoptimalkan pemuatan resource berdasarkan getResourceContent.

Namun, pengambilan data yang relevan hanyalah setengah dari tantangan. Meskipun fungsi memberikan data terperinci, data yang ditampilkan oleh fungsi tersebut dapat berukuran besar. Sebagai contoh lain, getDetailedCallTree dapat menampilkan pohon dengan ratusan node. Dalam JSON standar, ini akan menjadi banyak { dan } hanya untuk penyusunan bertingkat.

Oleh karena itu, diperlukan format yang cukup padat agar efisien token, tetapi tetap terstruktur agar dapat dipahami dan dirujuk oleh LLM.

Menserialisasi data

Mari kita pelajari lebih dalam cara kami menghadapi tantangan ini, dengan melanjutkan contoh pohon panggilan, karena pohon panggilan merupakan sebagian besar data dalam rekaman aktivitas performa. Sebagai referensi, contoh berikut menunjukkan satu tugas dalam stack panggilan di JSON:

{
  "id": 2,
  "name": "animate",
  "selected": true,
  "duration": 150,
  "selfTime": 20,
  "children": [3, 5, 6, 7, 10, 11, 12]
}

Satu rekaman aktivitas performa dapat berisi ribuan rekaman aktivitas tersebut, seperti yang ditunjukkan pada screenshot berikut. Setiap kotak kecil berwarna diwakili menggunakan struktur objek ini.

Format ini bagus untuk digunakan secara terprogram di DevTools, tetapi boros untuk LLM karena alasan berikut:

1. Kunci yang berlebihan: String seperti "duration", "selfTime", dan "children" diulang untuk setiap node dalam pohon panggilan. Jadi, pohon dengan 500 node yang dikirim ke model akan menggunakan token untuk setiap kunci tersebut sebanyak 500 kali.
2. Daftar panjang: Mencantumkan setiap ID turunan satu per satu melalui children akan menggunakan banyak token, terutama untuk tugas yang memicu banyak peristiwa hilir.

Penerapan format yang hemat token untuk semua data yang digunakan dengan bantuan AI untuk Performa adalah proses langkah demi langkah.

Iterasi Pertama

Saat mulai mengerjakan bantuan AI untuk Performa, kami mengoptimalkan kecepatan pengiriman. Pendekatan kami dalam pengoptimalan token bersifat dasar, dan kami menghapus JSON asli dari kurung kurawal dan koma, yang menghasilkan format seperti berikut:

allUrls = [...]

Node: 1 - update
Selected: false
Duration: 200
Self Time: 50
Children:
   2 - animate

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children:
   3 - calculatePosition
   5 - applyStyles
   6 - applyStyles
   7 - calculateLayout
   10 - applyStyles
   11 - applyStyles
   12 - applyStyles

Node: 3 - calculatePosition
Selected: false
Duration: 15
Self Time: 2
URL: 0
Children:
   4 - getBoundingClientRect

...

Namun, versi pertama ini hanya sedikit lebih baik daripada JSON mentah. Objek ini masih mencantumkan secara eksplisit turunan node dengan ID dan nama, serta menambahkan kunci deskriptif yang berulang (Node:, Selected:, Duration:, …) di depan setiap baris.

Mengoptimalkan daftar node turunan

Sebagai langkah selanjutnya untuk mengoptimalkan lebih lanjut, kami menghapus nama untuk turunan node (calculatePosition, applyStyles, … dalam contoh sebelumnya). Karena bantuan AI memiliki akses ke semua node melalui panggilan fungsi dan informasi ini sudah ada di head node (Node: 3 - calculatePosition), tidak perlu mengulangi informasi ini. Hal ini memungkinkan kita untuk mengecilkan Children menjadi daftar bilangan bulat sederhana:

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3, 5, 6, 7, 10, 11, 12

..

Meskipun ini merupakan peningkatan yang signifikan dari sebelumnya, masih ada ruang untuk mengoptimalkan lebih lanjut. Saat melihat contoh sebelumnya, Anda mungkin melihat bahwa Children hampir berurutan, dengan hanya 4, 8, dan 9 yang tidak ada.

Alasannya adalah pada percobaan pertama, kami menggunakan algoritma Depth-First Search (DFS) untuk melakukan serialisasi data pohon dari rekaman aktivitas Performa. Hal ini menyebabkan ID yang tidak berurutan untuk node saudara, sehingga kami harus mencantumkan setiap ID satu per satu.

Kami menyadari bahwa jika mengindeks ulang hierarki menggunakan Breadth-First Search (BFS), kami akan mendapatkan ID berurutan, sehingga memungkinkan pengoptimalan lain. Daripada mencantumkan setiap ID, kita kini dapat merepresentasikan ratusan turunan dengan satu rentang ringkas, seperti 3-9 untuk contoh aslinya.

Notasi node akhir, dengan daftar Children yang dioptimalkan, akan terlihat seperti ini:

allUrls = [...]

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3-9

Mengurangi jumlah kunci

Setelah daftar node dioptimalkan, kita beralih ke kunci yang berlebihan. Kami memulai dengan menghapus semua kunci dari format sebelumnya, yang menghasilkan:

allUrls = [...]

2;animate;150;20;0;3-10

Meskipun hemat token, kami tetap perlu memberi Gemini petunjuk tentang cara memahami data ini. Oleh karena itu, saat pertama kali mengirimkan pohon panggilan ke Gemini, kami menyertakan perintah berikut:

...
Each call frame is presented in the following format:

'id;name;duration;selfTime;urlIndex;childRange;[S]'

Key definitions:

*   id: A unique numerical identifier for the call frame.
*   name: A concise string describing the call frame (e.g., 'Evaluate Script', 'render', 'fetchData').
*   duration: The total execution time of the call frame, including its children.
*   selfTime: The time spent directly within the call frame, excluding its children's execution.
*   urlIndex: Index referencing the "All URLs" list. Empty if no specific script URL is associated.
*   childRange: Specifies the direct children of this node using their IDs. If empty ('' or 'S' at the end), the node has no children. If a single number (e.g., '4'), the node has one child with that ID. If in the format 'firstId-lastId' (e.g., '4-5'), it indicates a consecutive range of child IDs from 'firstId' to 'lastId', inclusive.
*   S: **Optional marker.** The letter 'S' appears at the end of the line **only** for the single call frame selected by the user.

....

Meskipun deskripsi format ini menimbulkan biaya token, biaya ini adalah biaya statis yang dibayar satu kali untuk seluruh percakapan. Biaya tersebut lebih kecil daripada penghematan yang diperoleh melalui pengoptimalan sebelumnya.

Kesimpulan

Mengoptimalkan penggunaan token adalah pertimbangan penting saat membangun dengan AI. Dengan beralih dari JSON mentah ke format kustom khusus, mengindeks ulang struktur dengan Penelusuran Luas Pertama, dan menggunakan panggilan alat untuk mengambil data sesuai permintaan, kami secara signifikan mengurangi jumlah token yang digunakan oleh bantuan AI di Chrome DevTools.

Pengoptimalan ini merupakan prasyarat untuk mengaktifkan bantuan AI bagi rekaman aktivitas performa. Karena jendela konteksnya yang terbatas, model ini tidak dapat menangani volume data yang sangat besar. Namun, format yang dioptimalkan memungkinkan agen performa yang dapat mempertahankan histori percakapan yang lebih panjang dan memberikan jawaban yang lebih akurat dan sadar konteks tanpa terganggu oleh noise.

Kami harap teknik ini menginspirasi Anda untuk melihat kembali struktur data Anda sendiri saat mendesain untuk AI. Untuk mulai menggunakan AI di aplikasi web, pelajari Mempelajari AI di web.dev.