Chromium Blog: Web Developers: Keeping Up With Google Chrome

Chromium Blog

News and developments from the open source browser project

Web Developers: Keeping Up With Google Chrome

2009年6月3日水曜日

Google Chrome is moving fast. Version 2.0 was stabilized just six months after 1.0, and auto-updates have ensured that nearly all users are using the newest version of the browser within days of a release. As a web developer, it can be a bit daunting that the browser version changes so fast: What if the new version breaks something? How can I be prepared for changes that will affect my sites?
To answer these questions, it's helpful to know how Google Chrome releases are made, the relationship between "dev," "beta," and "stable" update channels, and how you can test new versions. In this post, we'll be expanding on Mark Larson's earlier explanation of the update channel system.

Stable channel. As Mark outlines, the Stable channel is, well, stable. As a web developer, that means that as long as the major version — the "2" in "version 2.0.181.1" — doesn't change, you can count on Stable channel builds to use the same versions of WebKit (CSS, layout, etc.), V8 (JavaScript), and other components that might affect how a page loads or renders. Stable updates between major version releases are generally focused on addressing security issues, fixing egregious bugs, and improving stability. The big developer-facing bits of the browser won't change on the Stable channel until the next major version is released, and you can always preview upcoming changes using the Beta channel.
Beta channel. As a web developer, being on the Beta channel will ensure that you can test your sites with the next version of Google Chrome's rendering behavior before it's sent to the Stable channel and into the hands of most users. Whenever a major version lands in the Beta channel, the versions of WebKit, V8, networking, and the other systems that affect how web pages load and render generally become fixed. These versions may change during the major version's beta cycle, but changes are usually incremental fixes to help stabilize a feature rather than changes in behavior. New versions of WebKit may be introduced during a beta period, but those versions are always accompanied by a new build number (e.g. 2.0.169.xx vs. 2.0.172.xx) and are unlikely to differ drastically. As this major version moves closer to a stable release, these kinds of changes become more and more infrequent. Since Google Chrome development moves so quickly, you should stay on the Beta channel to catch compatibility issues ahead of time.
Dev channel. The Dev channel is where the sausage gets made. Dev releases happen frequently, and they track what's happening upstream in WebKit, V8, and other relevant systems very closely. This means that changes that might affect rendering, performance, and layout are likely to occur on the Dev channel on a regular basis. We don't recommend that you install the Dev channel if you're looking to maintain site compatibility, since tracking breaking changes as they happen can be a major headache. You should be able to spot any problems early enough via the Beta channel.

Users are on the Stable channel by default. To get onto the Beta or Dev channel, follow these instructions. Once you change to a less stable channel, e.g. from Stable to Dev, there isn't a supported "downgrade" path. If you change from the less stable channel back to a more stable one, Google Chrome will simply stop updating until your new channel "catches up" with the installed build. To force an immediate downgrade, uninstall and reinstall using an appropriate installer. This may occasionally cause errors when your more stable (older) version tries to read the newer user data left over from the previous installation.
Once you have a copy of Google Chrome, you can test your site's compatibility. Google Doctype has a helpful FAQ on best practices for Google Chrome compatibility. In short, prefer object detection over userAgent string parsing; don't rely on pixel-accurate font and element sizes; declare your pages' encodings correctly; double check <object> and <embed> parameters; check for illegal markup; and avoid browser-specific CSS.
The Chromium and WebKit teams work hard to ensure compatibility with websites. If after reading the above you discover browser problems, please don't hesitate to file a bug. If a particular problem with your site occurs in both Google Chrome and a corresponding version of Safari, it may be due to a WebKit issue, which you can file in the WebKit bug tracker. If the problem only happens in Google Chrome, log an issue in the Chromium bug tracker.
Posted by Alex Russell, Software Engineer

Google

ラベル

