Surf the Dream A discourse of links and articles from Justin Avery

Tag Archive: RWD

  1. Is CriticalCSS harming our site performance?

    1 Comment

    In a recent article on Medium, JP DeVries wrote about “Unfolding Critical CSS“.

    Are you building a single web page that users will visit once never to return to or are you building a multi–page website that most users click around on for a while?

    If you inline an average of ~20kB of critical CSS on each page and a user visits 10 pages that make use of those same styles you’ve served them 180kb of avoidable weight. That’s ~20kB of the same uncacheable non–blocking styles being downloaded 10 times (once for each page) vs ~20kB of blocking styles being downloaded once as part of a common stylesheet. The number of average page views per user should be taken into consideration when architecting your CSS delivery method.

    CriticalCSS is something that I’ve been HUGELY in favour of since it was first suggested through the Filament Group (citation needed). Since then I’ve showed clients many times how much faster we can make their website appear by loading the Critical CSS in the head…. although I leave off the how and just show them the results.

    The point about the 20kb of additional critical CSS of subsequent page requests is a really good argument, that can really add up over many visits. I will say though that the idea is to get the first part of the “fold” within the first 14kb of the entire HTML document, so we’re not really talking about 20kb of additional content (although the argument still holds fast just with less kb).

    The better approach is to send the critical CSS in the head through on the first visit, download the full CSS file, set a cookie, and then include the tag back in the head to replace the critical CSS.

    This does require some configuration on what the server is generating and might not be as straight forward for some sites, and it can have additional complications around CDN’s and caching URI’s as well…. but then the web is just getting more and more complicated these days.

  2. Next Steps in Responsive Design

    Leave a Comment

    Last week I was lucky enough to be the opening online speaker on Day 2 of the CSS Summit run and managed by Christopher Schmitt and Ari Styles from Environment for Humans.

    It was really enjoyable and even though I was really nervous I think everything went to plan. It was supposed to be 45 minutes long with 10-15 minutes of questions but I managed to stretch it all the way to 60 minutes… albeit having to speed up a little towards the end. To be honest I could have spaced it out to be two hours, but then no one wants to hear someone drone on for that long ;)

    You can flick through the slides below, they were based upon an article I wrote for Net Magazine that has recently been posted their Creative Bloq.

    Next Steps in Responsive Design from Justin Avery

    There were some lovely tweets from folks that watched it so at least a few people enjoyed it.

    I’m going to be speaking at MobXConf in Berlin in September and a yet-to-be-confirmed-but-would-be-awesome conference in the US in October… more about that one hopefully later.

  3. Responsive Answers

    Leave a Comment

    The other day I came across a post from Paul Robert Lloyd answering some responsive questions for Net Magazine and I realised that I did the same thing last year, I should share my answers as well. These are from 13th November 2013….

    Aaron JL Hatton @Aaron_JL_Hatton
    @netmag @justinavery whats the best way to do responsive design, CSS or Javascript?

    CSS all the way.

    There are element of Javascript that you can bring to your responsive implementations, although they should be primarily used as a progressive enhancement.

    There are some great js plugins available to assist with your responsive designs including FitText, FitVids, Respond.js, picture fill, element queries, and grunticon to name just a few (and you can find all my favourites at responsive design javascript tools.

    Rachael Knight @Rach_Jenn
    @netmag @justinavery media queries- good or bad?or should we simply sort when we find something that breaks?

    Good? Better? Media Queries are the best, they are the special sauce that makes responsive design…. Responsive!

    Always remember the first media query is the lack of a media query, so build your site mobile first. The chances are that the devices that don’t support media queries will require a mobile first approach anyway. As you expand your viewport watch the content stretch, and then included a breakpoint when the content looks rubbish. Use something like Brad Frosts ISH to help you find those in-between breakpoints.

    E for Or @EforOr
    @netmag @justinavery Breakpoints. RWD shouldn’t cater for specific devices, but iPhone/iPad screen sizes as standard regardless of content?

    You should always let the content dictate your breakpoints. When something looks wrong, add a breakpoint and make it right again.

    Today the most popular widths are the iPhone 5 and iPad, but if you look back 12 months it was the iPhone 4s instead (different dimensions). Who knows what the next most popular screen is or when it will come out, so why try and guess the size and lock yourself into something that will change?

    At the end of the day you should focus on your traffic and find which users are accessing your site of what devices and base your decisions off that. We’ve even prepared an easy to use free google analytics dashboard to help you make that decision with your existing traffic.

  4. Web design feedback tool for project teams

    Leave a Comment

    Ideas occur to me at the strangest times.

    Being on the internet all of the time means that it can be a bit of a struggle to stay focussed on just one thing. One of the benefits of this is that I occasionally have a moment of clarity and realise

    “Yes, this is exactly what I need and why doesn’t it exist just yet”

    The other day I had one of these thoughts, although I couldn’t tell you exactly where it occurred the main thing is that I had my notebook with me to jot the idea down before it was lost.

    Responsive Web Design Testing

    I’ve dropped the term “Responsive” off the heading here because at this point I’m going to assume that you’re all building responsive sites by default… and therefore we can just call it Web Design.

    A typical situation

    There have been some great articles about designing in the browser or deciding in the browser by folks much smarter than myself. Dan Mall, Stephen Hay, Brad Frost, they’ve all had something to say around the process.

    Typically we would see this:

    • Client needs a new website
    • Content review/strategy/rewrite (after all we want to base our designs upon the content and not Lorem Ipsum)
    • Moodboards, wireframes, design collages, getting to understand the general direction of the redesign
    • Move onto some photoshop comps to decide on some specifics
    • Further pad out the browser based wireframes with more fidelity, or start to ‘cutup’ the photoshop designs that have come from the designer

    At this point we’ve got a few people working on the project. The client, project manager, art director, designer/UX, front end person…. maybe a few others.

    Some of the issues that we might see are:

    • Browser based wireframes aren’t quite telling the full story, or there’s some issues with how they are layed out.
    • Photoshop designs don’t cover a few breakpoint edge cases, and the front end person needs to “fill in the gaps”
    • Client reviews the first set of browser based designs from the front end dev, and things aren’t working the way they expected
    • Art Director or Design check out the front end browser comps and there’s some discrepancies between what the direction was and the outcome.

    Each of these problems are unique, each of them involve various people. All of them are important.

    The process after this is an email from X to Y explaining the problem, or if you’re working with Github or Basecamp (yay for the client) then it’s updated as a discussion. There’s usually a screenshot involved as well highlighting the potential issue.

    This is great, but it’s not the best way to proceed through a series of reviews and fixes to keep everyone working together towards the same goal.

    What would be nice is if there was a browser extension or bookmarklet that could help. The tool would….

    1. log the user into the system
    2. click to clip the section of the web page you are making a point about
    3. a screenshot is taken of the entire browser window (viewport) and highlights the clipped section
      the clipping user now has the ability to add some comments around the issue or intended user experience
    4. the content is then stored ???? (in Evernote maybe to begin with), and along side it the following information is also captured as metadata
      • Date/Time
      • OS (version/patch/release)
      • URL
      • Browser (version/patch/release)
      • networking information (if available)
      • User details
      • Viewport
      • DPI

      This will help categorise the shots that are taken to focus on particular browsers/OS/URL’s etc.

    I suggested using Evernote as the storage because a lot of people are already using it and it takes some of the complexity away, however this could just as easily be configured to run as a complete stand alone web app.

    Possible downsides

    • Does it already exist?
    • Is the workflow going to make sense, is it easy enough to do without a second thought
    • Will the client be able to do it?
    • Can bookmarklets achieve this, or does it need to be browser extensions?
    • If browser extensions will all clients be able to install and use it?
    • Will it run across Safari, Chrome, IE, Opera, Firefox?
    • Does it need to be an OS specific App (OSX and Windows)?
    • There are tools like Pinegrow that will suck down a current URL and turn it into an editable webpage that you can export at a later date. Could/should this be able to do the same?
    • Could this be integrated into Evernote, or GitHub, or does it need to be the complete package rather than something that sits over the top?


    I’d love your feedback and thoughts, especially if something is out there that already does this kind of thing, or if there are other issues I’ve not thought of just yet.

  5. Fibonacci Flexbox Composer

    Leave a Comment

    This is an amazing piece of kit. Start with a box and add columns or rows. Then, from within each resulting box, create another set of evenly spaced columns or rows. It provides some exciting layout ideas. Check out the layout I created in 34 seconds.

    Visit Link

  6. Building Am I Responsive


    Eighteen months ago I put together a very crude webpage that used iFrames to preview a few of the popular viewports as a quick and dirty test for a responsive project we were working on.

    There were plans to improve the tools to something with quite a bit of sophistication, but with time constraints in addition to a plethora of similar tools becoming available I put it back on the shelf labeled “The projects that never were”.

    I never really needed this tool again. All my final testing was done on devices, and in the early stages using Media Queries (by Spark Box), dragging the chrome window. That was, at least, until a Thursday night in early February.

    After spending a couple of hours putting together the responsive design newsletter it was all ready to go once I added the feature site image to the top of the newsletter. To do this I would open up safari and resize the browser from 1600px to 1280px, 768px, 320px and take screen shots at each point. I would then import those shots to Photoshop and position it within some pre canned browser chrome images (iMac, macbook, iPad and iPhone). Once that was done I’d export it to the web, run image optim and upload it to the newsletter. The whole process would take 15-30 minutes depending on distractions.

    It’s not just the weekly newsletter I need them for either, it’s also website reviews for new responsive designs, visual aids for presentations, feedback for clients on their designs…

    So after the newsletter went out on Friday morning I opened up the laptop and started building a responsive design testing tool.

    Am I Responsive?

    A screen shot of Am I Responsive
    Am I Responsive doing it’s best inception impersonation.

    Am I Responsive is super simple, you enter a URL within the input and press go and it takes that URL and rewrites the src attribute of 4 iframes. Each iframe has a height a width attribute set to mimic a particular viewport, in this case 1600px, 1280px, 768px & 320px.

    $(document).ready(function() {
    // Change iFrame on a Button Click Event
            $("iframe").attr('src', $( '#url' ).val());

    The div around the iframe uses a transparent png background-image of the particular device chrome (iMac, Macbook, iPad and iPhone), which then makes it appear as though the iframe site is appearing directly within the device. Of course at their full size the iframe‘s would never all fit not the screen let alone within the image screen space, so the CSS3 transform property is used to scale the size of the iframes to fit nicely within the ‘device’.

    .laptop {
      background-image: url("../images/laptop-screen-optimised.png");
      width: 477px;
      height: 307px;
      top: 264px;
      left: 560px;
      position: absolute;
      z-index: 2;
      iframe {
        width: 1280px;
        height: 802px;
        transform: scale(0.277);
    -webkit-transform: scale(0.277);
    -o-transform: scale(0.277);
    -ms-transform: scale(0.277);
    -moz-transform: scale(0.277);
    transform-origin: top left;
    -webkit-transform-origin: top left;
    -o-transform-origin: top left;
    -ms-transform-origin: top left;
    -moz-transform-origin: top left;

    By Friday afternoon I had it working at the most basic level and pushed it out to a few twitter friends. The first thing they came back with was that it wasn’t responsive, ironic isn’t it, and although it was primarily required for screenshots on the desktop it was kind of annoying me too. I made a few adjustments to the overall scale of the preview area as you move through the various viewports and made some simple changes to the form as well.

    @media (max-width: 850px){
        height: 500px;
      transform: scale(0.65);
      -webkit-transform: scale(0.65);
      -o-transform: scale(0.65);
      -ms-transform: scale(0.65);
      -moz-transform: scale(0.65);
    .desktop{left: 100px;}
    .laptop{left: 440px;}
    .tablet{left: 0px;}
    .mobile{left: 180px;}
    @media (max-width: 768px){
        height: 450px;
      transform: scale(0.55);
      -webkit-transform: scale(0.55);
      -o-transform: scale(0.55);
      -ms-transform: scale(0.55);
      -moz-transform: scale(0.55);
    a.button {font-size: 1.6em; line-height: 1.75em; margin-top:0.5em; width:100%;}
    input {height:1.2em; width:100%;}


    Move me

    Rather than have the same screenshots EVERY single time I wanted the ability to move them around the screen and change their z-index order. jQuery was already getting loaded to help with setting the iframe src (my javascript is terrible, so jQuery to the rescue) so I also included jQueryUI to allow the devices to the draggable. Again, there’s probably lighter/faster ways to achieve this with JS but I tested the load and it had a reasonable response.

    <script src="//">
    $(document).ready(function() {
        var a = 3;
       start: function(event, ui) { $(this).css("z-index", a++); }
        $('.display div').click(function() {
            $(this).css("z-index", a++);
    This came about thanks to Setting z-index on draggable element from StackOverflow.

    Input + Enter

    I noticed during my testing that I was occasionally hitting the enter key after typing in the URL instead of hitting the GO button. To fix that I started trying to find ways to hijack the return key to activate the button instead. Fortunately I had a bit of trouble trying to achieve that because it took me in another direction of trying to deal with ?url= as part of the url string.

    I added a check to see if there was a URL variable and if so to load that into the <iframe src="". This provided the awesome benefit of being able to send someone a link that would load a specified site directly into the iframes. I think because of this the tool picked up a bit more traction in blogs and on twitter.

    function getUrlVars() {
        var vars = {};
        var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,value) {
            vars[key] = value;
        return vars;
    var first = getUrlVars()["url"]; 
    var first = decodeURIComponent(first);
    var first = first.replace(/\#$/, '');
    if(first === "undefined") {
      // don't do anything.
    else {
    //  take the url variable and update the iframes and input field
    This came about thanks to getting parameters from page url from StackOverflow.

    Go, then enter – the hash #

    With the added function of the URL variable I noticed that if you used the Go button first, and then used to the enter key (or visa versa) you would get a hash at the end of the url string which would shoot the preview to the top and interfere with the device previews. To fix this I added an extra check to remove # tag if it is found at the end of the url string. If it’s a legitimate anchor tag it will still work because it only removes the # from the very end of the string.

    // this line achieves that and is part of the code already listed above
    var first = first.replace(/\#$/, '');

    Transparent Previews

    I noticed a couple of sites people were posting didn’t have a background colour set. These were fairly basic information sites, but still it was bugging me. If you fail to declare a background-color: on your site it defaults to browser white, however because the iframes were sitting over a background image they were showing through in the site preview. This was quickly fixed by applying a background-color:#fff; to the iframes to hide what appears behind in the background images.


    I’m super excited/happy/humbled from how well received this tools has become. I’ve had help from people sending in bugs they’ve found and also sending through suggestions to improve the tool.

    The feedback so far has been

    • Add rotate to mobile and tablet
    • Allow the ability to zoom into a device
    • Enable the ability to change the background-color of the preview area

    These are good suggestions, and I’ve even implemented the zoom capability locally allowing for a double click to zoom however it just doesn’t work that well in practice so I was reluctant to push it live. I need to think about how the UI would work for the other ideas as well, plus spend a bit of time trying to write the actual functionality.

    I’m always keen to hear more about the things that could improve it, because after all it was built to help speed up my own workflow so the more it can help out others the better.

    Some things to do/note

    iPhone & iPad

    Although I mentioned that I made this responsive I noticed that you don’t have any control over the height of the iFrame on these devices. The fix seems to be to add another div containing the iframe to set the viewable area of the iframe and hide the overflow.

    @media max-device-width()

    These media queries will not fire if your CSS is set up in this way. Unless you’re really really sure that you only want to trigger the query on a specific device my general advice would be to use min-width max-width and target the viewport rather than the device itself.

    Non Responsive previews

    If you’re previewing a non-responsive site you’ll probably notice that rather than zooming out so that the whole site fits in the viewport (which would happen on iPhone) it actually expands past the viewable area. I think this has to do with Mobile Safari including a faux viewport value if no value is found to improve how non responsive sites appear. Unfortunately it’s not possible (corrections?) to target the viewport meta of a site being shown through an iFrame.


    With the local idea I thought about preparing presentations on trains, planes and automobiles. With that in mind there is now a cache manifest file added as well for those that want to take shots of local developments with not internet connection. Oh, and it made the page load even faster. Not sure if there’s any negatives to that though.

  7. jResize Plugin, for one window responsive development : Todd Motto: Front-End Web Developer

    Leave a Comment

    jResize is a responsive web development tool, built in jQuery to assist the workflow of developers on responsive projects. There are various tools for responsive development, iframes at different widths embedded in the page, and the tedious resizing of the browser. So here’s a different approach which grabs all your HTML, and resizes it inside the browser when you click the width you want. It’s dead simple.

    Visit Link

  8. Setup to Build Responsive Websites

    Leave a Comment

    Have you ever been stuck with testing your responsive designs? In this post Eric takes us through some tricks on Chrome Developer Tools, Bookmarklets, Adobe Edge Inspect and getting it working with LiveReload plus another bunch of techniques

    Visit Link

Surf the Dream is a blog that has been running since the mid 2000's when it started on BlogSpot. Over the years it's been rebranded as (now my resume) and (which now redirects back to this site).

I offer consultation services through Simple Things, produce a range of high quality pocket notebooks(including a Solar System Notebook, Space Notebook, and a Guitar Notebook), write about the Universe and run a responsive web design knowledge hub and a RWD Weekly Newsletter.