A look inside the latest jdmweb redesign

A look inside the latest jdmweb redesign


This is my website. I bought the domain name more than ten years ago, and maintain a personal website on it since then. This is probably my sixth or seventh version. I've always used my site as a playground to experiment on development approaches, and this version is no exception.

I am a web developer, which means that every day, I code, I code websites, products, side projects, and every of those new project I start brings its own challenges, its own questions. I take the opportunity to launch this new version to express a bit more what was in my head when building it. I know that in web development, there are many paths to arrive to a decent solution, and that many of today's challenges are widely debated on the web. I am not a preacher, I have opinions but I'm always opened to the discussion. I question things, I make choices, here are a few of them.

There are several topics I would like to discuss, so to keep things organised, I'll start from the the Backend point of view, and will work my way up to the front until the final optimisations.

The Back end: still WordPress and noewp

The main reason that makes this choice still relevant two years after the previous version resides in the fact that both WordPress and noew have evolved a lot during this time frame, thus avoiding them to become obsolete.

Why WordPress?

I am not necessarily a WordPress addict or extremist but I still consider WordPress to be one of the best CMS solutions out there, mainly thanks to the ease of use and power of its admininstration interface as well as its hook system which I think is pretty useful for web developers. Another plus: it's very modular. You can build any theme you want, and extend it with existing or hand made plugin. In other words you have everything you need to code custom features, and then hand it over to your client that will be able to administer it easily. To summarize, you get a stable, solid and powerful CMS solution out of the box, not to forget the size and activity of the WordPress community.

What's noewp again?

On the other hand, WordPress has been built to please the greatest number of users as possible, which is fine, but the drawback is that by default, you get a lot of features you might actually never use, inside a product that is not tailored to your specific needs when freshly installed. This is where noewp truly comes into play. The dedicated case study will teach you a lot more of what noewp truly is, so I encourage you to have a look. To summarize here, it allows us to clean the WordPress interface, and allow custom developments on top of WordPress. For example, every page of this website is hand made and has some sort of custom development into it.

The theme: HTML5, LESS, responsive, retina

Once the CMS is ready, it's time to get the data out of the backend to set it alive in the theme.

Generating the markup

I've coded a custom theme that WordPress will use to generate the markup from the data. I've been using HTML5 tags in my previous version already, this is more than relevant to carry on using them two years later. I mainly use the header, footer, sections and article ones to generate a relatively semantic markup.

To keep things organised, I like to create a WordPress child theme which will contain only project specific files in a folder compared to its parent folder (which is a noewp starter theme). That way, it's a lot easier to browse and maintain the site specific code, and you can update your starter theme across different projects as a commun structure if need be, without touching the project specific code.

The CSS layer

I use the LESS pre processor to code the CSS layer of my websites, for two main reasons. First: variables. As a developer, I understand how variables work and I see the benefits of using them in CSS, especially in my child theme environment. The parent theme has been coded to be easily configurable by a file of site specific variables that changes from project to project. Roughly, the common ground logic stays the same, and gets adapted by child variables, which is very handy.

The second advantage is mixins, which are very useful too, for example to automatically generate vendors prefixes instead of having to write them manually.
Thanks to mixins, I've been able to build a very practical grid system whose concepts is: always have the same fixed margin between the elements, but adapat their width in percentage. That way, you have a complete control on margins to ensure alignments, and on the number of elements per line.

I know there are many other advantages but those two are for me the most important ones. You can also for example, mention that you can use some deep indentations in your CSS, but I'm not a big fan of the generated outcome when you indent declarations too much as it results in very long selectors in the end.

Responsive Design

I still strongly believe in responsive design. It's been a part of my development workflow for more than two years now and I intergrate a responsive design in every project I do.

I stayed true to the approach I described in 2012 ,stating that I do not target device specific breakpoints but introduce them as the design gets broken instead. This gives me much more control on the way the deisgn is rendered, especially as I'm using a lot percentage and flexible units in my css instead of fixed values.

This time, I tried to make an effort with mobile devices by separating in a separated style sheet, only served to desktop devices, all the styles regarding the rich interface. For example, on the home page, you have a complex hover effect, apparitions as you scroll etc, all those styles are not used on mobile devices so they are not even served. I'm not sure this is called mobile first approach or cut the mustard, but I think it's definitely an improvement from what I used to do in the past where I coded the full desktop version, and override styles for mobiles on top of it.

