dracos
commented
11 years ago If you're worried about bandwidth, there seem to be other areas that would save you a lot more than a few Kb in the HTML. (I did my analysis on http://info.mzalendo.com/person/benjamin-langat/ FWIW.)
Nothing is being gzipped - that would save you over 200K on the CSS and JS being sent for that page (73K on kenya.css alone). Minifying the JS could save 20K. Minifying the CSS could save 16K. Just minifying the HTML would save 8K. What would be the difference in size of the served HTML post gzipping? I assume the second menu is heavily gzipped given the content is already present once in the same file, after all...
Another HTTP request over a slow connection on a mobile is never "near instant". I would be far more concerned over introducing another HTTP request, given mobiles don't cache much between visits, and the possibility of connection negotiation being the navigation never loads at all. How quickly would the menu actually load? Could this be done just for the drop-down menus of the desktop? Even so, I think gzipping is slightly more important.
Note that FixMyStreet manages to have the menu at the top on 'desktop' and in the footer on 'mobile' and only have it once in the HTML.
mhl
Whilst changing the layout on the Mz site I've been scrolling through the generated HTML, and have come to realise that the site menu eats up 7kB of each page - accounting for roughly 30% of an average page.
Obviously the menu has undergone a fair bit of bloat, and it repeated twice on every page (on desktop it is a bar in the header with pop-open sub menus, and then again in the footer. On mobile top menu is hidden and bottom menu is fully expanded[1]). I'm not sure that there is much of an alternative to having the big menu in two places on the page. Even just putting it in once though it would still be 3kB per page.
As jQuery (or Zepto) is already part of the site I'm wondering if it wouldn't be better to serve the HTML that the menu needs from something like '/menu-snippet' and give it the right caching headers. Then the two menus could by default be much smaller, effectively just a link to a separate menu page. For non-js browsers this would mean that navigating the menu means an extra page load. For all other browsers the menu would be filled in when the js kicks in and presumably the ajax request would be cached so near instant the second time round.
I feel confident it will work on the 30% of our visitors who use Opera Mini as the JS will run on the proxy servers. I'm less confident that it will reduce their page load amount as Opera may send it to them each time anyway. Ho hum.
[1] or rather will be once https://github.com/mysociety/mzalendo/commit/85770f0ea58e760330c16304cd8d05fdda23d3f0 is deployed.