წარმოგიდგენთ Kitesurf-ს: აგენტებზე ორიენტირებული ბრაუზერი, რომელიც Cloudflare Workers-ის V8 იზოლატებში მუშაობს

უნდა შევქმნათ ჩვენი საკუთარი ბრაუზერი?

ეს არის ერთ-ერთი იმ კითხვათაგანი, რომელიც წლების განმავლობაში ყოველ რამდენიმე თვეში ერთხელ ჩნდებოდა Cloudflare-ის შიდა განხილვებში. გასაკვირი არ არის, რომ ეს კითხვა იწვევდა გრძელ დისკუსიებს მრავალი მიზეზითა და დამარწმუნებელი არგუმენტით იმის შესახებ, თუ რატომ უნდა გაგვეკეთებინა ეს. ბრაუზერი აშკარად ყველაზე მნიშვნელოვანი პროგრამული უზრუნველყოფაა, რომელსაც ყოველდღიურად ვიყენებთ ჩვენს კომპიუტერებში; ის, ფაქტობრივად, ინტერნეტის ოპერაციული სისტემაა. ჩვენ ვართ კომპანია, რომლის მისიაა უკეთესი ინტერნეტის მშენებლობა — ვის არ მოუნდებოდა ახალი ბრაუზერის შექმნის გამოწვევის მიღება?

თუმცა, ვერასდროს ვპოულობდით ბალანსს ამ წამოწყების ტექნიკურ სირთულესა და იმ უნიკალურ პრობლემებს შორის, რომლებსაც ამით გადავჭრიდით. ასე რომ, იდეა არაერთხელ გადაიდო. აქამდე.

მოხდა რაღაც ჯადოსნური: მივაღწიეთ გარდამტეხ მომენტს, როდესაც ჩვენს დეველოპერულ პლატფორმაზე მძლავრი ტექნიკური მიღწევების სერია რეალობად იქცა, ხოლო AI აგენტების გამოჩენამ და ახალი ტიპის ბრაუზერის საჭიროებამ კრიტიკულ წერტილს მიაღწია.

WebAssembly (Wasm)-ის გაშვება Workers-ში ახლა უკვე სრულყოფილია. ისეთი პრიმიტივები, როგორიცაა დინამიკური ვორკერები, SQLite-ზე დაფუძნებული Durable Objects, Worker-to-worker RPC, სერვისების ბაინდინგები, უფრო მაღალი NodeJS თავსებადობა და გაზრდილი ლიმიტები, გზას უხსნის ბევრად უფრო ამბიციურ და კომპლექსურ აპლიკაციებს, რაც ადრე უბრალოდ შეუძლებელი იყო.

Browser Run, ჩვენი უეკრანო (headless) ბრაუზერის ავტომატიზაციის API პროდუქტი, AI-ის ზრდასთან ერთად საოცრად განვითარდა. აგენტებს ბრაუზერები სჭირდებათ მრავალი დავალების შესასრულებლად და ხშირ შემთხვევაში მათ გარეშე წარმატებას ვერ აღწევენ.

მაგრამ არსებობს პრობლემა — ბრაუზერის ძრავები, როგორიცაა Chromium, შეიქმნა ადამიანებისთვის და არა აგენტებისთვის, და მათ აქვთ ისეთი ზედმეტი დანახარჯები (overhead), რაც AI მოდელებს უბრალოდ არ სჭირდებათ. ისინი მოიხმარენ იმდენ მეხსიერებას და გამოთვლით რესურსს, რომ თითოეული აგენტისთვის საკუთარი ინსტანსის გამოყოფა წარმოუდგენლად ძვირია. ეს ზღუდავს ვებგვერდების დიდ ნაწილს მხოლოდ ყველაზე დახვეწილი და ძვირადღირებული AI მოდელებისთვის, ხოლო ბევრ სხვა აგენტურ აპლიკაციას გზას უკეტავს.

ჩვენ ყველა აგენტს უნდა მივცეთ ბრაუზერი, რომელიც საუკეთესოა იმაში, რაც AI მოდელისთვისაა მნიშვნელოვანი, მაშინაც კი, თუ ეს ნიშნავს იმის დათმობას, რაც მხოლოდ ადამიანებისთვისაა სასარგებლო. მაგალითად:

• AI-ს არ აინტერესებს ტაბები, თემები, ბრაუზერის გაფართოებები ან მოწყობილობებს შორის სინქრონიზაცია. მისთვის მნიშვნელოვანია ტოკენების რაოდენობა, კონტექსტური ფანჯარა, მასშტაბირებადობა, წარმადობა და ხარჯები.
• სტრუქტურირებული, მანქანურად წაკითხვადი კონტენტი მნიშვნელოვანია, მაგრამ ვიზუალური სრულყოფილება და გლუვი 60-fps სქროლინგი — არა. აგენტებისთვის პრობლემა არ იქნება, თუ CSS-ის პარსინგი ოდნავ ცდომილია ან რენდერინგი არ არის პიქსელურად ზუსტი.
• საფრთხეების მოდელი AI-ის მიერ ბრაუზერის გამოყენებისას განსხვავებულია. ისეთი ახალი პრობლემები, როგორიცაა პრომპტ-ინექცია და ხელსაწყოების უსაფრთხოება, მთავარი პრიორიტეტებია.

ამ რეალობის წინაშე დადგომისას, 12 კვირის წინ კვლავ დავსვით კითხვა: უნდა შევქმნათ ჩვენი საკუთარი ბრაუზერი? ამჯერად პასუხი ერთსულოვანი იყო: დიახ!

დღეს ჩვენ ვაანონსებთ Kitesurf-ს, ახალ ბრაუზერს, რომელიც მთლიანად Workers-ის ბაზაზე მუშაობს და რომელიც სპეციალურად აგენტებისთვის შევქმენით. ის უფასოდ არის ხელმისაწვდომი ბეტა რეჟიმში Browser Run-ში.

Kitesurf მნიშვნელოვნად უფრო ეფექტურია CPU-სა და მეხსიერების მოხმარების თვალსაზრისით, ვიდრე Chromium, ისეთი ტიპური აგენტური დავალებებისთვის, როგორიცაა სქრინშოტები და HTML ექსტრაქცია. ქვემოთ მოყვანილია ამბავი იმისა, თუ როგორ შევქმენით ის. მოემზადეთ, ტექნიკური დეტალები იქნება — მაგრამ გპირდებით, რომ საინტერესო იქნება.

როგორ დაიწყო ეს ყველაფერი

Kitesurf ისე დაიწყო, როგორც ბევრი სხვა შესანიშნავი იდეა Cloudflare-ში. ვიღაცამ რაღაც საინტერესო აღმოაჩინა და სანამ აზრზე მოვიდოდით, მან გუნდის დანარჩენი წევრები „ინტელექტუალური გამოწვევით“ (nerd sniping) დააინტერესა ერთი შეხედვით შეუძლებელი, მაგრამ ძალიან მიმზიდველი იდეით.

საწყისი ინსპირაცია მივიღეთ obscura-სგან, Rust-ზე დაწერილი headless ძრავისგან AI ავტომატიზაციისთვის, რომელსაც არ აქვს „არც Chrome, არც Node.js და არც დამოკიდებულებები“.

შემდეგ, AI აგენტის დახმარებით, ვცადეთ მისი პორტირება Workers-ზე. თავიდან კარგად არ იმუშავა. მაგრამ როგორც კი AI-ს მივეცით მყარი გეგმა და წარმატების მკაფიო განმარტება — საკმარისად დეტალური იმისთვის, რომ აგენტს უსასრულოდ ეტრიალა და საჭიროების შემთხვევაში კითხვები დაესვა — მან იმუშავა. ამ (ძლივს) მომუშავე კონცეფციის მტკიცებულებით (proof of concept) აღფრთოვანებულებმა, გადავწყვიტეთ გუნდისთვის მუშაობის საშუალება მიგვეცა.

დიზაინის გადაწყვეტილებები

აი, ზოგიერთი დიზაინის გადაწყვეტილება, რომელიც მუშაობის დაწყებამდე მივიღეთ.

ტესტები, ტესტები, ტესტები

ვიცოდით, რომ პროტოტიპიდან სრულფასოვან ბრაუზერამდე გადასვლა, რომელიც რეალურად გამოსადეგი იქნებოდა მასშტაბური წარმოებისთვის, დიდ შრომასა და იტერაციას მოითხოვდა. არ დავმალავთ, რომ პროცესის დასაჩქარებლად AI-ის გამოყენება გადამწყვეტი იყო. მაგრამ როგორ გამოვიყენოთ AI ასეთ რთულ პროექტში ისე, რომ კოდის და შედეგების ხარისხი კონტროლქვეშ გვქონდეს ტემპის დაკარგვის გარეშე? პასუხია: მიაწოდეთ რაც შეიძლება მეტი ტესტი.

