Google Developers Indonesia Blog: chrome

Update rilis Chrome dan Chrome OS

02 April 2020

Diposting silang dari Blog Rilis Chrome
Kami sebelumnya menghentikan sementara rilis mendatang untuk Chrome dan Chrome OS. Hari ini kami membagikan update bahwa kami sekarang melanjutkan rilis dengan jadwal yang disesuaikan:

M83 akan dirilis tiga minggu lebih awal dari yang direncanakan sebelumnya dan akan mencakup semua pekerjaan M82 karena kami membatalkan rilis M82 (semua channel).
Saluran beta, Dev, dan Canary, kami sudah atau akan dilanjutkan minggu ini, dengan M83 berpindah ke Dev, dan M81 berlanjut dalam versi Beta.
Channel stabil kami akan melanjutkan rilis pekan depan dengan perbaikan keamanan dan kritikal di M80, diikuti dengan rilis M81 tanggal 7 April, dan M83 ~pertengahan bulan Mei.
Kami akan membagikan update di masa mendatang tentang waktu rilis dan cabang M84.

Kami akan terus memastikan bahwa Chrome dan Chrome OS bekerja dengan stabil, aman, dan andal. Kami akan terus menginformasikan semua orang tentang perubahan jadwal apa pun di blog rilis kami dan akan membagikan detail jadwal ekstra di grup Chromium Developers, bila dibutuhkan. Anda juga bisa melihat halaman jadwal kami untuk melihat tanggal setiap milestone kapan pun.
Terima kasih kepada semuanya atas bantuan dan kesabarannya selama ini.
Diposting oleh Tim Rilis Chrome

Membangun World Wide Web yang Lebih Baik

23 January 2019

code { background-color: transparent } Pengalaman pengguna merupakan inti dari semua yang kami lakukan di Google. Hal ini mendorong keputusan, pengembangan, dan arah produk kami. Chrome memiliki sejarah panjang dalam melindungi pengguna dari pengalaman yang menjengkelkan dan berbahaya -- seperti memblokir jendela pop-up dan memperingatkan pengguna jika sebuah halaman memiliki malware.
Kami juga telah mengambil tindakan untuk melindungi pengguna Chrome dari jenis iklan tertentu yang mengurangi pengalaman online mereka, hal yang banyak dikeluhkan pengguna Chrome. Misalnya, tahun lalu, Chrome mulai memfilter iklan pada situs di Amerika Utara dan Eropa yang berulang kali melanggar standar industri dan terus menampilkan iklan yang mengganggu dan menjengkelkan kepada orang-orang yang mengunjungi situs web mereka. Selanjutnya, platform iklan kami telah menghentikan penjualan jenis iklan yang melanggar standar ini dan menimbulkan keluhan dari pengguna Chrome.
Kami mengikuti Better Ads Standards ketika menentukan situs web yang akan difilter iklannya di Chrome. Standar-standar ini dikembangkan oleh Coalition for Better Ads, sebuah kelompok industri yang didedikasikan untuk meningkatkan pengalaman periklanan web, berdasarkan masukan lebih dari 66.000 pengguna di seluruh dunia. Standar ini mengidentifikasi 12 pengalaman yang dianggap mengganggu oleh pengguna dan harus dihindari oleh pengiklan, penayang, dan vendor teknologi.

Saat ini, Better Ads Standards terdiri dari 12 pengalaman iklan yang menurut penelitian sangat mengganggu pengguna. Sumber Gambar: Coalition for Better Ads
Hari ini, Coalition for Better Ads mengumumkan bahwa mereka memperluas Better Ads Standards awal ke luar Amerika Utara dan Eropa untuk mencakup semua negara, di seluruh dunia. Mengikuti tuntunan Coalition, mulai 9 Juli 2019, Chrome akan memperluas perlindungan pengguna dan berhenti menampilkan semua iklan pada situs di negara mana pun yang berulang kali menampilkan iklan yang mengganggu ini.

