CPP: A Standardized Alternative to AMP

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

by Yennick • 10 years ago

306 93 10 years ago

timkadlec.com

dorianm• 10 years ago

The proposal: http://yoavweiss.github.io/ContentPerformancePolicy/

pjmlp2• 10 years ago

Just use pure HTML/CSS and the web sites will fly by comparison.

hyperpape• 10 years ago

HTML/CSS are slow. The true way is ".txt"

Edit: I mean this as a sort of lazy way of making a reductio. I don't think .txt is better than HTML/CSS for pages (and I hope that's obvious). I also don't think having no JS is a good idea.

I believe in progressive enhancement, and to a first approximation, I think that all websites have at least one feature that they could implement in JS that would be "a good thing".

mxuribe2• 10 years ago

I agree 90% with this; .txt files get most of the job done! ;-) The other 10% where i don't fully agree comprises of hyperlinks; i need me some clickable hyperlinks. :-)

arkitaip• 10 years ago

Whoa whoa whoa, what's some fat cat solution right there! Just use a http header for your content and you're set.

onion2k• 10 years ago

For a single page load, sure. For subsequent page loads you're loading a lot more than necessary (a JS app can fetch just the content that's changed, and without a blank page in between), so a pure HTML and CSS solution is a great deal slower.

Plus, if you users have unreliable internet connections then a JS app can use a service worker to cache the entire app to work offline, and only load in new content when possible. An HTML page doesn't work at all in those circumstances.

Sometimes JS does actually make a site better. It's not always unnecessary bloat.

colanderman• 10 years ago

Client-side XSLT and HTTP caching address both those issues. Yes, JS is another way to solve those issues, but not the only one.

sanbor2• 10 years ago

There is a thing in HTML5 called Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...).

It looks like this:

  <script src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap...."
  crossorigin="anonymous"></script>

I wonder if browsers could keep a cache with those hashes as keys and whenever the integrity hash has a match, then it can take the JS from the cache. That would save huge amounts of bandwidth and pages would be so much faster to load.

Probably right now we're fetching the same version of jquery hundred of times from 20 different domains a day.

pjmlp2• 10 years ago

Given my web development scars, I have become an advocate that for anything other than dynamic documents, the way to go is native.

NoGravitas• 10 years ago

pjax (whether using the old familiar jquery-pjax or some more up-to-date implementation) is great for decorating simple HTML pages with, to replace full page loads with just a main-content load. And since the fall-back is just a full page load, it degrades really gracefully.

splatcollision• 10 years ago

You're lucky if you've got a good enough site so that you can get people to stick around for the second page load! Subsequent CSS calls will be cached for the majority.

rakoo• 10 years ago