აქ დაგვეხმარა Web Platform Tests (WPT), იდეალური გარემო: წარმატების კრიტერიუმების ფართო ნაკრები, რომელმაც AI აგენტებს მისცა მკაფიო ორიენტირები ფუნქციების თავსებადობის შესაფასებლად. ჩვენ ვარჩევდით ფუნქციების თანმიმდევრობას აგენტებისთვის, რაც ადამიანებს საშუალებას აძლევდა ფოკუსირებულიყვნენ არქიტექტურულ სამუშაოებსა და აგენტების მიდგომების განხილვაზე.

თუმცა, WPT ტესტები მხოლოდ გარკვეულწილად გვეხმარება: ისინი ზომავენ W3C სტანდარტებთან შესაბამისობას და არა ბრაუზერის უნარს, მოახდინოს რეალური ვებგვერდების რენდერინგი და მათთან ინტერაქცია. ამ ხარვეზის შესავსებად, ჩვენ დავნერგეთ ინტეგრაციული ტესტირებისა და ვიზუალური რეგრესიული ტესტირების კომბინაცია — ის ატარებს მრავალსაფეხურიან Puppeteer ტესტებს რეალურ ვებგვერდებზე როგორც Chromium-ში, ისე Kitesurf-ში, არა მხოლოდ შედეგების შედარებით, არამედ ყოველ ნაბიჯზე რენდერინგის ვიზუალური შედარებით, რათა გამოვავლინოთ ნებისმიერი არასასურველი განსხვავება.

გამოიყენეთ Rust, როცა შესაძლებელია

Cloudflare უკვე დიდი ხანია მუშაობს Workers-ში WebAssembly (Wasm)-ის მხარდაჭერაზე. ეს შესანიშნავია, რადგან შეგვიძლია გამოვიყენოთ მაღალი წარმადობის C, C++ და Rust პაკეტები და მოვახდინოთ მათი Wasm-ში კომპილაცია. თუ გამოვიყენებთ (მაგალითად) Emscripten-ს და მის მრავალშრიან დამოკიდებულებებს, კომპილირებული ბინარული ფაილი შეიძლება გახდეს მოცულობითი და ნელი.

ამის ნაცვლად, ჩვენ ავირჩიეთ Native Rust, როცა ეს შესაძლებელი იყო, და პირდაპირი კომპილაცია WebAssembly-ში wasm-bindgen-ის გამოყენებით, რითაც თავიდან ავიცილეთ ზედმეტი ემულაციის შრეები და მივაღწიეთ მაქსიმალურ წარმადობას საიმედოდ.

შეცდომების დამუშავება (Exception handling)

ბრაუზერმა უნდა მოახდინოს მთელი არასაიმედო და ხანდახან მტრული ვებგვერდების რენდერინგი ისე, რომ გვერდი არ „დაუვარდეს“, ამიტომ შეცდომების დამუშავება უფრო მეტია, ვიდრე უბრალოდ ჰიგიენა — ეს არის გზა, რომლითაც აპლიკაცია უძლებს ცუდ მონაცემებს გათიშვის გარეშე.

ამიტომ თავიდანვე ერთ წესზე შევთანხმდით: ნებისმიერი შეცდომა იწვევს ცარიელ ჩარჩოს ან დაკარგულ ელემენტს, მაგრამ არასდროს მკვდარ სესიას. დააფიქსირეთ შეცდომები ყველა ზღვარზე, აჩვენეთ რამე უსაფრთხო და ცარიელი და აწარმოეთ საკმარისი ლოგირება დიაგნოსტიკისთვის.

იზოლაცია

თქვენს ლეპტოპზე ბრაუზერის გაშვებისგან განსხვავებით (სადაც სტუმრობთ საიტებს, რომლებსაც ენდობით და მისაღებია მათ შორის რესურსების გაზიარება), აგენტი მიმართულია იქით, რასაც დავალება მოითხოვს: ნებისმიერი კოდი ნებისმიერი წყაროდან.

ასე რომ, ჩვენ ეს ბრაუზერი ავაგეთ იმ დაშვებით, რომ ყოველი გვერდის ჩატვირთვა არის უნდობელი მონაცემი და ყოველი სესია იწყება სუფთა ფურცლიდან. თითოეული კომპონენტი იზოლირებულია და წვდომა აქვს მხოლოდ იმ რესურსებზე, რომლებიც კრიტიკულად აუცილებელია მისი ფუნქციონირებისთვის.

