back to article Google and pals launch Accelerated Mobile Pages project

Alphabet's ads, search and cloud subsidiary Google has announced an open source project it hopes will speed web page load times on mobile devices: Accelerated Mobile Pages. The Accelerated Mobile Pages (AMP) project is driven by Google, with help from major publishers and the BBC. Early adopters include Twitter, Pinterest, …

  1. msknight

    Dumb, dumb, DUMB.

    If they want to go after something important, how about slapping web developers on the wrist, who fail to optimise their graphics. THAT is what kills web pages for me on mobile.

    When I designed pages in the 90's, it was essential that we optimised graphics for the 56k modem. Now it's important for a morphed version of the very same reason.

    Going after device performance improvements when processing power and RAM on mobiles is increasing all the time, just seems ludicrous to me. Javascript allows a lot of flexibility regarding menu structures and is relatively easy for a noob to pull off. There is the potential here that they could lock people out of web design if they're not careful ... by including something that is obvious to them, but won't be so obvious to someone coming in fresh.

    1. msknight

      Re: Dumb, dumb, DUMB.

      And there's something else here. Design and programming are two different skills. I'm better at the latter than the former. But right now, designers can get a foot in the door of coding enough to make their designs happen.

      If techies re-define stuff in a way that closes that door, then we're going to lose some great designers, because they can't get to grips with the coding necessary. And don't anyone dare say WYSIWYG.

      They've got to be very damn careful about what they do here. There's a lot of positive potential, but also a massive potential to muck it all up.

    2. Alister

      Re: Dumb, dumb, DUMB.

      I agree with you about web optimisation of graphics, however, I don't agree with this sentence:

      Javascript allows a lot of flexibility regarding menu structures and is relatively easy for a noob to pull off. There is the potential here that they could lock people out of web design if they're not careful

      To suggest that removing Javascript would lock people out of web design is nonsense, in my view. Like any programming language, If you want to code web sites, you should learn how to do it correctly, not just take easy shortcuts.

      There are a lot of badly written websites out there because cutting and pasting chunks of Javascript is easy, instead of taking the time to design and build the functionality properly.

      1. msknight

        Re: Dumb, dumb, DUMB.

        My point is that learning to do the coding properly will be difficult for many of the designers. Doing both good design and good coding is not easy. I can code, but my design skills are the pits.

        To my mind, it's like asking painters to become experts in manufacturing their paints. We're going to lose more than we gain, IMHO.

        1. Dan 55 Silver badge

          Re: Dumb, dumb, DUMB.

          Perhaps first we could think about getting rid of jquery et al, 75 external tracking scripts for ad networks hanging off a web page, and huge bandwidth-eating images (looking at you Reg) before we're forced to go back in time and suffer WAP again.

          Less is more.

          1. LucreLout

            Re: Dumb, dumb, DUMB.


            Perhaps first we could think about getting rid of jquery et al

            I agree. However, one of my more cowboy colleagues who labours under the misaprehension that 7 years experience is experienced enough not to listen to those with multiples of that, has determined that all sites should be made responsive and slick via jQuery. There's literally no talking to him about it, or why JavaScript is one of the biggest security risks an enterprise can permit.

            With the advent of node.js things have gotten worse still. Now he just wants to write html + js front ends for everything, whether it belongs in a browser or not, and have that talk to a js back end. There's literally no understanding of secure computing, EVAL() risks, threading issues, or maintainability. TDD is that other bloke who had an excellent adventure with Bill, apparently.

            1. dogged

              Re: Dumb, dumb, DUMB.

              @LucreLout - while I have some sympathy, TDD with Javascript is more than possible. Take a look at QUnit (and the headless phantom.js browser).

              Even easier and more sensible with Typescript.

          2. Blitheringeejit

            Re: Dumb, dumb, DUMB - @ Kubla Cant

            AJAX is a part of the problem, not the solution - at least in the way that some use it. Textboxes which execute an XMLHTTPREQUEST on every single bloody keypress are exactly what makes browsers feel slow and jerky.

        2. Guus Leeuw

          Re: Dumb, dumb, DUMB.

          Dear Sir,

          Isn't this what the new breed of techsavvy kids are supposed to fix? They should know all about software programming from primary school, and if that fails, they can later go on a 18 month course that teaches them all about coding...

          Ok ok ... I'm removing the tongue from the cheek.



        3. Grikath

          Re: Dumb, dumb, DUMB.

          "To my mind, it's like asking painters to become experts in manufacturing their paints."

          Amazingly, artistic painters see "Knowing How To Manufacture and Mix Pigments Into Paint" as an essential skill....

      2. kmac499

        Re: Dumb, dumb, DUMB.

        I hope this approach will kill 'Responsive Design' sites that fill my screens with oversized meaningless images and video previews; whilst stopping me from choosing a render that I find comfortable to read. Are you listening BBC...??? I thought not.

    3. Kubla Cant

      Re: Dumb, dumb, DUMB.

      1999 called - they want their web pages back.

      A major use of JavaScript these days is to build single-page applications (SPAs), where the markup remains substantially unchanged while data is sent back and forth using AJAX. Removing JavaScript will presumably mean reverting to the slow round-trips and page refreshes of yesteryear.

    4. Anonymous Coward

      Re: Dumb, dumb, DUMB.

      Ummmm, let's not forget production code with comments left in (Security Risk), un-min'd JS ..... I've said it before, and again .... bandwidth is cheap, except where it isn't. With today's data plans, who needs 5MB of JS because LAZY FUCKING DEVs are "that" lazy that they cannot clean up their code.

      I've seen MBs, and MBs and MBs of un-optimized code. Devs, get your shit together!!!!!

  2. Winkypop Silver badge


    Nephew of Jar Jar, new Star Wars film?


    --> Puts on spacesuit and steps outside..

    1. Notas Badoff

      Re: Janky

      Actually you're quite close likening this to jAr! jAr!, to wit:

      1. (slang) of poor quality, odd

      2. (jargon, computing, rare) Unresponsive (of a software application’s user interface), sluggish.

      Me, I'm waiting for El Reg to define what a "Web Vomponent" is. Maybe that's from another StarWars movie?

      "I used to bullseye vomponent rats in my T-16 back home. They're not much bigger than two meters."

      1. AbelSoul

        Re: define what a "Web Vomponent" is

        The part of a site that makes you puke?

        Perhaps I'd rather not find out.

        1. Anonymous Coward

          Re: define what a "Web Vomponent" is

          Web Components = more-bloated JS widgets, and more of them on every page. 'Cause it's easy-peasy, man!

    2. hatti

      Re: Janky

      Clone of Wanky

    3. dogged

      Re: Janky

      Janky is a pretty good word for it.

      Load, for example, any article from (let's pick a serious offender) The Verge. The page loads, the text loads, there are big holes where the pictures should be but who gives a shit, you can read the text, right?

      So you start reading. 6 seconds later BOOM you're at the top of the page because a graphic loaded. You swear and find the bit you'd got to and then BOOM another graphic, back to the top. Continue for probably another three pictures.


      1. Jason Bloomberg Silver badge

        Re: Janky

        Jerky and wanky. Very apt.

      2. Robert Grant Silver badge

        Re: Janky

        What Car? never stop resizing the page and jumping you around on mobile.

    4. JLV

      Re: Janky

      our side of the pond.


      (adjective) inferior quality; held in low social regard; old and delapidated; refers almost exclusively to inanimate material objects, not to people

      Urban Dictionary. 3000+ votes on first entry, so likely not a word made up by some basement dweller looking to improve his score on UD.

  3. Michael Thibault

    This AMP-HTML...

    Does it go to 11?

    1. king of foo
  4. Christian Berger

    If you want to optimize something, go for code size...

    ...both in the webpages and on the browser. More HTML/CSS/JS code, particularly on more domains, kills performance. Many web pages now load _much_ slower than full sized screenshots of them!

    More browser code means more bugs and makes it harder to optimize the browser.

    1. James 51

      Re: If you want to optimize something, go for code size...

      If we got rid of ads, particularly the video ones that automatically start and take over the phone's screen, that would be a good way to speed things up. Or just design the sites correctly in the first place. HTML/CSS could be used to optimise sites for mobile but they aren't. We could use the tools we have better rather than create new ones.

      1. eddiejp

        Re: If you want to optimize something, go for code size...

        I try to read The Independent every day, but it's becoming more and more difficult with auto-play video ads, full screen ads and so much jankiness that you lose your place at least a couple of times. Case study on how not to do it.

  5. Anonymous Coward
    Anonymous Coward

    Interesting. Probably won't help

    Today JavaScript is blazingly ridiculously fast. Added to that, Chrome/Firefox are rapidly mashing out newly standardised APIs which make common pathways magnitudes faster. For example doing image work in separate processes and scheduling it so the main-thread can wait for the promise to resolve while staying responsive.

    The DOM (and CSS parsing, layout, rendering, and all that jazz) is fast enough, but it's a massive foot-gun. More like a foot-RPG actually.

    The main problem with the web are the advert + tracker infestation. Advert code, social media buttons, and all that embedded cruft is like someone took all the web performance best-practices, and coded the exact opposite.

    The other is jQuery wielding hipsters hammering on the DOM, without a passing awareness of how browser's graphical subsystems work, and pulling down 100+ HTTP resources, because networks are magic.

    With CSS3 + requestAnimationFrame it's perfectly possible to add hipsterific features such as lightbox or image carousels which have native-like responsiveness.

    Will restricting features and managing the renderloop be enough to allow hipsters free-reign to sprinkle their shiny plug-ins, yet still perform like it was built by a front-end engineer who actually knew what they were doing? Either way, I'm sure the adverts will find a way to crash the party as always.

    1. ChrisLaarman

      Re: Interesting. Probably won't help

      1) I agree with this one.

      I'd like to add:

      2) Many web editors insert lots of code, even if one (well, me) tries to avoid this. It makes me stick with an obsolete one (and partly therefore with its operating system).

      3) On the other hand, aren't chances that rising transmission speeds will have resolved the latency before the cause has been fixed?

    2. breakfast Silver badge

      Also Android devices suck at JavaScript.

      In most places you are correct, but this seems to me to be a move they are making because JavaScript on Android is horribly sluggish. A modern Android device is an order of magnitude slower at rendering JavaScript than an equivalent iOS device - the Discourse team give a good idea of the state of play - and rather than solving the problem with the rendering stack they make the call to exclude JavaScript.

    3. The Indomitable Gall

      It's not just about speed though.

      The big issue with JavaScript isn't that it's slow, it's that it can easily break a page-viewing experience.

      JavaScript that tries to dynamically resize a page can flip you out of your reading position if you accidentally tilt your phone/tablet. Or worse -- there's something you can't quite read, so you zoom in for a closer look and BAM! -- the whole thing repaginates and you have no idea where you are or what you're doing.

      I don't think they're really trying to "kill" JavaScript, just trying to get people to use CSS for text formatting and keeping JavaScript to content.

    4. Dakuan

      Re: Interesting. Probably won't help

      React.js can help with some of that layout thrashing. The jsx syntax makes it easy for designers and front end engineers to work together effectively as well.

  6. Mike Bell

    Well, Google...

    The biggest mobile performance improvement I've seen in recent times is ad and tracker blocking on my iOS devices. Easy peasy.

    1. Anonymous Coward
      Anonymous Coward

      Re: Well, Google...

      Perhaps that's one of the reasons they're pushing this now, before adblocking gets entrenched on all iOS devices.

  7. Anonymous Coward
    Anonymous Coward

    "jarring experience of ??? scrolling...."

    Whatever the word means, In my experience page loading delays (crap connections excepted) are almost entirely due to Ad network response times.

    Killing javascript usually sorts that out : does this new way provide for a similar solution (he naively asks)?

  8. Anonymous Coward

    Another standard?

    Why bother. This one would suffice.

    1. Solmyr ibn Wali Barad

      Re: Another standard?

      Seconded. Kill JS and CSS as many times you fancy -stake them, behead them, burn them, slice them, in sequence and in parallel.

      But leave HTML alone.

      1. lurker

        Re: Another standard?

        "Seconded. Kill JS and CSS as many times you fancy -stake them, behead them, burn them, slice them, in sequence and in parallel."

        I see a lot of people ranting about removing JS without really appreciating what that would mean. Javascript (or more specifically some form of in-page access to XMLHttpRequest or a mechanism which does the same thing) makes a huge difference to how web applications are built. Without these, we would be back in the mid-to-late-90s world of having to press the big old HTML SUBMIT button in order to have anything on any web page change, and full-page reloads for any change to the page content.

        Speaking as someone who has been a web application developer since before either javascript or CSS were things, I'm not a huge fan of either javascript or CSS as a language or markup respectively, but that cat is most definitely out of the bag now and cannot be put back, and if they didn't exist similar functional alternatives (with their own sins and issues) would be required. I can only guess that people making these 'remove JS' requests are either wearing rose-tinted nostalgia glasses or lack understanding of how modern websites work.

        The project in question isn't talking about replacing javascript anyway, it works simply by using a single 'amp' javascript library to which it expects developers to stick with the goal of increasing performance.

        It's not going to work though, projects like these stem from a naive engineering desire to 'refactor the web', and big as google and it's little coalition of the willing may be, I can't see this succeeding.

        1. Solmyr ibn Wali Barad

          Re: Another standard?

          "Without these, we would be back in the mid-to-late-90s world"

          Uh-huh. Would that be a good thing or a bad thing? Rhetorical dig of course.

          HTML was quite sufficient for pure information delivery. Which in turn was/is sufficient for a numerable group of people. Those who fancy Web 2.0 interactive malarkery were a bit neglected back then. Not anymore.

          "of having to press the big old HTML SUBMIT button in order to have anything on any web page change and full-page reloads for any change to the page content"

          Good for a frequently changing page. But why use a metric fuckton of scripts in the otherwise static page? Often messing with the page loading, thus preventing people from getting to the information therein.

          Let's sum it up tidily: healthy use of whateverscript is tolerable, abuse is not. And it's usually the abuse that causes bad blood and angry comments.

    2. Shadow Systems

      Re: Another standard?

      Thirded, Fourthed, Fifthed, ... Hell, I'd upvote this to 9,001 if I could.

      As MsKnight said in the beginning of this forum, code for a 56Kb dial up modem & it'll be fast on damn near everything else you may ever encounter. Slow WiFi? Flaky DSL? Dial Up? Comcast "Broadband"? No matter *how* shitty your connection, the page will fly from server to visitor & render like a champ.

      Limit the graphics where possible, limit the annoying & assinine crufty bits, take out the stupidity with a chainsaw & extreme prejudice. The results will be a site that loads fast, clean, & will be the very definition of "Responsive".

      Basic HTML + DHTML can do a hell of a lot of things in a lot smaller code-size than the same bits "requiring" all the JS/CSS/cruft of today's supposedly "Responsive" web.

      If the Reg is any indication of speed, then I can only shake my head in dismay & disbelief over how far the web has fallen under the guise of "progress". Between all the ad servers trying to force their crap down the pipe, the back end code trying to load a bazillion widgets & plug ins, all the Social Media bits trying to auto-connect back to their respective MotherShips, et alia, by the time the *CONTENT* has loaded I've nearly forgotten why I was visiting the site in the first place.

      I've seen better, cleaner, & more responsive HTML from a Geocities site written by an AOLuser.


      1. Solmyr ibn Wali Barad

        Re: Another standard?

        "If the Reg is any indication of speed, then I can only shake my head in dismay & disbelief"

        El Reg isn't that bad. And still allows to read stuff without JS & plugins enabled in the browser.

        Now various support sites... Hit the page, grab some coffee. Look at the little cogwheels spinning. Have a sip. Still loading. One more sip. OK, here's the page. About f-ing time. There's a shedload of pages to go through, and only so much coffee one could ingest during the day.

        What did those scripts really do? Oh. So two people have shared the page in Facebook and one in Twatter. Zero for Reddit, Tumbler, ButtPlugg, Wankr and other 37 social connectors. Gee, it seems that this RAID driver page isn't as popular as one may have thought.

        No, I do not want to participate in the satisfaction survey. You really wouldn't like the answers.

        1. GrumpenKraut

          Re: Another standard?

          > No, I do not want to participate in the satisfaction survey. You really wouldn't like the answers.

          So you would participate if the was cattle prod over IP.

  9. thames

    Some Actual Numbers

    Firefox has some very good web developer tools. Here's a brief summary of what happens when the article web page is loaded: All sizes are in uncompressed form with an empty cache.


    194 requests

    2,974.75 KB


    Of that:

    HTML: 16 requests, 312.91 KB, 22.41 sec

    CSS: 2 requests, 72.37 KB, 0.35s

    JS: 44 requests, 1,564.87 KB, 14.48s

    Images: 124 requests, 1,024.60 KB, 20.45s

    Flash (I don't have Flash installed): 4 requests, 0 KB, 2.75s

    Other: 4 requests, 0 KB, 0.01s

    Of the HTML, here are the top domains in terms of size along with transfer time:

    Twitter 50.16KB 0.117s

    Facebook 62.54 KB 0.343s

    theregister 67.34 KB 0.208s

    For the Javascript, 181.13 KB of that came from

    For the images, the slowest were from the following domains: 0.34KB 5.110s 0KB 5.100s 0KB 10.096s

    A lot of the images seem to be very small tracking pixels. The same is true for the Javascript, much of it is very tiny (likely cookies). I currently have 50 cookies set just from loading the web page and logging into the forum. Only a couple of those belong to El Reg. Making visible page images smaller or active page Javascript more efficient isn't going to change anything that matters here because they're not the slow or large parts.

    Here's the thing that nobody seems to want to admit. Loading a web page from The Register isn't the slow part. That is very fast. It's also not very big. The problem is the ad networks. There are multiple ad bids, ads, tracking cookies and pixels, and other crap being loaded, often taking a very long time to do so (e.g 5 to 10 seconds each in several cases).

    Fiddling with The Register's web page isn't going to do anything significant. For Christ's sake, Twitter and Facebook load as much HTML to do their tracking buttons as El Reg does to display the actual article! And there's roughly 3 dozen other parties all loading their crap, very slowly, into the page.

    Fiddling with the size of the images won't help either. Many of them seem to be used as tracking elements by the ad networks, and even very tiny ones take forever to load if they come from an ad network rather than The Register.

    The real problem is that ads are served from third party networks, and those ad networks don't care if The Register is slow, it's not their site after all. Instead, they spaff loads of crap into the page, very, very slowly.

    The real solution isn't going to be fiddling with the margins. It's going to require restructuring the ad business in order to put the content publishers in control so they can optimise the entire process, just like they do in physical print publishing. I'm not sure how to do that, but I don't see any other way.

    1. Yeti

      Re: Some Actual Numbers

      Thanks for the analysis, I just added the three bastards trackers to my hosts file (twatter & FB are there already). The load time has improved tremendously.

    2. VinceH

      Re: Some Actual Numbers

      What tool do you use to get those stats? I have one which measures page load times, but the information it presents is very limited compared to that.

      1. TimR

        Re: Some Actual Numbers

        Firefox Tools>Web Developer>Network>Network

        1. VinceH

          Re: Some Actual Numbers

          "Firefox Tools>Web Developer>Network>Network"

          D'oh! I have it already, but never noticed that aspect of its features.


    3. JLV

      Re: Some Actual Numbers

      Not to mention that if you use NoScript, a typical website doesn't leave you with just the need to assess the trust to grant to their domain.

      No, you have to decide on the javascript of all those other domains. Some of which, like CDN-hosted jquery, are delivering core page-rendering or processing functionality for that site.

      1. Boothy

        Re: Some Actual Numbers


        That's one of my pet peeves, web sites using 3rd parties to provide core functionality.

        In my view, all core JS etc should be hosted on the same domain as the site you are looking at.

        1. JLV

          Re: Some Actual Numbers

          Agree, except...

          In a perfect world, the CDN would report that jquery-3.1.4.js, which El Reg just requested, is the same as jquery-3.1.4.js for wikipedia and return a code 304 or whatever spec says is best. And if it was a different CDN, it should report equivalence as well and sig-check that the js contents were indeed the same, security-wise.

          The whole ...for mobile...--css...--js...++<our_new_spec_> twaddle from FB or Google seems rather self-serving, rather than addressing core concerns with web. css is, from a dev, not designer, perspective, an amazingly powerful way to separate presentation from deeper, business/data layers in a text format.

          And everytime a better .js has been cooked up it's floundered, the asm stuff aside.

          Regardless, as, stated by thames, we have way too many moving pieces that scrape against each other.

  10. Your alien overlord - fear me

    Get rid of HTML - it's plain text. It should be in binary.


    <HTML> 6 characters replace with ASCII x01 80% improvement

    </HTML> 7 charcters, replace with ASCII x02 80% improvement

    So 13 characters replace by 2 bytes. Same for <HEAD>,<BODY> etc. etc.

    <SCRIPT language=javascript> huh? ASCII x03, 28 characters to 1 byte.

    This is how you get instant speed increase.

    1. FF22


      Nowadays every page is sent gzip-compressed down to the client, which means that all HTML plain-text keywords get replaced with very short binary tokens.

      Actually, using gzip compression is even better than a regular binary format, because it produces shorter codes and also compresses not only the markup keywords, but also the textual and data content embedded between them. Client-side parsing also barely consumes any time.

      So what you're recommending would be nothing more than a pointless exercise in futility.

      1. fnj
        Thumb Up

        Re: Pointless

        @FF22 - thank you for that bit of information. I was not aware of HTML compression at all. Everyone in the same boat, have a look at this.

    2. Dan 55 Silver badge

      That was WAP. It's not around today.

      1. Your alien overlord - fear me

        Really? Never did WAP. Can't see why that wasn't a winner then, and not just because I thought of it !!!!

    3. Anonymous Coward
      Anonymous Coward

      I think you just invented WAP.

    4. Anonymous Coward
      Anonymous Coward

      Gzipped HTML *is* binary you fool.

      HTML may be verbose, but after compression you'd gain very little by switching to a more succinct markup language.

    5. Anonymous Coward

      ... And one more thing. You're decades behind on your syntax.

      HTML5 specifies that many elements are optional and can be omitted. html, body, head, for example.

      "Language" attribute is non-standard; you mean "type" but that defaults to application/JavaScript so can be ommited 100% of the time. Same for stylesheets.

      HTML5 is very clean and compact already.

      Also, Google is working on brotli, a drop in replacement for gzip but with a higher compression ratio, AND it defines a standard dictionary of common HTML and JS fragments. That means chunks of your markup will cost less than a single byte to transmit.

  11. Anonymous Coward
    Anonymous Coward

    Improve web page loading and display?

    Eliminate all intrusive ads and all tracking code!

  12. Nuno trancoso


    And poor me thinking they actually wanted to get rid of the whole miserable thing and come up with a decent new one.

    The problem, deep down, is that this wretched combo has become an ungodly mess of a hack on a kludge on a workaround on a tech that wasn't meant to do any of it.

    Quite honestly, it's time to put it to rest and come up with something that's designed from the ground up to do what it's doing now.

    1. Alister

      Re: Sigh...

      The problem, deep down, is that this wretched combo has become an ungodly mess of a hack on a kludge on a workaround on a tech that wasn't meant to do any of it.

      On the contrary, I would say that HTML was designed to do exactly what it is doing every day on the web - to present information and media and provide linking between documents. Unfortunately, it's the way it is being implemented, and all the add-on cruft, that is the problem.

  13. Pascal Monett Silver badge

    Destroy Javascript, OK

    Given that 99.9% of all malware exists because of Javascript, I'm on board with that.

    But kill HTML ? Where's the technical justification for that ? HTML doesn't make page loads longer, HTML loads in a jiffy.

    No, the things that make pages load slowly is always the additional cruft from anywhere but the site you're loading. Meaning, of course, ads.

    And Google is not going to kill its revenue stream.

    So this is just another useless announcement for everyone but Google.

    You want fast-loading pages ? Block ads. Problem solved.

  14. tiggity Silver badge

    Have to agree with the majority of commentards here.

    quote:'web pages deliver a “jarring experience of janky scrolling and users needlessly losing their reading position.”'

    I have had that a lot, enabling various ad / js / flash blockers for the misbehaving web site has always fixed it

    The main hindrance to " documents would always load and render with reliable performance" in my browsing experience is ads & the mass of graphics / multimedia they often deploy

  15. knarf

    Html CSS and JavaScript (and libraries)

    The whole point of this is to retro fit a MVC pattern into a model that didn't support it natively and what you got was load everything even if you don't need it.

    Maybe the old classic ASP model of everything inline was not such a bad idea after all.

  16. Tom 7 Silver badge

    A bad workman always blames his tools

    and any new design method is going to need 20 years of debugging before its decided another new method is needed leaving the wrong people still doing to designing and adding the trackers and overloads of adds and stupid graphics.

    Javascript has a bad reputation cos its been written by idiots and the inexperienced. Whatever comes next will suffer the same problems but everyone will be inexperienced.

    Its not working out for Google because they are the main problem, followed by all the other parasites who wish to freeload on others web pages.

  17. cantankerous swineherd

    opera mini is your friend (most of the time)

  18. Mage

    Walled garden

    An attempt to banish the Internet from Mobile and have Walled gardens curated by Google?

    We have big screen fast phones

    Tablets recognised as Mobile devices.

    This is just stupid. Creating a two tier web. I design my pages such that content ONLY responds to browser window size. So a small desktop window gets identical content to a phone with a usable size and resolution screen. Anything else is re-inventing WAP or subverting the process of Web standards.

  19. Mage

    Web compression

    any text content (CSS, HTML, Javascipt) compresses well. Don't suitably configured servers and browsers already compress / decompress (helping mobile connections which is main bottle neck).

    The other issue is websites with content (JS, HTML, CSS, cookies, and images) pulled from umpteen 3rd party domains, often with no relevance to real content, or stupid design decisions (some content)

  20. thenim

    As if things weren't befuddled enough...

    Another bloody useless "standard". After 10 years, got back recently into doing some web thingymagick, and the sheer number of acronyms that have been added to the mess it was back then is janky!

    I wish there was a browser that would only load content from a single domain once the page loads - without having to install a gazillion different plugins and play wack-a-mole..

    After the ad slingers the biggest blame lies at the feet of trash sites like Buzzfeed and it's kin...

    (Side question, does anyone on this site actually follow the register on facepalm/twatter/tumbleweed-plus/rss?)

    1. Solmyr ibn Wali Barad

      Re: As if things weren't befuddled enough...

      "does anyone on this site actually follow the register on facepalm/twatter/tumbleweed-plus/rss?"

      Tumbleweed does ring a bell. One chap tried to follow it on a bike, but could not peddle fast enough. Oh, tumbleweed-plus was something else? Really ought to get my coat then.

  21. Mr Templedene

    Ironic then

    That the website for their new "project" scores so badly on their own speed test. 33/100 for mobile and 41/100 for desktop.

    I design websites for a living, and try and avoid javascipt as much as possible, Forget jQuery, I wont touch it

    Does that mean I don't have flashy wanky graphics plastered everywhere flashing and moving about? yes.

    Does that mean I don't have pop up windows blocking the site until you subscribe to the newsletter? yes.

    Do people coming to your site really want that crap? no

    People come to your website for information, not to be blasted by pretty pictures that are of limited relevance.

    1. myhandler

      Re: Ironic then

      Live in the past if you want, but Javascripted solutions can provide big benefits to functionallity.

      I don't have any crap on the sites I build but they do gain from JS when it's used appropriately

      1. Mr Templedene

        Re: Ironic then

        I didn't say I ignored it altogether. I use javascript when it's needed to improve functionality, if, and only if, there is no other way.

        I hate websites that bring in content using jQuery, what happened to building the page on the server and presenting it in one lump rather than having it reformat 5 or 6 times as the javascript brings in extra elements left right and centre. You're halfway through reading something then it jumps about and you lose track of what you are reading

    2. anody

      Re: Ironic then

      "Does that mean I don't have flashy wanky graphics plastered everywhere flashing and moving about? yes.

      Does that mean I don't have pop up windows blocking the site until you subscribe to the newsletter? yes."

      I love you already

  22. Craig Chambers

    Rinse and repeat

    Hmm, will this be more successful than previous attempts such as cHTML and even (shudder) WML with WAP?

  23. myhandler

    Jquery is a very useful tool.

    It's the dozens of plugins and scripts and things like sodding bootstrap that kill it all.

    You can't get rid of CSS - it works well (even if it's a bodge) - it needs updating but that will take the committees years.

    Just not lets end up in a "multiple standards" situation again

  24. Anonymous Coward
    Thumb Up

    To save mobile web, we must destroy...

    ...all non-text adverts and 'persuade' telcos to spend a bit of money on rolling out global fast and reliable 4G.

    That'd do it.

  25. Black Road Dude

    Pay Per Article vs Ads

    This may be a little off topic but a nod was made in this article as to the low amount of revenue generated from having adverts throughout.

    I have seen others suggest a advert free subscription version for a small fee which would cut out the middle man. This is a good option and I believe I would happily pay that small fee.


    Another option is to get paid or tipped per article this is a costly thing to do with the current payment methods available but as this is a techy site anyway utilising something like ProTip would potentially be an low cost option.

    Tipping per article would also allow the readers to show which articles are more favoured than others (although im sure this metric is already available internally at el reg) but also give the option of a financial calculation on what type of articles to write to maximize profits and reader happiness.

    I would be happy to tip this way although I know there are alot of digital currency haters in these parts.

    Icon as getting paid for a decent days work is not too much to ask.

  26. wikkity

    Use web components instead?

    I'd really love to.

    But first we'd need cross browser support, only chrome comes close natively supporting the required features, and they are incredibly slow to start using a polyfill like polymer. Even then we still need javascript, or are they saying js embedded in a web component ok?

  27. Stevie


    "Janky" obviously means "jittery and wanky".

    Tch! Kids!

    I'm older than nitrogen and I figured it out with no trouble.

  28. juice

    To save the village...

    We first had to destroy it.

    Let's be honest here (as several people already have been): yes, there's a lot of JavaScript and HTML cruft out there, with varying degrees of effectiveness and efficiency. And yes, optimising it would reduce CPU usage and maybe improve battery life a bit. But that's not the main problem for mobile devices - or indeed deskbound computers.

    Instead, it's all about the network traffic - both the size of the data and the lookups/translations required to determine the route to said data. And while HTML/JS contribute to the size of the data, I'd be willing to bet that for 90% of the websites out there, the binary data (i.e. images) far outweighs the size of the code.

    F'instance, on this very page... if I download it, there's about 1.35mb of data. 34kb of this is the page/content. There's another 180kb for jQuery and another 85kb of CSS.

    There's then around 500kb of what looks to be advertising-related JS and a further 1280kb of data spread across some 120 images. And that all needs to be cached, decompressed and generally tinkered with to get the page rendered.

    And that's not going to change, no matter what form the code wrapped around it takes.

  29. heyrick Silver badge

    a new project it hopes will speed web page load times on mobile devices

    Here's a refreshing idea. FEWER ADVERTS. With 3G, image sizes are inconvenient but not a big problem. What is a problem is waiting for a dozen scripts from a dozen sites and all the resources they want. You can't keepalive a connection across multiple sites. So this takes time, it obviously impacts site loading times.

    Not to mention the time wastage and cursing as I'm about to tap something and the whole damn page changes shape because some goddamn advert has finally arrived.

  30. Detective Emil
    Black Helicopters

    If this means that Google the ever-benificent learns any more about me, I'm dead against it.

  31. Eistoper

    Call me old school...

    But didn't gopher provide a simple, low overhead method of navigating around? Plus without trackers and the such? Wasn't that proposed at some point for a mobile browser

  32. Riku

    Everything old is new again...

    So basically, WML redux?

  33. Alperian

    Yesterday's problem

    The mobile carriers are promising that everyone will be watching Wimbledon or the cup final on the bus in a couple years.

    Any single dynamic page even written by big nawks is going to float on the tide of data from the mast.

    When we look at the data bandwidth in South Korea and see the near future, we realise that this is yesterday's problem.

  34. Anonymous Coward
    Anonymous Coward

    Just simplify ads?

    Sure the web would be a much faster place if websites just stopped with the ads and tracking that make hundreds of separate connections. Was generally happy with ads until recently, when funnily enough it was the auto-playing videos at the top of the Reg that finally made me look into ad blockers. No sympathy at all for the "its how we make money" argument, but if you ever go back to plain, simple static picture ads then let me know and I'll turn off the ad blocker.

  35. Anonymous Coward
    Anonymous Coward

    1. Jaw hits the flaw...

    2. Closing down my Adwords account

  36. Medixstiff

    I sort of lost interest when i saw the name "Adobe Analytics".

  37. Henry Wertz 1 Gold badge


    I do disagree with "no javascript". But how about "think about what javascript you use?" Those pages that seem slow? I have written up a Greasemonkey script to log settimeout and setinterval calls.. they aren't even animated, but some of these banner ads javascript is so inefficiently coded that they'll call some function 100 times a second just to check if it's time to rotate the ad yet.

    I would say "keep the javascript, but lay off the timers." Again moderation is the key - I'd say feel free to use timers when you need too, but it's typical for a site with no apparent activity (page and ads have loaded, and nothing's animating) to have 5-10 timers running every 100ms (10 times a second), a few running every 80ms (~12 times a second), so you'll have like 100 calls a second to various javascript, and that's when there isn't a banner firing off yet more every 10ms (100 a second).

    This seems to be the problem. I've been to sites that make heavy use of javascript (but no random banners) and it runs great, it's all those timers that hurt things.

  38. simonb_london

    Janky performance on Android

    I thought the main culprit was because the OS doesn't make sensible use of the kernel and give the right bits of the UI (especially the phone app, you know, the one that actually makes a phone a "phone") a higher priority. Nothing should ever stop the display and touch responding. Ever. An outcome that requires at least quad core for Android, but IOS did since 2008 on one core.

  39. Zmodem

    to save the web you need good coders who know 10 small files is faster then 1 big file with encoded fonts and images in

    http connections are normally 12 -> 16, not 1 connection being hogged up with a 3mb css

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon