cpp是否完全替代c_CPP：AMP的标准替代方案

cpp是否完全替代c

It’s no secret that I have reservations about Google’s AMP project in its current form. I do want to make it clear, though, that what bothers me has never been the technical side of things—AMP as a performance framework. The community working on AMP is doing good work to make a performant baseline. As with any framework, there are decisions I agree with and some I don’t, but that doesn’t mean the work isn’t solid—it just means we have different ways of approaching building for the web.

我对当前形式的Google AMP项目 持保留态度已不是什么秘密。 但是，我确实想明确地说，困扰我的从来不是技术方面的事情-AMP作为性能框架。 从事AMP的社区在做好性能基准方面做得很好。 与任何框架一样，有一些我同意的决定，有一些我不同意的决定，但这并不意味着工作并不牢固，这只是意味着我们有不同的方法来构建网络。

But that’s the beauty of the web, isn’t it? It’s not just that anyone, anywhere can consume the information on the web—that’s fantastic and amazing, but it’s not the complete picture. What makes the web all the more incredible is that anyone, anywhere can contribute to it.

但这就是网络的魅力，不是吗？ 不仅仅是任何地方的任何人都可以使用Web上的信息-很棒而又令人惊奇，但这还不是全部。 使网络更加不可思议的是，任何地方的任何人都可以为它做出贡献。

You don’t need to go through some developer enrollment process. You don’t need to use a specific application to build and bundle your apps. At its simplest, you need a text editor and a place to host your site.

您不需要经过某些开发人员注册过程。 您不需要使用特定的应用程序来构建和捆绑您的应用程序。 最简单的是，您需要一个文本编辑器和一个用于托管站点的位置。

That’s it. The rest is up to you. You can choose to use jQuery, SASS, React, Angular or just plain old HTML, CSS and JavaScript. You can choose to use a build process, picking from one of numerous available options based on what works best for you. Certainly everybody has their own opinion on what works best but in the end it’s your choice. The tools are up to you.

而已。 其余的取决于您。 您可以选择使用jQuery，SASS，React，Angular或仅使用旧HTML，CSS和JavaScript。 您可以选择使用构建过程，然后根据最适合自己的情况从众多可用选项中选择一种。 当然，每个人对什么最有效都有自己的看法，但最终由您选择。 这些工具取决于您。

That’s not the case with AMP as it stands today. While I’ve heard many people claim that the early concerns about tying better methods of distribution to AMP were unfounded, that’s the very carrot (or stick depending on your point of view) that they’re dangling in front of publishers. There have been numerous rumblings of AMP content being given priority over non-AMP content in their search engine rankings. Even if this ends up to not be the case right away, they have certainly emphasized the need for valid AMP documents in order to get into Google’s “search carousel”—something any publisher clearly would like to benefit from.

如今的AMP情况并非如此。 尽管我听到很多人声称，早期对将更好的发行方式绑定到AMP的担忧是没有根据的，但这是他们在发行商面前摇摇欲坠(或者根据您的观点坚持的立场)。 在其搜索引擎排名中，有许多关于AMP内容优先于非AMP内容的传言。 即使最终并非立即成为事实，他们当然也强调需要有效的AMP文件才能进入Google的“搜索轮播”，这显然是任何发布商都将从中受益的。

This differs from similar announcements in the past from Google about what they prioritize in their search ranking algorithms. We know they like sites that are fast, for example, but they’ve never come out and said “You must use this specific tool to accomplish this goal”. Up until now.

这与Google过去的类似公告不同，即它们在搜索排名算法中的优先级。 例如，我们知道他们喜欢快速的网站，但他们从未问过“您必须使用此特定工具才能实现此目标”。 直到现在。

By specifying the specific tool to be used when building a page, Google makes their job much easier. There has been no simple way to verify a certain level of performance is achieved by a site. AMP provides that. Because AMP only allows a specific set of elements and features to be used, Google can be assured that if your page is a valid AMP document, certain optimizations have been applied and certain troublesome patterns have been avoided. It is this verification of performance that gives Google the ability to say they’ll promote AMP content because of a better experience for users.

通过指定在构建页面时使用的特定工具，Google使其工作变得更加轻松。 没有简单的方法来验证站点是否达到了一定的性能水平。 AMP提供了这一点。 由于AMP仅允许使用一组特定的元素和功能，因此Google可以确保，如果您的页面是有效的AMP文档，则可以应用某些优化方法，并且可以避免某些麻烦的模式。 正是这种性能验证使Google能够说，由于用户体验更好，他们将宣传AMP内容。

So when we look at what AMP offers that you cannot offer yourself already, it’s not a high-performing site—we’re fully capable of doing that already. It’s this verification.

因此，当我们查看AMP提供的服务而您无法提供自己的服务时，这不是一个性能很高的网站-我们已经完全有能力做到这一点。 就是这个验证。

内容效果政策 (Content Performance Policies)

I’d like to see a standardized way to provide similar verification. Something that would avoid forcing developers into the use of a specific tool and the taste of “walled-garden” that comes with it.

我希望看到一种提供类似验证的标准化方法。 可以避免强迫开发人员使用特定工具以及随之而来的“围墙花园”的味道。

There were several discussions with various folks around this topic, and the option I’m most excited about is the idea of a policy defined by the developer and enforced by the browser. We played around with name ideas and Content-Performance-Policy (CPP) seemed like the best option.

与该主题的人们进行了数次讨论，而我最兴奋的选择是由开发人员定义并由浏览器实施的策略。 我们反复研究名称创意，内容性能策略(CPP)似乎是最好的选择。