ეს იდეალურად ერგება Cloudflare Workers-ს, რომლის უსაფრთხოების მოდელიც თავიდანვე იზოლაციაზეა აგებული. თუმცა, პლატფორმა მხოლოდ იზოლატებს შორის ზღვარს გვაძლევს. ჩვენ მაინც გვიწევს იგივე პრინციპის დაცვა აპლიკაციის დონეზე, იმის განსაზღვრა, თუ რაზე აქვს თითოეულ კომპონენტს წვდომა და იმის უზრუნველყოფა, რომ არაფერმა გაჟონოს იქ, სადაც არ უნდა მოხვდეს.

სტატუსის არქონა (Stateless), როცა ეს შესაძლებელია

სტატუსი (State) არის ის, რაც შეცდომას ძვირად აქცევს — თუ აღსადგენი არაფერია, გათიშვისგან აღდგენა უბრალოდ ახლის დაწყება და მოთხოვნის თავიდან გაშვებაა. Stateless კომპონენტი ბუნებით ერთჯერადი და პარალელურია: გათიშეთ ის მაშინვე, როგორც კი შეფერხდება, გაუშვით ათასი ერთდროულად და მოარგეთ ისინი მოთხოვნას. ეს იდეალურად ერგება ავტომატიზაციას, სადაც დატვირთვა პულსირებადია და ყველაზე იაფი, რაც შეგიძლიათ გააკეთოთ, არის ისეთი პროცესის გაშვება, რომელიც ღირს მხოლოდ იმდენი, რამდენიც გამოიყენა და ქრება დასრულებისთანავე. მოკლედ, სადაც კომპონენტი შეიძლება იყოს stateless, ის ასეთი უნდა იყოს.

როგორ ავაგეთ ის

კარგი გეგმით, ფართო ტესტებითა და კარგი ინსტრუმენტული გარემოთი შეიარაღებულები, მზად ვიყავით საწყისი ეტაპის გასაცდენად. აი, Kitesurf-ის მოთხოვნის დამუშავების მაღალი დონის სქემა, რომელიც დღესაც მოქმედებს:

მოდით, განვიხილოთ სამი ძირითადი კომპონენტი, რომელიც Kitesurf-ს ამუშავებს: Engine, PageScript და PageRenderer.

მონაცემების ამოღება წყაროებიდან

უნდობელი ვებგვერდის რენდერინგისთვის ბრაუზერმა ინტერნეტიდან უნდა ამოიღოს სხვადასხვა ასეტები — სურათები, ფონტები, CSS, JavaScript და Wasm ფაილები. ეს არის ერთ-ერთი ყველაზე სახიფათო ოპერაცია, რაც ბრაუზერმა შეიძლება გააკეთოს.

Kitesurf ამას აკეთებს ერთი კომპონენტის, SandboxOutbound ვორკერის მეშვეობით და სხვა არაფერს შეუძლია ქსელთან პირდაპირი შეხება — ამას დინამიკური ვორკერები უზრუნველყოფენ. Engine იყენებს მას გვერდის დასაწყებად, ძირითადი დოკუმენტისა და მისი სკრიპტების ამოსაღებად, ხოლო PageScript იღებს ყველაფერ დანარჩენს: სტილებს, სურათებს, ფონტებს და თავად გვერდის fetch() გამოძახებებს.

ჩვენ ვიყენებთ SandboxOutbound-ს CORS-ის აღსასრულებლად, ბრაუზერის ტიპის ჰედერების ინექციისთვის, პასუხების გასაფილტრად და თითოეული გვერდის ქუქი-ფაილების (cookies) იზოლირებულად შესანახად. ყველაფერი, რაც ჩვენს პოლიტიკას არ შეესაბამება, იღებს 403 შეცდომას — თითოეული კომპონენტი იღებს ზუსტად იმ ქსელურ წვდომას, რაც სჭირდება და მეტს არაფერს.

Engine (ძრავა)

Engine არის Kitesurf-ის ერთადერთი საჯარო კომპონენტი. ის ამუშავებს Chrome DevTools Protocol (CDP) WebSocket და HTTP REST API-ებს, ემსახურება სატესტო გვერდს, რომელიც გამოსადეგია შიდა ტესტირებისთვის და, რაც მთავარია, ინახავს თითოეული სესიის სტატუსს. ყველა სხვა კომპონენტი stateless-ია.

CDP-ის გამოყენების უპირატესობა კლიენტებთან თავსებადობაა: Puppeteer, Playwright, chrome-remote-interface და თავად Chrome DevTools-ი. მიმართეთ ისინი Kitesurf-ისკენ და ყველაფერი იმუშავებს. ასე მუშაობს Browser Run-იც (მოგვიანებით ავხსნით, რატომ არის ეს მნიშვნელოვანი).

სახელწოდების მიუხედავად, Engine რეალურად ყველაზე მარტივი კომპონენტია Kitesurf-ში. საინტერესო ნაწილები შემდეგ მოდის.

