100+ Tips to Improve Website or Blog Ranking (2019)

Tips for Improve Website or Blog Ranking

200+ Tips for Improve Website or Blog Ranking in 2019

Page load Speed and performance are the main factors of Google Ranking in 2019. This blog explains the 200+ best Tips for Improve Website or Blog Ranking in Google. 


Focus on Accessibility

Improve Website Ranking

As I have mentioned in previous blogs, making sure your website is accessible should not merely be a step at the end of your project. Accessibility considerations begin with your content, whether it is in the form of words, images, videos, or any other format that communicates a message to someone or allows them to do something.


Accessibility thinking should also be ingrained in the design process: considering alternative ways of displaying the same message, and making sure designs and layouts do not get in the way of people accessing your content or completing a task. 


But in the same way that mockups and wireframes are pointless without markup and code, great content and accessible design will not suffice if that same markup and code do not respect accessibility considerations. Andrew Hoffman sums up this idea very clearly:


Here are some of the key aspects to consider when coding your responsive website accessible:

  • Use clean, semantic markup as much as possible.
  • Use WAI-ARIA landmark roles, if needed, to extend the semantic capabilities of your markup.
  • Provide a skip-navigation link at the top of your website.


  • Make sure non-decorative images include alt tags but do not simply repeat text that is already mentioned elsewhere on the page.
  • If you use JavaScript, provide fallbacks in navigation elements, because broken navigation can hamper access to content.
  • Consider how people with touchscreens will use your website.


  • Consider how someone with only a mouse or keyboard will navigate your website.
  • Make sure someone using a screen reader can navigate your website.
  • Consider how game console and TV users will navigate your website.


  • Add accessibility tests to your build process to test things such as color contrast and the existence of alt tags.


Focus on Performance

 Improve Website Ranking

Converting an existing fixed-width website that was originally designed to fit medium to large screens is not just a case of shrinking images and removing floats from your CSS. One of the main secrets to making sure your website provides a good experience on any device, of any screen size, is to make it lighter and faster.


The classic idea of the mobile user who is moving from one place to another is task-focused, and is on a slow connection is not accurate in many cases. Most of us can think of moments when we slouched on our sofa, browsing aimlessly on our phone while on a fast broadband connection, just a few feet from our laptop or desktop computer.


Conversely, what about that time the usually fast connection on the desktop computer at the office was incredibly sluggish, and every website took ages to load?


It is important that you avoid making assumptions about the context in which users will visit your website. You cannot assume that visitors will be accessing your website on only the fastest, low-tariffed Internet connections.


A responsive website enables people to access from an almost infinite number of devices, anywhere around the world. For this reason, it is key that you aim to build a responsive website that not only is visually responsive.


But that also responds quickly to the user—and that respects the fact that they may be paying through the roof for any unwanted or unexpected downloads.


The nature of a responsive retrofitting project, where the scope can be incredibly restricted, may mean improvements toward a performant website have to be made in stages.


There are a few aspects you should bear in mind as you make strides toward a more performant website, and some things you can do quickly that will bring you closer to a super-fast website.


Work with a Performance Budget

Performance Budget

Performance considerations should begin early in the design stages, but the bulk of the work that needs to be done still falls into development. One aspect that should be determined from the get-go is what level of performance is deemed acceptable—this can form the basis of a performance budget.


A performance budget works just like your household budget, but instead of money, your currency is time or megabytes. You begin with a defined, finite amount, and you distribute the resources with thrift and prudence.


Just as you have to cut down on restaurant visits when you really want that new Eames chair for the living room, you may have to cut down on your JavaScript libraries if you really want that large hero image on the website.


Setting the initial budget for your website is an exercise where you can and should involve team members with both design and development expertise.


Start by looking at your own website and two or three competitor sites with the development tools in your browser open, and measure how long they take to load. Make an informed decision about where you want your website to land.


You can also use a purpose-built tool like WebPagetest (www.webpagetest.org), which allows you to test and analyze your website’s performance. The website gives you a plethora of useful information about your website and helps you identify and rectify particular bottlenecks.


When the BBC developed its responsive news website half a decade ago, the stated goal was to have a working website in 10 seconds over GPRS (the mobile data standard that has since been superseded by EDGE, 3G, and 4G, but that is still the fastest available option in many places around the globe).


By setting a goal like this, you can work out a few baselines: for instance, GPRS averages out around to a download speed of 100 Kbps, meaning you can download 125 KB in 10 seconds.


Your goals will likely be different, but the approach is the same. On the basis of this information, you can make decisions about which and how many assets you can allow on each page.


Having a benchmark to work with that is easy to understand and communicate also helps in discussions with other team members and stakeholders. You have decided on a maximum page weight and set that as your maximum spending.


If for any reason you or someone in another department deems it necessary to add images, banners, scripts, or video to the page, the discussion should always include the performance budget, and stakeholders should be made aware that it is an integral aspect of a successful design.



Because this is a retrofit, many design decisions that impact performance have already been made. By setting a goal, however, you can do several things under the hood to improve performance.


Optimizing the way your website requests its resources is one of the key ways to speed up the website. This is a science unto itself and deserves its own dedicated book, but the following checklist is a good starting point:


  • Size matters. This may sound obvious, but a lighter page will download faster than a bloated one. It goes without saying that this becomes even more evident on a slow connection.


  • Minimize requests. Every time the browser has to go fetch a resource, your page gets slower. Fewer requests mean a faster-loading page. One of the easiest improvements you can make is to ensure that you are loading as few stylesheets and JavaScript files as possible.


  • Put things in the right order. Keep CSS in the HTML head element, before any linked JavaScript. That way, your browser can begin rendering the page before dealing with anything else.


  • Keep it lean. The browser needs to download and parse both your HTML and all of your CSS before it can start rendering your page. Yes, size matters—it is worth repeating.


  • Scripts are slow. As the browser parses your page’s HTML, it has to stop when it encounters a script. Then it has to execute the script to check whether the DOM has been altered.


  • If the script is external, it has to fetch the resource, download it, and execute it. This can cause significant delays. If you can, let your page render before fetching and executing your JavaScript asynchronously.


