Hacker Timesnew | past | comments | ask | show | jobs | submitlogin
Evaluating page experience for a better web (googleblog.com)
65 points by twapi on May 28, 2020 | hide | past | favorite | 38 comments


"Through both internal studies and industry research, users show they prefer sites with a great page experience." You don't say!!! Good they made internal and industry researches about this since I really thought users preferred poor experience...


Based on the update to google groups a few years ago it seems like these findings are at least a surprise to them.


So true! Also based on the design of Blogger!


“Through studies and research, HN users show they prefer to upvote popular comments”


Yes, same as people like good music :)


Off-topic: I meet someone who didn't like music. I mean no kind of music....hard to believe but such people exist.

https://en.m.wikipedia.org/wiki/Musical_anhedonia


I met someone that doesn't dislike it but is totally indifferent to it. Music for him is like traffic noise.


I’d like some personal ranking features, or a browser extension that changes the SERP. If a page is capable of asking me to enable notifications, I want it deleted from the results. If a page has a giant popover when it loses focus, I want it demoted. Negative signals for infinite clickbait at the bottoms of articles. Let’s be opinionated about the “better web”.


Same for scrolljacking or requiring js to even be able to render the page.

Another one is something I haven't seen named anywhere: maybe I'm in the minority, but I like to read by highlighting the paragraph or line that I'm reading. It helps with eye tracking or something. There are sites that like to "highlightjack" my selection. This is when highlighted text gets some popup to "help" you tweet or fb-post that selection. Those sites lose their js privileges on my machine pretty quickly.


> but I like to read by highlighting the paragraph or line that I'm reading

Same here. I have noticed it really annoys people that are reading a page with you, especially if it's not a thing they do.


You know you can turn off notifications in your browser if you don't want them right?


I think the larger point is that the user wants their customized results actually customizable using their metrics not Google's predefined metrics of a "better web".


Actually I didn't know that. There should be a setting that just closes tabs whenever they try to send notifications. That would be a real benefit. Desktop notifications feature of the web is like a big button labelled "press button if you are a jerk". Anyone who uses this feature is a jerk.


Seems like exactly what many on HN were asking for: weigh page speed without biasing towards AMP.

This can only be a good thing.


They are favouring pages that weigh less. But they don't say they are putting pages that weigh less above pages that use AMP (if they weigh more). I'm guessing it's another point on their metrics. If it weighs < X MB it's one point, if they use AMP it's another point, so those would still appear first.


I sure hope so.


These new metrics have a serious flaw. The iframe loophole is so bad, we even did a write-up on it: https://buzz.swarmify.com/how-to-get-a-100-score-on-lighthou.... See the article for the gory details, but the gist of it is, you can wrap the entire site in an iframe and always get a perfect score


I lead engineering for some of Google's developer tooling like Lighthouse. You are correct that we currently have a gap in our ability to measure subframes in the lab locally on your machine (doing so cross-origin reliably is complex), but we're looking at how we can improve this. The important bit I want to call out here is that "framehole" is a measurement gap in LH: you can currently game the score but you're only fooling yourself in the process — there is no benefit to the user experience.

Speaking of real world user experience, accounting for iframes has a number of complicated privacy and security challenges at the resolution of an individual page load. However, the good news is that the Chrome User Experience Report* aggregates anonymized data from many opted-in users and, as a result, is able to account for iframes in its measurement. Which is to say, the field data we surface in our tools (powered by CrUX) does not have this problem. We’re working to get our lab tools to align with this behavior as well.

* https://developers.google.com/web/tools/chrome-user-experien...


I appreciate the reasoned and thought out reply. At the engineering level, I get why capturing the results from the iframe is challenging and that its just a gap in the measurement by the tools.

Here is the problem though. When these new measurements roll out to Pagespeed Insights, that score will be treated like the holy bible of performance. Most who use and make decisions off of that score will not read nor understand the engineering level nuance that it doesn't take into account Iframe content.

That means that all over the world, people will be optimizing for the score even if the score is incorrect. Decisions will be made on whether the score goes up or down when using various tools, including our service. As it stands, the score ignores iframed content. So it will ALWAYS be the case that using a 3rd party embed of some content will lead to a better score than natively including the content on the page. Anything embedded from a third party simply disappears in the scoring.

While I don't believe that this choice is being made on purpose to favor Google properties, at the end of the day that is exactly what happens. YouTube embeds improve page speed, slow loading advert iframes, don't impact the score.

