mobile web

Blogposts on blog.futtta.be about “the mobile web” (i.e. internet on your iphone, nokia with symbian, htc with android or windows mobile or other smartphone), including links, best practices and some reviews.

When lazyloading iframes does (not) work (automatically)

by

WordPress has made some good progress to speed up site rendering the last couple of years and part of this is thanks to images and iframes having the “loading” attribute with value “lazy”, telling browsers these can be loaded later allowing other (more important) assets to take priority. Especially iframes can consume a lot of bandwidth (think embedded Google Maps or one or more YouTube videos), so the performance impact of lazyloading those can be very significant.

Unfortunately one cannot always rely on WordPress core to automatically make sure there is no performance penalty from stuffing your site with iframes. Here is a non-exhaustive list of when iframes will still delay your site:

  1. WordPress core does not always add the loading="lazy" attribute;
    1. if loading="eager" is set (which means load asap)
    2. if no width & height are set (as lazyloading iframes without those could cause layout shifts)
  2. Firefox (and some less important browsers) does not support lazyloading iframes even if loading="lazy" is set
  3. iframes in or near the “above the fold” part of a page are loaded immediately, even if loading="lazy" is set

Conclusion; show restraint when adding iframes; adding an image of Google Maps which links to (a separate page with) Google Maps is almost always as informative and the performance benefit of using an image instead of an GMaps iframe is huge. And when using iframes then consider using alternative solutions to avoid the performance impact (for YouTube you might want to give WP YouTube Lyte a try).

Redirecting to AMP (reader mode) for mobile

by

I’m not a big fan of AMP but I do have it active here on this blog using the official AMP plugin for WordPress, using it in “Reader” (aka “classic”) mode. That’s as far as I want to take it, but suppose (as was the case for an Autoptimize/ Critical CSS user I was helping out) you want to redirect all mobile traffic to AMP, then you could use below code snippet to do just that.

add_action('init','amp_if_mobile');
function amp_if_mobile() {
  $_request = $_SERVER['REQUEST_URI'];
	if ( strpos( $_request, '?amp' ) === false && strpos( $_request, '&amp' ) === false && ! is_admin() && wp_is_mobile() ) {
    if ( strpos( $_request, '?' ) === false ) {
      $_amp = '?amp';
    } else {
      $_amp = '&amp';
    }
    $amp_url = home_url() . $_request . $_amp;
    wp_redirect( $amp_url );
    exit;
  }
}

It might be a little rough around the edges, but it (mostly) gets the job done 😉

Mijn m.deredactie.be-alternatief nu ook met Sporza

by

futttas-sporzaHet was exact een jaar geleden dat ik nog iets over mijn m.deredactie.be-alternatief schreef en het was nog langer geleden dat ik er aan gesleuteld had. Omdat ik tussen mijn echte werk en mijn WordPress plugin spielereien nog wat tijd had, heb ik één en ander verbeterd;

  1. Je kunt nu ook Sporza-nieuws lezen
  2. Op PHP-installaties zonder APC-support (apc_store/ apc_fetch) wordt de cache nu op disk bijgehouden
  3. Op PHP-installaties zonder CURL-support wordt nu teruggevallen op file_get_contents
  4. Een reeks kleinere UI-verbeteringen en fixes voor PHP-notices
  5. Getest op PHP 5.2, 5.5, 7.0 en HHVM (op openshift)

De (crappy) sourcecode staat nog steeds op GitHub, bug-meldingen of pull-requests zijn daar zeer welkom 🙂

Mobile web vs. Native apps; Forrester’s take

by

So web is going away, being replaced by apps? Forrester researched and does not agree;

Based on this data and other findings in the new report, Forrester advises businesses to design their apps only for their best and most loyal or frequent customers – because those are the only one who will bother to download, configure and use the application regularly. For instance, most retailers say their mobile web sales outweigh their app sales, the report says. Meanwhile, outside of these larger players, many customers will use mobile websites instead of a business’ native app.

