Komuniti Automasi Pelayar Berdebat Mengenai CDP Mentah berbanding Kerangka Kerja Tahap Tinggi ketika Syarikat AI Meninggalkan Playwright

Pasukan Komuniti BigGo
Komuniti Automasi Pelayar Berdebat Mengenai CDP Mentah berbanding Kerangka Kerja Tahap Tinggi ketika Syarikat AI Meninggalkan Playwright

Komuniti automasi pelayar sedang menyaksikan perdebatan sengit mengenai pertukaran antara menggunakan Chrome DevTools Protocol (CDP) mentah berbanding kerangka kerja yang telah mapan seperti Playwright dan Puppeteer . Perbincangan ini semakin memanas apabila syarikat automasi pelayar AI semakin meninggalkan abstraksi tahap tinggi demi kawalan pelayar secara langsung.

Gambar rajah konseptual yang menggambarkan hubungan antara pelbagai komponen automasi pelayar seperti Chrome, CDP, dan Playwright
Gambar rajah konseptual yang menggambarkan hubungan antara pelbagai komponen automasi pelayar seperti Chrome, CDP, dan Playwright

Migrasi Kerangka Kerja Besar-besaran

Beberapa syarikat pelayar AI baru-baru ini beralih daripada Playwright kepada pelaksanaan CDP mentah, menyebut isu prestasi dan kawalan. Peralihan ini mewakili trend yang lebih luas di mana syarikat sanggup mengorbankan kemudahan untuk kelajuan dan ketepatan. Satu syarikat melaporkan mencapai peningkatan prestasi 5 kali ganda dalam pengekstrakan elemen selepas meninggalkan Playwright sepenuhnya, walaupun ini datang dengan kos perlu membina semula keupayaan automasi pelayar asas dari awal.

Migrasi ini bukan hanya mengenai kelajuan. Syarikat-syarikat mendapati bahawa lapisan abstraksi Playwright mengaburkan butiran pelayar kritikal yang diperlukan untuk tugas automasi AI yang canggih. Sokongan iframe merentas asal, pengesanan pendengar acara terperinci, dan pengurusan keadaan elemen yang tepat menjadi mencabar apabila bekerja melalui pelbagai lapisan abstraksi.

Perbandingan Prestasi

  • CDP Mentah: ~100 mikrosaat masa perjalanan pulang pergi secara tempatan
  • Pengekstrakan elemen: 5x lebih pantas daripada Playwright (dilaporkan oleh sebuah syarikat)
  • Tangkapan imej: ~60ms melalui CDP
  • Syot halaman: 40-500ms bergantung kepada kerumitan

Alternatif Berasaskan Sambungan Mendapat Tarikan

Perkembangan menarik dalam komuniti melibatkan pemindahan alat automasi tradisional untuk berjalan sebagai sambungan Chrome . Pendekatan ini menawarkan kelebihan unik, termasuk akses kepada 3.5 bilion pemasangan Chrome dan keupayaan untuk beroperasi dalam sesi pelayar sedia ada pengguna dengan semua kelayakan log masuk mereka yang utuh. Sambungan boleh mengelakkan banyak mekanisme pengesanan bot kerana ia beroperasi lebih dekat dengan interaksi pengguna yang sah.

Walau bagaimanapun, automasi berasaskan sambungan menghadapi batasan yang ketara. Mereka tidak dapat mengautomasikan laman web tertentu yang memeriksa acara pengguna yang dipercayai, bergelut dengan tangkapan skrin halaman penuh, dan menghadapi cabaran pengedaran melalui dasar Chrome Web Store . Sekatan manifest v3 telah memperumitkan lagi pembangunan sambungan, memaksa pembangun mencari penyelesaian kreatif.

Statistik Automasi Sambungan Chrome

  • 3.5 bilion pemasangan desktop Chrome di seluruh dunia
  • Pendekatan sambungan berjalan "sangat pantas" disebabkan kedekatan dengan pelayar
  • Had: Tidak dapat mengautomasikan laman web yang memeriksa peristiwa isTrusted
  • Tidak dapat mengambil tangkapan skrin halaman penuh tanpa penyelesaian alternatif
  • Sekatan Manifest v3 mengehadkan keupayaan automasi tertentu

Warisan Selenium Muncul Semula

