Google takes a tiny step toward fixing AMP’s URL problem

When you click on a link on your phone with a small lightning bolt next to it in the Google search, you get something in the AMP format. AMP means "Accelerated mobile pages" and you probably noticed that those pages load very quickly and, in general, they look much simpler than normal web pages. You may have also noticed that the URL at the top of your browser started with "www.google.com/somethingorother" instead of the webpage you thought you were visiting.

Google is trying to solve that today by announcing support for something called "signed exchanges". What it should mean is that when you click on one of those links, your URL will be the original and correct URL of the story. Cloudflare joins Google to support the standard for customers who use their services.

For this to work, every step in the chain of technologies involved in loading the AMP format has to be compatible with the signed exchanges, including your browser, the search engine, and the website that published the link. At this time, that means that the URL will be corrected only when a Chrome browser loads a Google search link to a published article that has implemented the support.

all that? Probably not because it is very complicated, and there are a large number of traps and web standards proposed behind almost all the clauses of the last three paragraphs. Let's move away a little, and let's talk about what AMP is and what is trying to become. We can start with what we've been talking about for more than four years:

The mobile web still sucks.

Many companies have tried to solve the problem. On the one hand, there are ad blockers, several browser updates that should not be tracked and the advertising industry promises to be more pleasant. None of these efforts has reached much because it is a game of cat and mouse with people trying to improve the web and those who earn money with bad advertising experiences.

That's why, on the other hand, there have been several attempts to supplant the web with something a little more controlled and focused on the mobile. That's what instant Facebook articles were and that's what, to a large extent, Apple News is now. These new standards are also better for phones because they can be packaged, preloaded and sent from any server.

Google AMP also fits into this category, but Google is trying to split the difference between opening the web and the safe and controlled nature of those other rules. An AMP article can not have the most JavaScript you'll find on a web page, and it can be packaged and served from anywhere.

This brings us to the problem. Since Google is trying to make AMP a web standard, it needs to use web standards, namely the URL. But the URL has always been a kind of promise: what you're seeing comes from where it says it comes from. It is called an "address" for a reason. AMP, because it is based on the web, does not break that contract, even though the article can be served by another person. That's why you see a different URL in some AMP articles. Although an article by AMP Verge definitely comes from us, it can be served by a Google server.

Here, for example, there are three different URLs, all for the same story. I have marked the parts that indicate that you are viewing AMP:

https://www.theverge.com/circuitbreaker/2018/9/11/17842556/ipad-logitech-crayon-apple-pencil- stylus-review

] https://www.theverge.com/ platform / amp / 2019/4/16/18311894 / logitech-express-alexa-remote-control-advertised-features-prices [19659014] https: / /www.google.com/amp/s /www.theverge.com/platform/amp/2019/4/16/18311894/logitech-express-alexa-remote-control-announced-features -pricing

This is the last real problem, both in terms of page functionality and in terms of trust. It is also a big annoyance when you share a URL. Sometimes your browser can be smart and share the "real". But most of the time, you end up sending the AMP URL, and it seems ridiculous in a desktop browser.

That's what all this of the Signed Exchanges means to fix. All parties in the chain of technologies mutually tell each other that they trust each other, and therefore, the Google server would get permission to provide a URL that starts with www.theverge.com instead of www.google.com. Break the promise of the URL: says www.theverge.com, but the server is from Google. In theory, that's not a problem because the publisher will have signed that we trust Google to do that.

That means that Google has to incorporate publishers to support the standard, which means that there is still more work for companies that are already trying to make sure their content appears on the web, Apple News, AMP and Who knows where else? (For the record, I do not know if The Verge or Vox Media plans to support the signed exchanges.) It's the classic "chicken or egg" problem of all web technologies, and I expect a lot from editors are going to take a similar approach to wait and see. That is going to be a big obstacle for Google's future.


gif;base64,R0lGODlhAQABAIAAAAUEBAAAACwAAAAAAQABAAACAkQBADs

All this work is part of a generalized impulse for AMP to be subsumed or replaced by something called "Web Packaging Standard", which (very basically) allows web pages to be packaged and expanded on the Internet so that they can be preloaded and serve more quickly. That's what AMP does too, but the new standard should be a bit more universal.

Everything that has web standards takes time. There is not an annual cadence in which a technology executive takes the stage in a main event and presents an amazing technology to which he can subscribe tomorrow . Instead, there are discussions in email threads, consensus building among stakeholders and several companies that support or make rational decisions about the effort to not be worth the payment. It is slow, messy and complicated. In addition, at least, in theory ( Google ), it is not controlled by a single company or entity.

This whole business of signed exchanges is a small step, but it's a small step in the right direction.

Please Note: This content is provided and hosted by a 3rd party server. Sometimes these servers may include advertisements. igetintopc.com does not host or upload this material and is not responsible for the content.


Open

Close