Apa artinya hal ini bagi pemilik situs? Jika Anda mengoperasikan situs yang menampilkan iklan, Anda harus mempertimbangkan untuk meninjau status situs dalam Ad Experience Report, sebuah fitur yang membantu penayang untuk memahami bila Chrome telah mengidentifikasi pengalaman iklan yang melanggar di situs Anda. Mulai hari ini, penayang di luar region Amerika Utara dan Eropa bisa menggunakan fitur ini untuk mengetahui bila mereka memiliki pengalaman iklan mengganggu di situs mereka, status mereka saat ini (lulus / tidak ditemukan masalah atau gagal), dan menyelesaikan masalah yang belum diselesaikan atau mengadu tinjauan. Meskipun telah meninjau jutaan situs di seluruh dunia, kami akan terus memperluas tinjauan ini dalam beberapa bulan mendatang.
Ringkasan singkat dari Ad Experience Report.

Hasil awal dari AS, Kanada, dan Eropa Tujuan utama kami bukanlah untuk memfilter iklan, tetapi untuk membangun web yang lebih baik bagi semua orang, di mana pun. Penegakan standar Coalition oleh Chrome telah menginspirasi banyak pemilik situs untuk meningkatkan pengalaman beriklan di situs mereka sehingga menguntungkan pengguna. Di AS, Kanada, dan Eropa, para pemilik situs telah berhasil membuat perubahan iklan di situs mereka. Pada tanggal 1 Januari 2019, dua pertiga dari semua penayang yang sebelumnya tidak patuh terhadap Better Ads Standards, kini memiliki reputasi baik. Selanjutnya, dari jutaan situs yang telah kami tinjau hingga saat ini, kurang dari 1% iklannya telah difilter.
Kami berharap bisa terus bekerja sama dengan industri untuk menciptakan ekosistem web yang lebih baik dan lebih beragam dengan pengalaman pengguna terbaik. Web adalah bagian penting dari kehidupan kita sehari-hari dan kami akan terus memberikan pengalaman pengguna terbaik.
Anda bisa mempelajari detailnya lebih lanjut dari Coalition di sini.
Ditulis oleh Ben Galbraith, Senior Director of Product, Chrome

10 tahun, Chrome Semakin Cepat

01 October 2018

empat prinsip utama Chrome Banyak komponen dalam browser berkontribusi terhadap kecepatanV8pipeline eksekusi JavaScript baruIgnitionTurboFanStreaming skripkompilasi latar belakang

Pekerjaan kami di project Orinoco memungkinkan pengumpulan sampah secara bersamaan, mengosongkan thread utama dan mengurangi jank. Seiring waktu, kami juga menggeser fokus pada kinerja JavaScript yang sesungguhnya, membantu kami menggandakan kinerja waktu proses React.js dan meningkatkan kinerja library seperti Vue.js, Preact, dan Angular hingga 40%. Pengumpulan sampah secara paralel, bersamaan, dan bertahap mengurangi pengumpulan sampah yang disebabkan jank sebesar 100× sejak awal V8 dijalankan. Kami juga mengimplementasikan WebAssembly, yang memungkinkan developer menjalankan kode non-JavaScript di web dengan kinerja yang terprediksi, dan meluncurkan compiler dasar Liftoff untuk memastikan waktu startup yang cepat dari aplikasi WASM. Komponen-komponen baru ini adalah yang terbaru dalam upaya 10 tahun yang telah meningkatkan kinerja rilis-ke-rilis V8 sebesar 20x lipat selama tahun-tahun tersebut.

Skor V8 Bench untuk berbagai rilis Chrome selama beberapa tahun. V8 Bench adalah pendahulu dari benchmark Octane yang lama. Kami menggunakannya untuk bagan ini karena tidak seperti Octane, ia bisa berjalan di semua versi Chrome, termasuk Chrome Beta awal.

Chrome juga memainkan peran kunci dalam membantu mengembangkan protokol jaringan dan layer transpor melalui SPDY, HTTP/2 dan QUIC. SPDY bertujuan untuk mengatasi keterbatasan HTTP/1.1 dan menjadi dasar dari protokol HTTP/2, yang sekarang didukung oleh semua browser modern. Secara paralel, tim telah secara aktif melakukan iterasi pada QUIC, yang bertujuan untuk meningkatkan latensi dan pengalaman pengguna dan sekarang memiliki karya IETF aktif di belakangnya. Keunggulan QUIC terlihat nyata untuk layanan video seperti YouTube. Pengguna melaporkan 30% lebih sedikit rebuffer saat menonton video melalui QUIC.