Actually for the first part, there is this protocol called SDCH (https://en.wikipedia.org/wiki/SDCH) that allows a site owner to define a site-global compression dictionary, and each resource then becomes a compressed resource with the dictionary being the former one. It's hard to deploy, but it works: LinkedIn saw an average of 24% additional compression.

For the second part I wonder if browsers could display stale data with some warning saying so; that would solve many problems that happen all the time (refreshing a page after the website came down, ...)

honkhonkpants2• 10 years ago

All that stuff sounds really great if you had a lot of engineering resources and you are writing Gmail, but for 99% of the sites out there the JS hacks that load just the deltas and whatnot just get confused by packet loss and I end up having to reload the entire page including the gigantic JS hairball, or even worse the thing is so confused that I have to clear my cache and cookies to make it ever work again.

Simplicity has so many things in its favor.

codedokode3• 10 years ago

if you users have unreliable internet connections then a JS app can use a service worker to cache the entire app to work offline,

It looks like an over engineered system, and you have to preload the content while on WiFi. And by the way do you know a reliable way to detect whether device is really online or there is a link but no packets are going through?

And every website is supposed to write its own code for service worker.

I think it would be easier to implement a feature in a browser where user can explicitly save some pages for offline reading. Or allow user to view pages from cache.

Sometimes JS does actually make a site better.

For most sites it just adds unnesessary widgets (like spying share buttons) and advertisements. Especially on newspapers' sites - most of them work better without JS.

xd1936• 10 years ago

This was first published last February, and the top comment was from a Googler who's involved with the AMP project:

Love this. Not sure by coincidence, but the AMP team has been playing around with the same thing under literally the same name. We should meet up some time and discuss details. Not sure it would be an alternative, but rather a complementary thing.

I wonder what ever came of that.

cbr2• 10 years ago

The spec has been moving along: http://wicg.github.io/ContentPerformancePolicy/

yoavweiss_• 10 years ago

The spec has been split into smaller pieces. The first one that made the most progress is https://wicg.github.io/feature-policy/

Ph0X• 10 years ago

Correct me if I'm wrong, but doesn't the content maker get to decide if they in fact do want all the AMP benefits or not? If I remember correctly you can choose to disable the whole AMP cache google link, and only use the AMP optimizations.

Secondly, He goes on for a few paragraph at the start about how anyone can do this, but that's not so true is it? The whole point of the AMP redirect is that it's on Google cache servers, and unless you have a lot of money, that ain't gonna be cheap.

So at the end of the day, the last part is optional, and it's basically you paying for the cache with allowing them to use their domain (will all ads and traffic stats still sent to you).

notatoad• 10 years ago

omitting the amp cache google link basically makes it not AMP though - you can still follow the rules but it's just called "writing clean and minimal html" at that point.

throwaway2016a• 10 years ago

This is very interesting and I don't want to detract from that .

However, pointing out that for a (large?) portion of us, CPP means "C Plus Plus" so I was confused for a few seconds.

octo_t• 10 years ago

Or C Pre-Processor.

the_mitsuhiko• 10 years ago

Or Socialist Republic of Romania :P

happyslobro3• 10 years ago

Welcome to the world of "$lang-lang" queries. Go, Rust, please make room.

aviraldg• 10 years ago

You would then need to disambiguate between "clang" the compiler and "c-lang" the language.

ohyes• 10 years ago

AMP is "asynchronous message passing" to me.

petecooper• 10 years ago

…and Apache + MySQL + PHP for me.

deno6• 10 years ago

The name makes perfect sense in context:

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.

Longhanks• 10 years ago

Isn't there a better alternative to an abbreviation that's already widely used in the software engineering context?

deno6• 10 years ago

Search engines already deal just fine with context. Just type in “cpp language” or “cpp html,” respectively.

I think everyone keeps making name collisions to be a much bigger deal than they are in reality.

maccard• 10 years ago

If it was a minor collision, sure. But CPP is one of the most used programming languages on the planet. I suppose you think we should create standards for C++ and call them JS or RB or py, for short?

mcbits3• 10 years ago

cpp html: http://imgur.com/gV3dMI9

It's going to take significant momentum to displace "CPP" in the appropriate computing contexts.

sfrailsdev• 10 years ago

PPC is pay per click, which is more likely to create confusion in a web dev context. PCP is less widely used in a software engineering and web developer context (one hopes anyway), but probably not something you want to be searching for from a work computer.

If we could get away from policies though, Performant Content Contracts doesn't overlap with much that is CS related.

ajdecon• 10 years ago

PCP is also Performance Co-Pilot, a relatively widely-used systems performance tool. :)

bluesmoon• 10 years ago

The CPP abbreviation is used to be consistent with CSP.

TickleSteve• 10 years ago

What has Communicating Sequential Processes got do do with it??

chubot• 10 years ago

Alternative name: CWP for Content Weight Policy :)

c0g• 10 years ago

Best part is AMP is a C++ library.

eganist• 10 years ago

COP? Content Optimization Policy?

That's the quickest alternative I can think of to CPP, though I'd be fine with CPP in any case.

mxuribe2• 10 years ago

I agree with the premise that the amp framework (or any such framework) should be separate from being forced to work with only a specific set of tools, etc. However, it seems to me that what the author is proposing is really just more/better adherence to html/web specs...no? Or perhaps, a few performance-related tweaks to existing html/web specs...I mean, if we all (that is web producers, website managers, content authors, etc.) simply produce sites that adhere more to already established web standards (a la html5, xhtml, etc.), AND have browser makers be more strict in their interpretations of the established html/web specs, then we'd be almost all the way there...no? I'm by no means stating that this is easy, just stating that the author might be re-inventing a wheel that simply could use some optimization.

