In 2014 I relaunched my personal website with a Responsive Web Design. But having a Responsive Web Design with a good font size, without horizontal scrolling and pinch-zooming needed, where links can be clicked easily with a finger, is just the beginning.
When building a mobile website there are some best practices, which can be followed along. Google provides a lot of documentation on these topics, for example the Webmasters Mobile Guide or the Mobile SEO documentation.
There is an easy test for your website, which can check if your website already meets the basic features a good mobile experience should provide: Mobile-Friendly Test.
But I thought my website is cool now?!
You build your website, followed Googles Web Fundamentals Guidelines, wrote semantic markup, made a Responsive Design, got rid of Flash, increased the font size and click areas for a finger, build it Mobile First.
You thought you’re done, you’re cool now. The website is running the latest shit. Build a Responsive Website. Check.
Mobile phones and tablets are getting faster and faster, but some technical difficulties can’t be overcome easily and probably won't be solved in near future: Slow processors in phones, slow rendering in mobile browsers, bad mobile latency. Plus, 85% of mobile users expect pages to load as fast or faster than they load on the desktop. If your site doesn’t render in less than 5 seconds, 74% or mobile visitors will be gone. The may come back later at home or on the desktop, but maybe the won’t.
Your website may look better now on a lot of devices, but it doesn’t make your site faster. Responsive Web Design is not mobile friendly by default. But it can be.
There are a lot of things one can do, some are easy to achieve, some are really hard. You should start with some kind of performance budget, may it be it should render in less than 3 seconds, or no more than 20 requests or no more than 1 MB of data. Try to stick to this budget and keep it. You will have to make compromises or even say no to some wishes. Maybe it’s not possible to include 5 different web fonts, your design department wants you to include. Or maybe the large header image in retina resolution has to go. Or the slideshow of your products, the marketing department wants.
I didn’t optimize my content images (but my images, which are part of the design), instead I worked on the solution which was recommended by Google PageSpeed Insights:
I did this by inlining critical CSS and deferring all other non-critical assets to avoid render blocking.
The trick is to figure out what styles are needed to display the upper part of your website as it’s seen on a Smartphone or Tablet. There are automatic solutions to find the needed styles like Grunt Critial CSS or Critical by Addy Osmani. But for me, automatic tools didn’t work out. So I did this work manually with the help of a bookmarklet.
I created a new CSS file file (
critical.css) with Sass and added all the styles, which where needed for the Grid, Header, Logo, Navigation, some Typography. I tried to load the page with just this one stylesheet until it looked good in the Viewport. And I provided good fallback solutions: background colors for boxes with patterns, which get loaded later and good font fallbacks, which show a similar font until the Webfonts are loaded. I looked into all available fonts on iOS, Android and Windows Phone and added a font stack like this:
The rest of my stylesheets are published in two CSS files: The
application.css and the
homepage.css. I use loadCSS by the Filament Group to load these stylesheets asynchronously. Additionally I provide fallback links in
<script>) and my minimized critical CSS (
<style>) I placed directly into the source code of my page (with a Jekyll
include). This way all critical things are already available when the loading of the HTML file is finished.
</body> tag, thus is not blocking the rendering. Adding the
Having a Responsive Design is not enough. You need to do your homework first and crunch, minimize, and optimize everything you can out of your website. But working on the optimization of the Critical Render Path will provide real speed. I brought down my speed for DOMContentLoaded on EDGE from over 4.11 s to 2.37 s and on 3G from 1.65 s to 1.07 s. My score on Google PageSpeed Insights got from 79/100 to 98/100. My website wasn’t bad before, but optimizing the critical render path nearly doubled the speed.