Cara peningkatan INP Fotocasa berkontribusi terhadap pertumbuhan 27% dalam metrik utama

Dipublikasikan: 14 Oktober 2025

Interaction to Next Paint (INP) adalah metrik Core Web Vitals penting untuk mengukur responsivitas. Di Fotocasa, Google Search Console menandai sejumlah besar halaman yang beralih ke "Perlu ditingkatkan" dan "Buruk" saat INP menggantikan First Input Delay (FID) pada tahun 2024. Studi kasus ini menguraikan alat dan strategi yang digunakan untuk mendiagnosis dan menyelesaikan masalah ini, yang pada akhirnya meningkatkan INP secara signifikan.

Tempat tim Fotocasa memulai

Sebelum peralihan dari FID ke INP, hampir setiap halaman di desktop dan perangkat seluler berada dalam batas "Baik", yang berarti semua Data Web Inti pada saat itu (LCP, CLS, dan FID) berperforma baik. Namun, setelah beralih ke INP, hampir semua halaman beralih ke "Perlu ditingkatkan" dan beberapa bahkan ke "Buruk", karena nilai INP secara konsisten melebihi 200 milidetik untuk sebagian besar interaksi pengguna.

Google Search Console menampilkan distribusi URL Fotocasa di desktop, dengan banyak halaman yang beralih dari 'Baik' menjadi 'Perlu ditingkatkan' setelah INP menjadi Data Web Inti.
Gambar 1. Google Search Console – Distribusi URL Fotocasa di desktop: saat INP berlaku, banyak URL yang sebelumnya diklasifikasikan sebagai "baik" berpindah ke kategori "perlu peningkatan".

Perubahan ini membuat tim Fotocasa menyadari bahwa mereka mengabaikan aspek penting dari pengalaman pengguna. Meskipun FID hanya mengukur penundaan interaksi pertama, INP mengevaluasi responsivitas semua interaksi, dengan memperhitungkan penundaan pemrosesan input dan presentasi. Pengukuran yang lebih luas ini merupakan pengganti yang jauh lebih baik untuk interaktivitas yang sebenarnya (seperti yang dinyatakan oleh Google) dan menyoroti peluang yang terlewat.

Meskipun Google Search Console memberikan data performa kolom, data ini tidak memberikan insight real-time. Datanya diagregasi selama periode 28 hari, sehingga sulit untuk menentukan secara tepat interaksi mana yang menyebabkan masalah pada saat itu.

Cara untuk melacak INP secara real time diperlukan untuk mengidentifikasi interaksi yang paling lambat dan paling sering digunakan oleh pengguna, serta mereproduksinya secara andal di lingkungan pengembangan tim. Yang sama pentingnya adalah memahami dampak perubahan yang dilakukan, bukan hanya perbaikan mana yang membantu, tetapi juga penyesuaian mana yang secara tidak sengaja memperburuk keadaan.

Oleh karena itu, serangkaian alat digunakan untuk membantu mendiagnosis dan menyelesaikan masalah tersebut. Yang paling penting adalah:

  • Google Chrome DevTools, khususnya tab Performance.
  • Sistem RUM (Real User Monitoring) kustom yang dibuat oleh tim Fotocasa di Datadog menggunakan library web-vitals.
  • React Developer Tools.

Alat untuk mendiagnosis masalah

Untuk mendiagnosis dan men-debug masalah performa INP, alat berikut digunakan.

Google Chrome DevTools

Cara terbaik untuk mendeteksi dan mereproduksi masalah terkait Data Web Inti dalam aplikasi web adalah dengan menggunakan tab Performa di Google Chrome DevTools. Tab Performa mengukur metrik Core Web Vitals secara otomatis, sehingga memberikan masukan instan tentang metrik pemuatan, interaktivitas, dan pergeseran tata letak. Secara umum konsisten dengan cara metrik ini dilaporkan ke alat Google lainnya.

Tab Performa di Google Chrome DevTools, yang menampilkan linimasa dengan berbagai metrik performa seperti LCP, FID, dan CLS, beserta aktivitas CPU dan Jaringan.
Gambar 2. Tab Performa di Google Chrome DevTools.