Subplot menarik muncul apabila pencipta asal Selenium menyertai perbincangan, memberikan konteks sejarah yang telah diabaikan oleh ramai. Kecenderungan komuniti untuk hanya memberi tumpuan kepada alat moden seperti Playwright dan Puppeteer secara tidak sengaja telah memadamkan sejarah kaya automasi pelayar yang bermula sejak awal 2000an. Perspektif sejarah ini menyerlahkan bagaimana industri cenderung untuk berputar melalui cabaran dan penyelesaian yang serupa.

Masa adalah bulatan rata... dahulu kala, kebanyakan pembangun hanya mengambil berat tentang satu pelayar -- internet explorer. kemudian untuk tempoh yang lama, keserasian merentas pelayar sangat dihargai. kini, kebanyakan pembangun hanya mengambil berat tentang satu pelayar -- google chrome.

Garis Masa Automasi Pelayar

  • 2005-2017: Era PhantomJS (headless WebKit)
  • 2011: Chrome remote debugging diperkenalkan
  • 2013: WebKit Remote Debugging Protocol v1
  • 2017: Headless Chrome dan Puppeteer dilancarkan
  • 2018: WebDriver menjadi standard W3C
  • 2020: Playwright 1.0 dikeluarkan
  • 2023-2024: Sokongan WebDriver BiDi ditambah
Meneroka peralihan daripada Playwright kepada CDP dalam alat automasi pelayar dan konteks sejarah yang mengelilingi perubahan-perubahan ini
Meneroka peralihan daripada Playwright kepada CDP dalam alat automasi pelayar dan konteks sejarah yang mengelilingi perubahan-perubahan ini

Pertukaran Prestasi berbanding Kebolehselenggaraan

Perdebatan teras berpusat pada sama ada keuntungan prestasi daripada CDP mentah membenarkan beban kerumitan dan penyelenggaraan yang meningkat. Penyokong berhujah bahawa masa perjalanan pulang pergi 100-mikrosaat CDP dan akses langsung kepada dalaman pelayar menjadikannya ideal untuk tugas automasi frekuensi tinggi. Pengkritik bimbang mengenai mencipta semula roda yang telah diuji dengan baik dan usaha kejuruteraan yang besar yang diperlukan untuk mengendalikan pengurusan kitaran hayat pelayar, pemulihan ranap, dan navigasi merentas bingkai.

Syarikat yang menggunakan CDP mentah melaporkan cabaran ketara dengan pengendalian ranap tab, keadaan perlumbaan, dan pengurusan keadaan merentas pelbagai sasaran pelayar. Ini adalah masalah yang tepat yang kerangka kerja seperti Playwright direka untuk menyelesaikan, menyebabkan sesetengah pihak mempersoalkan sama ada faedah prestasi berbaloi dengan kos kejuruteraan.

Kebimbangan Monopoli Chrome

Ketegangan asas dalam perbincangan ini melibatkan pergantungan yang semakin meningkat kepada teknologi khusus Chrome . Walaupun CDP menawarkan keupayaan automasi yang berkuasa, ia terutamanya adalah ciri Chrome / Chromium . Firefox telah menyusutkan sokongan CDP memihak kepada WebDriver BiDi , tetapi yang terakhir belum cukup lengkap ciri untuk tugas automasi yang menuntut.

Pendekatan berpusat Chrome ini mencerminkan corak sejarah di mana peralatan pembangun tertumpu di sekitar pelayar dominan, berpotensi mengukuhkan monopoli pasaran. Walau bagaimanapun, pertimbangan praktikal sering mengatasi kebimbangan ideologi apabila syarikat memerlukan penyelesaian automasi yang boleh dipercayai hari ini daripada menunggu piawaian merentas pelayar matang.

Landskap automasi pelayar terus berkembang dengan pantas, tanpa pemenang yang jelas muncul antara pelaksanaan CDP mentah dan kerangka kerja yang mapan. Pilihan semakin bergantung kepada kes penggunaan khusus, keperluan prestasi, dan sumber kejuruteraan yang tersedia untuk mengendalikan kerumitan kawalan pelayar langsung.

Rujukan: Closer to the Metal: Leaving Playwright for CDP

Panduan menggunakan Chrome DevTools Protocol, menimbang faedahnya berbanding potensi kelemahan dalam konteks automasi yang lebih luas
Panduan menggunakan Chrome DevTools Protocol, menimbang faedahnya berbanding potensi kelemahan dalam konteks automasi yang lebih luas