Earlier quoted context omitted.
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.
PCP is also Performance Co-Pilot, a relatively widely-used systems performance tool. :)
CPP: A Standardized Alternative to AMP
71–80 of 97 posts
Re: CPP: A Standardized Alternative to AMP
#72Just cut the crap.
Re: CPP: A Standardized Alternative to AMP
#73Earlier quoted context omitted.
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 possib…
There is a thing in HTML5 called Subresource Integrity ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ). It looks like this: 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 sa…
Re: CPP: A Standardized Alternative to AMP
#74Isn't there a better alternative to an abbreviation that's already widely used in the software engineering context?
Re: CPP: A Standardized Alternative to AMP
#75This 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.
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…
Re: CPP: A Standardized Alternative to AMP
#76Just use pure HTML/CSS and the web sites will fly by comparison.
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 possib…
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.
Re: CPP: A Standardized Alternative to AMP
#77Earlier quoted context omitted.
There is a thing in HTML5 called Subresource Integrity ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ). It looks like this: 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 sa…
It's not really bandwidth that causes the issue. Javascript is just really slow, both in parsing and execution. According to Chrome dev tools, parsing jquery takes 20ms on my 4.4 GHz desktop CPU. Now imagine how long that takes on a mid-range smartphone. Then add in a dozen other javascript libraries and shims and polyfills and the site is barely usable.
But I doubt the bottleneck is JS code. The problem is that web sites are not optimized (some frontend developers think that writing a CSS stylesheet for narrow screen is enough) and they include a lot of resources (including trackers, advertisement, spying social network buttons I never click). Some of the widgets create an iframe (which is like a separate tab in your browser) and load a separate copy of jQuery there, make AJAX requests etc. And even worse, some advertisement networks can create nested iframes 2 or 3 levels deep (for example when a network doesn't had own ads, they can put Google Adwords block). So when you load a page with 10 iframes it loads the CPU as 10 separate tabs.
Decoding images is not free too, especially if it is thousand pixel wide heavily compressed JPEG or PNG image.
The real optimization would be cutting away (or making lazily loadable by user request) everything except content. As website developers are not going to do it, it is better to do the optimization on client side. I wish standard mobile browser allowed disabling JS, web fonts (which are just a waste of bandwidth) and loading images on request. Mobile networks usually have high latency so reducing the number of requests needed to display a page could help a lot.
Re: CPP: A Standardized Alternative to AMP
#78Earlier quoted context omitted.
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 possib…
There is a thing in HTML5 called Subresource Integrity ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ). It looks like this: 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 sa…
(And if you meant using hashes to use cache for resources from different domains - there probably will be many misses because every website can use different library versions, they can compress or bundle libraries etc).