Untuk mengidentifikasi dan menyelesaikan masalah INP, tim Fotocasa biasanya memulai dengan membatasi CPU untuk menyimulasikan performa perangkat kelas bawah dan menengah. Hal ini memungkinkan tim Fotocasa mengamati perilaku halaman dalam kondisi yang lebih terbatas. Sesi kemudian direkam menggunakan profiler dan rekaman aktivitas dianalisis dengan cermat, dengan berfokus pada interaksi pengguna untuk menunjukkan masalah performa.

Tab Performa di Google Chrome DevTools menampilkan menu drop-down pelambatan CPU dengan opsi seperti '4x slowdown' dan '6x slowdown'.
Gambar 3. Tab Performa di Google Chrome DevTools yang menampilkan menu drop-down pelambatan CPU.

Saat mengidentifikasi hambatan, sangat berguna untuk memeriksa sub-bagian INP dan tugas yang dilakukan browser dalam setiap sub-bagian tersebut. Misalnya, pada gambar berikut, terlihat bahwa INP cukup tinggi karena dua penghitungan ulang gaya yang disebabkan oleh perubahan gaya di isi dokumen.

Tab Performa di Google Chrome DevTools menampilkan tugas panjang di profiler, dengan detail yang menunjukkan dua penghitungan ulang gaya yang menyebabkan INP tinggi.
Gambar 4. Tab Performa di Google Chrome DevTools yang menampilkan profiler yang terisi.

Fotocasa menyiapkan sistem untuk melacak INP dan metrik Core Web Vitals lainnya, sehingga memastikan bahwa setiap masalah performa dapat diidentifikasi dan ditangani dengan cepat. Jika metrik melampaui nilai minimum tertentu (berdasarkan rentang yang ditentukan Google), atribusi akan dicatat sehingga masalah dapat dianalisis dan diselesaikan.

Untuk sistem tersebut, library web-vitals digunakan untuk merekam metrik ini dari pengguna sebenarnya dengan cara yang secara akurat cocok dengan cara metrik tersebut diukur oleh Chrome dan dilaporkan ke alat Google lainnya (seperti Laporan Pengalaman Pengguna Chrome, PageSpeed Insights, Laporan Kecepatan Search Console, dan lainnya).

Untuk tampilan komprehensif dan pelacakan terpusat, Fotocasa menggunakan Datadog untuk mengumpulkan dan memvisualisasikan data, sehingga tim dapat membuat keputusan berbasis data yang tepat. Metrik kustom membuatnya hemat biaya, dan lebih mampu melacak hampir semua pengguna di situs Fotocasa.

Dasbor Datadog Fotocasa yang menampilkan berbagai metrik performa, termasuk INP, LCP, dan CLS, dari waktu ke waktu.
Gambar 5. Dasbor RUM Performa Datadog Fotocasa.
Dasbor Datadog yang menampilkan grafik untuk metrik penundaan input, durasi pemrosesan, dan penundaan presentasi.
Gambar 6. Metrik penundaan input, durasi pemrosesan, dan penundaan presentasi.

Sistem ini memungkinkan tim Fotocase memantau dengan cepat apakah modifikasi mereka memengaruhi metrik atau apakah terjadi perubahan yang tidak terduga, yang berpotensi membahayakan metrik tersebut. Metrik INP kemudian dapat dianalisis menjadi beberapa bagian seperti penundaan input, durasi pemrosesan, dan penundaan presentasi untuk menentukan secara tepat bagian interaksi mana yang terutama bertanggung jawab atas waktu interaksi yang lama.

Grafik dari Datadog yang menunjukkan lonjakan mendadak pada nilai INP, yang menunjukkan adanya anomali.
Gambar 7. Anomali INP terdeteksi di dasbor.
Alarm monitor di Datadog yang menampilkan anomali INP yang terdeteksi.
Gambar 8. Anomali INP terdeteksi di alarm monitor.

Setelah mendeteksi anomali, seperti yang diilustrasikan dalam gambar 7 dan 8, Fotocasa segera merespons dan menggunakan OpenSearch, alat lain yang membantu menentukan dengan tepat di mana perubahan mungkin terjadi. Data yang disediakan oleh library web-vitals membantu mengidentifikasi target (elemen DOM yang berpotensi bertanggung jawab atas nilai metrik yang tinggi) dan membantu tim lebih fokus dalam memperbaiki masalah.

Dasbor OpenSearch yang menampilkan data dari library web-vitals, yang digunakan untuk mengidentifikasi elemen DOM mana yang memengaruhi metrik INP.
Gambar 9. Dasbor OpenSearch untuk men-debug target mana yang memengaruhi metrik INP.