I made my grid system responsive too. Depending on how much columns I render, I adjust the elements widths and stack the columns as the window gets resized. Having a trustful responsive grid system saves me a lot of development time when working on the responsive design of a new project.

Another important point when doing a responsive design is images. Noewp handles a lot of the heavy lifting in the sense that it is capable of serving the right image size to the right device based on its width and if its is retina or not. In other words, if you have a full screen slider on your page, that you want to render on the desktop site, and on the mobile site, noewp will serve high resolution images to the desktop, and optimized thumbnails to the mobile, therefore saving a lot of image size and download time.

Towards a retina website

To make this site more retina friendly, I've first replaced all the images icons by an icon font. Font rendering is a lot sharper than images, and also easier to manage instead of having double versions of images. The icon font has been created with Fontastic.

Another adjustment since last time, the way I handle retina in CSS. Instead of having a lot of media query declarations in the style sheet, with all the pixel densities and so on, I've created a modernizr test that adds a retina class to the html tag. Thanks to the presence of this class, it's a lot easier and cleaner to override retina styles in the CSS.

We've seen in the responsive paragraph that noewp is able to serve correctly scaled and retina optimized images automatically. However, this concerns mainly featured images, and I have yet to find a decent replacement solution for the editorial content images, aka the ones that you upload directly in a page in your post content. For now those images are not retina optimised.

The frontend development

At this point, I could have stopped there, I have my WordPress theme that is nicely integrated and serves its purpose. Even without JavaScript, you have access to all the content, which is very nice in terms of accessibility. The frontend development is therefore about enhancing the interface and making it richer. Here's what's behind it.

The simple JavaScript

If you turn off you JavaScript, you'll see my starting point: a functional not animated theme. From there I've added the simple JavasCript: simple animations, infinite scrolling, those kind of things. As for the CSS, I've separated the simple JavaScript from the Rich Javascript in order to only serve the light JavaScript to mobile devices.

I always follow an object oriented design pattern when coding, be it in php, CSS or JavaScript. I think it's cleaner, better organised and easier to maintain. In JavaScript especially, I find objects very useful to have control over event management, even more so in a full ajax setup like this website. So for every page where I want to add some JavaScript, I create a dedicated object that will handle the JS on the content of this page especially. The site wide JavaScript (like the fact to toggle the header for example), is in another object. I like to keep things separated in a lot of different files.

This is where you might raise the issue of the number of http requests to load all those files, and you'd be right. To solve this, I use grunt, that gathers them all into one concatenated and minified file. This way when you are in development mode, it's easier to stay organised, and easier to spot JavaScript errors than in a concatenated file (even with source maps). And when you get into production mode, you only serve one optimised file to the browser. Everyone is happy.

The richer JavaScript

What I call richer JavaScript is the JS code that regards animations, transitions, more complex effects... They truly make the interface greater, but it's also heavier, and as it is more complex, it's also more difficult for mobile devices to render them properly. This is why I like to separate them in a different file to only serve them to capable devices.

It's with this kind of JavaScript that I've coded the home page's head rotation, the different entrance animations (in the home page, the portfolio, but more importantly in the about page), or more advanced hover effects. To couple rich JS and rich CSS, I add a rich class to the body when I'm in rich mode. That way, all the CSS rules that are concerned with the .rich class kick in.

The Ajax Layer

Making a website full ajax has some pros and cons, and as such must not me taken lightly. It's when you start making your site full ajax that you realize a lot of concepts are taken care off by themselves when pages reload when navigating. For example, updating all the head information, page title, description, keywords, metas, body classes, style sheets, and JavaScript files are all included and changed automatically when you navigate from one page to another with full page refreshes, but when you go full ajax, they are NOT!

To solve this problem, this website sits on an ajax layer driven by backbone.js. The Backbone implementation handles the routing, loads page models from a JSON representation. We made our own instead of waiting for the soon the land WordPress JSON API. The rendered JSON contains all the information that define a page that we just outlined (CSS and JS files, metas ...). The page model is then injected in the DOM. The interesting thing here is the fact that thanks to the way the simple and rich JavaScript is implemented (self contained objects that have a clear context), the website can function with or without the Ajax layer, which is very flexible. It's in fact activated to take care of the page loading mechanism, including adding classes to allow transitions between two pages.

On the pros side, going full ajax gives you control over the way you transition between pages, and that can truly add a motion aspect on your site. When in full ajax, you only load what you don't have in your browser already when navigating to a new page: the new page content obviously, and probably a few assets, but not side wide elements such as the header, the footer, site wide CSS, site wide JS etc... In the end, it accelerates the navigation and reduces downloads. I originally intended to shut it down foro mobile devices but that's the reason that convinced to keep it on for them too.


