back |

Best Practices for Web Design you might not have heard of

There are several articles about good practices in web design out there on the web. However, a lot of them sound the same and lack some meaningful insights and advices. I won't copy what has been published a hundred times already. Instead I consider this article here as an addition to all the good articles about the best practices in Web Design.

Don't make use of third party scripts

A lot of webmasters use scripts that someone else has written. Especially in old web circles a good chunk of websites make heavy use of JavaScript. This is totally fine but let me tell you why you should download and self-host the script instead of letting your visitors browser fetch it from someone elses webspace (be it the script authors webspace or any CDN out there). While using cross-site origin scripts aka third party scripts is very convenient, it comes along with some privacy and security concerns. You can read about the privacy related stuff here

Besides privacy concerns, letting users fetch scripts from a third party can potentially endanger visitors of your webspace and even yourself when browsing it. This is because you can't control the content that gets delivered. If a script author goes mad, his webspace gets hacked or a cdn gets compromised and starts to deliver malicious code instead of the script/font you had in mind when coding your website, you put a risk on everyone using your website. When browsing other peoples websites, you can mitigate this risk by hardening your browser against cross-site origin scripting attacks. However, best practice for coding your own website is to host the scripts / fonts / images whatever yourself, on your webspace.

In many cases downloading the script file and hosting it yourself will do the trick. But there are some use cases, where this won't work. And there as well are good reasons to rely on the usage of a CDN, if you make use of bigger scripts / frameworks and your webspace couldn't handle the load (many users at the same time while your website is being served from a lower quality shared hosting provider for example). Transparency: I am making use of third party scripts on my current personal homepage myself. The rotting fishtank on my main page is an example (because I trust Melooon! and believe in the one and only melon king) that wouldn't work the same way when I would self-host it on neocities. At the moment, my guestbook is served from the atabooks webspace (which to my discomfort as well loads a cloudflare captcha to fight spam). I will think of a way to make both features available without relying on 3rd party scripts (When I stop writing articles for you, which really is time consuming to say the least).

How to hyperlink properly within your own site structure

Why the difference between absolute paths and relative paths makes so much of a difference. Most people place hyperlinks by using the absolute path (linking to their Top-Level-Domain (or subdomain) and adding the path to the file). This seems logical but it has some downsides. Instead of linking to https://example.com/folder/filename.html you should instead link to /folder/filename.html Both of these point to the same file (as long as you are linking to content on your own domain / webspace. However, the latter has some serious advantages.

