167 captures
29 Apr 2017 - 10 Apr 2026
Jun
JUL
Aug
24
2017
2018
2019
success
fail
About this capture
COLLECTED BY
Collection:
Twitter Outlinks
This is a Collection of URLs (and Outlinked URLs) extracted from a random feed of 1% of all Tweets.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20180724200035/https://blog.chromium.org/2017/04/
Chromium Blog
News and developments from the open source browser project
Next steps toward more connection security
Thursday, April 27, 2017
In January, we
began our quest
to improve how Chrome communicates the connection security of HTTP pages. Chrome now marks HTTP pages as “Not secure” if they have password or credit card fields. Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in
Incognito mode
.
Treatment of HTTP pages in Chrome 62
Our plan
to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the
change in Chrome 56
, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we’re ready to take the next steps.
Passwords and credit cards are not the only types of data that should be private. Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the “Not secure” warning when users type data into HTTP sites.
Treatment of HTTP pages with user-entered data in Chrome 62
When users browse Chrome with Incognito mode, they likely have increased expectations of privacy. However, HTTP browsing is not private to others on the network, so in version 62 Chrome will also warn users when visiting an HTTP page in Incognito mode.
Eventually, we plan to show the “Not secure” warning for
all
HTTP pages, even outside Incognito mode. We will publish updates as we approach future releases, but don’t wait to get started moving to HTTPS! HTTPS is
easier and cheaper than ever before
, and it enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our
set-up guides
to get started.
Posted by Emily Schechter, Chrome Security Team
Real-world JavaScript performance
Wednesday, April 12, 2017
The V8 JavaScript engine is a cornerstone of fast browsing in Chrome. Over the course of the past year, the V8 team has developed a new method for measuring performance against snapshots of real web pages. Using insights from real-world measurements, the V8 team improved the speed of the average page load in Chrome by 10-20% over the course of the past year.
Historically, JavaScript engines such as V8 used benchmarks like Octane to improve the “peak” performance of JavaScript, or the performance of CPU-intensive script in
hot loops
. At the beginning of last year, the V8 team started to measure performance with higher fidelity by instrumenting snapshots of popular web pages such as Reddit, Twitter, Facebook, and Wikipedia. This analysis revealed that while peak performance benefits certain types of large web applications, browsing typical websites relies more on “startup” performance, or the speed it takes to start running script. Using insights gleaned from this real-world performance data, the V8 team implemented optimizations which improved mean page load between Chrome 49 and Chrome 56 by 10-20%, depending on CPU architecture.
The web page snapshots also enabled analysis of the differences between various benchmarks and real web workloads. Although no benchmark can be a representative proxy for all sites, the
Speedometer benchmark
is an approximation of many sites due to its inclusion of real web frameworks including React, Angular, Ember, and jQuery. This similarity can be seen in the startup optimizations above, which also yielded a 25-35% improvement in Chrome’s Speedometer score. Conversely, comparing page snapshots to Octane revealed that Octane was a poor approximation of most websites. Given the
plateau of Octane scores across web browsers
and the over-optimization of peak performance, we decided to
retire
the benchmark as a general-purpose measure of real-world JavaScript performance.
V8 performance optimizations improved Chrome's Speedometer score by 25-35% over the past year
Going forward, we plan to ship more JavaScript performance improvements for new patterns of script appearing on the web, including modern libraries,
frameworks
, and ES2015+
language features
. By measuring real-world websites rather than traditional benchmarks, we can better optimize JavaScript patterns that matter most to users and developers. Stay tuned for updates about our new engine architecture, designed for real-world performance.
Posted by Seth Thompson, V8 Track Commentator
Scroll anchoring for web developers
Tuesday, April 11, 2017
One of the strengths of the web is progressive loading, which means that there is no install step and users can start consuming content almost immediately while the site keeps loading. But progressive loading can also result in annoyances, such as an unexpected page jump when offscreen content loads and pushes down what’s currently on the screen. This can be even worse on mobile devices, since smaller screens mean more content is offscreen and page jumps are more likely.
Since its early days, Chrome has taken a stand against bad or abusive content. For instance,
Safe Browsing
warns users before they visit malicious websites, and
visual indicators on tabs
allow our users to quickly track down the source of unexpected noise. Similar to other features designed to protect our users from bad experiences, starting in version 56 Chrome prevents these unexpected page jumps with a new feature called scroll anchoring. This feature works by locking the scroll position on an on-screen element to keep our users in the same spot even as offscreen content continues to load.
Side by side comparison
of a web page with scroll anchoring disabled (left) and enabled (right).
Due to the expressiveness of the web, there might be some content for which scroll anchoring is either unwanted or misbehaving. For this reason, this feature ships alongside the
”overflow-anchor” CSS property
to override the functionality. To further minimize potential issues, scroll anchoring is disabled on complex interactive layouts via
suppression triggers
, and on back/forward navigations to allow for scroll restoration.
Today, scroll anchoring is preventing about three page jumps per page-view, but with your help it could be even better. Get involved by participating in the
scroll anchoring Web Platform Incubator Community Group
, submitting feedback via
g.co/reportbadreflow
, and designing your websites or services with a no-reflow mindset.
Posted by Steve Kobes, “The Unbouncer”
Labels
accessibility
1
benchmarks
1
beta
8
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2018
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Google
on
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