These are only a few things you may want to consider improving on your newly retrofitted responsive website that can make it considerably faster. But sometimes speed only needs to be skin deep, as you see in the next section.


Understand Perceived Performance

Understand Perceived Performance

Page weight is not everything. A user does not know whether your website has too many HTTP requests or is this or that many megabytes. Their experience is based on what they see.


And you do not perceive that something is faster or slower in a vacuum; you can only tell that something is fast if you can compare its speed with something else.


When trying to improve your site’s performance, aiming for it to be 20% faster than before is usually a good goal. This value has its root in how human perception works.


According to Weber’s Law, “the just-noticeable difference between two stimuli is proportional to the magnitude of the stimuli”; this means there is a point at which humans can perceive that there is a difference between two states, and a smaller difference than that will not be detected.


This rule can be applied to anything from discounts to increases or reductions in how many potato chips are in a bag. It can also be applied to software development and user experience.


The value of 20% is regarded as the baseline at which someone will perceive any difference in stimuli, so this number can be used to your advantage when assessing and determining performance-improvement goals.


Depending on how much earlier work and focus has gone into making your website performant, this performance gain may be achieved just by looking at some easy wins.


Here are some things that can make a website feel faster:

  • Having touch/hover states on buttons and links
  • Optimizing time to first byte/time to render
  • Including critical CSS inline


  • Loading the most important above-the-fold content first
  • Considering progressive/lazy loading, meaning you only load content that is visible in the viewport
  • Avoiding spinners if you have to reload content, and using animation instead


  • Avoiding repaint, because pages that jump around as they load feel slower
  • Considering loading fallback fonts before fetching web fonts to avoid a flash of invisible text (FOIT)


It is important to note that these tips and hints should be used in addition to the under-the-hood performance enhancements that reducing page weight, HTTP requests, and so on will bring.


Large Screens Like Lean Sites, Too

performance enhancements

If you do, stop to think about whether they add anything to the large-screen views, too. If your mobile users can live without that parallax effect on the background or that hijacked scrolling effect, are you sure it is necessary at all?


We have a tendency to want to decrease page weight on mobile devices, but the benefits of doing so will improve the experience for every user, across all devices.


Consider the job your website is there to do. More often than not, the design is successful if you do not notice it. When reading a book, becoming engrossed in the characters and storyline is preferable to paying constant attention to the typography and layout.


Similarly, if your website is there to provide content or a service, you should consider your priorities.


Simple, unobtrusive, fast, and efficient is often better than complicated, noticeable, or even innovative and remarkable. As luck would have it, most people will love your fast, boring-looking website more than a slow, striking one.


