80 captures
31 Mar 2019 - 10 Apr 2026
Feb
MAR
Apr
31
2018
2019
2020
success
fail
About this capture
COLLECTED BY
Collection:
Wikipedia Eventstream
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20190331224727/https://blog.chromium.org/search/label/capabilities
Chromium Blog
News and developments from the open source browser project
Chrome Dev Summit 2018: Building a Faster, Smoother, Capable Web
Monday, November 12, 2018
Today, we’re welcoming the web community to the 2018 edition of the
Chrome Dev Summit
. Over the next two days we will celebrate the evolution of the platform and share updates on our efforts moving the web forward with the help of the entire ecosystem.
Chrome’s 10th birthday gave us an opportunity to
reminisce
about how much Chrome and the web have evolved over the past decade. We love seeing how rich the
content
,
apps
, and
games
you build have become.
Amongst other updates that we’ve made to Chrome, one that we work very hard at is making the browser fast. We see speed as one of the defining and most important features of the web. No other platform can match how quickly a user can go from discovery to the actual experience and move between websites, but this breaks down if the sites take too long to load or if the UI is janky.
Thus, we'd like to collaborate even more with the web developer community in delivering delightfully fast experiences to our end users, from the moment they click on a link.
Fast from the first click
HTTPArchive shows that since 2011, sites are using on an
average of 8x more JavaScript
. We’re starting to see the CPU becoming one of the main performance bottlenecks, especially with more and more code often compiled and executed on under-powered mobile devices.
Businesses who focus on the first load (and beyond) are increasingly seeing great results by focusing on the use of
Performance Budgets
. These budgets can be based on the byte size of your JavaScript, CSS, images and other resources, as well as other loading metrics. For example, you could specify that Time-to-Interactive will not exceed 5s on an emulated 3G network and specific class of mobile phone.
Consistently staying within budget as you add features over time isn’t easy. After
Wayfair
noticed their own regressions, they built an internal performance budgeting system for their developers to track their performance scores. Since then, their page speeds have continuously become faster, and they’ve seen a year-over-year conversion rate increase of more than 10%.
Pinterest
revamped their mobile web experience focusing on performance and saw an uplift in user sentiment and engagement. Their mobile website is now their
top platform for sign-ups
! You can see their journey here:
Buttery smooth beyond the click
Optimizing the loading speed of your webpage is important, but so is ensuring that the page delivers a smooth, interactive user experience as it loads and after it’s displayed. This means responding to all user input quickly, in less than a 1/10th of a second, and ensuring that the user interface doesn’t “jank”— meaning the UI doesn’t pause and then jump suddenly.
Over the past decade, we’ve been evolving Chrome so that it can off-load as much work as possible from the main thread. For example, now we decode images and parse JavaScript separately, and with Web Workers you can execute long running JavaScript without blocking up the UI.
How buttery smooth can you make your web apps today? Especially if you have non-trivial workloads? Our team set out to explore just this, and the end result is a new application launching today called
Squoosh
. This powerful image compression tool launches almost instantly, and then manages a smooth UI even when it’s doing heavy work, including using Web Assembly to do more with codecs the browser doesn’t have baked in. Tune in to
Jake and Mariko's session
later today to learn how they did it.
But there is even more to do here, and we are excited about up-coming platform APIs, such as Worklets , Virtual Scroller, and even a scheduler, that help developers build smoother experiences more easily. You’ll hear more about many of these tools and techniques in our
Day 2 keynote
and beyond.
Capable with deeper integrations
We’ve seen that PWAs make it easy to delight your users, grow engagement and increase conversions. Now with deeper integrations to the host OS and the ability to load and run faster than ever, your PWAs can really shine, yet most of these integrations have been focused on mobile-first, or even mobile-only.
Over the last 6 months we’ve been renewing our investments in providing these same set of capabilities across all desktop platforms. Chrome OS has given us a fantastic surface to really push the boundaries of the web, and based on these learnings we are expanding our Desktop PWA support across Chrome for Windows and Linux, with Mac support targeted to land in Chrome 72.
As we bring more and more capabilities to both mobile and desktop, we want to include the voice of the community to ensure we prioritize features that are important to the community. So today we are sharing
our plan
to get the capabilities YOU need on the web, and how we can work together to make sure we are solving your real world needs.
Helping you as a web.dev
We know that you want
one place
that consolidates all the reference information for modern Web APIs, and this is why we continue to
collaborate with MDN
on improving the core reference documentation of the web.
We have also heard that you would like more hands on guidance on how to deliver on the principles that make a web experience great. So today, we’re excited to announce a new approach:
web.dev
.
Through a partnership with
Glitch
,
a deep integration with our
Lighthouse
tool and best-practice guidance from our team,
web.dev
helps you improve
your
site through direct and targeted best-practice and the ability to monitor your sites over time to ensure that you are always able to keep your site fast, resilient and accessible.
As we were working on web.dev, we were inspired by other amazing content on the web that help you learn.
Dave Geddes
, who created Flexbox Zombies and CSS Grid Critters, created a new learning game.
Service Workies
helps you understand Service Workers soup to nuts. The first chapter of the adventure is rolling out in beta now. We partnered with Dave to make sure the full adventure can be free to all, so check it out now and whatever you do, listen to Grannie!
Web design, right in the browser
At Chrome Dev Summit we cover all of the updates to our developer centric tools and libraries that you know and love, but we also want to show you a new, early experiment that we would love your feedback on.
We remember the impact that Firebug had when it hit the scene, and how it showed how the browser could be the developer tool platform itself. Now we are also thinking about design on the web, and just as Lighthouse started as a Chrome extension to explore, we have another extension,
Project Visbug
, which allows you to design — right in the browser. You can
download
it now, but before you do see it in action right here:
Tune into our
livestream
or watch the videos on the
Chrome Developers Youtube channel
to follow the rest of the sessions of the day and watch this space for our Day 2 wrap up blog where we will have some more exciting announcements.
Posted by Ben Galbraith & Dion Almaer
Our commitment to a more capable web
Monday, November 12, 2018
Since the
beginning of Chrome
we have worked to provide a solid foundation for modern web applications. Those capabilities have enabled new experiences on the web that were never thought possible. WASM is enabling new classes of games and productivity apps like Sketchup and AutoCAD, WebRTC enables new ways to communicate, and
service workers
allow developers to create reliably fast web experiences regardless of network conditions.
However, there are some capabilities, like file system access, idle detection, and more that are available to native but aren’t available on the web. These missing capabilities mean some types of apps can't be delivered on the web, or are less useful. To cope, some developers build native apps, or use wrappers like Cordova or Electron to access the underlying capabilities of the device.
We strongly believe that every developer should have access to the capabilities they need to make a great web experience, and we want to support them as they do.
Closing the gap
We want to close the capability gap between the web and native and make it easy for developers to build great experiences on the open web. Meanwhile we need to preserve everything that is great about the web. We will rapidly bring new, powerful, portable, and standardized capabilities that unlock key verticals on both mobile and desktop. Giving developers these new tools will empower the open web as a place where any experience can be created, and make the web a first class platform for developing apps that run on any browser, with any operating system, and on any device.
We plan to design and develop these new capabilities in an open and transparent way, using the existing open web platform standards processes while getting early feedback from developers and other browser vendors as we iterate on the design, to ensure an interoperable design.
Per our practice of open design and public iteration, look for many proposals for new designs to surface at the
W3C
's
Web Incubator Community Group
.
What are the initial capabilities?
We’ve identified and prioritized an initial set of capabilities we feel are critical to closing the gap between web and native, and have already started work on a handful of them. You can see the list by searching the Chromium bug database for bugs that are tagged with
proj-fugu
.
Personally I’m really excited about the
writable file API
that make it possible to create web based editors, and
event alarms
that help perform arbitrary work at some point in the future. But there are
plenty more
: Web Share Target, Async cookies, Wake Lock, WebHID, user idle detection, just to name a few.
Early feedback is critical
We developed a
process
to make it possible to design and develop new web platform capabilities that meet the needs of developers quickly, in the open, and most importantly, work within the existing standards process. It’s no different than how we develop every other web platform feature, but it puts an emphasis on developer feedback.
Developer feedback is critical to help us ensure we’re shipping the right features, but it’s easier to change course early in the process. That’s why we’re starting to ask for feedback earlier. When actionable technical and use-case feedback comes in early, it’s easier to course correct or even stop development, without having shipped poorly thought out or badly implemented features. Features being developed at WICG are not set in stone, and
your input can make a big difference
in how they evolve.
It’s worth noting that many ideas never make it past the
explainer
or
origin trial
stage. The goal of the process is to ship the right feature. That means we need to learn and iterate quickly. Not shipping a feature because it doesn’t solve the developer need is OK.
Getting everyone involved
The first API we’re looking for feedback on is the
writable files API
. We want to hear about your use cases and how you expect the security model to work. And keep an eye on our new
capabilities page
on
developers.google.com/web
to see the list of capabilities that we’re working on, and how you can participate.
The apps you want to build on the open web should only ever be limited by your imagination, never by missing capabilities. As we look to the future, the gap between web and native will get smaller as browser vendors add new capabilities to the web.
Here’s to a more capable open web.
Posted by Pete LePage, dreamer.
The ‘Capable Web’: A 10 Year Retrospective
Tuesday, September 4, 2018
When we
introduced Chrome
in 2008, our goal was to “keep evolving with the web and continuing to build a solid foundation for modern web applications.” In honor of our tenth year, we’d like to highlight some of the major changes in the web’s rich capabilities that we feel lucky to share with other browser vendors.
As the very first pages were served on the open web in
1990
, people recognized that the ability to deliver dynamic content would make the web unique—you could provide information and function just by sharing a URL. The
Common Gateway Interface
standard released in 1993 defined a simple interface for web servers to run code in response to web requests. It brought a new era of experience and capability to computing, accessible at the click of a link. Hop forward two short years to JavaScript, then another year to frames, specifically the <iframe> tag. These innovations let developers dynamically load content into pages, brought a new level of interactivity to the web, and increased user expectations of what could be done in the browser.
Accessibility, linkability, indexability, and universal reach have always been the web’s core strengths. Alongside these super powers, users want ever richer and more-engaging experiences. “
Ajax
” was coined in 2005 to describe the combination of asynchronous JavaScript and XML, which shaped a more interactive, modern web. It led to the creation of such services as Google Maps, cementing the web as the best way to deliver experiences available to anyone, on any device.
2008 – 2014: Web applications, HTML5, and the start of the mobile era
Chrome saw huge progress in its early years, with a large number of what are now considered “core APIs” coming to the web after the WebKit implementation. The
video
,
audio
, and
canvas
elements were some of the first “modern web” features that many of us distinctly remember (and who can forget border-radius?). These features brought a new level of interaction to web experiences, and meant developers no longer needed plugins such as Adobe Flash or Java, to build interactive media and graphical experiences.
Chrome experiments
have captured great examples of rich experiences that are a direct result of the web’s improved performance.
The “Mobile Web” really hit the world in 2010, and we saw a slew of new platform primitives introduced for the platform (many inspired directly by
Google Gears
) to help make building web apps easier. We could now make responsive, offline-enabled applications with
AppCache
and
WebSQL
, request permission to access the user's
geolocation
, and even understand the
orientation
of the user’s device.
WebSocket
landed on the platform the same year, heralding a change in the types of experiences developers could deliver on the web. No longer did they have to use long polling to enable a bi-directional channel between the user and a service; developers now had a two-way channel with a simple API to provide real-time communication.
Plink is an interactive music experiment synchronising player state via websockets.
Four major APIs came to Chrome in 2011.
WebGL
,
Web Audio
, and the
Fullscreen API
let us build rich and immersive experiences that could take advantage of the entire screen.
IndexedDB
— a new “web-first” storage mechanism — us store and query serializable JavaScript objects such as Strings, Objects, Arrays, Files, and Blobs more effectively.
Chrome Web Lab was an experiment that bridged the physical and digital worlds. It used Web Socket, video, real-time streaming, WebGL, and Web Audio to create an immersive world.
A bumper year for game-changing experiences on the web arrived in 2012. On the back of
WebGL
and
Fullscreen
, the
Pointer Lock
and
Gamepad
APIs let us build games and other web experiences that felt really interactive. The game-changing collection of
WebRTC
APIs truly set the web apart from all of the other platforms: It let us build P2P video-chat and real-time data sharing, without any plug-ins or proprietary stack, and accessible by simply clicking a link.
One of the first Chrome on Android to Chrome on Android WebRTC calls (March 2013)
In just seven years, the web changed drastically. Browsers got significantly faster and more capable, letting developers build richer experiences on the desktop. Users started to consume even more content on mobile, meaning we all had to rethink how our experiences would work across devices and form-factors, even when the user had no connectivity.
2015-2018: PWA, The Extensible Web, and deeper integration era
In 2015, we experienced a fundamental change in how we thought about integrating capabilities into the web platform. The
Extensible Web manifesto
asked browser engineers to consider a layered platform that offered lower-level primitives that were easier to explain, more efficient to implement, and allowed web developers to easily build higher-level abstractions, thus increasing the cadence and availability of compelling new features.
Service Worker
is an example of building on these APIs to follow these principles. Service Worker is a small piece of JavaScript that sits between the browser and the network, and lets the developer decide what to do with any web requests.
The combination of Service Worker and a handful of new APIs allowed marked the beginning of the Progressive Web Apps (PWA) era. PWAs are high-quality sites that combine the reach of the web with the user expectations that come with native platforms. Specifically, PWAs are...
Fast
—they load instantly
Reliable
—they never show the “
downasaur
,” even in uncertain network conditions, by taking advantage of the Service Worker and Cache APIs
Engaging
—they respond quickly to user interactions with silky-smooth animations and no janky scrolling
Capable
—the sites feel like natural extensions on the device, with immersive user experiences provided by features such as “fullscreen” and standalone mode through Web App Manifest; they deliver capabilities for meeting specific business goals, such as re-engagement through the Add to Homescreen feature and Web Push notifications
As PWAs became more established, so did the capabilities of the platform. The
Background Sync API
brought increased opportunities for developers to improve the resilience of their applications. We also got a better understanding of the network capabilities with extensions to the
Network Information API
.
Pointer Events
, a critical component for any web site or app, came to Chrome after a long wait. Pointer Events presented a unified model for handling all forms of gesture-based input, ranging from touch to pens to mouse pointers.
In 2017, deeper integration of web apps with the host operating system and secure access to devices around the user arrived..
The
Image Capture
and
Media Capture
APIs provided full-frame access and control over a phone camera, as well as from other input sources such as a canvas. The
Web Share API
let sites share data directly with the operating system’s native sharing systems.
The
Web Bluetooth API
let a user securely select a Bluetooth LE device and have a webpage interact with the device. The
Web USB API
enabled the same level of connectivity, but to devices connected to the user's machine.
WebAssembly
(WASM) opens up many possibilities. It brings a runtime that can execute code at near-native performance. Plus, it opens a new world of experiences on the web by letting developers use existing codebases built for other platforms on the web platform.
Web VR
came to the web at roughly the same time it came to native platforms. It let us deliver immersive experiences without installing an app, significantly reducing the gap between a new native primitive arriving on platforms and being available across the web platform.
Forward to the future
We’re excited about the possibilities of the web platform. The web can (and should) be feature-rich, but new capabilities don't always have to be more complex. Web development should be predictable, manageable, and pain-free. Coming APIs such as
Feature Policy
are great examples of additions that will help developers create amazing sites in a more predictable way, and provide more control and customization over the UX of certain browser features. Feature Policy is the browser's built-in guide rails to help web developers avoid common pitfalls and use best practices.
Layered APIs
is another initiative that we're excited about. With it, developers will be able to load and use high-level features shipped directly into the browser as JS modules. For example, instead of building a custom virtualize-scrolling component, developers can just import and use <virtual-scroller> in a site. Layered APIs can be quickly iterated on by the standards bodies and implemented by browser vendors, and will help create a pay-as-you-go standard library for the web. And looking further, the Houdini and Web XR APIs will radically change experiences we can build on and with the web.
Over the last 10 years, we’ve seen a massive increase in the rate at which new primitives and capabilities can be introduced to the web. We can thank all the browser vendors for their continued work to create and iterate on specs, using streamlined processes like those defined by the
WICG
and based on the principles in the
Extensible Web Manifesto
. We’ll continue our commitment to work with browser vendors and the developer ecosystem to prioritize features that users need, and to ensure that those capabilities arrive in a “webby” way. By doing so, we can uphold our original mission, while also prioritizing user safety, discoverability, instant access, and universal reach for everyone on the planet.
Here’s to the future of an even-more-capable open web.
Posted by Paul Kinlan, the Wizzy Web Warrior.
Labels
$200K
1
10th birthday
4
abusive ads
1
accessibility
1
ad blocking
1
android
1
benchmarks
1
beta
15
billing
1
birthday
4
blink
1
browser
2
browser interoperability
1
capabilities
3
capable web
1
cds18
2
cds2018
1
chrome
12
chrome ads
1
chrome apps
3
chrome dev summit 2018
1
chrome devtools
1
Chrome Frame
1
Chrome lite
1
chrome web store
27
chromedevtools
1
chromeframe
3
chromeos
3
chromium
3
cloud print
1
coalition
1
coalition for better ads
1
dart
8
dashboard
1
Data Saver
1
day 2
1
design
1
devtools
13
discoverability
1
extensions
24
features
1
feedback
2
field data
1
frameworks
1
fund
1
funding
1
gdd
1
googlechrome
12
harmful ads
1
html5
11
incognito
1
ios
1
javascript
4
lab data
1
lighthouse
1
linux
2
Lite pages
1
loading interventions
1
loading optimizations
1
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
3
pagespeedinsights
1
performance
2
performance tools
1
play store
1
portals
1
progressive web apps
1
protection
1
pwa
1
releases
3
rlz
1
security
30
slow loading
1
spdy
2
speed
1
ssl
2
store listing
1
subscription pages
1
tools
1
trusted web activities
1
twa
1
v8
6
web apps
1
web intents
1
web packaging
1
web.dev
1
webapi
1
webaudio
3
webgl
7
webkit
5
webmaster
1
webp
5
webrtc
4
websockets
5
webtiming
1
writable-files
1
Archive
2019
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
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
.