Selain itu, berbagai filter dapat ditentukan, seperti jenis halaman, perangkat, atau status pemuatan untuk menyederhanakan skenario, dan mendapatkan pemahaman yang lebih akurat tentang pengaruh INP.

Alat Developer React

React Developer Tools digunakan untuk meningkatkan kemampuan proses debug Fotocasa, yang menyediakan fitur canggih yang memungkinkan Anda menandai komponen yang telah dirender ulang secara visual.

Fitur ini dapat diaktifkan dengan membuka tab Profiler. Dari sana, klik roda gigi di sisi kanan panel atas, buka tab Umum, dan centang kotak Soroti pembaruan saat komponen dirender. Dengan opsi ini diaktifkan, komponen akan disorot saat dirender ulang, sehingga memberikan representasi visual yang dinamis.

Panel setelan di React Developer Tools, dengan kotak centang 'Highlight updates when components render' dicentang.
Gambar 10. Konfigurasi profiler React Developer Tools.

Mengetahui penyebab render ulang

Setelah komponen yang dirender ulang diidentifikasi, pertanyaan berikutnya adalah "mengapa hal itu terjadi?" React DevTools menjawabnya dengan tooltip bermanfaat dalam tampilan flame graph.

Untuk mengakses informasi ini, rekam sesi profiler. Dengan menganalisis output profiler, Anda akan menemukan informasi yang berguna:

  • Di pojok kanan atas, jumlah commit React ditampilkan.
  • Grafik flame secara visual merepresentasikan hierarki komponen, dengan warna abu-abu menunjukkan komponen yang tidak dirender ulang. Setiap batang mewakili momen saat hierarki komponen React berubah, dan saat perubahan yang sesuai dilakukan ke DOM.
  • Arahkan kursor ke setiap komponen dalam grafik flame untuk melihat alasan perenderannya ulang di bawah subjudul Mengapa perenderan ini terjadi?.

Alasan perenderan ulang komponen dapat mencakup:

  • Ini adalah pertama kalinya komponen dirender
  • Konteks berubah
  • Hook diubah
  • Properti diubah
  • State berubah
  • Komponen induk dirender
Profiler React Developer Tools yang menampilkan grafik batang, dengan tooltip terbuka pada komponen yang menjelaskan bahwa komponen tersebut dirender ulang karena 'Hooks changed'.
Gambar 11. Panel render di profiler React Developer Tools.

Mengetahui waktu rendering

Warna dalam grafik flame menyampaikan informasi yang bermakna. Warna seperti berbagai nuansa biru menunjukkan bahwa komponen memerlukan waktu rendering yang relatif singkat dibandingkan dengan komponen lainnya. Sebaliknya, warna seperti oranye dan merah menandakan bahwa komponen memerlukan waktu rendering yang lebih lama.

Profiler Alat Developer React menampilkan grafik batang di mana warna menunjukkan waktu rendering, dengan warna biru menunjukkan waktu yang lebih singkat dan warna oranye/merah menunjukkan waktu yang lebih lama.
Gambar 12. Waktu rendering seperti yang ditampilkan di profiler Alat Developer React.

Cara tim Fotocasa memperbaiki masalah

Menghapus render ulang yang tidak perlu

Render ulang terjadi setiap kali React perlu memperbarui UI dengan data baru. Hal ini biasanya berasal dari tindakan pengguna, respons API, atau peristiwa penting lainnya yang memerlukan update antarmuka pengguna. Karena setiap render ulang menjalankan JavaScript, terlalu banyak render ulang sekaligus—terutama dalam hierarki komponen yang besar—dapat memblokir thread utama dan menyebabkan masalah performa.

Ada dua jenis perenderan ulang:

  • Render ulang yang diperlukan: Saat komponen benar-benar perlu diupdate karena memiliki atau menggunakan data baru.
  • Render ulang yang tidak perlu: Saat komponen diupdate tanpa perubahan yang berarti, sering kali karena pengelolaan status yang tidak efisien atau penanganan properti yang tidak tepat.

Beberapa render ulang yang tidak perlu biasanya tidak menjadi masalah besar, karena React cukup cepat sehingga pengguna umumnya tidak akan menyadarinya. Namun, jika terlalu sering terjadi, atau di seluruh hierarki komponen yang berat, hal ini dapat merusak pengalaman pengguna dan berdampak negatif pada INP halaman.