The idea is that you would define a policy using dedicated directives (say….no hijacking of scroll events) in either a header or meta tag. The browser could then view this as a “promise” that the site adheres to the specified policy (in this case, that it doesn’t hijack any scroll events).

这个想法是，您可以在标头或元标记中使用专用指令(例如……不劫持滚动事件)定义策略。 然后，浏览器可以将其视为站点遵守指定策略的“承诺”(在这种情况下，它不会劫持任何滚动事件)。

If the site then tried to break its promise, the browser would make sure that it cannot (e.g. ignore attempts to cancel the scroll event). An embedder, such as a search engine or a social network app, can then be certain that the “promises” provided by the developers are enforced, and the user experience on the site is guaranteed not to suffer from these anti-patterns.

如果该站点随后试图违背其诺言，则浏览器将确保它不能(例如，忽略取消滚动事件的尝试)。 这样，嵌入程序(例如搜索引擎或社交网络应用程序)就可以确定执行了开发人员提供的“承诺”，并保证了站点上的用户体验不会受到这些反模式的影响。

CPP directives could also be used to control what third parties can do on a given site, as well as a way for third parties to provide guarantees that they will “behave”. This way, content owners can be sure that the user experience will not contain obvious anti-patterns even if the page is pulling in scripts and content from a large number of arbitrary third-party sources.

CPP指令还可以用于控制第三方在给定站点上可以执行的操作，以及第三方提供保证其“行为”的方式。 这样，即使页面从大量任意第三方来源提取脚本和内容，内容所有者也可以确保用户体验不会包含明显的反模式。

CPP could borrow from the concept and approach of the already existing Content Security Policies (CSP). This means that there would likely be a reporting-only mode that would allow sites to see the impact the policy would have on their pages before applying it live.

CPP可以借鉴现有的内容安全策略(CSP)的概念和方法。 这意味着可能会有一个仅报告模式，该模式将允许站点在应用该策略之前先查看该策略对其页面的影响。

CPP’s would free developers up to use their own tools again and avoid limiting them to the specific subset of web technologies that AMP imposes. Because it uses a set of definable policies versus a specific framework, there is much more flexibility in how browsers and apps choose to enforce and promote content. For example, an app may choose to look for a certain set of policies that would work best for its context while Google may prioritize an entirely different set of policies when considering how a page should be prioritized in their search-engine. It’s far more extensible.

CPP可以使开发人员腾出更多时间再次使用自己的工具，而不必将其限制为AMP所强加的特定网络技术子集。 因为它使用了一组可定义的策略而不是一个特定的框架，所以浏览器和应用程序选择如何实施和推广内容具有更大的灵活性。 例如，一个应用可能选择寻找一组最适合其上下文的策略，而Google在考虑如何在其搜索引擎中对页面进行优先级排序时可能会优先考虑一套完全不同的策略。 它的可扩展性更大。

You could also imagine smarter content blockers that let through ads and other third party content guaranteed to be fast and not interfere with the user experience, while blocking third party content without these guarantees. That would allow us to avoid the centralized model of things like the Acceptable-Ads program, while providing a standard way to have the same benefits.

您还可以想象更智能的内容阻止程序，这些内容阻止程序可以保证广告和其他第三方内容的传输速度快，并且不会干扰用户体验，而在没有这些保证的情况下阻止第三方内容。 这样一来，我们就可以避免采用诸如Acceptable-Ads计划之类的集中式模型，同时提供了获得相同收益的标准方法。

那么……AMP发生了什么？ (So…what happens to AMP?)

There are too many smart people building AMP to let all that good work go to waste. If we decouple the distribution benefits away from the tool, then suddenly AMP becomes a framework for performance—something it is far better suited to. Developers could choose to use AMP, or a subset of its features, to help them accomplish their performance goals. The difference is that they wouldn’t be forced to use it. It becomes an option.

建立AMP的聪明人太多了，以至于无法浪费所有好的工作。 如果我们将分配收益与工具脱钩，那么AMP就会突然成为性能的框架-更适合的东西。 开发人员可以选择使用AMP或其部分功能来帮助他们实现性能目标。 不同之处在于他们不会被迫使用它。 它成为一种选择。

I’m working with Yoav Weiss to create a formal proposal for CPP’s that can be shared and built up. There’s an extremely early draft up already, if you would like to take a look. We’ve discussed the idea with numerous people from browsers and publishers and so far the feedback has been positive. People like the more standardized approach, and publishers in particular like that it feels more open and less like something they’re being forced into.

我正在与Yoav Weiss合作，为CPP创建一个正式的提案，该提案可以共享和建立。 如果您想看看，已经有一个非常早的草稿 。 我们已经与来自浏览器和发布者的众多人讨论了这个想法，到目前为止，反馈是积极的。 人们喜欢更标准化的方法，尤其是发行商，它感觉更加开放，而不像他们被迫采用的那样。

The idea of CPP is still young and nearly all discussion has happened behind closed doors. So this is us putting it out publicly to get people thinking about it: what works, what doesn’t, what could make it better.

CPP的想法还很年轻，几乎所有讨论都是在不公开的情况下进行的。 因此，这就是我们公开发布该产品，以使人们对此进行思考：什么有效，什么无效，什么可以做得更好。

I like the work AMP has done from a technical perspective, and I love the ambitious goal of fixing performance on the web. Let’s find a way of accomplishing these goals that doesn’t lose some of the openness that makes the web so great in the process.

我喜欢AMP从技术角度所做的工作，我喜欢将性能固定在网络上的宏伟目标。 让我们找到一种实现这些目标的方法，同时又不会失去使网络变得如此出色的开放性。

翻译自: https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/

cpp是否完全替代c