Yang berikutnya adalah pipeline rendering Chrome. Ini bertanggung jawab untuk memastikan halaman responsif terhadap pengguna dan ditampilkan dengan kecepatan 60 bingkai per detik (fps). Untuk menampilkan konten pada 60fps, Chrome memiliki waktu 16ms untuk merender setiap bingkai. Ini mencakup eksekusi JavaScript, gaya, layout, warna dan mendorong piksel ke layar pengguna. Dari 16ms ini, semakin sedikit waktu yang digunakan Chrome, semakin besar kemungkinan developer web memuaskan penggunanya. Penyempurnaan pada pipeline rendering ini termasukmengoptimalisasi bagaimana kami mengidentifikasi elemen apa di halaman yang harus digambar ulang dan pelacakan yang lebih baik secara visual dari perangkat yang tidak tumpang tindih. Ini mengurangi waktu untuk menggambar bingkai baru ke layar hingga 35%.

Pada tahun 2015, model kinerja berorientasi-pengguna yang disebut RAIL diperkenalkan oleh tim Chrome. Kami baru saja mengupdatenya. mengurangi Memberikan developer web kemampuan lebih besar untuk mengukur dan mengoptimalkan halaman web merekalabsesungguhnyaChrome DevToolspeluang kinerjaLighthouseWebPageTest

Lighthouse berjalan di panel Audits Chrome DevTools

Untuk melengkapi data lab yang disediakan Lighthouse, kami merilis Chrome User Experience Report untuk membantu developer mendapatkan akses ke metrik kolom untuk pengalaman yang dirasakan pengguna di dunia nyata, seperti First Contentful Paint dan First Input Delay. Sekarang, developer bisa mem-build laporan kinerja situs khusus mereka sendiri dan melacak perkembangan jutaan sumber menggunakan Dasbor CrUX.

Kami juga memperkenalkan sejumlah kemampuan Platform Web untuk membantu developer mengoptimalkan pemuatan situs mereka. Kami meluncurkan Resource Hints dan <link rel=preload> sehingga memungkinkan developer memberi tahu browser tentang sumber daya apa yang penting untuk dimuat sejak awal. Chrome adalah salah satu browser pertama yang mengimplementasikan dukungan untuk pendekatan penghemat-byte seperti Brotli untuk kompresi, WOFF2 untuk font web yang lebih kecil dan dukungan WebP untuk gambar.

Kami senang melihat semakin banyak browser yang mendukung fitur ini dari waktu ke waktu. Chrome mengimplementasikan Service Worker, mengaktifkan caching offline & jaringan yang andal untuk kunjungan berulang ke halaman. Kami sangat senang melihat dukungan browser modern yang luas untuk fitur ini.

Bahkan, Google Penelusuran sekarang menggunakan Service Worker dan pramuat navigasi untuk caching oportunistik pada penelusuran berulang. Hal ini menyebabkan peningkatan 2x lipat dalam waktu pemuatan halaman untuk kunjungan berulang.

Saat kami melihat ke masa depan, kami juga bersemangat tentang potensi standar yang muncul seperti pemuatan untuk gambar & iframe selalu lamban, dan format gambar seperti AV1 harus membantu menyampaikan konten kepada pengguna secara efisien.

Nikmati lebih banyak konten web di paket data Anda dengan Chrome

Selama 10 tahun terakhir, ukuran halaman web semakin meningkat, tetapi bagi banyak pengguna yang online untuk pertama kalinya, data bisa sangat mahal atau sangat lambat. Untuk membantu, Chrome merilis fitur sadar-data selama bertahun-tahun seperti Penghemat Data Chrome. Penghemat Data secara cerdas mengoptimalkan halaman, menghemat konsumsi data hingga 92%.

Ke depannya, kami akan mengeksplorasi cara-cara baru untuk membantu Anda menghemat data. Bagi pengguna yang memiliki koneksi paling lambat, kami telah mengerjakan Chrome untuk Android, yang memungkinkan optimalisasi halaman yang lebih cerdas untuk menampilkan konten penting lebih dahulu. Transformasi halaman ini dimuat jauh lebih cepat daripada halaman penuh, dan kami terus meningkatkan keakuratan, cakupan, dan kinerjanya.

Kami juga bereksperimen dengan menempatkan pagar pengaman untuk pengguna yang data atau jaringannya dibatasi. Misalnya, kami melakukan penjelajahan dalam menghadirkan pemuatan untuk gambar & iframe selalu lamban ke Chrome, serta memberikan opsi kepada pengguna untuk menghentikan permintaan tambahan dari halaman saat ia menggunakan banyak data

Kami baru memulai...

Bersama-sama, perubahan ini membantu developer dan bisnis mengirimkan konten yang bermanfaat kepada pengguna mereka dengan lebih cepat. Kami tahu masih ada pekerjaan yang harus diselesaikan. Kami di sini untuk menghadirkan peningkatan kinerja pemuatan halaman untuk 10 tahun berikutnya!

Ditulis oleh Addy Osmani, JavaScript Janitor

10 Tahun Chrome DevTools

26 September 2018

Pada awalnya, hadir Firebug

Screenshot panel Net Firebug, diambil dari Saying Goodbye to Firebug (sumber dan lisensi)

Firebug adalah ekstensi Firefox yang memungkinkan Anda men-debug, mengedit, dan memantau halaman secara real-time. Sebagai developer web, dari yang sebelumnya Anda tidak memiliki visibilitas ke halaman web, tiba-tiba Anda langsung bisa memiliki apa yang pada pokoknya adalah fitur inti dari fitur developer modern. Kemampuan untuk memahami dengan tepat mengapa Firefox berperilaku seperti ini menimbulkan banjir kreativitas di web. Tanpa Firebug, era Web 2.0 tidak akan mungkin terjadi.

WebKit Web Inspector

Pada waktu yang hampir bersamaan dengan peluncuran Firebug, beberapa engineer Google mulai mengerjakan project yang pada akhirnya mengarah ke Chrome. Sejak awal, Chrome adalah mashup library kode yang berbeda. Untuk rendering, para engineer Chrome memilih WebKit, yang merupakan project open source yang masih mendukung Safari hingga hari ini. Bonus tambahan menggunakan WebKit adalah bahwa ia hadir dengan fitur siap digunakan yang disebut Web Inspector.

Screenshot Web Inspector, diambil dari Web Inspector Redesign (sumber dan lisensi) Seperti panel Net Firebug, Web Inspector asli mungkin tampak tidak asing. Banyak dari fungsionalitasnya masih ada sampai hari ini sebagai panel Elements di Chrome DevTools. Web Inspector diluncurkan beberapa hari setelah Firebug, dan Safari adalah browser pertama yang memaketkan fitur-fitur developer langsung ke browser.

Era "Inspect Element"
Chrome membawa banyak ide inovatif ke ekosistem browser, seperti omnibox yang menggabungkan penelusuran dan kolom URL, dan arsitektur multiproses yang mencegah satu tab menggantung membuat error seluruh browser. Namun inovasi yang paling kami sukai adalah menyediakan fitur developer di setiap build untuk setiap pengguna, yang bisa dijalankan hanya dengan mengklik mouse.

"Inspect Element" pada 2010
Sebelum Chrome, fitur developer adalah pengalaman pilihan. Anda harus menginstal ekstensi, seperti Firebug, atau mengaktifkan beberapa flag, seperti yang masih dipakai di Safari hari ini. Chrome adalah browser pertama yang menjadikan fitur developer dapat diakses dari setiap instance browser. Kami ingin mengklaim bahwa kami memiliki visi besar untuk membuat browser ramah-developer sejak awal, tetapi kenyataannya adalah bahwa Chrome memiliki banyak masalah kompatibilitas di hari-hari awalnya (hal ini masuk akal, karena tidak ada yang mem-build untuk Chrome) dan kami harus menyediakan cara mudah bagi developer web untuk memperbaiki masalah ini. Developer web berkata kepada kami bahwa ini adalah fitur yang bermanfaat, dan kami mempertahankannya.

Era seluler

Dalam beberapa tahun pertama project DevTools, kami pada dasarnya menambahkan babak-babak ke cerita yang dimulai oleh Firebug dan Web Inspector. Pergeseran besar berikutnya dalam pendekatan kami terhadap DevTools terjadi ketika semakin jelas bahwa smartphone hadir di sini untuk tetap tinggal.

Misi pertama kami di dunia baru yang menantang ini adalah memungkinkan developer untuk men-debug perangkat seluler real dari mesin pengembangan mereka, yang kami sebut proses debug dari jauh. DevTools sebenarnya diposisikan dengan baik untuk menangani proses debug dari jauh, akibat lain dari arsitektur multiproses Chrome. Pada awal project DevTools kami menyadari bahwa satu-satunya cara debugger bisa mengakses browser multiproses adalah melalui protokol klien-server, dengan browser menjadi server, dan debugger menjadi klien. Ketika Chrome seluler hadir, protokol ini sudah dimasukkan ke dalamnya, jadi kami hanya perlu membuat DevTools yang berjalan di perangkat pengembangan Anda berkomunikasi dengan Chrome yang berjalan di perangkat seluler melalui protokol ini. Protokol ini masih merupakan kekuatan DevTools sekarang ini, dan sekarang dikenal sebagai Chrome DevTools Protocol.

