The mobile browsers aren't the problem, the content (read: advertising) is the problem. Loading tons of ad images and tracking scripts is what makes it shitty.
This is, I believe, the more correct answer. There are so many different assets being delivered for every URL that it degrades the performance of desktop browsers, let alone mobile ones. HTTP/2 will help somewhat, but the overarching problem -- megs of cruft for every KB of content -- will remain.
It may not address the underlying issues with ad-based revenue for websites but at least for performance, it does make a big difference. Adblocking extensions have been available on other platforms for a while now and they're one of the main reasons I use Firefox as my primary mobile browser (albeit on Android instead of iOS). I can install the same Adblock Plus/Edge/etc. as the desktop version and immediately my little 5" screen is less cluttered, sites load faster, and I use less of my metered data plan.
Mobile web browsing without an ad blocker is miserable compared to the same thing on desktop. At least on the desktop you've probably got 1920x1080 or 2560x1440 screens, more processing power, more RAM, and a connection that offers more than 5GB of data each month. With mobile it's unbearable.
HTTP/2 isn't really going to help here. When you request five different CSS files and ten tiny images all from one server HTTP/2 does the equivalent of resource combining and helps a lot. The core issue with ads, though, is that no one trusts anyone else, and so all of those requests are going to different servers operated by different groups. Each of those servers will need its own connection with connection startup costs, and if the only purpose is to logging an access and maybe drop a cookie HTTP/2 won't help at all.
I agree, and the answer is that browsers should start shipping ad-blockers as a core feature and have them on by default. Tracking scripts and ad-spam should be treated the same way pop-up ads were treated 10 years ago.
I'm not saying kill advertising, but they could control it so that only a set number (2 or 3) ad scripts could run per page, not the 10-15 that is common nowadays.
I don't think that's the purview of browsers. Browsers are, however, responsible for maintaining a good user experience, so the length to which ads and tracking scripts, like pop-ups of years before, create a poor user experience the browser is right to take measures to block bad actors. I think limiting the number of ad/tracking scripts is a measure towards that.
You get what you pay for. Everyone wants everything to be free, therefore it is shit, and you shouldn't complain because if it's free you are not the customer. The advertisers are the customers.
Of course radio and TV are the same way. Mass media has always been a race to the bottom where producers race to out-do themselves on offering 'free' content of absolute minimum quality to occupy someone's time and get ad dollars. Listen to the absolute shit that fills free TV and radio airwaves.
Market dynamics are complex and the wants of the uncoordinated many are usually override by the wants of the coordinated few. For instance, Microsoft wanted core competencies of the competition to be free. So it developed Internet Explorer and bundled with every Windows system. The wants of the people weren't relevant.
You get what you pay for, therefore it is shit.
This implies a correlation between money and quality, which not always holds.
Some things are free and aren't shit. For example: Linux
Some things are made shit when they aren't free. For example: many scientific papers .
Things that require effort usually require an incentive. Money, specially paying for use, isn't the silver bullet of incentives.
It goes on to say it's the performance of mobile browsing and mobile networks that are a problem. Because ads and other cruft abuse resources which is more noticeable when your browser only holds 30kb cache and your network is 3G.
How is Google Contributor working? I could use it with an US credit card (even though I live in Brazil), but I am still very afraid of enabling it, disabling my uBlock for Google, being tracked and continuing to see most ads, specially the most obnoxious ones.
However, I believe the idea to be a very good one. If Google guaranteed no ads at all, on their site or in other site, I would compromise giving them this tracking, as the their interests on my personal data interests would likely change if the commercial part of the deal is out of the table. However, this demands no adverts at all, and no selling of personal information at all. Hard to see Google going for it.
While Google Contributor is a great first step (currently i'm using it with a $7 a month contribution), it doesn't really help that much.
It only applies to adsense, and they already have pretty strict rules on ads that make them pretty painless (only 3 per page on desktop, 2 per page on mobile, and some pretty strict guidelines on where they can be placed and how they can be shown).
Still, i see the "Thanks for being a contributor" pretty frequently, and the ability to not only see an overview of where and how much of my money is going places, but also to "disable" certain sites from getting any of my contributor money is exactly what i've been wanting for a long time.
So this won't help any websites which already use "excessive" ads as they aren't (or shouldn't be) using adsense, but instead are using more invasive networks.
Building ad support into the browser sounds like a great idea, except it's not strategically a good idea for any of the browser vendors. There's a constant struggle between advertisers, publishers and browser/platform developers for data -- not to mention a huge conflict of interest with Google (and to a lesser extent Apple).
The reason ad networks are so bloated is because web advertising as it currently stands has a measurement problem: if I display an ad, I have no way of knowing if a reader even saw it. This is why you rarely see ads displayed below the fold; and when they are, they're wrapped in a bunch of JavaScript or Flash to ensure they're not tracking displays for ads that were never seen. Advertisers literally want pixel-level tracking of page scroll, mouse movement, etc. and they use all this bulky JavaScript to collect it. Do you think it's a good idea to let the browsers report this information? Because if not, the advertisers are going to inject as much JavaScript as they can to use every workaround to collect as much data as possible.
This also ignores the fact that Google is the head honcho of online advertising. Google can (and probably does) collect much of this information from inside Chrome. They would be violently opposed to sharing this data with their competition, because proprietary data like this enables them to charge a premium for ads they place. Advertising is all about proprietary data sources, and the moment something becomes commoditized it loses most of its value. Considering Google makes something like 95% of its revenue from its network of proprietary user data, they would never engage in any sort of browser ad placement unless it funneled money through them (which their competitors would never go for).
At the left are the advertisers, and the right is the end user. In between you can see so many boxes with lots of logos. The sheer number of companies is what contributes to so much of the ad "weight".
Even if the browser had some sort of overview, the players before wouldn't just hand over control. For example Verizon would want to control what happens to users on their network (and already do so).
This chart is the gold standard for describing the ad tech market, but I actually think it is a bit myopic with regards to the "full-stack" view. You're thinking of a strategic control point, and the networks aren't in as good of a position as you would think. Things like SSL limit their ability to perform segmentation via DPI -- but since browsers are the SSL termination point, it's not nearly as much of an issue. With security becoming more and more important and "SSL everywhere", the networks' ability to collect data from ad networks through DPI is disappearing.
Typically, strategic control points should be thought about in terms of their physical proximity to the user. That is, if it is a device that the user touches, that device and its software stack represents a potential control point. Currently, the devices aren't the control point (thanks to Google's Android strategy), but the OS and by extension the browser is much more promising. If I had to describe a value chain, it would look like this (you can replace "browser" with "app", though with a much more limited scope):
User > Device > OS > Browser > Network > Publisher > Ad tech (most of what is shown in the chart above) > Advertiser
Basically, every company on this chart is trying to disintermediate every other company to the right and left of them. What we're left with is a reasonably efficient advertising marketplace that serves the needs of advertisers and publishers, but the tricks and methods used by advertisers are frustrating to users. The browser vendors have enormous control over what techniques can and can't be used to implement ad tech -- the reason Flash hasn't been removed entirely is because Flash-based tracking cookies offer far more information than the browser, especially with regards to video ads. Google hung on to Flash for a long time because of YouTube, but I think they've recently realized that if they can get Flash off of the web, it would hurt their competition more than it would hurt them.
I always wondered, why websites don't deliver ads integrated? Why Google Analystics can't use server-side data? I don't want my user to load any unnecessary JavaScripts, if all data is already available in nginx logs. Why should my user issue additional HTTP requests to Google Ads, when I can issue those requests at server-side (and they'll work faster, because server interconnectivity usually is very good) and deliver the single complete web page to user, with all ads included. Images might load faster from different hosts now, because browsers might restrict connection count to the single host, but in HTTP/2 era single host with single connection will work faster, so loading ad images from website server will be faster too.
The only difference is how easy to integrate ads to your site. Adding <script> tag is certainly easier than tweaking server-side logic or setting up nginx module. But it doesn't matter for big sites, yet they employ the same technique, making their sites unnecessary slow, especially for low-bandwidth users.
Google does not trust sites as many will fake their numbers to make more from Ads. If Google directly talks to each user's IP it's much easier for Google to tell that each page load was a real page load.
In your approach they are stuck trusting the webserver and it's far easier to add fake page loads, this is somewhat less of an issue with PPC, but there are still issues.
On top of that advertisers want to track each user which is far simpler when it's a separate HTTP request.
Not to mention the algorithms and business behind which ad to serve where and when are worthy of an entire field of study all by themselves.
Read the Advertising chapter in Mining Massive Datasets - http://www.mmds.org/ - and then figure out how you'd tackle those problems when you distribute them onto other people's servers.
> Google does not trust sites not to fake their numbers. If Google directly talks to each user IP it's much easier for Google to tell that each page load was a real page load.
If we're talking about Google Analytics, the user wants to view correct data in the first place.
> In your approach they are stuck trusting the webserver and it's far easier to add fake page loads, this is somewhat less of an issue with PPC, but there are still issues.
That's true.
> On top of that advertisers want to track a user which is far simpler when it's a separate HTTP request.
Webserver is supposed to send all necessary user's data to Google server (like IP, UA, Cookies) and Google might ask Webserver to set google-specific Cookie.
Cross-site tracking won't be possible, that's true. Probably some standard could be invented for that (e.g. Google signs global inter-site cookie to deliver to the user and browser should send this cookie to all Google-enabled sites). That'll make easier for user to disable tracking, if user wants that.
My point is that if Google doesn't want to improve their scheme, may be other advertising company will want to improve that scheme. And Google might realize that users will follow that company, that's what competition is about.
And probably Google itself is not the evil here. There are many other ad networks with huge banners and slow loading scripts.
Google Analytics had a self-hosted version, or more specifically Google Analytics was a self-hosted solution when it was Urchin before Google acquired it.
You could still get the self-hosted version for a price until Google killed it in 2012.
The reason Google doesn't want you to do this is simple: they want the data.
The Google Analytics Measurement Protocol allows developers to make HTTP requests to send raw user interaction data directly to Google Analytics servers. YMMV, I haven't tried it yet but want to hook it into our app asap.
Forget about mobile, modern web sites suck everywhere, desktop included.
Giant banners that stick along the top of the screen. Infinite scrolling that (1) leaves all elements loaded, severely limiting the amount you can scroll, and performance as you scroll deeper and (2) breaks the back button and (3) breaks bookmarking and link sharing. Click-interceptors that ruin the ability to command click to open in a separate tab. Shitty attempts at navigation transitions that ruin the Safari's built-in Back w/ swipe transition.
Not to even mention the ungodly amount of intrusive ads on many sites.
I've been seeing that more and more lately and GOD it's obnoxious. It suddenly feels like my phone is out of controls because things aren't 'moving' right. I don't know why they think it's a good idea either. On most sites it's way too fast and on a few it's slow as molasses.
At this point when I run into 90% of this stuff I switch to Reader mode in Safari, which also cures things like insane font sizes and pages that refuse to let you zoom in.
Reader mode not available for your site? I won't read it. If you want to go out of your way to make it hard to read (not just ads that distract, but ones that cover up or things like scrolling that break basic interaction) then you must not want me reading your content.
I feel the same way about ignoring content that is packaged in a user hostile manner. However, the sites that do it do not care whether you or I read the site, they only care about revenue, revenue, revenue. If they lose 85% of their audience but get better revenue, that's fantastic for them.
I don't advocate using the law to enforce web standards, but if websites all followed disabilities standards it would be pretty straightforward to strip out all of the extra stuff. You could just browse the web painlessly in Lynx.
It could be a lot worse. Misuse of HTML5 and WebGL could leave users wishing for Flash. Publishers are just scratching the surface for how poor web usability could be. Like really fucking bad. Prediction: we will see some hard sell porn sites make breakthroughs in this area first.
There is some humor in hitting a "mobile friendly" website and desperately requesting the desktop version because its such a pile of shit. Many newspapers have fallen in to this trap. Even companies that should know better, like AirBNB have had issues in the past (can't comment now because I haven't looked in a few months.) Ironically if your company is data driven and doing a lot of front end testing, your winning design that converts users in to app installs may be doing just so because it is broken.
As someone who has a decent number of users in developing countries I'll point out these problems compound themselves abroad. Users are on older phones, Android or Blackberry, broadband is limited, and resolutions are much lower. There are publishers and startups who are failing in other markets because their designers only test locally, may be not even on a real phone. You can't make the excuse that eventually everyone will have high DPI iPhones, because by the time they do, the first tier devices will be that much better and you will be developing for them instead.
> I don't advocate using the law to enforce web standards, but if websites all followed disabilities standards it would be pretty straightforward to strip out all of the extra stuff.
In the U.S, the Department of Justice is responsible for enforcing the Americans with Disabilities Act (ADA). The ADA does include language on web accessibility and the Dept of Justice has repeatedly signalled that it believes that that language applies to basically all publicly accessible websites.
They are working on a new rule to clarify that, but its release has been delayed until April of 2016. But in every case so far, their standard has been the Web Content Accessibility Guidelines (WCAG) 2.0 at Level A or AA. [1] So basically, right now it's looking like the law will in fact begin enforcing a web standard in the next year or two!
I don't remember what the number is, but mobile browser performance is a fraction of that of desktop browsers and the number hasn't changed much in the past 5 years.
This is worrisome to me because if it means we've tapped out on ARM performance then we need to look to a future without ARM on mobile.
I disagree. Mobile performance is fine; modern smartphones and tablets provide more than enough power. It's enough power to be able to churn through huge photo libraries and power surprisingly capable video NLEs and multitrack DAWs; why should any website ever need more power than that?
No, what we should pursuing much more fervently is browser engine optimization and more efficient JS. I've always been a strong supporter of baking more functionality found in commonly used JS libraries into JS itself (allowing aggressive optimization and reduction of number of libraries loaded) and while I may be wrong, I suspect that the web could benefit greatly from dependency sharing systems (if [lib] is already loaded from one source, don't try to load it again).
And of course, nothing will have as much impact as thoughtfully written JS. There needs to be a big push in the web community to take responsibility for performance because expecting browser developers and increasing hardware power to magically make everything OK isn't a solution.
Performance of which Safari? My biggest problem is that webviews in Facebook/Twitter use a UIWebView that doesn't have the Nitro JS engine. That absolutely hammers performance. If you have a lot of traffic coming from social and are testing in Safari proper, you're not testing in the environment your users are experiencing your site.
Apple have released the WKWebView but last I checked it has a number of bugs/errors that make it very difficult to use.
`WKWebView` has issues that made it untenable for use as a web browser last year, but there's nothing I'm aware of preventing its use for common in-app browsers.
It's AMAZING what a difference that can make, which really just shows how terribly written the JS on most sites is. It's often faster when pulling up an article in Twitterrific to have it open in Safari than to try to let it finish 'loading' in the web view.
No page should have so much JS (for ads and such) that without a hyper-fast JS engine it feels like it stopped loading.
which really just shows how terribly written the JS on most sites is
IMO, not necessarily. I was playing around with a D3 visualization that ran terribly within the UIWebView, there was really very little I could do about it.
But I won't argue that plenty of sites are overusing JS for rendering etc when they should be leaving that to static HTML.
Visualizations and demos and games and such make sense to me. But when the page has finished loading and looks like every other page of text with some image ads? Yeah you didn't need that JS did you.
UiWebView from fb/tw is really the biggest pain point on iOS when most of your traffic come from social media.
The only way I foud to escape it is to add a little bit of js to perform the following :
- test if the browser is an UI webview
- if yes redirect to ftp://(mysite).com
- safari will intercept this uri scheme and try to open the ftp link.
- serve an html page over ftp than just contain a small js script that redirect to the original url.
- the user is back to the original page but on safari and can now browse more modern web content (webgl games?)
This is tedious, broke the back button and glimps for half a seconds beforebuser can access my content. I will loved to not have to do it anymore.
UiWebView from fb/tw is really the biggest pain point on iOS when most of your traffic come from social media.
The only way I foud to escape it is to add a little bit of js to perform the following :
- test if the browser is an UI webview
- if yes redirect to ftp://(mysite).com
- safari will intercept this uri scheme and try to open the ftp link.
- serve an html page over ftp than just contain a small js script that redirect to the original url.
- the user is back to the original page but on safari and can now browse more modern web content (webgl games?)
This is tedious, broke the back button and glimps for half a seconds beforebuser can access my content. I will loved to not have to do it anymore.
... reading content on the mobile web can be less than ideal ...
That must the understatement of the year for the last five years. In fact, my Mobile Safari feels so broken (functionally, not performance-wise), I do mobile browsing only in an emergency.
Opera Mobile works, but sadly it's only available for Android. Only mobile browser that can handle full desktop sites without excessive horizontal scrolling, most of the time well enough desktop versions become preferable to "mobile" versions. Not to be confused with rather useless Opera Mini.
When I was last on iOS, I actually preferred Opera Mini. This was before Chrome, etc. were options and I have barely used iOS since then, but it was much faster, and had saner zooming.
I think what we need to make the web better are new ways of advertising. Sites like The Verge depend on ads, and currently that means lots of requests and extra js which both hurt the experience, as the author pointed out. Which leads to people browsing with things like ad blockers and Ghostery. I'm no expert on the subject, but there are certainly better ways to advertise than plastering sites with videos and giant banners.
As someone pointed out on Twitter, the reason The Verge and others are getting upset about "Mobile Safari" may be Apple's upcoming introduction of Safari Content Blockers, which would deprive them of advertising revenue. By badmouthing Safari (for something which isn't its fault), it can get people to switch to Chrome, which won't have ad-blocking on iOS.
I think that argument could be made without the conspiratorial angle, too. The Verge and others are probably grumpy about Safari because of that, and that in turn makes them more eager to bad-mouth it.
Regardless of whether or not most developers are upset about Safari's performance, most users would very strongly welcome a faster web browser. I'm pretty sure speed, stability, and ease of use are the main reasons Chrome is such a popular browser on the desktop. The thing is, it is not really that much faster than other browsers. However, even that small difference feels like a big difference and wins over many users. I'm sure many developers are aware of this. You can't get away from the fact that only allowing one browser rendering engine has some strong disadvantages and is one of if not the biggest disadvantage of using iOS.
> I'm pretty sure speed, stability, and ease of use are the main reasons Chrome is such a popular browser on the desktop.
Unfortunately they don't seem to care about efficiency. I know numerous people who have given up on Chrome (on Mac, don't know if Windows is better) because using Safari keeps the laptop's fans from spinning up and gives them an extra few hours of battery life.
That is one of the main reasons that I stick to firefox and safari for my browsing needs. The extra battery goes a long way (and chrome's poor tab handling).
For me the greatest limitation of mobile safari is the lack of WebRTC. Being able to bring and develop communication focused applications via a server side application would be amazing. The web platform has countless advantages to a native only environment.
1. rapid application deployment
2. immediate fixes to address real world issues.
3. easier a/b testing push tests remotely and easily collect these updates.
4. it's freaking easy to develop html/css/js applications - the browser vendors put a lot of time an energy in testing html/css/js rendering over a huge number of use cases
5. it's cross platform it runs in more than mobile safari.
IndexedDB is another one - if mobile safari or rather just safari had a working implementation of IndexedDB some interesting offline applications would be possible.
I find it interesting that no one picks on the phone being as fast as the laptop. Its not exactly true either and the phones are fast but not that fast.
Its a mix of safari perf, Network latency, memory, cpu/bus... And of course the biggest contender, the website itself.
In the past a slow app would be blamed for being poorly written. Now its as if you cant write poor js.
Recently I had to develop a video overlay in html5 - a text that tweens together with a html5 video.
Wasn't a problem with performance - even an aged iPad1 was able to fluently do all the movement, translations etc.
What forced us to choose the ridiculously expensive option of server-side prerendering with After Effects was that iOS Safari is unable to play a HTML5 video inline on iPhones and thus cannot be overlaid with a Canvas.
I ran into the same issue trying to use a video as a texture in WebGL. Worked beautifully on desktop, mobile and even in an iOS UIWebView with inline video allowed. But in Safari? Nope.
I do get the reasoning why it was done when the iPhone 1 came out, but come on. Everyone ends up using animated GIFs instead, which just chew up more bandwidth.
64 comments
[ 2.0 ms ] story [ 114 ms ] threadMobile web browsing without an ad blocker is miserable compared to the same thing on desktop. At least on the desktop you've probably got 1920x1080 or 2560x1440 screens, more processing power, more RAM, and a connection that offers more than 5GB of data each month. With mobile it's unbearable.
I'm not saying kill advertising, but they could control it so that only a set number (2 or 3) ad scripts could run per page, not the 10-15 that is common nowadays.
Well, I do say kill advertising :)
https://news.ycombinator.com/item?id=9961761
Of course radio and TV are the same way. Mass media has always been a race to the bottom where producers race to out-do themselves on offering 'free' content of absolute minimum quality to occupy someone's time and get ad dollars. Listen to the absolute shit that fills free TV and radio airwaves.
Market dynamics are complex and the wants of the uncoordinated many are usually override by the wants of the coordinated few. For instance, Microsoft wanted core competencies of the competition to be free. So it developed Internet Explorer and bundled with every Windows system. The wants of the people weren't relevant.
You get what you pay for, therefore it is shit.
This implies a correlation between money and quality, which not always holds.
Some things are free and aren't shit. For example: Linux
Some things are made shit when they aren't free. For example: many scientific papers .
Things that require effort usually require an incentive. Money, specially paying for use, isn't the silver bullet of incentives.
However, I believe the idea to be a very good one. If Google guaranteed no ads at all, on their site or in other site, I would compromise giving them this tracking, as the their interests on my personal data interests would likely change if the commercial part of the deal is out of the table. However, this demands no adverts at all, and no selling of personal information at all. Hard to see Google going for it.
It only applies to adsense, and they already have pretty strict rules on ads that make them pretty painless (only 3 per page on desktop, 2 per page on mobile, and some pretty strict guidelines on where they can be placed and how they can be shown).
Still, i see the "Thanks for being a contributor" pretty frequently, and the ability to not only see an overview of where and how much of my money is going places, but also to "disable" certain sites from getting any of my contributor money is exactly what i've been wanting for a long time.
So this won't help any websites which already use "excessive" ads as they aren't (or shouldn't be) using adsense, but instead are using more invasive networks.
The reason ad networks are so bloated is because web advertising as it currently stands has a measurement problem: if I display an ad, I have no way of knowing if a reader even saw it. This is why you rarely see ads displayed below the fold; and when they are, they're wrapped in a bunch of JavaScript or Flash to ensure they're not tracking displays for ads that were never seen. Advertisers literally want pixel-level tracking of page scroll, mouse movement, etc. and they use all this bulky JavaScript to collect it. Do you think it's a good idea to let the browsers report this information? Because if not, the advertisers are going to inject as much JavaScript as they can to use every workaround to collect as much data as possible.
This also ignores the fact that Google is the head honcho of online advertising. Google can (and probably does) collect much of this information from inside Chrome. They would be violently opposed to sharing this data with their competition, because proprietary data like this enables them to charge a premium for ads they place. Advertising is all about proprietary data sources, and the moment something becomes commoditized it loses most of its value. Considering Google makes something like 95% of its revenue from its network of proprietary user data, they would never engage in any sort of browser ad placement unless it funneled money through them (which their competitors would never go for).
At the left are the advertisers, and the right is the end user. In between you can see so many boxes with lots of logos. The sheer number of companies is what contributes to so much of the ad "weight".
Even if the browser had some sort of overview, the players before wouldn't just hand over control. For example Verizon would want to control what happens to users on their network (and already do so).
Typically, strategic control points should be thought about in terms of their physical proximity to the user. That is, if it is a device that the user touches, that device and its software stack represents a potential control point. Currently, the devices aren't the control point (thanks to Google's Android strategy), but the OS and by extension the browser is much more promising. If I had to describe a value chain, it would look like this (you can replace "browser" with "app", though with a much more limited scope):
User > Device > OS > Browser > Network > Publisher > Ad tech (most of what is shown in the chart above) > Advertiser
Basically, every company on this chart is trying to disintermediate every other company to the right and left of them. What we're left with is a reasonably efficient advertising marketplace that serves the needs of advertisers and publishers, but the tricks and methods used by advertisers are frustrating to users. The browser vendors have enormous control over what techniques can and can't be used to implement ad tech -- the reason Flash hasn't been removed entirely is because Flash-based tracking cookies offer far more information than the browser, especially with regards to video ads. Google hung on to Flash for a long time because of YouTube, but I think they've recently realized that if they can get Flash off of the web, it would hurt their competition more than it would hurt them.
The only difference is how easy to integrate ads to your site. Adding <script> tag is certainly easier than tweaking server-side logic or setting up nginx module. But it doesn't matter for big sites, yet they employ the same technique, making their sites unnecessary slow, especially for low-bandwidth users.
In your approach they are stuck trusting the webserver and it's far easier to add fake page loads, this is somewhat less of an issue with PPC, but there are still issues.
On top of that advertisers want to track each user which is far simpler when it's a separate HTTP request.
Read the Advertising chapter in Mining Massive Datasets - http://www.mmds.org/ - and then figure out how you'd tackle those problems when you distribute them onto other people's servers.
If we're talking about Google Analytics, the user wants to view correct data in the first place.
> In your approach they are stuck trusting the webserver and it's far easier to add fake page loads, this is somewhat less of an issue with PPC, but there are still issues.
That's true.
> On top of that advertisers want to track a user which is far simpler when it's a separate HTTP request.
Webserver is supposed to send all necessary user's data to Google server (like IP, UA, Cookies) and Google might ask Webserver to set google-specific Cookie.
Cross-site tracking won't be possible, that's true. Probably some standard could be invented for that (e.g. Google signs global inter-site cookie to deliver to the user and browser should send this cookie to all Google-enabled sites). That'll make easier for user to disable tracking, if user wants that.
My point is that if Google doesn't want to improve their scheme, may be other advertising company will want to improve that scheme. And Google might realize that users will follow that company, that's what competition is about.
And probably Google itself is not the evil here. There are many other ad networks with huge banners and slow loading scripts.
You could still get the self-hosted version for a price until Google killed it in 2012.
The reason Google doesn't want you to do this is simple: they want the data.
https://developers.google.com/analytics/devguides/collection...
When I open an article I am really looking for original content, not some "I disagree with this other dude" evangelism.
Giant banners that stick along the top of the screen. Infinite scrolling that (1) leaves all elements loaded, severely limiting the amount you can scroll, and performance as you scroll deeper and (2) breaks the back button and (3) breaks bookmarking and link sharing. Click-interceptors that ruin the ability to command click to open in a separate tab. Shitty attempts at navigation transitions that ruin the Safari's built-in Back w/ swipe transition.
Not to even mention the ungodly amount of intrusive ads on many sites.
And God help you if you have flash enabled.
At this point when I run into 90% of this stuff I switch to Reader mode in Safari, which also cures things like insane font sizes and pages that refuse to let you zoom in.
Reader mode not available for your site? I won't read it. If you want to go out of your way to make it hard to read (not just ads that distract, but ones that cover up or things like scrolling that break basic interaction) then you must not want me reading your content.
It could be a lot worse. Misuse of HTML5 and WebGL could leave users wishing for Flash. Publishers are just scratching the surface for how poor web usability could be. Like really fucking bad. Prediction: we will see some hard sell porn sites make breakthroughs in this area first.
There is some humor in hitting a "mobile friendly" website and desperately requesting the desktop version because its such a pile of shit. Many newspapers have fallen in to this trap. Even companies that should know better, like AirBNB have had issues in the past (can't comment now because I haven't looked in a few months.) Ironically if your company is data driven and doing a lot of front end testing, your winning design that converts users in to app installs may be doing just so because it is broken.
As someone who has a decent number of users in developing countries I'll point out these problems compound themselves abroad. Users are on older phones, Android or Blackberry, broadband is limited, and resolutions are much lower. There are publishers and startups who are failing in other markets because their designers only test locally, may be not even on a real phone. You can't make the excuse that eventually everyone will have high DPI iPhones, because by the time they do, the first tier devices will be that much better and you will be developing for them instead.
In the U.S, the Department of Justice is responsible for enforcing the Americans with Disabilities Act (ADA). The ADA does include language on web accessibility and the Dept of Justice has repeatedly signalled that it believes that that language applies to basically all publicly accessible websites.
They are working on a new rule to clarify that, but its release has been delayed until April of 2016. But in every case so far, their standard has been the Web Content Accessibility Guidelines (WCAG) 2.0 at Level A or AA. [1] So basically, right now it's looking like the law will in fact begin enforcing a web standard in the next year or two!
[1] http://www.w3.org/TR/WCAG20/
If that's the case, would anyone care to put forward a defence of why they do this to their users?
http://pitchfork.com/features/cover-story/reader/bat-for-las...
It's a fancy web page, but it's still just a page that respects the content and doesn't try to look like an app.
This is worrisome to me because if it means we've tapped out on ARM performance then we need to look to a future without ARM on mobile.
No, what we should pursuing much more fervently is browser engine optimization and more efficient JS. I've always been a strong supporter of baking more functionality found in commonly used JS libraries into JS itself (allowing aggressive optimization and reduction of number of libraries loaded) and while I may be wrong, I suspect that the web could benefit greatly from dependency sharing systems (if [lib] is already loaded from one source, don't try to load it again).
And of course, nothing will have as much impact as thoughtfully written JS. There needs to be a big push in the web community to take responsibility for performance because expecting browser developers and increasing hardware power to magically make everything OK isn't a solution.
Apple have released the WKWebView but last I checked it has a number of bugs/errors that make it very difficult to use.
No page should have so much JS (for ads and such) that without a hyper-fast JS engine it feels like it stopped loading.
IMO, not necessarily. I was playing around with a D3 visualization that ran terribly within the UIWebView, there was really very little I could do about it.
But I won't argue that plenty of sites are overusing JS for rendering etc when they should be leaving that to static HTML.
This is tedious, broke the back button and glimps for half a seconds beforebuser can access my content. I will loved to not have to do it anymore.
This is tedious, broke the back button and glimps for half a seconds beforebuser can access my content. I will loved to not have to do it anymore.
That must the understatement of the year for the last five years. In fact, my Mobile Safari feels so broken (functionally, not performance-wise), I do mobile browsing only in an emergency.
This is hypothetical, of course.
Unfortunately they don't seem to care about efficiency. I know numerous people who have given up on Chrome (on Mac, don't know if Windows is better) because using Safari keeps the laptop's fans from spinning up and gives them an extra few hours of battery life.
1. rapid application deployment
2. immediate fixes to address real world issues.
3. easier a/b testing push tests remotely and easily collect these updates.
4. it's freaking easy to develop html/css/js applications - the browser vendors put a lot of time an energy in testing html/css/js rendering over a huge number of use cases
5. it's cross platform it runs in more than mobile safari.
IndexedDB is another one - if mobile safari or rather just safari had a working implementation of IndexedDB some interesting offline applications would be possible.
Its a mix of safari perf, Network latency, memory, cpu/bus... And of course the biggest contender, the website itself.
In the past a slow app would be blamed for being poorly written. Now its as if you cant write poor js.
Wasn't a problem with performance - even an aged iPad1 was able to fluently do all the movement, translations etc.
What forced us to choose the ridiculously expensive option of server-side prerendering with After Effects was that iOS Safari is unable to play a HTML5 video inline on iPhones and thus cannot be overlaid with a Canvas.
Fuck you very much, Apple.
Define "had to"
I do get the reasoning why it was done when the iPhone 1 came out, but come on. Everyone ends up using animated GIFs instead, which just chew up more bandwidth.