At this stage, the minimum local development was more or less achieved, so I put the website on a staging url to begin the optimisation phase.

To optimise a website, I usually first turn to gtmetrix. I like it because it tests Yslow and page speed in parallel.

I'll soon detail in another article the breakdown of the optimisation process but here's a summary:

  1. The easiest thing to do to begin with is to optimize images, this can be down in two steps. First, make sure you serve correctly scaled images in the page. For example, if you need 400x300 thumbnails, serve images that effectively 400x300, not 4000x3000 resised in CSS or HTML for example. Gtmetrix will actually give you a list of images that do not follow this guideline if any. Then run all the images inside an image optimisation tool, such as ImageOptim for example. You'll literally save megabytes (maybe giga) on image size without any quality loss.
  2. Second step, try to minimise http requests by combining images into sprites, and css and js into concatenated files. As mentionned earlier, I use grunt for this. I ndevelopment mode, I have over 40 different CSS and JS files, and this number is reduced to one or two in production mode. It'll save a lot of network and processing time.
  3. Third important step, try to configure your server, or via .htaccess if you can't, to make sure all the server and client assets caching is optimal (enable gzip compression, configure e-tags, expire headers, leverage browser caching and so on). GTmetrix will guide you along the way.

I went from grade E to B simply by following those three steps, which do not take that long to get through. It's the famous 80/20 rule. With a 20% effort, you can achieve the first 80% of performance gain. To get the remaining 20%, you might need the 80% of energy. The next step I'll probably take is to use a caching plugin, such as WP Rocket, to cache all the backend part into html files ready to serve, but it's not that simple in a full ajax environment.

As a comparison, I found it interesting to keep the 2O12 version here too. It's the same exercice I did two years ago when launching the previous version. It's interesting to see what changed in this time period, and what is indeed still relevant.

The 2012 version

The structure: WordPress + noewp

Why WordPress?

The WordPress platform is for me the best CMS on the market because it is very easy to use and well designed for the end user. At the same time, it's packed with plenty of features and it's very powerful for the developer. I see that as a very interesting balance between the interests of everyone involved in the management of a website. I've started using it in 2008 and was particularly keen on extending the platform, to add functionalities via hand made plugins, using hooks and so on. I've always thought that what was really interesting in using WordPress was to benefit from what was already there from scratch right after you've downloaded it, and built custom development on top of that to give your customers a solution that would truly suit their needs.

What's noewp?

This approach has been taken to its best and packaged into an extra layer of features and knowledge that we called noewp at NOE interactive. It's a little framework that enhances the default WordPress installation in many ways as you can read in this dedicated post. We use it as a standard for our websites so that was natural and obvious for me to use it for mine.

It's written in HTML5 and CSS3

HTML5 markup

As it's based on WordPress, I built a custom theme for this new version, using the latest HTML5 markup. I like the way it adds meaning to the page structure, it's easier to recognize what each section is about by looking at its markup such as header, section, footer, article...


With the introduction of new JavaScript APIs included in HTML5, web developers can add some very interesting features to their new sites. I checked and tried most of them, and decided to include some in this site, but only if it was relevant of course. The best one to use was for me the history api, that I included in the portfolio and the resources sections. If you click the next post link at the top of this page, then hit the back button in your browser, you'll see that the implementation of the HTML5 history api changes the native behaviour of the back button into something truly customised.

CSS3 styling

The new theme uses plenty of CSS3 properties such as:
  • Rounded corners
  • Shadows
  • Transitions and animations
This is my personal site, so I had fun experimenting and playing with all those "new" properties. You can have a look at the demonstration page, or the 404 page for examples of my experiments.

So what about retro compatibility?