$200K 1
10th birthday 4
abusive ads 1
abusive notifications 2
accessibility 3
ad blockers 1
ad blocking 2
advanced capabilities 1
android 2
anti abuse 1
anti-deception 1
background periodic sync 1
badging 1
benchmarks 1
beta 83
better ads standards 1
billing 1
birthday 4
blink 2
browser 2
browser interoperability 1
bundles 1
capabilities 6
capable web 1
cds 1
cds18 2
cds2018 1
chrome 35
chrome 81 1
chrome 83 2
chrome 84 2
chrome ads 1
chrome apps 5
Chrome dev 1
chrome dev summit 1
chrome dev summit 2018 1
chrome dev summit 2019 1
chrome developer 1
Chrome Developer Center 1
chrome developer summit 1
chrome devtools 1
Chrome extension 1
chrome extensions 3
Chrome Frame 1
Chrome lite 1
Chrome on Android 2
chrome on ios 1
Chrome on Mac 1
Chrome OS 1
chrome privacy 4
chrome releases 1
chrome security 10
chrome web store 32
chromedevtools 1
chromeframe 3
chromeos 4
chromeos.dev 1
chromium 9
cloud print 1
coalition 1
coalition for better ads 1
contact picker 1
content indexing 1
cookies 1
core web vitals 2
csrf 1
css 1
cumulative layout shift 1
custom tabs 1
dart 8
dashboard 1
Data Saver 3
Data saver desktop extension 1
day 2 1
deceptive installation 1
declarative net request api 1
design 2
developer dashboard 1
Developer Program Policy 2
developer website 1
devtools 13
digital event 1
discoverability 1
DNS-over-HTTPS 4
DoH 4
emoji 1
emscriptem 1
enterprise 1
extensions 27
Fast badging 1
faster web 1
features 1
feedback 2
field data 1
first input delay 1
Follow 1
fonts 1
form controls 1
frameworks 1
fugu 2
fund 1
funding 1
gdd 1
google earth 1
google event 1
google io 2019 1
google web developer 1
googlechrome 12
harmful ads 1
html5 11
HTTP/3 1
HTTPS 4
iframes 1
images 1
incognito 1
insecure forms 1
intent to explain 1
ios 1
ios Chrome 1
issue tracker 3
jank 1
javascript 5
lab data 1
labelling 1
largest contentful paint 1
launch 1
lazy-loading 1
lighthouse 2
linux 2
Lite Mode 2
Lite pages 1
loading interventions 1
loading optimizations 1
lock icon 1
long-tail 1
mac 1
manifest v3 2
metrics 2
microsoft edge 1
mixed forms 1
mobile 2
na 1
native client 8
native file system 1
New Features 5
notifications 1
octane 1
open web 4
origin trials 2
pagespeed insights 1
pagespeedinsights 1
passwords 1
payment handler 1
payment request 1
payments 2
performance 20
performance tools 1
permission UI 1
permissions 1
play store 1
portals 3
prefetching 1
privacy 2
privacy sandbox 4
private prefetch proxy 1
profile guided optimization 1
progressive web apps 2
Project Strobe 1
protection 1
pwa 1
QUIC 1
quieter permissions 1
releases 3
removals 1
rlz 1
root program 1
safe browsing 2
Secure DNS 2
security 36
site isolation 1
slow loading 1
sms receiver 1
spam policy 1
spdy 2
spectre 1
speed 4
ssl 2
store listing 1
strobe 2
subscription pages 1
suspicious site reporter extension 1
TCP 1
the fast and the curious 23
TLS 1
tools 1
tracing 1
transparency 1
trusted web activities 1
twa 2
user agent string 1
user data policy 1
v8 6
video 2
wasm 1
web 1
web apps 1
web assembly 2
web developers 1
web intents 1
web packaging 1
web payments 1
web platform 1
web request api 1
web vitals 1
web.dev 1
web.dev live 1
webapi 1
webassembly 1
webaudio 3
webgl 7
webkit 5
WebM 1
webmaster 1
webp 5
webrtc 6
websockets 5
webtiming 1
writable-files 1
yerba beuna center for the arts 1

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Chromium Blog

Web Developers: Keeping Up With Google Chrome

ラベル

Archive

Feed