noir_lord• 10 years ago

However, it seems to me that what the author is proposing is really just more/better adherence to html/web specs...no?

Pretty much but buzzwords/PR work, "CPP Compliant" vs "We build stuff properly (for a given value of properly)"

deno6• 10 years ago

No, there are terrible antipatterns that browsers enable to not break compatibility. A strict performance sensitive mode for web platform (HTML/CSS/JS) is long overdue. AMP is a pretty great solution, and the only issue with it has been the proprietary feeling. The browser support is the cherry on top.

The argument that people will just use best practices out of sheer goodwill or even just basic competence has been thoroughly debunked. No one optimizes for performance if they are not penalized.

cbr2• 10 years ago

Right now there are a lot of things that specs let you do that will make your page slow, like running a lot of js in the scroll event handler, or just including too much js overall. If you read the current proposal [1] the idea is that the site could make promises not to do various kinds of slow things, and the browser could enforce that.

[1] http://wicg.github.io/ContentPerformancePolicy/

nailer• 10 years ago

It’s also the only JavaScript allowed: author-written scripts, as well as third party scripts, are not valid.

Minor nitpick: they're allowable in iframes. I.e. sandboxed.

djsumdog2• 10 years ago

Someone posted this in a reply the other day and I feel it should go here as well:

https://vimeo.com/147806338

It's a pretty interesting talk. Just thinking about this kind of stuff can make way skinnier web pages than AMP. I mean really, if we designed pages for 56k modems, the web would be much much fast on mobile.

honkhonkpants2• 10 years ago

I would just about give my left arm for a consistent 56k mobile connection.

theandrewbailey• 10 years ago

No synchronous external scripts nor blocking external stylesheets

I know we have:

but for stylesheets, why can't we have something similar? Instead of a JS workaround, can't we have:

I hate hate HATE the idea of having css dependent on some JS (even if enabled) that might or might not run depending on what feels like working today.

wanda• 10 years ago

In the future, (i.e. only Chrome support this) you will be able to do this:

    <link rel="preload" href="/assets/stylesheet.css" as="style" onload="this.rel='stylesheet';">

which will more or less be async CSS. You can see that it will download in the background and morph into a stylesheet when it's ready, while the document continues to be parsed below it.

Then it will just be a matter of including this for people with JS switched off:

    <noscript>
      <link rel="stylesheet" href="/assets/stylesheet.css">    
    </noscript>

And then for browsers which have JS enabled but don't support the resource hint 'preload', you could do something like this as a fallback:

    window.addEventListener(  'load', function sweepUnloadedPreloads() {
      
      window.removeEventListener( 'load', sweepUnloadedPreloads, false );

      [].slice.call( document.querySelectorAll( '[rel=preload]' ) )
        .forEach( function( item ) {
          
          // simply doing this might work:
          item.rel='stylesheet';
          
          /** OR, if that doesn't work (I haven't tested it)**/
          var new_link = document.createElement( 'link' );
          new_link.rel = 'stylesheet';
          new_link.href = item.href;
          document.head.appendChild( new_link );
        });

    }, false );

The sketchy hypothetical fallback technique above, or any JavaScript CSS loader, could be augmented by using prefetch to attempt to get the tyres warm and start a low-priority download of the stylesheets in question.

    <link rel="prefetch" href="/assets/stylesheet.css">

And obviously there's Service Worker, which is also slim on support, but promises to turn your website into a near-native experience by providing the mother of all caches for resources and offline pages/resources.

Preload spec: https://www.w3.org/TR/preload/

Preload support: http://caniuse.com/#feat=link-rel-preload

You could also just put the link element(s) specifying your stylesheet(s) in the body to 'async' it — Stripe does this on stripe.com. It's not valid HTML but very few browsers seem to give a damn.

msorvig• 10 years ago

Mildly interesting: CPP AMP is already a thing: https://msdn.microsoft.com/en-us/library/hh265137.aspx

jasonhansel• 10 years ago