For the markup, I personally think it is now okay to use this HTML5 syntax, and I use it for every project. For retro compatibility, I use Modernizr which handles non compliant browsers and that is also very helpful with feature detection to help you implement fallbacks for the things that are not working properly in older browsers. Talking about CSS retro compatibility now. When I started web development more than 10 years ago, it was a real pain to implement basic design effects such as shadows or rounded corners, so when CSS3 came out, I was thrilled. Finally, no need for stupid extra divs and background images for simple things like that. But wait... as usual, it's not standard, not supported by every browser and so on. We know how it goes... In front of this problem, I think you need to make choices. Ask yourself if websites need to look the same in every browsers? I personally believe the answer to that is no, so as a result, I would implement degraded versions of a design for an older browser. What I mean by that is if I think a design element, for example a rounded corner, is not working in an older browser, I wonder if it is crucial for the user that is element must look the same than in a modern browser. If yes, then I would implement a fallback, if no, I think it's okay to leave it as is. For the very same reason, I tend not to use a method that is not compatible enough yet, such as css animations, for a crucial part of a website, because it's going to break too much in an old browser. The same applies to HTML5 APIs. In my blog, if your browser doesn't support the HTML5 history API, I'd say it's not crucial, it will be a bit less practical to navigate, but you won't miss anything in terms of content, and that's what really matters to me.

It's responsive

What I think about rwd

I believe strongly in responsive design, and I actually started experimenting with it in early 2012 with sites like Green Ardeche Tourism or Saint Etienne Tourism. Many other followed throughout the year so I have now a solid understanding of what challenges are involved in a responsive implementation. For me it is really worth spending this extra time to ensure the design is going to be fully exploited by the device you are viewing it on.

My approach

In my point of view, a responsive design shouldn't target specific devices nor browsers. What I mean by that is that I would rather introduce break points as soon as the design gets messed up rather than introduce break points that correspond to a popular device and try to fit the design in. This approach ensures that your design will never appear broken, and you'll reach a much wider market share of devices than if you focus more or less on the "iDevices". What's important there is the design. We all know that in the web industry, coding for a particular browser, or resolution has never been a good choice. Remember those 90's "best viewed in 1024*768 internet explorer" disclaimers? I think it's not different for devices. The consequence of this approach is that you'll have more break points to deal with in the end, but that has never caused me any trouble so far.

Responsive is not just media queries

This another important point. One of the very main reason to use responsive design, is to ensure our designs are adapted to mobile browsing, which by definition, are devices that are not connected to an high speed internet in a home. They are mobile, on the go, probably with a limited connection. So if you are serving them your full desktop version, and then hiding things from them with media queries, that's not the best way of doing responsive design as you've not fully adapted your design to the device that's viewing it. It's still going to take the time to load the things you hide for nothing. It's wasted. If it's hidden, then you might as well not generate it in the first place. I take the time to think about responsive design as a whole, from backend to frontend, from desktop to mobile, and I sometimes don't calculate things that are not going to be used directly in the backend (a sidebar for example). Tim Kadlec wrote an excellent article on the 24 ways website that I recommend you should read to get more ideas on this subject.

Images in responsive design

Images are at the center of responsive design discussions. It's not a simple topic because there are many factors at stake like syntax, markup maintenance, image quality, image size, load time etc. I usually use the image resizing technique in CSS with properties like width: 100%; height: auto. On a site like jdmweb, that's good enough because I have small visuals that are less than 320px wide so even on mobile there is no real need to distort them much. On a site with bigger visuals, it won't be good enough, and as there are for the moment no real standards dealing with this problem, I use the Adaptive Images technique. I think it's great because it works with .htaccess to intercept your images requests, and serves an optimized scaled down version of them according to a set of widths you can configure. It's easy to configure, works brilliantly, and gave me convincing results on several projects. A really good solution overall for responsive images.

It's retina ready

In theory

2012 saw the rise of retina displays, first of all with the latest apple devices (iPhone, iPad and macbook pro not to name them). These devices have a resolution roughly 2 times greater than other current devices, but those ones actually start to propose higher resolution screens too. What this means for your websites is that if the resolution of your design elements and images are too low, they'll appear blurry on those modern devices. One solution to that is to propose those same images with a resolution 2 times bigger for high resolution screens. For background images you could use css media queries to serve them bigger ones.

In practice

If you had an existing site like me, creating a double sized image for each one you already have could be a huge task. And if you use a replacement method that is too strict, then you'll have to go through that. For background images, you'll have to use media queries. As media queries target a specific device attribute, it raises the questions of which ones you should use, which resolution do you want to target, which device etc. As you can read in this article written by the ever interesting Chris Coyer, if you want to be exhaustive, you might end up with a fairly long media query declaration.

How did I apply this to my problem?

I chose a flexible image replacement method that would allow me to serve retina graphics if I had them, and normal ones otherwise. It's called retina.js, a little script that replaces normal images with their @2x named counterparts if available on retina screens. Easy to implement, flexible, that was a good compromise for me, but it doesn't seem to take background images into account, so I had to add a few media queries into my css to serve retina background images. I supported two set of devices with a not complete media query for the moment: @media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi). I'll see about other devices later on.

