Replace 'user agent' with crawler if you'd like.
1,271 karma · joined September 17, 2010
"Hey useragent, if you understand this markup, please send mobile users to this other URL that I have provided."
Twitter then respects the website owner's markup request.
If the markup was "here's a mobile optimized page", we wouldn't get this kind of strong reaction in HN. If the markup was "here's a the language X variant of the document", we wouldn't get this kind of reaction in HN.
If Google preloaded the page from a non-google server, there would be a few problems. The most important one is that it would violate the user's privacy. That server would have in it's logs a request from a user that didn't click on the article, and could intuit information about the user's searching behavior from that request.
Less importantly, without the page being served from Google's cache, there is no way to guarantee it's actually a valid AMP page. The only thing Google knows is that it was valid AMP the last time it was crawled, which could be days ago.
> With AMP [chat applications] cannot be used
True currently. There are no chat application amp extensions, yet. This could change in the future. Vendors interested in implementing one for AMP should get involved at http://github.com/ampproject/amphtml
> AMP does not have any markup specific to checkouts
Most web pages move from shopping cart to payment by changing URLs. This would work just fine with an AMP page. There is in fact at least one vendor who has integrated payments with AMP already: https://www.ampproject.org/docs/reference/components/amp-acc...
Also take a look at https://ampbyexample.com/advanced/payments_in_amp/
> AMP does not allow for use of forms
See https://www.ampproject.org/docs/reference/components/amp-for...
> They really do not support a logged in state, or user preferences. Things like recommended products, or recently viewed products will not work with an AMP page. None of the personalization aspects like “Hi, Lesley” are done with AMP.
See the (perhaps poorly named) https://www.ampproject.org/docs/reference/components/amp-lis... This supports loading content specific to the user, even on a cached amp document.
> if search and filtering are a large part of your site’s mobile navigation, AMP will be useless.
This is exactly what amp-bind was built for: https://ampbyexample.com/components/amp-bind/
> Google Analytics is not supported on AMP
Google Analytics is fully supported in AMP. Here's the Google Analytics support page: https://developers.google.com/analytics/devguides/collection...
> If you use a different suite of tracking such as Piwik or kissmetrics, they will not work with AMP.
There is a large list of analytics vendors that have direct support here: https://www.ampproject.org/docs/guides/analytics/analytics-v...
Other vendors can be added with a small amount of configuration. Here's a guide for Piwik, for example: https://www.elftronix.com/guide-to-using-piwik-analytics-wit...
Alternatively, vendors can submit a configuration to the AMP project which is just a few lines of JSON, then the vendor will be supported more directly.
> Ad Revenue is Decreased
The link is to a single article from a year ago. There are many studies pointing to the opposite effect as well.
> A/B testing is not supported
See https://www.ampproject.org/docs/reference/components/amp-exp...
> Performance
I'm not sure what URLs the author used, but I tried to find a similar overstock recliner page that might be the right one. I found:
https://www.overstock.com/Home-Garden/Recliners/Leather,/mat...
The author tries to use a google.com/amp URL, but these redirect when not coming from a search click. Much easier is to take the CDN amp URL, which is served the same way:
https://cdn.ampproject.org/c/s/www.overstock.com/Home-Garden...
I loaded both of these in Chrome, simulated a mobile device, network tab, and throttling with Fast 3G. Here were my results:
* non-AMP: 42 requests, 1.1 MB transferred, Finish: 10.3s, DomContentLoad: 3.38s, Load: 9.52s
* AMP: 35 requests, 408 KB transferred, Finish 5.87s, DomContentLoaded 1.28s, Load: 5.88s
The AMP page is 60% smaller and hits the load event in 40% less time. However "loaded" is a funny term in the world of javascript driven websites and needs to be looked at more carefully.
I suspect that the author's referenced tool is reporting "fully loaded time" as the time that the last network event ended. AMP pages intentionally delay loading images below the fold to prioritize visible content. This results in some images loading later without impacting the user experience. For example, as I scrolled in the AMP page, the "Finish" time would move ahead to a new time as new images were loaded. With events like analytics triggers, looking at the time the last network event finished is typically a misleading metric and won't work correctly with most amp documents.
If you load filmstrips in Chrome's Performance Tab, you can see this more clearly. Filmstrips display what the page looked like at snapshots in time after loading starts. For my quick test with network throttling, the non-AMP page takes a little over 6s to finish reaching it's final state and the AMP page takes about 2.2s. So AMP here is nearly 3x faster as the user would perceive it on similar connection speed.
You can even go so far as to have the cars soak up the capacity. If you have a 2kW capacity circuit in the house, you can have the car drop it's draw as the fridge compressor clicks in.
So, if you zone housing, eventually the cost of servicing that housing exceeds the tax revenues from it, and there is little you can do to avoid that process. If you zone businesses, you get sales tax and similar revenue from the workers. Financially, it's best to let your neighboring municipalities build homes for your workers.
There is also a backlash from locals who see higher density housing as the core cause attributed to most local issues: traffic, crime, overtaxed city services, etc. This is mostly an incorrect perception, but it's a persistent one.
These combine to prevent zoning for housing.
Take a look at the version of the doc which is served from the AMP cache: https://cdn.ampproject.org/c/s/lolware.net/2017/07/04/amp-bl...
I like to think of PageSpeed Insights like the output of a good linter. No linter is or can be perfect. The issues reported are good things to consider and are correct for the majority of times that they trigger, but not in all cases. This is one of those cases.
> CORS
The best fix here might be a more useful response in the dev console. Plenty of sites, especially on dev servers, don't have any CORS headers at all, so this does work in those cases. I'd still recommend one of the other validation methods which work fine with any CORS setup.
> Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript.
It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement.
However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files:
- The file loads with an async tag, so does not block rendering.
- The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users.
- If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.
- The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it.
> Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB.
All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc.
However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run.
Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth.
> you can still embed bloatey ads
True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads.
> you could dynamically build a page using a mustache template
True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html.
> The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation.
The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers.
> Paraphrasing: you can still load animations, large images, videos, etc.
True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading.
As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing.
The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared.
> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something.
It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.
- WSJ subscriber, where WSJ results should be present and maybe even get a ranking boost.
- User happy with paywall results, these results could be surfaced, with UI treatment indicating paywall.
- User uninterested in paywall results, where these results would be essentially removed.
The ranking between the latter 2 of these users could be a bit of a sliding scale too, rather than two distinct groups.
If universities started choosing applicants this way, we end up with a system that reinforces generational wealth, rather than lifting folks out of poverty. No easy solutions here.
The feature that does make social security progressive it's the diminishing contribution to benefit ratio a lifetime contributions increase.
Content ads, more or less, offer a fixed amount per impression. Sure, you might get a higher ad price for certain audiences than others, but this is related to topic, not the quality or cost of content.
If you only make a fixed amount per impression, the only business model low-cost content targeting a large audience. High quality (aka high cost) content, with a narrow interest audience needs a different model.
That different model is probably charging your reader. However, the moment you set up a paywall, the content disappears. Search engines will not suggest the content, feed readers can't access it, suggestion interfaces won't suggest it, etc. The content might as well not exist.
We don't need micropayments. We need a model where paywall content can be discovered. Systems whereby paywall content can be accessed by aggregators who then can suggest/search/deliver the content, but will not give the content to users without payment.
Total cost of ownership per month of the lease is $136. This is not counting KWHs or insurance, but includes all dealer costs, maintenance, and taxes. That's really hard to beat, other than buying some used vehicles. Lots of people spend more than that on fuel. These things are becoming affordable fast.
In my case, it's a 2nd car as my wife has a longer-range vehicle, so I'm fine that I can only use it for commutes and short trips.
I wanted to also mention that someone has built a handy web app for this kind of accounting that I use for similar trips at https://kittysplit.com/