Proses Debug dari Jauh

Proses debug dari jauh adalah sebuah langkah ke arah yang tepat, dan sampai hari ini masih merupakan fitur utama untuk memastikan bahwa situs Anda berperilaku wajar di perangkat seluler real. Namun, seiring waktu, kami menyadari bahwa proses debug dari jauh menjadi kurang menarik. Ketika Anda berada di fase awal mem-build situs atau fitur, Anda biasanya hanya membutuhkan perkiraan orde pertama pengalaman seluler. Ini mendorong kami untuk membuat serangkaian fitur simulasi seluler, seperti:

Dengan tepat mengemulasikan viewport seluler, menyimulasikan masukan berbasis-sentuh dan orientasi perangkat.

Membatasi sambungan jaringan untuk menyimulasikan 3G dan CPU untuk menyimulasikan hardware seluler yang kurang kuat.

Spoofing browser, geolokasi, data akselerometer dan banyak lagi.

Kami secara kolektif merujuk fitur-fitur ini sebagai Device Mode.

Prototipe awal Device Mode

Device Mode pada 2018

Era kinerja

Saat era seluler terbuka, aplikasi besar seperti Gmail mendorong batas-batas kemampuan web. Bug berskala-Gmail diperlukan untuk fitur berskala-Gmail. Salah satu kontribusi besar pertama kami ke ekosistem fitur adalah menunjukkan perincian secara mendetail tentang semua yang harus dilakukan Chrome untuk menampilkan sebuah halaman.

Panel Timeline asal, seperti yang ditampilkan dalam Do More with Chrome Developer Tools

Panel Performance pada 2018

Fitur-fitur ini merupakan langkah ke arah yang tepat, tetapi untuk menemukan peluang optimalisasi, Anda harus mempelajari detail-detail mendalam tentang bagaimana browser bekerja dan menyaring banyak data. Akhir-akhir ini, kami mem-build berdasarkan fondasi ini untuk menyediakan lebih banyak analisis kinerja terkendali. Lighthouse engine baru menggerakkan panel Audits, dan juga tersedia sebagai modul Node untuk integrasi dengan sistem CI.

Saran kinerja di panel Audits

Era Node.js

Hingga tahun 2014 atau sekitar tahun tersebut, kami memikirkan DevTools sebagai fitur untuk mem-build pengalaman yang menakjubkan di Chrome. Kemunculan Node mendorong kami untuk memikirkan kembali peran kami dalam ekosistem web.
Dalam beberapa tahun pertama keberadaan Node, developer Node berada dalam situasi yang mirip dengan developer web sebelum Firebug, atau developer Gmail sebelum panel Timeline: skala aplikasi Node melampaui skala fitur Node. Mengingat Node berjalan di JavaScript engine Chrome, V8, DevTools adalah kandidat dasar untuk mengisi kekosongan ini. Dukungan untuk proses debug Node dengan DevTools hadir pada tahun 2016 dan menyertakan fitur DevTools yang biasa, seperti breakpoints, code stepping, blackboxing, source maps for transpiled code, dan sebagainya.

Node Connection Manager

Ekosistem protokol DevTools

Nama Chrome DevTools Protocol (CDP) menyarankan API yang hanya bisa digunakan oleh DevTools. Kenyataannya lebih umum dari itu: ini adalah API yang memungkinkan akses terprogram ke Chrome. Selama beberapa tahun terakhir, kami telah melihat beberapa aplikasi dan library pihak ketiga bergabung dengan ekosistem protokol:

chrome-remote-interface menyediakan akses JavaScript tingkat rendah ke protokol

Puppeteer membawanya ke tingkat abstraksi berikutnya dan mengaktifkan otomatisasi browser headless Chrome dengan JavaScript API modern

Lighthouse mengotomatiskan proses pencarian cara untuk meningkatkan kinerja dan kualitas halaman