PageScript

PageScript არის ჩვენი Workers-ის ახალი ფუნქციების ძალის კარგი მაგალითი: ამ შემთხვევაში, დინამიკური ვორკერების. Kitesurf უბრალოდ შეუძლებელი იქნებოდა ამ ფუნქციის გარეშე.

აი, PageScript-ის მუშაობის გამარტივებული დიაგრამა.

ყოველი შემდეგი გვერდი ან პროცესსგარე iframe (OOPIF) იყენებს დინამიკურ ვორკერებს PageScript იზოლატის გასაშვებად, რომელიც მართავს გვერდის სესიას, რომელიც შედგება სუფთა globalThis-ისა და DOM დოკუმენტის ობიექტისგან.

შემდეგ DOM ობიექტი ივსება HTML დოკუმენტის პარსინგისა და ყველა JavaScript სკრიპტის გაშვების შედეგად. HTML-ისა და CSS-ის პარსინგისთვის ჩვენ ვიყენებთ Blitz-ის ნაწილებს, მოდულურ რენდერინგის ძრავას და Stylo-ს, Firefox-ის მაღალი წარმადობის CSS პარსერს, ორივე მათგანი Rust-ზეა დაწერილი.

თითოეული ნაპოვნი <script> ტეგისთვის ან .wasm ფაილისთვის, ჩვენ ვუშვებთ JavaScript და WebAssembly კოდს იმავე იზოლატში.

დიახ, მაგრამ eval-ები?

იკითხავთ, რა ვუყოთ eval-ებს? Eval-ების დამუშავება უფრო რთულია, რადგან უსაფრთხოების მიზეზების გამო ჩვენ კვლავ არ გვაქვს eval-ის მხარდაჭერა Workers-ში. მათთვის სხვა იზოლატსაც ვერ გამოვიყენებთ, რადგან მას არ ექნებოდა წვდომა globalThis-თან.

ჩვენი გამოსავალია Boa JS-ის გამოყენება, Rust-ზე დაწერილი ECMAScript ძრავა, რათა მოვახდინოთ კომპილაცია და გაშვება Workers-ზე. ჩვენ, ფაქტობრივად, ვუშვებთ Runtime-ს სხვა Runtime-ის ზემოთ, რაც შეიძლება ოპტიმალურად არ ჩანდეს (და არც არის), მაგრამ ის საკმარისად კარგად მუშაობს კოდში არსებული იშვიათი eval-ების დასამუშავებლად. მომავალში, როდესაც Workers-ში native eval-ის მხარდაჭერა გაჩნდება, ჩვენ Boa-ს აღარ გამოვიყენებთ.

PageRenderer

ეს კომპონენტი პასუხისმგებელია გამოთვლილი გვერდის ობიექტებიდან რეალური პიქსელების გენერირებაზე. აი, როგორ მუშაობს ის:

PageRenderer მუშაობს ციკლში Engine ვორკერთან ერთად. ყოველ ჯერზე, როდესაც ძრავას სჭირდება ჩარჩო (frame), PageRenderer იღებს გვერდის ობიექტს PageScript-დან (ასევე ცნობილია როგორც scene), იღებს შიდა ფონტებსა და სურათებს Static Assets-დან, ახდენს ყველაფრის რასტერიზაციას სურათის ბუფერში და შემდეგ უბრუნებს ბუფერს ძრავას ისეთ ფორმატში, რომელიც კლიენტს შეუძლია აჩვენოს, მაგალითად JPEG/PNG ან PDF.

ამ ჯადოსნობის დიდი ნაწილი სრულდება სხვა Blitz მოდულის, blitz-paint-ის მიერ, რომელიც თავის მხრივ იყენებს Parley-ს სიმბოლოების გლიფებად გარდასაქმნელად, ფონტების ასარჩევად და ტექსტის ხაზებად დასაყოფად.

Workers-ის ჩაშენებული RPC სისტემა: ერთი აპლიკაცია, მრავალი იზოლატი

Cloudflare Workers-ს აქვს ჩაშენებული დისტანციური პროცედურის გამოძახების (RPC) სისტემა, რომელიც საშუალებას გაძლევთ გამოიძახოთ მეთოდები სხვა Workers-ებში, გადასცეთ ობიექტები მათ შორის და გამოიძახოთ მეთოდები ამ ობიექტებზე. თქვენ არ გჭირდებათ ფიქრი API სქემებზე, ტიპებზე ან აუთენტიფიკაციაზე, თქვენ უბრალოდ იძახებთ remoteFunction(...params) და ის მუშაობს. თქვენ სარგებლობთ დისტანციური ვორკერის იზოლაციითა და რესურსებით ისე, რომ არ კარგავთ მათი ყველა ფუნქციის ლოკალურად გამოყენების კომფორტს JavaScript-ის მეშვეობით.