Hal ini terjadi pada tim Fotocasa. Mereka menyadari bahwa situs memiliki banyak render ulang yang tidak perlu. Hal ini terjadi dalam dua skenario utama:

  • Selama pemuatan halaman: Meningkatkan jumlah tugas panjang di thread utama dan menunda interaksi pertama, yang berdampak negatif pada INP halaman.
  • Selama interaksi pengguna: Meningkatkan waktu pemrosesan sebagian besar interaksi, yang juga merusak INP.

Banyak render ulang yang tidak perlu akhirnya dioptimalkan di situs Fotocasa. Salah satu pengoptimalan terbesar yang dilakukan adalah di halaman Penelusuran. Ada tiga render ulang yang tidak perlu saat pemuatan halaman. Setelah dihapus, hasil berikut diamati:

  • Lebih sedikit tugas panjang (lihat gambar berikut)
  • Total Blocking Time yang lebih rendah (bandingkan gambar 14 dan 15)
Dua snapshot thread utama dari Chrome DevTools. Snapshot atas menunjukkan lebih banyak tugas panjang sebelum pengoptimalan, sedangkan snapshot bawah menunjukkan lebih sedikit tugas panjang setelah menghapus rendering ulang yang tidak perlu.
Gambar 13. Snapshot thread utama dengan dan tanpa render ulang yang tidak perlu.
Laporan Performa Seluler Lighthouse yang menampilkan Total Waktu Pemblokiran 1.080 md, yang menunjukkan masalah performa yang disebabkan oleh render ulang yang tidak perlu.
Gambar 14. Laporan Performa Seluler Lighthouse yang menampilkan render ulang yang tidak perlu.
Laporan Performa Seluler Lighthouse yang menunjukkan Total Waktu Pemblokiran yang berkurang secara signifikan setelah menghapus rendering ulang yang tidak perlu.
Gambar 15. Laporan Performa Seluler Lighthouse tanpa rendering ulang yang tidak perlu.

Kolokasi status

Penempatan status React yang tidak tepat dapat memperlambat aplikasi dan membuat UI terasa tidak responsif. Saat status komponen berubah, komponen turunannya akan dirender ulang secara default kecuali jika digunakan mekanisme alternatif (misalnya, memo).

Seperti yang dijelaskan di bagian sebelumnya, render ulang tidak selalu buruk, tetapi merender ulang seluruh halaman karena update status tertentu dapat menyebabkan interaksi yang lebih lambat, karena update DOM terjadi setelah render.

Misalnya, di halaman Penelusuran ada dialog yang menampilkan semua filter saat tombol diklik.

Panel filter di halaman Penelusuran Fotocasa, yang menampilkan tombol untuk membuka dialog dengan semua filter.
Gambar 16. Panel filter Fotocasa.

Status yang mengontrol status terbuka dialog dalam kasus ini ditempatkan di halaman Penelusuran. Saat status ini berubah, seluruh halaman dirender ulang sehingga menyebabkan INP yang buruk, terutama pada perangkat yang lebih lambat seperti yang terlihat saat pembatasan CPU digunakan di DevTools:

Throttling CPU INP
Pelambatan 4x 440 milidetik (perlu peningkatan)
Pelambatan 6x 832 milidetik (buruk)

Mengubah status sedekat mungkin dengan komponen yang memicu perubahan akan menyelesaikan masalah ini. Dalam kasus ini, status dapat ditempatkan di komponen tombol filter sehingga saat status berubah, hanya tombol yang akan dirender ulang.

Throttling CPU INP
Pelambatan 4x 64 milidetik (baik)
Pelambatan 6x 232 milidetik (perlu ditingkatkan)

Menghapus status yang tidak perlu

Status tidak boleh berisi informasi yang berlebihan atau duplikat. Jika melakukannya, hal ini dapat menyebabkan render ulang yang tidak perlu, dan menimbulkan masalah.

Misalnya, di kolom filter Fotocasa, ada teks yang menunjukkan jumlah filter yang diterapkan untuk penelusuran tertentu:

Panel filter Fotocasa menampilkan tombol berlabel 'Filter' dengan angka yang menunjukkan jumlah filter yang diterapkan.
Gambar 17. Tombol dan penghitung filter Fotocasa.