I think the real concern about AMP is not that it's nonstandard, but that Google's caching mechanism reduces publishers' control over how their content is presented and keeps users on Google's domain. This is a problem for publishers, but I assume it increases performance (perhaps because Google prefetches the page while the user is looking at search results?).

irq-1• 10 years ago

Shouldn't this be a white-list? If we restrict the features allowed we won't run into all the same security and performance issues we have with the web.

(also, we could call it HTML Light, or htmll)

pcwalton2• 10 years ago

I'm much happier to see this. My concern with AMP has always been that it removes incentives for browsers to get faster, because if most of the content is using AMP there's no point in optimizing important things. Having a multi-vendor solution gives us non-Chrome browser vendors a voice at the table.

(To give a concrete example, why bother with optimizing layout-affecting animations to run off the main thread if AMP just forbids them? Such animations are useful, precisely because they affect layout; we aren't doing Web authors any favors by forbidding them instead of just making them fast.)

hilop2• 10 years ago

AMP is for news pages, stuff is one page away from Search. Browsers still work to optimize the overall experience for web apps and full sites.

pcwalton2• 10 years ago

1. Animations have their place on news sites.

2. I'm not just talking about animations: things like parallel layout are also useful for static sites.

fefe23• 10 years ago

I can't take AMP seriously as long as it forces web sites to include resources from Google.

That basically turns all AMP web pages into something that Google can track. Google can track enough of the web already, thankyouverymuch.

If your "standard" proposal starts with telling me I have to include content from a specific URL, you already lost me as a potential proponent.

I also happen to disagree with "all CSS needs to be inline".

Unless I missed something, CPP appears to not require me to include some 3rd party content, so I'm on board already :-)

acqq2• 10 years ago

Aren't the AMP pages anyway delivered from the Google servers to the users? Then Google can track them anyway?

I'm just a casual observer and that's just how I understood the idea.

mcbits3• 10 years ago

AMP pages are served from the publisher's server as usual, but Google can easily direct their users to their cache instead of the official site. Every AMP page also includes JavaScript hosted by Google, so Google gets pinged every time someone visits an AMP page, even if it wasn't through their cache.

vmarsy• 10 years ago

I don't think it forces you to include resources from Google. I think the 2 primary reason Google asks you to include a specific javascript script [1] are :

1 - Lazy & Prioritized asset loading logic

2 - Loading assets from cache

Regarding the lazy & prioritized asset loading, the script [2] shouldn't be relying on some Google specific stuff. Since the project is open source, anyone can take a look and get an answer.

Regarding the loading from Google's cache: I haven't dug that much into it, but it's supposedly possible to write your own cache service (instead of relying on the currently free google CDN). Google provided the API and the URL format to so that it should be doable [3]. My assumption is that you can then create your own script, with the cache server URL changed to your own instead of Google's in a simple config file[4].

The question is then: by doing so (and effectively cutting any ties with Google's servers) will your page still be recognized as AMP by Google search engine? It will still reap the actual perf benefits (assuming your CDN does not suck), but if Google's crawler really wants that [1] to be present (and it should not), you wouldn't get the SEO benefits.

[1]

    <script async src="https://cdn.ampproject.org/v0.js"></script>

[2] https://github.com/ampproject/amphtml

[3] https://developers.google.com/amp/cache/

[4] https://github.com/ampproject/amphtml/blob/c44a48fbb1dbd0de0...

rhizome• 10 years ago

That basically turns all AMP web pages into something that Google can track. Google can track enough of the web already, thankyouverymuch.

The point is to be able to track requests with javascript (or just Google Analytics, really) blocked.

pmlnr• 10 years ago

We already have a standardized alternative to AMP; it's called HTML.

Just cut the crap.

ephimetheus• 10 years ago

http://xkcd.com/927 comes to mind

krakmh• 10 years ago

No alternative can take part of AMP, now it become standard and there are hundred of scripts and plugin available for it. I am using WordPress plugins https://talktopoint.com/wordpress-amp-and-instant-articles/ and they are just working fines. What is need of this new alternative and why should I use it?

CPP: A Standardized Alternative to AMP

Related Stories