Hi, my name is Jeffrey, and I’m a product manager on Search.
Thank you all for joining,
and today I’ll be walking you through the page experience ranking
that’s soon coming to Google Search,
and later, Naina will be joining to give us an update
on how the AMP team is setting developers up for success
with this upcoming launch.
Hi folks, glad to be here.
Google Search has always considered user experience as part of ranking.
You’d remember some of our past efforts from 2014,
where we announced mobile friendliness as a ranking signal.
The same year, we also launched an effort
to rank based on HTTPS to ensure webpages
are delivered in a secure fashion to our users.
Let's take a closer look into page experience.
When we think about page experience,
we think in terms of the four pillars of user experience.
They are loading, which signifies how fast or slow
the resources of the page is downloaded and displayed on the user’s browser.
User annoyance, an important pillar that quantifies some of the webpage behavior
that might get in the way of a user accomplishing a task.
Security and privacy,
a critical aspect of how safe, secure, and privacy-friendly a web page is.
And accessibility, the World Health Organization’s disability/health fact sheet
finds that over a billion people, about 15% of the world’s population,
have some form of disability.
We as web developers have a huge responsibility
to build web pages that are inclusive to all users.
These four pillars provide a structure
for how to think about page experience for your pages.
We believe when pages perform well on these, they provide exceptional value to the users
which can drive long term relationships with your customers.
Let's take a look at how these four pillars translate
in practice for a page experience.
For loading, we use Largest Contentful Paint and First Input Delay.
The largest Contentful Paint, LCP for short, is a metric that reports the render time
of the largest image or text block visible within the viewport,
relative to when the page first started loading.
First Input Delay, FID for short,
measures the time from when a user first interacts with a page,
that is, when they click on a link, tap on a button,
or use a custom JavaScript powered control,
to the time when the browser is actually able to begin processing the given handlers
in response to that interaction.
For the user annoyance pillar, we have Cumulative Layout Shift, CLS.
CLS measures the sum total of all the individual layout shift scores
for every unexpected layout shift that occurs on the page.
A layout shift occurs anytime a visible element
changes its position from one rendered frame to the next.
No abusive interstitials is an existing Search ranking policy
and an associated signal that we've longed used on Search
that detects the presence and use of interstitials that are user-hostile.
We've noticed that such interstitials are often used to trick users
to doing something that they do not want to,
preventing them from reading or interacting with the page
that they landed on from Google Search.
There are a lot of great uses for interstitials,
such as the ones required by law, GDPR consent is an example,
or an interstitial that shows updated business hours
during the coronavirus pandemic.
Those are not affected by this signal.
For security and privacy, we want to ensure
that the sites are delivered using the HTTPS protocol.
Users should be able to confidently browse the internet
without having to worry about man-in-the-middle attack
or improper impersonations.
Safe browsing systems at Google bring together decades worth of experience
in identifying and mitigating web-based threats,
such as malware, unwanted software downloads or social engineering.
Similar to some of the other signals, we’ve long been using safe browsing on Search
to warn users when we detect that they might be clicking on a potentially harmful site.
Every user deserves to have a safe and secure browsing experience,
and these two signals work together to ensure that sites are good citizens on the internet.
The mobile friendliness signal covers the accessibility pillar,
which measures how effective the pages are on small screens
on small screens, often used by mobile phones.
The first three metrics, Largest Contentful Paint,
First Input Delay, and Cumulative Layout Shift
are the Core Web Vitals,
a set of metrics that apply to all the web pages
and should be measured by all site owners
and would be surfaced across all the Google tools.
Each of the Core Web Vitals represents a distinct facet of user experience
and is measurable in the field,
and reflects the real world experience of a critical user-centric outcome.
They can be measured using JavaScript using the standard web APIs
and provides an excellent product-agnostic path for instrumentation.
To learn more about Core Web Vitals, check out the talk from the Chrome team
titled What’s new in Web Vitals at I/O 2021.
Core Web Vitals are not just a set of metrics but also a robust set of threshold guidance
that map to user expectations.
The Chrome team has done extensive research and come up with the guidance
for what it means to be performing good, poor, or somewhere in between.
For instance, LCP where we measure the loading performance of the page,
values less than 2.5 seconds
means the page is delivering good user experience.
Pages that take more than four seconds are deemed poor.
Similarly for First Input Delay, 100 milliseconds is a maximum delay
users have to encounter during the initial input and its response.
Anything greater than 300 milliseconds
starts to feel like the page is frozen and leads to bad user experience.
Cumulative Layout Shift is a unitless metric.
0.1 score or below is good while 0.25 or greater is deemed poor.
A quick aside, when the Chrome team first introduced Cumulative Layout Shift,
the metric accounted for the entire life cycle of the page.
Recently, the team has updated the definition
to be more accurate by capping the maximum duration of the window at five seconds.
When Google Search launches page experience ranking,
we will be using this updated definition of the Cumulative Layout Shift.
As previously announced, when we launch the page experience ranking,
we also plan to update the top stories feature on Google Search.
The changes include broadening the eligibility requirement
to all qualifying webpages,
irrespective of their Core Web Vitals score, or page experience status
provided they satisfy the Google News content policies.
We plan to use a page experience ranking
to ensure high-quality news articles are surfaced for our users on mobile.
Speaking of devices, today, I am happy to announce
that we are bringing page experience ranking to desktop.
While we’re launching page experience on mobile soon,
we believe page experience is critical
no matter the surface the user is browsing the web.
This is why we’re working hard on bringing page experience ranking to desktop.
As always we’ll be providing updated guidance, documentation and tools
along the way to help you make your pages perform at its best.
Stay tuned for more details on this.
One other way you can get page performance for your users is taking advantage
of prefetching on Google Search via the use of signed exchanges.
Earlier this year,
we announced that Google Search will prefetch websites built using signed exchanges.
Pages are prefetched and stored on the user’s browser,
ready to be loaded when the user clicks on the result,
leading to near instant loading.
This is possible through the use of Google’s fast cache servers,
distributed around the world
that you can now take advantage of without any additional cost.
Nikkei, a large Japanese publisher,
saw tremendous improvements in both performance numbers
and business metrics using signed exchanges prefetching.
In their tests, LCP improved by 300 milliseconds, about 20%
and this was before the team did micro optimizations.
In other words, 20% was the lowest hanging fruit.
As a result of fast loading, they saw 12% more user engagement.
Congratulations to the team for such an amazing accomplishment.
If you are raring to get-go, Search Console’s page experience report
is an excellent place for all of you to get started.
The page experience report offers valuable metrics,
such as percentage of URLs with good page experience,
and their Search impressions over time,
allowing site owners to quickly evaluate their performance.
Site owners can dig into the components of page experience signal
to gain additional insights on opportunities for improvement.
The Search Performance report has also been updated
to allow for filtering pages with good page experience,
which helps site owners keep track
of how these pages compare to others on the same site.
I’ll now turn it over to Naina to talk more about AMP,
our turnkey solution for page experience.
Thanks, Jeffrey.
Hi, folks, as Jeffrey mentioned, my name is Naina Raisinghani,
and I lead product for the AMP team.
Now on the AMP project we strongly believe
that AMP puts developers on the path to success,
to not just creating, but also maintaining great page experience.
This means that the AMP runtime
provides developers with the constraints needed to create a great performing page,
and then AMP caches can actually help further improve the performance of these pages
by making them near instant.
However, like many other frameworks,
AMP can’t implement all web development best practices into its runtime.
And this is why in the run-up to the page experience ranking change going live,
we actually encouraged developers
to ensure that AMP pages served from both the publisher site
or via an AMP cache are both equally optimized.
And the first step to a great page experience here is the AMP core,
that is the AMP extensions and the runtime
that enforce the design constraints that make AMP great.
The next building block is how the page is being served.
Core Web Vital metrics for a page are determined
by observing real user interactions with web pages,
and in the case of AMP, this means that the pages
could be served from either the publisher’s domain or via an AMP cache,
depending on how the user encounters the content.
Many sites actually see a significant proportion of their AMP visits
actually occurring on their own domain.
Now to get the strongest possible user experience on your AMP pages,
we highly encourage all site owners
to implement a number of additional optimizations
that they can perform themselves.
AMP Optimizers are actually tools
that bring the AMP cache optimizations to your own site.
And by using the latest AMP Optimizer,
you're getting the easiest way to automatically benefit
from any new server-side optimizations for AMP.
You can learn more about AMP Optimizers at the link on the screen.
And that's how the AMP project actually thinks about performance.
We make sure that you have the tools to create
and then maintain really great page experience.
And in fact, we also launched the AMP page experience guide last year,
it’s a one-stop tool to help developers debug
why their AMP page might not be meeting page experience criteria.
And since launch, we’ve actually added even more
actionable feedback to the AMP page experience guide,
making it even more useful.
These improvements have actually been driven by websites
testing their AMP pages using the tool.
So we encourage you to try out the tool
at the link shown on the screen and provide feedback.
And that's that, we on the AMP team genuinely believe
that AMP sets you up for success when you're looking at creating
and then maintaining well-performant sites in the long run.
We hope you give it a try and leave your feedback,
and with that, I’ll hand it back to Jeffrey.
Thanks, Naina.
With page experience ranking, we are on a multi-year journey
to surface high-quality content
with exceptional user experience for our users.
We want to give developers actionable guidance through the various tools we offer,
such as Search Console’s Page Experience Report
and AMP’s Page Experience Guide.
With that, I want to thank all of you for joining us today.
We hope you are staying safe, and have a good rest of I/O 2021.
Thank you.