Jumlah filter yang diterapkan dihitung dari status aplikasi. Namun, hal ini tidak hanya mengakibatkan rendering ulang yang tidak perlu pada seluruh komponen, tetapi dalam kasus tertentu juga menyebabkan pergeseran tata letak karena komponen ini dirender sisi server:

const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)

useEffect(() => {
  const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER

  setFiltersCount(counter)
}, [searchParams]);

Untuk mengatasi masalah ini, nilai diturunkan dari objek filter menggunakan variabel, bukan menggunakan status:

const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER;

Mengurangi render yang mahal

Saat interaksi terjadi di aplikasi React, biasanya akan memicu perubahan status. Seperti yang dijelaskan sebelumnya, saat status komponen berubah, komponen akan dirender ulang bersama dengan semua turunannya.

Jika salah satu fungsi render komponen ini lambat, INP halaman akan terpengaruh secara negatif karena tugas yang panjang kemungkinan akan dibuat, dan DOM akan membutuhkan waktu lebih lama untuk diupdate.

Tim Fotocasa mencoba meminimalkan komputasi yang memakan waktu dalam fungsi render komponen sebanyak mungkin. Chrome DevTools dan React Developer Tools sangat berguna dalam mendeteksi operasi rendering yang lambat.

Menunda eksekusi kode

Selain mengoptimalkan fungsi render komponen, fungsi lain juga dioptimalkan untuk meminimalkan tugas panjang sebanyak mungkin. Namun, beberapa tugas tidak dapat dioptimalkan karena bergantung pada kode pihak ketiga.

Salah satu contohnya adalah analitik. Dalam hal ini, diputuskan untuk menunda eksekusi kode analisis dan memprioritaskan update DOM saat interaksi pengguna terjadi. Untuk mencapainya, tim Fotocasa menggunakan library bernama idlefy, yang juga memastikan bahwa kode analisis akan tetap berjalan meskipun browser ditutup segera setelahnya.

Budaya performa

Pekerjaan performa bukan upaya satu kali, tetapi sesuatu yang harus dipertimbangkan dengan setiap fitur yang dirilis ke produksi. Semua orang dalam tim harus selaras, jika tidak, regresi di Data Web Inti hampir pasti terjadi.

Untuk terus memantau hal ini, tim Fotocasa secara aktif membagikan pengetahuan dalam tim dan menetapkan kerangka kerja yang jelas untuk mengidentifikasi masalah performa berdasarkan data RUM Datadog Fotocasa, termasuk cara mereproduksinya. Peringatan untuk Core Web Vitals—terutama INP—disiapkan di sistem RUM, yang dikonfigurasi untuk memberi tahu tim Fotocasa secara langsung di Slack. Pendekatan ini membuat performa menjadi prioritas utama, dan membantu mendeteksi masalah sebelum berubah menjadi regresi.

Hasil

Meningkatkan INP di Fotocasa memerlukan kombinasi pengoptimalan teknis dan perubahan budaya. Dengan menghilangkan rendering ulang yang tidak perlu, mengoptimalkan penempatan status, mengurangi rendering yang mahal, dan menunda kode yang tidak penting, tim Fotocasa berhasil memindahkan semua halaman desktop dari "perlu ditingkatkan" menjadi "baik", dan secara signifikan meningkatkan kualitas halaman seluler dengan mengupgrade hampir semua halaman "buruk" dan "perlu ditingkatkan" menjadi "baik".

Google Search Console menampilkan Core Web Vitals untuk Desktop Fotocasa setelah peningkatan INP.
Gambar 18. Google Search Console menampilkan Core Web Vitals untuk Desktop Fotocasa setelah peningkatan INP.

Perubahan ini meningkatkan keseluruhan pengalaman pengguna Fotocasa dan, bersama dengan inisiatif lainnya, mendorong peningkatan sebesar 27% pada iklan prospek kontak dan telepon, sehingga secara langsung memperkuat metrik bisnis utama perusahaan.

Pemantauan real-time dengan Datadog memungkinkan tim Fotocasa memvalidasi peningkatan INP, mendeteksi anomali dengan cepat, dan mencegah regresi. Selain pencapaian ini, Fotocasa juga berhasil menyematkan performa web ke dalam budaya pengembangan mereka, sehingga memastikan bahwa INP dan Data Web Inti tetap menjadi prioritas dalam setiap rilis.