Kitesurf იყენებს ამ RPC სისტემას: Engine ვორკერი იძახებს renderFrame()-ს PageRenderer ვორკერიდან RPC-ის საშუალებით ერთი გამოძახებით და პასუხად იღებს PNG-ს. ვინაიდან რენდერერი არ ინახავს გვერდის სტატუსს (მხოლოდ ერთჯერად ქეშს), ძრავას შეუძლია უსაფრთხოდ გათიშოს და თავიდან გაუშვას ის RPC-ის ნებისმიერი შეფერხებისას — რაც ყოველ რენდერინგის მოთხოვნას ავტონომიურს და განმეორებადს ხდის.

Kitesurf გადის 215,000+ WPT ტესტს და ეს რიცხვი იზრდება

Kitesurf მუშაობს. ის უკვე გადის დაახლოებით 215,000+ WPT ტესტს და ჩვენ ყოველკვირეულად ვამატებთ ასობით ახალ წარმატებულ ტესტს. აქ შეგიძლიათ ნახოთ ევოლუცია დროთა განმავლობაში, პროექტის დაწყებიდან უახლეს ვერსიამდე:

აღსანიშნავია, რომ ბრაუზერის ის ნაწილები, რომლებიც მნიშვნელოვანია აგენტებისთვის (მაგ. CSS, DOM, HTML, სელექცია, SVG და XHR), უკვე კარგად არის დაფარული. ისეთი რამეებიც კი, რაც შეიძლება არ იყოს განსაკუთრებით მნიშვნელოვანი აგენტების კონტექსტში, როგორიცაა სტრიმები (streams), ახლა უკვე კარგად არის მხარდაჭერილი.

წარმადობის მხრივ, Kitesurf საკმაოდ კარგად გამოიყურება. ქვემოთ მოცემულია ხუთი Browser Run სწრაფი მოქმედების მედიანური მაჩვენებლები 14-URL-იან კორპუსზე, სადაც Chromium-ი შედარებულია Kitesurf-თან.

| მეტრიკა | Kitesurf | Chromium (warm pool) | Kitesurf, შეფარდებითი |
| :--- | :--- | :--- | :--- |
| CPU: სქრინშოტი | 380 ms | 1,173 ms | 3.1× ნაკლები CPU ვიდრე Chromium |
| CPU: HTML ექსტრაქცია | 229 ms | 877 ms | 3.8× ნაკლები ვიდრე Chromium |
| მეხსიერება: სქრინშოტი | 57.8 MiB | 271.0 MiB | 4.7× ნაკლები ვიდრე Chromium |
| მეხსიერება: HTML ექსტრაქცია | 39.4 MiB | 273.7 MiB | 7.0× ნაკლები ვიდრე Chromium |
| რეალური დრო (Wall time): სქრინშოტი | 1,148 ms | 637 ms | 1.8× ნელი ვიდრე Chromium |
| რეალური დრო (Wall time): HTML ექსტრაქცია | 820 ms | 472 ms | 1.7× ნელი ვიდრე Chromium |

Chromium-ი იგებს სიჩქარეში, რადგან JIT-ი, რომელმაც ეს გვერდი უკვე ნახა, ყოველთვის სჯობნის „ცივ“ პროგრამულ რენდერერს — და დღეს ის სჯობნის დაახლოებით 1.7-ჯერ. ამ სხვაობის უდიდესი ნაწილი მოდის რასტერიზაციასა და JPEG/PNG კოდირებაზე, რის ოპტიმიზაციასაც ვაგრძელებთ.

მაგრამ Kitesurf იგებს მეხსიერებასა და CPU-ში, რაც რეალურად განსაზღვრავს თქვენს ხარჯებს, 3-7-ჯერ უფრო ნაკლებს მოიხმარს Chromium-თან შედარებით. ნაკლები მეხსიერება ნიშნავს, რომ შეგვიძლია მეტი სესიის გაშვება, უკეთესი მასშტაბირება და ფუნდამენტურად ჩვენი და თქვენი ხარჯების შემცირება.

ყველაზე მნიშვნელოვანი ტესტი: Kitesurf-ზე Doom-ი ეშვება