[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


Trim Down Your Web Fonts

Web Fonts

Another simple thing you can do to shave some kilobytes off your website is to remove unnecessary character sets and font weights from your web font if you are using one.


Check whether you are using variants such as italics and bold—there may be design guidelines in place that restrict their use, and emphasis can be added to the text in other ways.


The gains of doing this can be in the hundreds of kilobytes. If you are hosting your web fonts externally and the licensing of your fonts allows it, you can also consider self-hosting your fonts, because doing so cuts out the reliance on an external service.


This allows you more fine-grained control of how and when to serve your fonts, and how to implement your caching strategy.


A downside to using web fonts is that some browsers (I am looking at you, iOS Safari) display no text at all until the entire page, including the web font assets, has loaded fully.


This means you sometimes have to wait up to 30 seconds before seeing any text on the website. There aren’t any simple solutions to this problem, apart from ensuring that your website loads fully very quickly, but there are a few tricks you can use to make the experience better.


One of these techniques, introduced by Filament Group, is to serve a fallback font the first time someone visits your website, load the web font asynchronously after the page has rendered, and serve the web font from that point on.


 Another, far more drastic approach is to remove the web font and rely on the fonts installed on your visitors’ operating systems.


In a recent website update for a small side project, replacing a single hosted web font with a system font saved 3.5 seconds in load time and a half-megabyte download. This technique is certainly worth at least considering when page weight is at a premium.


 Removing web fonts is not possible for all projects, of course; but when you are reviewing design visuals hot out of Photoshop, remember that looking great is not the only way in which your website will be evaluated by users. You have to provide a good experience as well.


Some Handy Tools


Various tools can help you improve your site’s performance. The ones listed here are some of my favorites and are popular among front-end developers because of their reliability. Make sure you take them for a spin.



You have already been introduced to WebPagetest in this blog. It is an open source tool supported by Google that aims to make the Web faster by providing metrics on all things related to page speed.


It allows you to test your sites on real browsers across the world so that you can see how your website performs in different areas, which is great if you have a global audience.

Speed Index

The Speed Index is one part of the WebPagetest suite. It measures how quickly your page content visually renders. It can be particularly useful for before-and-after comparisons when doing optimization work because it gives an indicator of the site’s perceived loading speed.


To keep up your team’s morale, make a habit of noting the speed index before and after you make any changes that you think will have a performance impact, so you can see concrete, measured improvements as you go through the drudge of improving things behind the scenes.


What Does My Website Cost?

What Does My Site Cost

When carrying out a responsive retrofit, you will naturally have mobile use of your website in mind. The What Does My Website Cost? website (https://whatdoesmysitecost.com/), which forms one of the metrics of the WebPagetest, tells you how much mobile network users across the world have to pay for the data required to download and use your website.


Discussions about performance often focus on reducing the number of requests and rendering pages as quickly as possible, so page weight often gets pushed into a corner. 


This tool serves as an important reminder that if your website becomes bloated and overweight, it costs people real money. These tools form only a small subset of those available to analyze and improve performance. You can find more in the appendix.


Fluid Grids and Type

Fluid grids, along with media queries and responsive images, are one of the three tenets of a responsive website, according to Ethan Marcotte’s seminal A List Apart article “Responsive Web Design.” 


When converting a website to being responsive, one of the most important and visible tasks you will perform is making your grid and your typographic scale responsive.


These changes do not have to be complicated, but it is important that the code you create is robust and that it provides a solid foundation for your content to live in.


Fast Track to a Fluid Grid

Fluid Grids

There is a quick test I like to do on sites that are not yet responsive, which can quickly provide you with a good idea about how much work you will have to put into making your grid responsive. All you need to do is remove float and width rules from your CSS to see how your website behaves in a linear format.


This can be done quickly by using Firebug or another inspector and resizing your browser window, but it is even better if you can create a prototype that can be tested across a selection of real devices and that the team can huddle around and discuss.


You may be surprised by how good your website looks in this simplified attire, and by the small number of changes you would have to make to achieve a passable responsive experience.


But fiddle with your prototype for long enough, and you will begin to find numerous ways in which you can massively improve the small-screen experience of your users. List these, prioritize them, and make yourself a plan.


Improve your Markup


Ideally, your website was built following the principle of separation of concerns, where the HTML gives your content a consistent and logical structure, the CSS describes style and layout, and JavaScript adds behavior and other enhancements.


If this is not your case, you should give serious consideration to refactoring your markup to better reflect these ideas before you delve any deeper into your retrofitting work.


This is obviously much easier said than done, but remember that when you are working with messy HTML, you will more likely than not end up with messy CSS.


Your responsive retrofitting project, although tight in scope, should still provide you with a venue to make some much-needed improvements to the foundations of your website.


 In his article “Responsive Retrofitting,” Ben Callahan makes this very same point evident: Avoid doing retrofit work when the website doesn’t have a solid foundation of clean, semantic HTML.


There are some things to look out for when you are considering improving your markup:

semantic markup

  • Use semantic markups such as headings, paragraphs, lists, and HTML5 sectioning elements to describe your content.
  • Keep your markup consistent by making sure everyone follows the same guidelines.


  • Keep divs and other elements that do not describe content structure to a minimum, especially when they are used to describe layout
  • Use the HTML5 doctype if you do not do so already.


  • Validate your markup: there may be things you did not catch that a validator will.
  • Consider making the HTML improvements suggested by Google Webmaster Tools for your website.


In some cases, it may be possible (or necessary) to leave the existing HTML untouched. In this situation, it is likely that your CSS will have to work harder to be able to target the HTML you need to style.


You can also consider using CSS flexbox to reorder content at different breakpoints, independently of the order of the content in the markup, if it is not possible for you to edit the HTML. 

Although not necessarily recommended for full-scale grid-layout design, flexbox can come in handy to reorder smaller bits of content in your pages.


The global support for flexbox is just over 94%, with Internet Explorer only supporting the property from version 11 onward. So, make sure you consider how non-supporting browsers will render your website.


Remove Inline Styles


It is not uncommon for inline CSS to creep its way into your markup. Sometimes things need to be built that do not follow any existing patterns and that is enough of an exception that adding a single style tag is the simplest way to achieve the intended effect. But once you make your website responsive, these inline styles may come back to bite you.


Before you move too far into your development, you may want to sweep your website to find any pesky inline styles, including those added via JavaScript, so that you can then make the decision to either leave them or remove them, case by case.


Depending on how many styles you have let sneak into your markup over the years, this decision-making process may be a quick task or something more involved; but it is something you do not want to remember at the last minute or after the website has gone live.


Some tools online can help you with this task, such as HTML-Cleaner (https://html-cleaner.com). While you do this, you should also search for instances of inline JavaScript and consider refactoring those before they become a problem.


When going through these frameworks’ code, remember that their target audience is in many cases, everyone. This means their markup and CSS are made to be much more malleable than yours probably needs to be. This need for malleability can and does cause bloat and unnecessary classes and markup, so remember that this is not necessarily your case.


Another thing you may want to do is to look at well-designed responsive sites that have a solid grid, check how their grids are built, and see how the CSS was written and how the markup works with it.


Look at how your competitors have solved the same problems, and think about whether you can come up with a better or cleaner solution that is more adapted to your needs. This is, and always has been, the beauty of the Web: the ability to view source. Use it to your advantage.


Abandon Absolute Units


Depending on how your stylesheets have been created in the past, you may have to convert the way you created your grid and font sizes from using absolute units of measurement, such as pixels and points, to using relative units, such as em and percentages.


When you define a column to be a certain width in pixels, that is the width it will always be, regardless of whether you are looking at the website on a small or large screen.


The goal of making your website responsive is that it can adapt to any screen size and allow the content to use the space available as well as possible. You cannot do this with absolute units.


Bear in mind that design guidelines and pattern libraries can be defined in pixels because this is the unit in which measurements are generally computed, but that does not mean you should be using pixels in your CSS. In a responsive retrofit project, you will most likely be converting some sort of absolute unit to percentages to have a fluid grid.


You may run into trouble when you need to mix percentages with absolute units for things like gutters and sidebars—for instance, you may want a sidebar on your website that takes up only 200 pixels in width, and the main content should take the remaining width depending on the viewport.


In this case, consider using the CSS function calc(), which allows you to do exactly that type of math:

 style="margin: 0px; width: 971px; height: 162px;">aside  {

width:  200px;


main  {

width:  calc(100%  -  200px);


It sounds like magic, right? Bear in mind, though, that this function’s support is less than 80% globally at the time of writing, so make sure to add a fallback for non-supporting browsers. 


Scalable Type


 Rem browser support is quite good, with almost 95% global support at the time of writing. It is supported by Internet Explorer from version 9, with the caveat that IE 9 and 10 lack support for styling pseudo elements and require you to specify the font-size values separately instead of in the shorthand format throughout.


You may want to look at the REM unit polyfill if you want to provide rem support for older IE versions (https://github.com/chuckcarpenter/REM-unit-polyfill).


Something else to keep in mind when building your typographic scale is that if you specify a unitless value for the line-height property (instead of one with a specific value, like me), that value will multiply the font-size value by the defined amount.


So if the font-size is 1 rem, the computed value is 16 pixels, and the line-height value is 1.5, it translates into the computed line-height value being 24 pixels (16 pixels × 1.5). This means you can set a line-height across all breakpoints, instead of defining one for each breakpoint, which will make your type even more responsive.


Mobile First, and Enhance Progressively


As part of the work you do on your CSS, consider refactoring it to work in a mobile-first way. This means the initial CSS rules are the ones designed for small screens, whereas the rules in media queries target larger screen sizes. 


If you currently use any type of media query in your CSS, it is likely following the opposite approach: the default styles target large (and perhaps medium) screen sizes, and separate rules are added in a media query to target smaller-screen devices. The notion behind this approach ties deeply with the principles of progressive enhancement.


When following the mobile-first principle, you usually start with a more linear representation of your content.


This simplified layout is likely to work well in old browsers and devices, as well as for screen readers and other accessibility aids, and it will form a good foundation on which more complex layouts can be built.


The process of simplifying your layout to work in a mobile-first kind of way falls mostly in the disciplines of design and user experience. But you can also apply this principle to your stylesheets independently.


Consider spending some time turning your CSS upside down. Depending on the scale and complexity of your existing stylesheets, this may be an easier or more difficult task, but it is worth it in the long run if you can afford it.


This exercise consists of moving all the CSS rules that are not relevant to a mobile-sized view into a media query. Let’s look at an example. Say your layout includes a sidebar and an article area:


And your CSS looks something like this:
article {
float: right;
width: 75%;
background-color: #f7f7f7;
aside {
float: left;
width: 20%;
background-color: #333333;
In a linear, mobile-first world, you can determine that your article area will be stacked above your sidebar, and both will fill the entire width of the container. In that case, your refactored CSS looks like the following:
article {
background-color: #f7f7f7;
aside {
background-color: #333333;


You remove the float properties because both containers are stacked; and you also remove the width properties, because they take the full width of the viewport.


The next step is to add a media query at the breakpoint where you want the original large-screen layout to kick in, and reinsert the float and width properties. Let’s say this should happen at a minimum viewport width of 700 pixels:

article {
background-color: #f7f7f7;
aside {
background-color: #333333;
@media screen and (min-width: 700px)
article {
float: right;
width: 75%;
aside {
float: left;
width: 20%;


This is, of course, a very simplified view of the type of work you will have to carry out, but the principle is always the same: outside of media queries should only live the styles that power a beautiful small-screen view of your website. As with anything else, you should make sure you test a prototype on real devices as soon as possible.


The advantage of this approach is not only related to the fact that you are progressively enhancing your layout with media queries. You are also slightly improving the speed of your page render.


When your browser attempts to render a page, it loads the HTML first and parses it to build the Document Object Model (DOM): that is, the structure of the page.


It also loads all of your CSS and builds the CSS Object Model (CSSOM), informing the browser how to style the page. Importantly, any CSS in a media query is marked as non-render-blocking until the media query has been evaluated.


This means although the entire stylesheet is being downloaded, the browser does not have to stop and evaluate anything in a media query that does not apply to the current viewport.


In other words, the critical content your browser is parsing first is all being used. For a device with a slower processor, this can only be a good thing, because evaluating, discarding, and re-evaluating stylesheets takes up valuable processor cycles.


Browser Support

Browser Support

At the time of writing, the global audience using a browser with media query support is of almost 95%.10 Only Internet Explorer 6 through 9 (released in 2011) and Firefox 2 and 3 (released in 2008) do not support media queries, so you may be tempted to ignore the small percentage of users with no media query support.


But 5% of global usage represents a fair number of people, so it is good practice, and important, to also consider the experience you are delivering to visitors using browsers that do not support media queries.


If your CSS has been created following mobile-first principles, this means non-supporting browsers show the small-screen layout, even on large screens.


This may be acceptable in your case, but depending on the number of users who are still visiting your website on older IE versions, you may have to consider using a polyfill that enables these browsers to understand media queries.


Respond.js (https://github.com/scottjehl/Respond) is the most popular polyfill for this effect. It weighs only 1 Kb when minified and gzipped, and it adds support for the media query types that are most relevant to building a responsive website: min-width, max-width, and media types. It is worth exploring it to see if it matches your site’s particular needs. 


Whatever way you decide to cater to older browsers, it is unlikely that you will be able to not use media queries on a responsive website, because they are so fundamental to the notion of what responsive is.


SVG Images

SVG Images

If there is only one thing you change in the way you deal with images on your new responsive website, it should be starting to use SVG images. As I mentioned in the previous blog, user interface icons, logos, diagrams, and illustrations are prime candidates to become SVG images.


SVG is not the best format for all types of images, though. More complex images like photos and complex logos are probably better as bitmap images. SVG lends itself to images that were initially created as vector graphics because it best describes lines, shapes, and flat colors.


When in doubt, compare the file size of the resulting SVG image with its bitmap equivalent. For complex images, in many cases, even doubling the physical size of the bitmap image will result in smaller file size than SVG, which compensates for the loss of resolution when the image is sized up.


When it comes to browser support, SVG has nearly 95% global support at the time of writing. If you want your images to display correctly on Internet Explorer 8 and below, you may have to rely on a polyfill or another fallback technique.


The same is true for IE 9 through 11, depending on how you need to implement your SVG images because these browsers support SVG only if used in certain conditions.

You can use Modernizr to detect whether a browser supports SVG, and serve it a different format image. This will not solve the defective support in IE 9–11, though, because these browsers do support the feature—just not at its full capacity.


Regardless of the downsides, the benefits of using SVG images where possible are manifold. The two key benefits are tightly coupled with the goals for which any responsive retrofitting project should be striving: fast and lean experience, and light but perfectly scalable graphics.


Picture and class='lazy' data-srcset


At the time of writing, global browser support is just over 60% for the picture element and just over 66% for the class='lazy' data-srcset attribute but growing quickly. And remember that if the browser does not support either of them, there is always a fallback image to rely on.


If you are wary of using this type of cutting-edge technique, remember what I mentioned at the start of this blog: you can always experiment on a smaller project to test the waters, and if it does not work for you, find another solution. This could also be a way to test the feasibility of existing polyfills, such as Filament Group’s Picturefill.


Even if you decide that these are not appropriate for your website right now, it is important that you look into them carefully: they will become ubiquitous at some point in the future, and learning them is key.

Image Caching


Good responsive images are not just ones that scale up and down with the viewport. They are also responsible images: they should not be larger than necessary and cause users to download more than they need to render the website on the device of their choosing. If your website uses the same images in more than one place, you should make sure you are always using the same instance of the image.


If you display on your website logos from partners or products, or user interface icons for things like search, shopping cart, and so on, anyone working on the website should never have to create a new instance of the same logo or icon. And similarly, a user who visits your website more than once should not have to download these assets twice.


You can create logo packs and icon packs that live in a central location where someone working on new designs can download them. Ideally, every time you need to reference them in your website, you should use the same source file in the same location. You should also ensure that your site’s server is set up to cache the images appropriately if you are not doing so already.


Compress Those Bitmaps

Compress Those Bitmaps

Often, when deadlines are looming, content and image creators are not necessarily paying much attention to the size of the images they upload onto content management systems—and many times, CMSs are not great at cleverly compressing images when they are unnecessarily large.


Another of my favorite exercises that you can follow when making your website responsive is to go through the website with a tool like YSlow (http://yslow.org/) to pinpoint the location of the worst offenders, so you can resize them for better performance.


Once you have a list of where the extra-large images are hiding—they tend to hide in the plain website, though—compress the bitmap images that do not need super-high quality or transparent background. This is a quick, simple way to reduce the file size of the images across your website.


A neat trick you may want to try when you want crisp images on Retina displays but still want to save on file size is to export the JPEG at twice its size using a high compression rate. Because you will not display the image at its original size, the fact that it is a little blurry will not be noticed.


Optional Images

Optional Images

Optional images are ones that are not crucial for the experience of your website. All decorative images fall into this category. I


If the image is added directly into the HTML, however, it will be much more difficult, if not impossible, to stop the unnecessary download.


It would be nearly impossible to cover all possible solutions for responsive images that are currently in circulation; but now you have a good overview of some things you can test and try on your retrofitting project, along with some key techniques to consider.


Bear in mind that, depending on your site’s needs and the types of images you are using, you may well have to apply more than one technique to build a solution that is best for your users.




Making sure you test your website and prototypes on real devices as soon as you begin working on your responsive retrofit is without a doubt one of the key ingredients for a successful project.


If you leave testing for later, you run the very real risk of getting too far into the build and the decision-making process before you spot big mistakes and bugs that could have been more easily and cheaply fixed at earlier stages of the project.


What to Test On and What to Fix

What to Test On and What to Fix

It is a good idea to define which browsers, devices, and operating systems you are going to test your website on. By doing this, you are not determining that you will not fix bugs or make improvements on anything else; this simply serves as a guide for your team, and other teams, to ensure that testing is conducted in a systematic and unambiguous manner.


Having a document and process that everyone follows, no matter who is testing or what is being tested ensures that your website will always comply with certain standards. Determining what to test depends greatly on your existing users.


A good starting point is to analyze your analytics numbers and see which devices are the most popular ones that people try to access your website with. The key word here is trying.


If you do not have a good mobile experience, it is unlikely that your analytics will reflect the same usage as if you did. Repeat visits would probably be higher, and the devices used most frequently might be different, too. Regardless, you have to begin somewhere, so existing numbers are perfectly acceptable.


Do not focus simply on mobile device data, though. You want to make sure your new responsive website has been tested across a wide range of browsers and operating systems, and that includes desktop-like environments.


I cannot tell you what the minimum threshold should be for your team to determine whether an issue should be taken care of; that is up to you and your special circumstances.


It is not possible to say that you should not fix any bugs for browsers with fewer than 1% of visitors, because 1% can mean an enormous number of people for high-traffic websites.


If your website gets 100,000 visitors per month, 1% translates into 1,000 users. If your website gets 10,000,000 visitors per month, 1% means 100,000 people.


Is it worth improving the experience of 1,000 people? What about 500? Or 100? That is a question that only you, your team, and your company can answer.


You should also check the most popular current devices and combinations of browsers and operating systems. Your own analytics may not reflect the current state of affairs, but that does not mean it will stay like that once you release your beautiful new responsive website.


BrowserStack has created a very convenient list of devices and operating systems that you should be testing on, based on global trends. This list is updated frequently, so it is a useful resource when determining which devices to add to your testing guidelines and keep on hand. Remember to add tricky operating systems and browsers to your testing protocol, too.


Make sure you do not just test on easier ones, like the latest iOS phone and tablet and the latest Android release. Test on older versions of these operating systems, and on non-default browsers, such as Opera Mini and UC Browser, which are popular in China and India and have an expanding user base.


Build Your Device Lab

Build Your Device Lab

The idea of having your own set of devices to test on can sound like an expensive endeavor. But you can build up a device suite, even if you are on a tight budget, by considering your analytics and which devices your visitors are using.


Building your own device lab should be something you do early in the project because you want to start testing as soon as possible.


Just as I recommended in the previous section, fall back on your site’s analytics data to see the devices on which people are using your website. This will give you a better idea of which devices are more of a priority for your team to get access to.


Once you have a wish list of devices you feel are important for you to own, there are a few things you can do to put together your own lab:

  • Use auction sites like eBay to get a better deal on new or like-new devices.
  • If you decide to not spend on more expensive devices like iPhones and iPads, there is money left in the pot to buy a larger number of other devices.


  • Ask if anyone in your company and your team has old devices that they do not use anymore that they would like to donate. People tend to forget about these at the bottom of their drawers, so it is always worth asking.


  • Set up a dedicated testing machine that runs several instances of Windows and Linux with different versions of Internet Explorer and other browsers that may be relevant for you to test on.


As the project evolves, your device suite will likely grow as your needs change. After you release the first iteration of your website, whether you are doing it in a closed way, internally, or open to the world, people will begin to access your website from devices that you may not have tested on.


An easy-to-follow strategy to expand your device lab is to acquire devices with operating systems from which you receive a fair number of bug reports.


As I said before, ideally, you will be testing on your own set of real devices; but you can also consider using a public device lab if there is one in your area. In some cities across the world, there are Open Device Labs, which are open for designers and developers who wish to test their sites across a multitude of real devices but do not have a suite of their own


Emulators and Other Tools


Even if you build the ultimate device lab, you will not be able to physically have all the possible devices people may use to browse your website on. Several tools can help you fill in the gaps when the real deal is not available or if you are working from another location but still need to do testing.


It also lets you securely test sites that live on development and staging environments, which is extremely useful particularly in the early stages of the project.


Another useful tool to have in your arsenal is Ghostlab (www.vanamco.com/ghostlab/). It performs a different purpose than BrowserStack: Ghostlab makes it possible to test simultaneously on various browsers and physical devices.


So if you are testing a certain interaction pattern on a specific page, whatever you are doing on your computer also happens on all the other connected screens at the same time.


You can even inspect the CSS and markup on one device, make changes, and see them reflected in all other devices. Very neat, right? Ghostlab also supports Sass, Less, Haml, CoffeeScript, TypeScript, Jade, and Stylus, and testing on development environments.


Finally, Percy (http://percy.io/) is a visual regression tool that integrates with your continuous integration. If you already have CI set up, this is a great little addition.


Percy takes screenshots of your website before and after you make changes to the CSS and push them to the server. It also, gloriously, allows you to test your responsive designs.


You can give the service a list of breakpoints, and it takes and evaluates browser screenshots to check how the CSS changes have affected your website on the desktop as well as mobile devices.


Regardless of the number of devices you have, or whether you need to use emulators, testing is a vital part of any responsive design project and should be performed constantly and consistently throughout.


Whether you have a very small or a sprawling suite of devices to test on, or you rely mainly on emulators and other tools, make sure to instill on your team the need to test early and often in a responsive world.


Improving Your Process


It is well beyond the scope of this book to go into any kind of detail about the many and varied options available to development teams today. But there are a handful of principles you may want to strive for as you think about how to improve your team’s processes and workflow. 


As I hinted earlier in this blog, undertaking a responsive retrofit is a great opportunity to take a look at your working processes when writing, publishing, and maintaining code. Let’s dive in.


Writing Code and Markup

Writing Code and Markup

When working in a team, you can follow a few core principles to make writing HTML, CSS, and JavaScript a more pleasant experience for everyone.


Focusing on the quality and robustness of the code is important, but almost as important are the factors that matter most when you are knee-deep in stylesheet declarations or buried to the nose in HTML: consistency, readability, and predictability. Establishing a few rules and guidelines will help everyone collaborate and contribute consistently.


Have a Markup and Code Style Guide

It makes sense to formalize the conventions you are using. Write them down, share and use them, and do not forget to update them, too. 


If you do not already have a style guide covering markup and code conventions, there are several good examples you can use as a starting point. For instance, the guidelines for Primer (http://primercss.io/guidelines/), the framework that powers GitHub, are a good, open source example to take inspiration from.

Have a Markup and Code Style Guide

So, what best practices should a style guide cover? The answer depends on how you work, the projects you are working on, how many people are on your team, and other individual factors.


The key is ensuring that your guidelines help you avoid confusion and conflict within your team and make things clear for new starters. Consider including guidelines about the following:


  • How to format HTML markup.
  • How to use indentation and spacing consistently.
  • How to mark up specific elements, like forms and tables.


  • Class-naming conventions. The use of prefixes, capitalization, and underscores can help identify what type of class you are dealing with.
  • How CSS declarations should be formatted. This removes doubt when writing your stylesheet, and makes reading and updating it easier, too.


  • How to use whitespace in your documents to aid readability.
  • Whether to use tabs or spaces.
  • How and when to write comments.


  • Documentation practices in general.
  • How to write tests, what to test, and when.


  • Source-control workflow, including best practices for commit messages and pull requests.


If you are using Sass, your guide should also cover best practices regarding things like how deeply you should nest declarations, which helps to limit specificity issues that result from a too-deeply nested stylesheet.


 The key is to have guidelines that work for your situation, are consulted and updated when conventions change, and help your team work together with less friction.


Using Sass Responsively


As you are toiling away in your text editor, one of the things that can cause more agony is having to repeat yourself unnecessarily.


Typing #ff69b4 over and over is not much fun; and if you grow tired of hot pink, having to find and replace all instances over several stylesheets will seem like a chore. This is the kind of problem preprocessors exist to help you with.


Simply put, preprocessors are scripts that take a file in one format, manipulate it in clever ways, and output the converted result at the other end. Although there are preprocessors for HTML and JavaScript, I am focusing on CSS in this section because it is likely the one most relevant to the process your team will be undertaking during a responsive retrofit.


Sass also fills in and makes some of the shortcomings of CSS easier to deal with: it provides variables, nested declarations and properties, mixins, functions, and much more.


If Sass’s only feature was variables, it would still be worth using. By defining all of your site’s colors, measurements, and grid layout in one place, you can abide by the Don’t Repeat Yourself (DRY) directive and save countless tears, both when writing and when maintaining your website.


One example of how variables can help in creating a responsive stylesheet is in the definition of the grid. Let’s say you want to define a simple grid with a set number of columns and a defined max-width. Keeping these values in a central location means you know where to go looking for them.

You can name the file anything you like, but _variables.scss has a nice ring to it. If you are curious, the underscore prefixing the filename tells the Sass compiler that the file is partial: it will not compile this file into CSS, because the file’s purpose is to be included in other Sass files using the @import directive. Put your grid and column definitions in this file:


Defining our grid and columns $grid-max-width: 55em; $col-num: 12;


As you will have noticed, Sass variables are prefixed by a dollar sign ($), making them easy to spot when used in the stylesheet. When you enter the variables to use, they look like this:

  • We need to include the part in our SCSS  stylesheet.
  • Note  that  we  do  not  need  to  include  the  underscore  prefix


Usually, variables are used several times throughout a stylesheet, saving repetition when you have to change or update values. There is a case to be made, however, for keeping values that you only use once in a stylesheet as a variable too;


Doing so gives you one central point—your variables partial—where you can go to find all the relevant, crucial definitions for your website, such as color, grid measurements, typographic scale, and more.


Organizing Your Stylesheets


There are several considerations when writing CSS; and as often is the case, these considerations can be conflicting. You want to write lean, efficient CSS, and you want your CSS to be performant;


But you also want CSS that is easy to maintain. The good news is that with a few tricks and tools, you can have your CSS cake and eat it too. It just requires some thinking ahead.


It probably makes sense for you and your team to split the site’s stylesheets up into several files dealing with distinct areas of your website. This is not required, and some teams prefer to work with one or two larger stylesheets.


But separating your CSS into different files may provide some flexibility in your workflow and make your styles more manageable, as long as everyone knows the structure and follows the conventions.


When serving the website, however, having several stylesheets is a bad idea, because each request slows down the website. Luckily, our great web developer community has already solved this kind of problem with the introduction of build tools.


These tools let you maintain a working environment where your stylesheets are logically separated and well commented, and rules are spaced out and easy to read, maintain, and contribute to. When it is time to ship, the build tools take care of all the grunt work, such as


  • Combining separate CSS files into one
  • Ensuring that the caching for CSS assets is set correctly so they do not have to be fetched again when you return to the website
  • Replacing the notoriously slow @import directive with link tags


  • Ensuring that your CSS is always placed before any script tags in your document head
  • Inlining layout-critical CSS to really turbo-boost the initial rendering of the page


Depending on the particular stack you are working with, the best tools to use will vary, but the key objectives remain the same. The beauty of working with Sass, or other tools with similar functionality, is that you can break up your stylesheets into as few or as many separate files as you like.


When it comes to testing or making the website live, the separate stylesheets will be concatenated, which is another way of saying they will be combined. This reduces the number of time-consuming requests the page is required to make to the server, thereby speeding up your website.


How you break up the stylesheets is a matter of taste, but common wisdom dictates that keeping common variables in one place is a good idea. You can then consider breaking up specific items by theme:

  • Typography
  • Grid and layout
  • Color
  • Buttons
  • Forms
  • Tables
  • Reset styles, and so on


You can also add separate stylesheets for CSS needed for components from third-party sources, like a date picker library or a slideshow plug-in. It usually makes sense to keep these in a specific folder, perhaps called the vendor, to differentiate them from the in-house styles you developed.


This also makes it easier to find that particular piece of CSS when you need to remove or update a third-party resource.


The amount of work involved in adding consistency to your markup and your code can be substantial and perhaps unfeasible within your time constraints. It is, however, something that is worth investing in, because robust, flexible code can save you considerable time and effort in the future.


Publishing Your website


The process of publishing your website is an area where you can make tremendous improvements with a few lines of code. Several tedious tasks can benefit greatly from a sprinkling of automation.

There are some things you should consider adding to your build process:

  • Minifying your documents
  • Removing comments
  • Concatenating stylesheets
  • Ensuring that your assets are cached appropriately and perhaps served from an asset server


Forty years ago, Bell Labs developed Make (https://en.wikipedia.org/wiki/ Make_(software)), a program for the Unix operating system. Still widely used today, Make works by taking instructions from a text file to transform source code files into working software.


Most of the build-automation tools in use today, which help you through the process of publishing HTML, CSS, and JavaScript, work on the same principle: they run through a list of tasks, doing what computers do best repetitive, predictable chores. 


Most of the deployment tools used today can be tied into the version control system of your choice and are based around a workflow that assumes the existence of version control.


If you are not using version control for some reason, this is the time to set that straight. In his pocket book Version Control with Git, Ryan Taylor has outlined how to get started with Git, and version control. It is worth a read for the uninitiated (https://gumroad.com/l/rXch).

The build tools, sometimes referred to as task runners, can help with repetitive chores relating to development, testing, optimizing assets, and deploying your website to the server. Here are some of the popular tools you can use to help you automate the most tedious tasks:


  • Rake (http://guides.rubyonrails.org/command_line. html#rake) is a Ruby implementation of Make. It is most commonly used to create a list of tasks that need to be completed in a specific order, much like a recipe. Although it is associated with Ruby on Rails, you can use Rake to help automate any manual build process.


  • Grunt (http://gruntjs.com/) is another build tool that can help with the chores involved in building a website. It has its roots in JavaScript and Node.js (https://nodejs.org/) development, and you write the list of tasks you want it to run in JavaScript. It has a solid reputation and community around it, meaning most of the tasks you will need are available as plug-ins.


  • Gulp (http://gulpjs.com/), a challenger to the Grunt throne, has features and requirements very similar to Grunts. Gulp can run several tasks at the same time, giving it a reputation for speed.


  • Brunch (http://brunch.io/#why) is a lean, fast, simple tool for the most common build tasks. Like Grunt and Gulp, it uses Node, and its recipes are written in JavaScript.


  • CodeKit (https://incident57.com/codekit/) differs from the other tools on this list in that it does not require you to use the terminal—it is an app with a nice-looking GUI. Like the other tools on the list, it allows you to compile and optimize your assets, check the quality of your code, and more.


Most of these tasks sport a command-line interface (CLI), meaning you invoke and run them through the terminal. There are many tools on offer, and they all do a good job of relieving you of the type of tasks a computer does much better than any human.


If you are not sure which tool is the best one to pick, choose one, try it, and keep on trying until one fits your needs. All the tools on this list will free you to concentrate on more important—and more creative—matters.


There are many things you can do to your writing and publishing processes that can save you time and effort. They all require some initial investment as you investigate the best tools for you and change the ways in which you are used to working.


Measuring Success After Release


The feeling of accomplishment after you finally get to release your new responsively retrofitted website is terrific. But even if you managed to make as many changes and improvements as you wanted, work should not stop there.


You need to make sure the hard work has paid off in a positive way, so it is important to have defined ways to measure success post-release. You can do this in simple or in extremely complex ways.


Here I give you a few ideas about what you should keep an eye on before and after you publish your new website to get you started if you haven’t done so already.


Once your website is up and running, you want to make sure it keeps running smoothly and that you are alerted when something goes wrong. In addition to monitoring the health of your site—uptime, server capacity, and database connections, for example— you should gather insights on your site’s visitors.


One metric you should keep an eye on is the number of users visiting your website on mobile devices. Remember that the numbers after release can be a bit skewed.


Because previously the user experience of your website on small-screen devices may have been too painful to navigate. But an increase in mobile visits is nonetheless something to celebrate, if not to be expected.


You also want to make sure you are tracking the following before and after release:

  • Drop-off rate
  • Session duration
  • Repeat visits
  • Key journeys, such as logins, signups, and checkouts


Each website and organization will have different ways of measuring success. Page views, shares on social media, advertisement revenue, active users, new signups, number of successful checkouts, visit length, number of pages per visit, repeat visits, and even how fast the visits are can all be good indicators of how well, or not, your website is doing.


The most important takeaway is that whatever metric you have determined defines success for your website should be tracked before, throughout, and most certainly after release.


Also consider how visitors to your website can provide feedback if they wish to. This is particularly important in the first few weeks after release, when the website is new and people are more likely to comment on anything they think may be wrong with it; but it is important to consider doing this in the long term, too.


If you make it easy for users to submit feedback and bug reports, your users will provide an important and invaluable layer of testing that you would not be able to replicate on your own.


There are a few relatively simple and, most important, inobtrusive ways in which you can do this:

  • Create a form (like a Google Form) to capture visitors’ feedback, and add a link to it on your website
  • Include a feedback button on your website
  • Include a mini-survey directly on your website, with one or two key questions you want to know more about
  • Add a link to submit a bug report directly to your issue tracker, ensuring that there are guidelines on how to do so

You can also consider something more sophisticated, like using a product such as Intercom.io (www.intercom.io/;, which allows you to engage with your users in a much more targeted and customized manner.


Do not let the momentum die down. Your team’s schedule is probably fully packed for the weeks and months after the release of your newly responsively retrofitted website.


But if you planned subsequent stages into your schedule, and if you have captured all the other things you want to improve in your backlog, you should be able to keep on improving.


The next phases of your project may be much smaller than the first push to go live. You may want to divide the subsequent work into smaller projects that tackle a specific problem or enhancement.


And this list of projects is probably never going to be completely finished because you are sure to see the potential for improvement in many areas of your website. But that is the nature of our work.


Experiment on Smaller Projects


When responsively retrofitting your website, in addition to simply making it responsive, you probably want to take the opportunity to introduce new technologies and ways of coding and building the website that can improve it and benefit your team’s processes.


But, many times, making those changes on a project of considerable size can seem like a daunting prospect. If this is your case, consider trying and testing new things on smaller projects.


It is less scary to try something new in less conspicuous and less complex projects, rather than jumping straight into the main website. When you try out new ideas and assumptions on smaller projects, it is easier to take a step back if something does not work out as planned.


It is easier to revert changes, fix bugs, or try something else entirely. And if something goes wrong, it is also likely to affect a smaller number of people.


The things you can test on a smaller project do not necessarily have to be code related. However, it is on the building and coding side of things that have to deal with a bigger website and code base usually makes trying new things more complicated.


Here are a few things you can consider testing on smaller projects:

  • Using scripts you have not used before, like Modernizr
  • New image solutions, such as moving to SVG images
  • New responsive typographic scale
  • Modern CSS techniques, such as flexbox
  • New design and interaction patterns, like a new navigation menu pattern
  • Improvements to the build process, such as the addition of minification and concatenation of stylesheets
  • New testing procedures, including automated tests
  • A/B testing


There are countless more things you can consider trying on a smaller scale before you commit to them on your larger website. The key idea to keep in mind is that a change in the way you code and build your website does not have to be tested in its final location—the main site—and that smaller projects can serve as a playground for trying cool new techniques.