My biased interpretation; unless you think can compete with Facebook for mobile users’ attention, mobile apps should maybe not be your most important investment. Maybe PPK conceeded victory too soon after all?

QuirksMode: “The problem with Angular”

by

I’ve previously already expressed my doubts about the how well-suited AngularJS is for mobile web development (in Dutch, though, as I was discussing the merits of the mobile news-site of the Flemish broadcaster VRT).
QuirksMode’s PPK dove in a lot deeper in his “The problem with Angular“, stating amongst other things;

Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues. I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognize Angular’s performance problems.

The performance problems PPK mentions are not the initial download of angular.js in the browser (which is one of the reasons why I dislike it), but the fact that angular.js does a huge amount of DOM-manipulations, which are costly, especially on mobile. This quote says it all;

Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers — especially not the mobile ones. This job belongs on the server.

But do read PPK’s article for more insights on Angular and the road it is heading down with AngularJS 2.0!

Uw eigen mobielere deredactie in 5 stappen

by

openshift configureer uw redactieuwredacie op openshift uwredactie op openshiftOok al kunt ge mijn alternatieve mobiele redactie hier bekijken, dan zout ge toch, om redenen die geheel de uwe zijn, misschien liever uw hoogst persoonlijke redactie hebben?
Wel, dat kan in 5 eenvoudige stappen dankzij Openshift, het freemium PAAS platform van Red Hat en dat gaat ongeveer zo:

  1. Maak een gratis account aan bij Openshift
  2. Klik op “Create your first application now“
  3. Vul PHP in in het zoekvenster en selecteer de PHP 5.4 cartridge
  4. Vul een naam in voor de public URL, copy/paste https://github.com/futtta/redactie in het source code veld en klik op “Create application“
  5. Even geduld terwijl uw eigenste redactie wordt aangemaakt. In het laatste scherm kunt ge eventueel git access configureren (“Will you be changing the code of this application?”) of direct op “Visit app in the browser” (in mijn geval naar http://mijnredactie-futtta.rhcloud.com/) klikken.

Spreading the news, tiens!

Verder sleutelen aan mijn m.deredactie.be-alternatief

by

futtta-redactie-tabs-compressorDat ze daar aan de Reyerslaan niet stilzitten; http://m.deredactie.be/ is nu ook bruikbaar op een JavaScript-loze browser! Dat klinkt misschien onbelangrijk, maar zo een basis-versie die werkt, ongeacht de browser, is een grote stap in wat ik de juiste richting acht. Spijtig genoeg blijft de site voor de rest onder Google’s verwachtingen en de laadtijd en total download size blijven een mobiele site onwaardig. Daar ten gronde iets aan veranderen binnen het kader van de gekozen architectuur (MVC in de browser) zal niet eenvoudig zijn.
Daarom ben ik dus ook niet blijven stilzitten en sleutelde ik verder aan mijn alternatief voor m.deredactie.be. Video werkt nog steeds niet (misschien moet ik eens kijken of ik iets kan doen met de JS-file van de VRT), maar onder andere deze verbeteringen zijn er wel bij:

  • Op de homepage hebben “hoofdpunten”en “laatste nieuws” nu elk een eigen tab (ik ben zelf niet overtuigd van de kleurenkeuze, maar soit).
  • Op de detail-pagina’s kun je artikels delen op sociale media (met lyteshare.js)
  • De html is opgekuist en valideert nu bijna op de W3 validator (bijna maar nog niet helemaal; de imgsrc attributen op placeholder-divs voor image lazyloading mogen niet).

Daarnaast zitten er nog een handvol bugfixes en andere kleine wijzigingen in, cfr de  “done” lijst op Trello. Pagespeed Insights score en webpagetest.org testresultaten zijn nog steeds “up to snuff”. De geüpdate code staat op GitHub en het resultaat (als je het projectje niet zelf wilt/ durft/ kunt installeren) zie je op http://futtta.be/redactie/.

Mijn alternatief voor m.deredactie.be

by

Dat ik niet content was met de vernieuwde mobiele redactie.be schreef ik hier al. Maar commentaar spuien kan iedere blogger, afbreken is makkelijker dan opbouwen en het beste argument is een uitgewerkt alternatief. Vandaar; ik werkte de afgelopen maanden tussen de soep en de patatten aan een eigen “progressive enhanced” Proof of Concept van een mobiele deredactie.be (in PHP) die op alle browsers werkt, minder mobiele data verbruikt en sneller rendert (hier moet ge zijn, ongeduldigaard).
Waarom ik denk dat deze aanzet beter is dan de officiële versie van de VRT? Wel, de POC

  • futttas-redactie-pagespeed-insightsis op elke browser te bekijken, ook als er geen (of slechte) JavaScript-ondersteuning is. Opera Mini? Lynx? De Netfront op uw grootvader’s Nokia? Geen probleem!
  • kan makkelijk uitgebreid worden om afhankelijk van context de presentatie anders toe doen, bv. op tablet de nieuwscategorieën permanent aan de linkerkant
  • de download-size is véél kleiner (en vreet dus minder van uw mobile data-abonnement); 472KB (document complete) en 979KB (fully downloaded) vs 126 en 127KB
  • de site rendert véél sneller (en spaart uw batterij dan ook meer); 7.419s vs 1.557s
  • Google PageSpeed Insight geeft m.deredactie.be een mobile score van 61/100 tegenover 97/100 voor deze POC (91/100 indien de data niet uit de cache, maar van VRT komt)

Je kunt:

Een paar technische feitjes;

  • De basis-versie werkt volledig zonder JavaScript. Als JS aanwezig is en “up to snuff” (cfr. cut the mustard), wordt de ervaring “verrijkt” (fixed header, uitklapbare navigatie, lazy-loading van images …).
  • Alle CSS en JS staat -weliswaar slordig maar oh zo performant- inline (behalve aniHead.js, een onafgewerkte en dus inactieve “verrijkings”-PoC in de PoC, type aniHead(); in de console om te activeren).
  • De POC gebruikt dezelfde data-feeds als m.deredactie.be, maar haalt die server-side binnen (dependancy; Curl)
  • Data wordt -gecomprimeerd- gecachet in APC cache (dependancy; APC)
  • Externe HTML in de data-feeds (iframe, script of object van bv. Twitter & Facebook) wordt rudimentair weggefilterd, maar dat is een optie in de code ($trustHTML=false;)
  • De code-kwaliteit is ongetwijfeld beneden alle peil (geen OO, geen MVC, veel spaghetti), maar ik ben dan ook geen èchte developer.
  • Grootste missing feature is video (er zijn er nog, zie Trello-board)

Zo, dat is het zo wat. Bekijk het eens, geef commentaar, fork op GitHub, fix bugs, voeg features toe. Maar wat je ook doet, vergeet niet dat de content van VRT is en blijft en dat je daar dus niet zomaar wat mee kunt doen.

Android Chrome bug when styling unicode character?

by

symbols CSS weirdness in chrome for androidWhile experimenting with the use of Unicode characters in a small proof of concept, I stumbled upon what I think is a bug in Chrome for Android. Apparently character ☰, which renders as ☰ and which most people consider the “options”-icon, cannot be given a color in Chrome for Android whereas other Unicode characters can.
As you can see when visiting this test-page, the 3 symbols styled correctly (font color white) in most browsers (tested on IE8, FF on W7, Ubuntu and Android, Chrome on W7 and Ubuntu), but the options-symbol is not white on Chrome for Android (at least on my Samsung Galaxy S4).
So, does this qualify as a bug, or did I just mess up? Anyone happens to know a workaround?