დიზაინის გადაწყვეტილებებში ტესტირების მნიშვნელობას გავუსვით ხაზი, მაგრამ ყველამ ვიცით, რომ რაც არ უნდა ბევრი ტესტი გქონდეს, პროექტი ნამდვილად დასრულებული არ არის, სანამ მასზე Doom-ი არ გაეშვება. აი, Kitesurf-ი, რომელიც უშვებს https://silentspacemarine.com/-ს ჩვენი პატარა Doom ექსპერიმენტიდან, რომელიც რამდენიმე წლის წინ ჩავატარეთ.

სცადეთ დღესვე Browser Run-ში

Kitesurf-ის გამოცდა შეგიძლიათ Browser Run-ით დღესვე, უფასოდ ბეტა რეჟიმში, თითოეული ანგარიშის ლიმიტების ფარგლებში.

Browser Run CDP ენდპოინტი ახლა მხარს უჭერს Kitesurf-ს, როგორც არჩევანს, ასე რომ თქვენი არსებული კლიენტები Puppeteer, Playwright, chrome-remote-interface ან ნებისმიერი AI აგენტი, რომელიც იყენებს MCP-ს და CDP-ს, უკვე მუშაობს. თქვენ მხოლოდ უნდა დაამატოთ browser=kitesurf პარამეტრი ჩვენს ენდპოინტებს.

მაგალითად, Kitesurf-ის გამოსაყენებლად Opencode-თან, იხილეთ გამოყენება MCP კლიენტებთან (CDP) ჩვენს დოკუმენტაციაში და გამოიყენეთ ეს კონფიგურაცია:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ],
      "enabled": true
    }
  }
}

Kitesurf-ის გამოყენების კიდევ ერთი გზაა Browser Run-ის სწრაფი მოქმედებები. კვლავ, უბრალოდ დაამატეთ browser=kitesurf სწრაფი მოქმედების ენდპოინტს და ის იმუშავებს. მაგალითად, თუ გჭირდებათ სწრაფი სქრინშოტი Wikipedia-დან:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }' \
  --output "screenshot.png"

გამოიყენეთ Kitesurf Playground-ი Chrome DevTools-თან ერთად

Kitesurf-ის შესასწავლად კიდევ ერთი ვარიანტია ჩვენი საჯარო playground. შეგიძლიათ ჩაწეროთ ნებისმიერი URL, რათა ნახოთ, როგორ ახდენს Kitesurf გვერდის რენდერინგს და განახორციელოთ ინტერაქცია.

Playground-ის ერთ-ერთი საინტერესო ფუნქციაა ის, რომ ჩვენ ჩავაშენეთ Chrome DevTools-ი ინტერფეისში, ასე რომ თქვენ შეგიძლიათ შეამოწმოთ DOM ელემენტები, წაიკითხოთ კონსოლის შეტყობინებები და თვალი ადევნოთ ქსელურ აქტივობას. უფრო მეტიც, ჩვენ დავნერგეთ საჭირო CDP ინსტრუქციები Memory პანელისთვის, რათა აჩვენოს თითოეული იზოლატის WebAssembly დანახარჯი, ჩარჩოების ჩათვლით, რაც საშუალებას გაძლევთ ნათლად დაინახოთ, რა რესურსებს მოიხმარს თითოეული გვერდი.

დეტალებისთვის იხილეთ ჩვენი დეველოპერული დოკუმენტაცია.

როდის არის Kitesurf უკეთესი?

დღეის მდგომარეობით, Kitesurf სწორად ახდენს ისეთი გვერდების რენდერინგს, როგორიცაა TodoMVC (vanilla, React, Vue, Angular, Preact), Wikipedia, Hacker News, Cloudflare Blog და Cloudflare-ის მართვის პანელის დიდი ნაწილი. ჩვენ გავაგრძელებთ Kitesurf-ის გაუმჯობესებას და WPT ტესტების წარმატების პროცენტის გაზრდას უფრო რთული ვებგვერდების მხარდასაჭერად.

Kitesurf შესანიშნავია AI აგენტებისთვის, რომლებსაც გვერდების რენდერინგი სჭირდებათ, მაგრამ შეუძლიათ დათმობაზე წასვლა სრულფასოვან, პიქსელურად ზუსტ Chromium ბრაუზერთან შედარებით. ის ასევე საუკეთესოა ავტომატიზაციისა და აპლიკაციებისთვის, რომლებიც ეყრდნობიან ერთჯერად სწრაფ მოქმედებებს, როგორიცაა კონტენტის ექსტრაქცია, PDF-ების ან სქრინშოტების გენერირება თავსებადი საიტებისთვის.