When you move your website to another domain (lets say change from neocities to nekoweb or you get yourself a real domain name), you don't have to update all of your links manually
You can significantly reduce the size of your webpage making it load faster (you won't notice it that much on a high speed line or if your host enforces gzip compression or the likes but it still is measurable)
Allows for your site to be accessible from different url's (example.neocities.org as well as example.com and www.example.com as long as they point to the same webspace)
By not specifying http or https in your links, you don't enforce the transfer protocol. Instead the transfer protocol used by the visitors browser to connect to your site in the first place is used
By not specifying the transfer protocol, users relying on old browsers can still visit your site (if you/your webhoster doesn't enforce https)

You can use this technique for all "links" and even load scripts and images this way.

Easiest approach to make use of relative paths

Think of an image located inside a folder named images in your root webspace directory (example.com/images/picture.jpg) and you want to show this image on a webpage located in example.com/my-recipes/monkey-brain-ice-sorbet/recipe.html. The most used way to specify the path will be the use of

<img src="https://example.com/images/picture.jpg">

but instead you will use:

<img src="/images/picture.jpg">

The / at the beginning refers to the domain root (root directory of your public webspace) and after that refers to the image picture.jpg inside the images folder. It doesn't matter if you change your domain as long as the hierarchical folder structure stays the same. You can just upload your old files to your new webhost or move to another domain and everything will work as before.

This works as well for scripts, .css, fonts, cursors etc.

<a href="/images/gallery.html">Gallery</a>

for example will do the same. Link to the file gallery.html located inside the images folder on the webspace.

<link rel="stylesheet" href="/css/style.css">

includes a stylesheet located inside the folder css (example.com/css/) You can as well make use of documents or scripts located further down in the folder hierarchy.

<script src="/stuff/javascript/stupid-example-folder-name/boring.js"></script>

for loading the javascript boring.js located in example.com/stuff/javascript/stupid-example-folder-name/

Making use of ../ in your link structure
This is another approach but isn't as foolproof as the above because the usage relies heavily on the filepath of the current document. We will use the same example as above, image located in the folder images in your webspace root and you want to show this image on a page: example.com/my-recipes/monkey-brain-ice-sorbet/recipe.html
You can do it this way:

<img src="../../images/picture.jpg">

The ../ indicates that the image you refer to is located a level up in the folder hierarchy. Using it two times points to the root of your webspace (because recipe.html is two levels further down in folder hierarchy). You have to adapt this technique when dealing with more folder levels, e.g. add another ../ or use one less to make it point to the right filepath.

Hint: When using this technique on your local windows machine and it doesn't seem to work, you might have to use a backslash instead of /, for example: "..\..\index.html" instead of ../../index.html. When hosting your website online, you should always make use of the regular slash.

Use JavaScript only if it is necessary

When creating a website, you can be considered as an artist. To make your vision come to life, in some cases JavaScript is a necessity. In a lot of use cases it isn't and can be considered as a gimmick. I would strongly advise you to create your websites in a way, that doesn't hinder users from browsing your website in a proper way when they have chosen to disable JS in their browser. Instead of making use of a JavaScript navigation menu for example, you could as well achieve a similiar functionality by using css only. But like I said, in some cases CSS is not enough.

So if you really want to show off your skills as a webmaster, you can provide a JS navigation menu and a fallback option, a simple html navigation menu by making use of the <noscript> element (see below). The same approach should be followed for each script and if there is no proper fallback option, at least include a message that tells the user that a JavaScript should be present here but couldn't be loaded.

Use JavaScript if necessary but provide a fallback

A website in general should remain its main functionality even when the user has disabled JavaScript in his browser settings or if the browser in use doesn't support JS. This is something I truly believe in.

To make the user aware that his browser settings keep him from using the site in the way you had envisioned, you might drop him a message:
<noscript>This site makes use of JavaScript but my scripts didn't load because you seem to have JS disabled</noscript> Instead of showing this message, you could as well put any other HTML code inside the <noscript> tags as a fallback option when JS is disabled.

Example given: A JS navigation menu isn't available to the user, present him something like this <noscript><a href="/home.html">Home</a> | <a href="">Blog</a></noscript> as a fallback option.

Provide navigation options at the end of your content

When you read through a text on a website, especially if it is a longer text, you should give the user an option to navigate around at the end of your content because most users will have their mouse cursor somewhere in the lower thirds when scrolling through your content. This way the user doesn't have to scroll all the way up to the navigation menu or to make use of the browsers back button.

A simple approach is to display a link that refers to an anchor point inside your html document To do this you simply have to add an empty hyperlink as an anchor point at the top of your content (inside the body tags):

<a name="scrolltotop"></a>

And at the bottom of your content, place a visible link that refers to the anchor point "scrolltotop" by making use of something like this:

<a href="#scrolltotop">Scroll to the Top</a>

The # in front of the anchor name states, that the browser should not leave the current page and instead jump to the anchor.

A javascript back button with a fallback option
A more sophisticated approach is to make use of a JavaScript that checks if there is a browsing history present and if so, presents a back button or link to the user. This link doesn't get shown, when the site was opened in a new tab/window or no history is present.

Simple approach to show a link that takes the user back to the page he has visited before
This approach shows you how to present some kind of back button functionality to your user while still maintaining operatibility for browsers without JavaScript support

Add this to your source code where the "back" link should occur

<p><noscript><a href="/">read more on my homepage</a></noscript><span class="backtothefuture"><a href="#">back</a> | </span>read more on my <a href="/">homepage</a></p>

If JavaScript is disabled, the user instead gets shown a simple link to the homepage (the noscript part). Otherwise if there is a browsing history present, the user sees the link back which takes him back to the previous page on your site.
I added the read more on my <a href="/">homepage</a> at the end (you might delete it) to provide a link to my domain root/homepage in case JavaScript is enabled but there is no browsing history present in the current browser window/tab.

To make this approach work, you need to put this JS snippet in your html. Best practice would be loading it at the end of the document to make the visible parts of your page load without loading the script first.

<script> 
(function () {
const tuffyshistoryride = document.querySelectorAll('.backtothefuture');
const visitorlocation = window.location.pathname;
let tuffhistory = JSON.parse(sessionStorage.getItem('tuffhistory') || '[]');
tuffhistory.push(visitorlocation);
if (tuffhistory.length > 10) {
tuffhistory = tuffhistory.slice(-10);
}
sessionStorage.setItem('tuffhistory', JSON.stringify(tuffhistory));
const isfirsttimevisit = tuffhistory[0] === visitorlocation;
const hasahistory = tuffhistory.length > 1 && !isfirsttimevisit;
const whereareyoufrom = document.referrer;
const beenherebefore = whereareyoufrom && new URL(whereareyoufrom).origin === window.location.origin;
const visitedpages = window.history.length;
const enablewarpspeed = 
(visitedpages > 1 || hasahistory) &&
(!whereareyoufrom || beenherebefore);
if (enablewarpspeed) {
tuffyshistoryride.forEach(backhref => {
backhref.style.display = 'inline';
backhref.addEventListener('click', (e) => {
e.preventDefault(); // prevent <a> default navigation
history.back();
});
});
}
})();
</script>

Always load scripts at the end of your document (if possible)

Like I have mentioned before, making JavaScript load at the end of the content usually is considered best practice. There are use cases where your JS needs to get loaded sooner but keeping them at the end of your content, e.g. below the footer area is considered a good practice in general. Just make sure they stay within the html body.

Making your website more accessible

Make use of the ALT attribute

For users that rely on the usage of screen readers (blind people or analphabets as an example) having an ALT text present is mandatory to understand parts of your content or to navigate your site properly. Especially when using images to show meaningful content. An ALT text is as well shown to the user if the resource (e.g. an image) couldn't be fetched from the server (404, whatever). It as well helps search engines to better understand the content of your website. Making use of ARIA labels plays another big role in making your website more accessible. I haven't implemented all of this yet on my website because I didn't find the time to do it. But it is on my priority list. I will write an article about this topic when I have found the time to update my site accordingly to my preaching of good practices in web design.

Optimize for desktop and mobile users

Even if mobile users aren't your targeted audience for whatever reason, providing them with a smooth browsing experience should be out of question. Your website should display well at different resoluions no matter of what browser or device the visitor is using. This isn't an easy task sometimes but you should maximize the usability for all kinds of users. Having a responsible design is mandatory IMHO.

back |