So we are trying to shine some light on exactly how important this now is, and how at the extreme excluding iframes can be used to show a score of 100 even when nothing else has been done to improve the actual speed. If there are engineering challenges that prevent counting iframes as of yet, then I would submit that the score is not ready for primetime until that can be worked through. It may not have seemed like a big enough issue, but hopefully I can convince you that it is.


Even if Google fixes that loophole, I think the larger point remains, that if they're exempting iframed content from their calculations, we're going to see a lot of SMB site builders sticking stuff unnecessarily in iframes just to claim a good "score".

Long-term, there's no rationale for excluding iframes. If it's visible on page, it should count.


I think I welcome these changes, but I'm worried about some of the wording that Google uses.

The page experience signal measures aspects of how users perceive the experience of interacting with a web page. Optimizing for these factors makes the web more delightful for users across all web browsers and surfaces, and helps sites evolve towards user expectations on mobile. We believe this will contribute to business success on the web as users grow more engaged and can transact with less friction.

I guess I have a problem with the fact that Google sees the web as primarily a business platform where users simply transact. I do use the web this way, but I don't mostly use the web this way.


This requires trust that 1. Google understands how users perceive the experience and then 2. can operationalize something that may be rather personal into repeatedly measurable elements.


> While all of the components of page experience are important, we will prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search.

> ...

> When we roll out the page experience ranking update, we will also update the eligibility criteria for the Top Stories experience. AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page.

All sounds pretty sensible.

For anyone working on this: Why wasn't the above done sooner? Was it challenging to come up with a fair page performance metric for instance? Was a very slow loading page not penalised before?

For people that weren't happy with AMP: is this moving in the right direction?


Headline:

> When we roll out the page experience ranking update... AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page.


> By contrast, here are some examples of techniques that, used responsibly, would not be affected by the new signal:

> Interstitials that appear to be in response to a legal obligation, such as for cookie usage or for age verification.

Too bad they don’t penalize cookie consent popups. Google is in a unique position to motivate website owners to stop using tracking cookies and make the web a better place. As a reminder, under GDPR a consent is only needed for tracking cookies, not for functional cookies. I guess whitelisting such popups is better aligned with their ad business.


> ...remove the AMP requirement from Top Stories eligibility. Google continues to support AMP, and will continue to link to AMP pages when available.

Is this Google backing down on the AMP nonsense?


Something might be changing inside Google.

- Last year after 10 years of utterly irrelevant and insulting ads they've now started to show me relevant ads. I might even have clicked one or two as it was kind of interesting.

- Twice in the last six weeks when I hit !g in ddg to see if I was luckier in Google, Google delighted me by actually showing exactly the results I wanted.

For those who are too young to remember old Google I'll try to explain: normally when I search with Google the last ten years if the topic wasn't completely mainstream, Google would twist my words to mean something that they could show more results for.

Old Google showed what you searched for in an almost intelligent way, and this is what I have seen again no, for the first time in ~10 years, and not only once buy twice!

- And now this: they'll stop trying to shove AMP down our throats..?

Let me guess:

- someone is threatening to sue Google

- and Googlers are tired of getting rightfully roasted for something stupid Goolge does, every single time they show up here


DDG has reduced my need for Google Search for about 99% now. I even dread having to adding “!g” to my search as I have a growing dislike for Google’s grey UX patterns.


> I even dread having to adding “!g” to my search as I have a growing dislike for Google’s grey UX patterns.

Same here, and often the difference has been down to randomness, but lately - as I mentioned - I have had not just one but two times that Google actually behaved like Google from < 2009.


Irony is that if I want to shop online I have to use Google because DDG pretty much only shows Amazon.

If I wanted Amazon I'd just be on amazon.com not ddg.com, fellas.


I sure hope you are right. It would be about time, too.


Next we know Reader is back ;-)


Google is under investigation by 48 state governors and the Department of Justice, not to mention all of the various scrutiny in other countries and governing bodies such as the European Union.

Special-casing the top search results for sites that implement a Google-proprietary replacement web format that lets them host the content on their own servers is a really bad look with all of that looming.

I doubt Google will give up on AMP, it provides them way more control over the Internet than they've ever had before, but search result ads, knowledge graph/carousel content, and the top results of search are under incredible scrutiny right now.


I think it’s more about the content they can get. This’ll only happen when there are no AMP links so it’s still a tragedy of the commons, the only winner is Google.


At last!


I'd say "I'll believe it when I see it" :)


not enough rounded borders and box shadow on card like ui and subtle parallax effects. D- you aren't even trying.


It just doesn't pop.

Can you make it pop?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: