241–250 of 261 posts
Earlier quoted context omitted.
http://www.imagemagick.org/script/convert.php You can insert ImageMagick somewhere into your production pipeline. It's excellent software.
Well other than being riddled with security holes. It has its place, but never use it on user-submitted images.
https://www.alexkras.com/google-may-be-stealing-your-mobile-...
Hey, this is Malte and I am the tech lead of the AMP Project for Google. While I work on the AMP open source project, I did check back with the Google Search team that is more directly responsible for most of the points mentioned in the post. I personally find it very important to respond, because “stealing traffic” is literally the opposite of what AMP is for. The original idea behind AMP was to allow content to be distributed to platforms (such as Google, Twitter and Pinterest) in a way that retains branding and monetization control for the publisher. AMP traffic is the publisher’s traffic. Period.
I also realize that “just turning on the WordPress plugin” doesn’t get you there. Especially if a WordPress installation is heavily customized, one will need to invest similar effort to get the AMP pages to the same quality. While this may be a lot of work, this is by design: We recommend to really optimize AMP pages and fine tune them to your needs. AMP is not a templated format for that reason. While neither the AMP project, nor Google are directly responsible for the WordPress plugin, the AMP open source project working closely with the authors of the plugin(s) to improve the quality and scope. AMP is very flexible and should be capable of providing most features of a typical WordPress site, but this flexibility also requires respective work to make custom plugins and development show up in the AMP version.
Getting more literal about “stealing traffic”: there are audience measurement platforms that attribute traffic to publishers. They might in theory wrongly attribute AMP traffic to the AMP Cache (not Google) rather than to a publisher because they primarily use referrer information. That is why we worked with them in worldwide outreach to get this corrected (where it was a problem), so that traffic is correctly attributed to the publisher. If this is still a problem anywhere, AMP treats it as a highest priority to get it resolved.
“Ask Google to give users an easy option to view the original post.”
Let us start by saying that we love URLs as much as everyone else, and we tried hard to make the AMP URL scheme as usable as possible given the technical constraints of web apps. We’re looking at ways to make the source link more discoverable and will update once that is done. AMP is super flexible in terms of how a publisher can direct traffic to their site. Typical ways to get to a publisher’s homepage (like clicking the logo) should just work and are in no way restricted. Also, make sure to check out amp-sidebar (https://ampbyexample.com/components/amp-sidebar/) for adding a menu to your AMP pages.
If you are not comfortable with traffic on your AMP pages, please do not publish AMP pages. Google Search has 2 types of AMP related features:
Normal search: AMP does not influence ranking. Your pages will appear in the same spot with or without AMP. AMP specific features (such as the “Top Stories Carousel”): For these features, we believe that AMP is the format that currently delivers the best possible user experience on the mobile web. That is because AMP allows for consistent speed, caching, pre-rendering, and enables swiping between full-length pages. This is a big deal for topics where there isn’t “that one best result” that a user might want to look at.
“Google takes away ad revenue on AMP pages”
AMP supports over 60 ad networks (2 of them are owned by Google) with 2-3 coming on board every week and makes absolutely no change to business terms whatsoever. There is no special revenue share for AMP.
“If Google cares so much about the mobile experience, why cover 15% of the small mobile screen with a fat bar at the top?”
The Android users might have already noticed that it is now scrolling out of the way and the same is coming soon for iOS (we’re just fighting a few jank issues in Safari). Similarly we’re spearheading a long term effort (https://github.com/bokand/NonDocumentRootScroller) to allow web apps to define how the address bar is hidden on scrolling. It looks like this will land in Chrome soon, providing even more space to web pages.
My biggest problem with AMP is I can never go directly to the source. AMP has buggy scrolling and can be quite annoying sometimes.
HTML is already fast, it's all the extra resources added that makes pages slow. For publishers, the reason sites are slow is a combination of ad revenue pressure, poor tech skills, lack of time and focus on other priorities like producing content in a saturated market. This is changing slowly so that UX is more important but creating an entirely new proprietary system that only takes time away from the main site (and just affects mobile) is not the right answer.
More interestingly, the #1 most used adserver on the planet is Google's own DoubleClick - which means they could singlehandedly make all sites (desktop + mobile) faster by implementing better tech in their own stack.
"I hope I am not being too hard on Google." -- no, the author is being very, very nice. Google has a strong business interest in users never going to other sites. Between AMP & voice search, the future is going to be very rough for businesses that rely on free search traffic. In practical business terms I would strongly suggest website owners build ultra-light versions of their sites. If you have international aspira…
Web publisher here...the real problem is twofold: - Display advertising makes the web suck; while display ads fund a large share of general market content sites, from a purely technical perspective they kill site performance. - All major market participants suck equally, rendering no alternatives for end-users or advertisers to defect to; this inherently limits any incentive for real change. AMP / Mobile index (new d…
I don't (and never will) use AMP and I feel that it is patently unfair to penalize pages for not using some non-standard tech. Google should index the web fairly, not make use of their tech a factor. Webpage speed is a fair measure (and I really wouldn't know what I could do to make my pages any faster, AMP will not make a measurable difference). I would expect an un-biased search engine to rate pages with and withou…
In my opinion, the problem is that your version of unbiased doesn't add much value to a user (and is actually biased for the website-owners). For example, SourceForge started adding a lot of misleading 'Download' buttons all over their page, and they might ask the same thing about 'an unbiased ranking' (Google's always been criticized for being the 'Web Police'). As a user however, I'd want Sourceforge's rankings go…
- whitelisting (AMP bolt); OR
- blacklisting (down-rankings)
So now it depends on our perspective, is the web default good or bad? default good means blacklisting & vice-versa
Alternatively, maybe DDG can do a blacklisting of sites based on some criteria (bad-practice / malicious / content-farm / etc... )
Actually having the site served from the same, already-open, probably pre-fetched connection, already open browser is great for the user. It even has the advantage of loading inside the Google App, where no adblocking exists, so it might even be good for publishers. Yes, there's no discovery if you don't design for that, user will just bounce.
> having the site served from the same, already-open, probably pre-fetched connection So, the bottleneck is really the connection setup time? Seems to me, that http2 largely solves that problem, while html already supports prefetch. Don't kid yourself, the goal here is a better web locked into the google ecosystem .
It might be locking you in the Google ecosystem, but the project is open source, and if there wasn't a monopoly in search/ads it wouldn't be an issue…
Earlier quoted context omitted.
How do you suggest publishers who are dependent on traffic from Google cope with AMP in the short-term? It seems like there is no way to compete with AMP-enabled content on Google ranking except by adopting AMP.
Stop using amp and find other ways to optimize and minifity their websites for mobile? Foundation has the ability to include only the components you want if you build it using SASS and by including/minifiying the individual Javascript files during your build process. The more I look at AMP the more I absolutely hate it. This is just another thing to make me not want to use it. If Google points to a site, they should…