წარმოიდგინეთ Kitesurf, როგორც ეფემერული, სრულად იზოლირებული, stateless ძრავა, რომელიც შექმნილია მხოლოდ დავალების შესრულების ხანგრძლივობით არსებობისთვის და რომელიც კარგად მასშტაბირდება AI-ზე დაფუძნებული სამუშაო დატვირთვისთვის.

რისი გაკეთება არ შეუძლია ჯერ Kitesurf-ს

თუ გჭირდებათ ვიდეოს ჩვენება, WebGL-ის რენდერინგი, ბოტებისგან დამცავი შემოწმების გავლა რეალური TLS თითის ანაბეჭდებით, ან ათწუთიანი აუთენტიფიცირებული სესიის დაწყება, რომელიც მოითხოვს მუდმივ სტატუსს — Kitesurf ჯერჯერობით არ არის სწორი არჩევანი. ასეთ დროს გამოიყენეთ Browser Run-ის სტანდარტული ვარიანტი, რომელიც Chromium-ით მუშაობს.

საუკეთესო გზა იმის გასაგებად, არის თუ არა კონკრეტული საიტი თავსებადი Kitesurf-თან, მისი გამოცდაა. ამის გაკეთება შეგიძლიათ API-ების მეშვეობით ან უფრო სწრაფად, ჩვენს საჯარო playground-ში.

დაათვალიერეთ DevTools პანელები და ნახეთ რა ხდება კულისებში, განსაკუთრებული ყურადღება მიაქციეთ კონსოლს და მეხსიერების მეტრიკებს.

საით მივდივართ

Kitesurf თორმეტი კვირისაა. პირველი კოდი მაისში დაიწერა. აი, ზოგიერთი რამ, რაზეც აქტიურად ვმუშაობთ:

• უკეთესი CDP დაფარვა. Kitesurf ახორციელებს CDP პროტოკოლის ნაწილს — იმდენს, რაც ფარავს აგენტებისა და ავტომატიზაციის ხელსაწყოების უმეტეს მოთხოვნებს, DOM-ისა და ქსელის ინსპექტირების ჩათვლით — და ჩვენ ვაგრძელებთ მისი შესაძლებლობების გაფართოებას.
• რენდერინგის სიზუსტე სქრინშოტებისა და PDF-ებისთვის, რადგან ვიცით, რომ LLM-ები ხშირად უკეთ მუშაობენ სურათიდან, ვიდრე ტექსტიდან.
• WPT დაფარვა. ჩვენ სწრაფად ვამატებთ ახალ Web API-ებს და გავდივართ მეტ WPT ტესტს Kitesurf-ის სრულყოფის გზაზე.
• ეფექტურობა. ჩვენ მუდმივად ვატარებთ CPU-ს, მეხსიერებისა და დროის ბენჩმარკებს და ვმუშაობთ დეველოპერული პლატფორმის სხვა გუნდებთან ერთად, რათა Kitesurf მაქსიმალურად ეკონომიური და ეფექტური გავხადოთ.

დასკვნითი შენიშვნები

მადლობა, რომ ბოლომდე წაიკითხეთ — ვიცით, რომ ეს გრძელი და ტექნიკური პოსტი იყო, მაგრამ იმედია, საინტერესოც. დეტალებში იმიტომ შევედით, რომ კარგად გვესმის ახალი ბრაუზერის შექმნის მნიშვნელობა და სირთულე, თუნდაც ის ძალიან სპეციფიკური იყოს.

Kitesurf საწყის ეტაპზეა, მაგრამ გვინდოდა ის თქვენთვის რაც შეიძლება მალე გაგვეხსნა და თქვენი გამოხმაურება მოგვესმინა. გუნდი აქტიურად გააუმჯობესებს მას ხშირი განახლებებით, რომლებიც ფოკუსირებული იქნება წარმადობაზე, ეფექტურობასა და თავსებადობაზე.

და ბოლოს: ჩვენ ვაპირებთ Kitesurf-ის კოდის გახსნას (open source), როგორც კი მზად ვიქნებით — იმედია, მალე. ჩვენი მიზანია, ნებისმიერ მომხმარებელს მივცეთ საშუალება, გაუშვას Kitesurf-ის საკუთარი ვერსია საკუთარ ანგარიშებზე, თუ ამის სურვილი ექნება.

ასე რომ, სცადეთ ის playground-ში, თვალი ადევნეთ ჩვენს ცვლილებების ჟურნალს და მოდით სასაუბროდ გუნდთან Discord-ზე. გაგვიზიარეთ თქვენი გამოცდილება და გამოგვიგზავნეთ შენიშვნები; ჩვენ გისმენთ.