Kami senang melihat ribuan project bergantung pada package ini untuk mengaktifkan interaksi yang kaya dengan Chrome. Jika Anda berada di bisnis otomatisasi atau fitur, ada baiknya memeriksa protokol ini untuk melihat apakah ia membuka peluang apa pun dalam domain Anda. Misalnya, tim VS Code dan WebStorm menggunakannya untuk mengaktifkan proses debug JavaScript dalam IDE-nya masing-masing.

Apa yang berikutnya?

Misi utama kami adalah mem-build fitur yang bisa membantu Anda menciptakan pengalaman menakjubkan di web. Kami sangat bergantung pada masukan Anda untuk membantu kami menentukan produk atau fitur yang perlu di-build.

Jangan ketinggalan informasi fitur baru dengan postingan What's New kami

Usulkan fitur baru di milis

Laporkan bug di Chromium Bug Tracker

Ikuti kami di Twitter untuk menemukan fitur baru dan alur kerja mini

Ajukan pertanyaan di Stack Overflow untuk mendapatkan bantuan mengenai penggunaan DevTools

Selesaikan masalah dengan keahlian Anda dan berkontribusi untuk DevTools

Terima kasih telah membuat komunitas yang menyenangkan. Kami menantikan kebersamaan 10 tahun selanjutnya untuk mem-build web bersama Anda.

Ditulis oleh tim Chrome DevTools

‘Web yang Berkemampuan’: Retrospektif 10 Tahun

14 September 2018

memperkenalkan Chrome1990Common Gateway InterfaceAjaxvideoaudiocanvasEksperimen ChromeGoogle GearsAppCacheWebSQLgeolokasiorientasiWebSocketWebGLWeb AudioFullscreen APIIndexedDBWebGLFullscreenPointer LockGamepadWebRTC

Manifesto Extensible WebPekerja LayanandownasaurBackground Sync APINetwork Information APIPointer EventsImage CaptureMedia CaptureWeb Share APIWeb Bluetooth APIWeb USB APIWebAssemblyWeb VRFeature PolicyLayered APIWICGManifesto Extensible Web

Membantu menguji / memberikan masukan untuk fitur browser Chrome mendatang

05 September 2018

Apa yang dimaksud dengan saluran Chrome versi Beta?

Bagaimana cara saya beralih ke saluran Chrome versi Beta?

Apakah saluran Beta ini dianggap cukup stabil untuk digunakan setiap hari?
Secara umum ya - tetapi mungkin saja Anda menemui beberapa masalah. Kami menyarankan pengguna saluran Beta untuk secara teratur melakukan backup setelan pribadi yang penting, seperti bookmark, sandi, dan banyak lagi.

Apa cara terbaik untuk memberikan masukan, melaporkan masalah, dll.?
Chrome memiliki tiga cara untuk memberikan masukan dan melaporkan masalah yang mungkin Anda temukan.

Melaporkan masukan dalam Chrome. Anda bisa menggunakan petunjuk yang dapat dilihat di sini untuk mengirimkan laporan masukan dalam Chrome. Kami menggunakan laporan ini secara keseluruhan untuk mengidentifikasi lonjakan dan tren. Kami juga melakukan pendalaman ketika menyelidiki masalah, ketika memeriksa peluncuran fitur baru, dan sebagai bagian dari upaya penjelajahan pengguna reguler.
Memecahkan masalah. Forum komunitas resmi kami adalah tempat terbaik untuk mendapatkan bantuan pemecahan masalah. Kami memiliki grup kontributor utama yang juga memiliki kemampuan untuk mengeskalasi thread, yang sering kali membantu mengidentifikasi masalah yang tidak kami lihat di tempat lain.
Melaporkan bug yang terkonfirmasi pada pelacak project ini. Setelah masalah terkonfirmasi sebagai bug, Anda bisa membuat laporan di pelacak pengembangan publik - langsung ke tim kami! Anda mungkin menemukan bahwa bug telah dilaporkan (semuanya bergerak cepat!), tetapi ini memungkinkan kami melacak siklus hidup bug secara mudah.

Apakah ada versi Beta yang lain?
Ya! Untuk beberapa platform, kami juga menawarkan versi developer dan bahkan build canary yang masih baru dari server pengujian. Biasanya ini hanya disarankan bagi orang-orang yang bekerja pada project yang membutuhkan pengujian lead time. Anda bisa mempelajari lebih lanjut tentang opsi rilis lainnya di sini.