It's optimized for SEO

WordPress and noewp legacy

As you can see in the article I wrote on NOE interactive's blog, the fact to build my site with WordPress and noewp gives me plenty of SEO advantages. I won't go through all the article again but here's a little summary of what I do in terms of SEO on jdmweb:
  • I use the built in URL rewriting system to ensure my posts have relevant titles.
  • My code is full SEO friendly data: it's coded semantically with HTML5 tags, I use a hierarchy of titles, I define meta tags, I use micro data, my images and links are labelled properly with alt and title attribtutes.
  • I have a dynamic sitemap, that references all my content, and is updated and submitted to search engines with every new post I publish.
  • I try to write quality content, which is actually one of the most important SEO factor.

It's tailored for performance

YSlow and Page Speed analysis

Performance improvements principles are pretty well defined. You can see the list of best practices on the yahoo developer network page. There some tools that can analyse your website, tell you how well you are dealing with performances on your website, and suggest you how you can improve things. They are called YSlow and PageSpeed. By using them, I've been able to get an overall grade B out of F on performances, which is pretty good considering that grade A is pretty hard to get. Let's see how I achieved this.


WordPress is a powerful but heavy platform, and known to be a bit slow. It takes time to load the platform, locate the page you want to load, get its content from the database, and generate the page markup accordingly. To avoid going through this process with every user visiting a particular page, I put a cache system in place. It generates the page if no cached version exists and saves a cached version of it. It then serves directly the cached version if the content hasn't changed to every user that wishes to view that page afterwards. It reduces the amount of work the server has to do before sending the page to your browser such as file inclusion, database requests etc. There are plenty of caching plugins ready to use for WordPress. I hesitated particularly between W3 total cache and WP super cache. I finally chose WP super cache because I found it easier to configure and its end result was closer to what I wanted.

Reducing the number of http requests

As the yahoo guideline explains: "80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages." So you can see it is crucial to reduce the number of components you load in order to speed your page up. To remedy this, I use a little tool called minify, which does three things very well. It concatenates, minifies and caches several files into a compress one on the fly. So if I have several js files, it combines them all into one minified js. It works similarly with CSS files. It saves me many http requests, and reduces the total weight of my files in the same time. I can't code a site without this. Still talking about reducing http requests, I combined all the icons used across the site into on image sprite so when the page loads, it only needs one request to this image for all the icons instead of one per icon. To build this sprite, I used a tool called SpritePad, which is simple to use. You can drag and drop your images into a workspace, and download the corresponding image and CSS code in one click.

Following other guidelines

There are many other guidelines I advise you to follow if you wish to improve your site speed like gzip compression, components caching, Etags etc. Don't forget it's now also a criteria of ranking for Google. I always aim for the best possible grade even though A is tough to get, B and C are quite good already.

It's getting accessible

I've recently been interested in accessibility in web design, and try to follow a few guidelines to improve the accessibility of my sites, especially the ones provided by the accede-web website. As a result, I've introduced a few extra elements in my code like:
  • Skip links which allows you to go directly to the page content when navigating with the keyboard
  • Role attributes that define a bit more what a certain area of the page does, like where the content is, where the navigation is, the search ...
  • There are always titles and alt attributes where necessary, like on images and links, and sometimes a bit more information on language switch links (language attributes) or download links (extension and size).
I'm only starting out on accessibility and I hope to improve things up on my different sites from now on.


The web industry is evolving very fast. We have technologies rising and falling at fast pace so it's likely that as web developers, we'll find ourselves in a situation where an approach we would like to use would be like 70% mainstream but not standard, 15% not supported by old browsers and 15% nearly deprecated in modern ones to caricature things up a little bit. In such an environment, I try to get the best result as possible for everyone even though I know some browsers / devices will get different versions, (enhanced or degraded). I believe the best to way to achieve this is to accept the current state of our industry, and to make choices that will serve best the design we are trying to code.


I'd love to have you opinion on one or several of the covered areas. How do you usually address them? Do you have some nice tools that you find useful and think would be interesting to share like the different ones I mentioned along the article? Is there another topic you'd want to see added? It was rather interesting to think about all those things myself, but it will be even more to get the opinion of fellow developers so don't hesitate to get this discussion going.
Keep on reading.
@ambroisemaupate @orange Moi j'ai pris une 503 toute à l'heure. #irony25 Mar / 16:20