Armaan Bhojwani


Published on

On Bad Web Practices

This is a continuation of post 003 with more general thoughts that I have about what plagues the web today, and how to fix it.

Insecure server settings

Mozilla Observatory is an online tool that checks server settings and HTTP headers to see how secure they are. This website earns a 120/110. If your website is unable to earn a good score because of how its designed (fetching lots of external resources, using iframes, javascript, et cetera) it may be time to revisit how it is designed. Design should never come at the risk of security.

Printing badly

I shouldn't have to find some little print button to open a popup with a printable version of the website (recipe sites especially are often guilty of this). A CSS media query which hides background images and unnecessary elements is easy to implement, and makes printing web pages easy. Modern "responsive" sites seem to be impossible to print nowadays, always picking up unnecessary images, and not scaling correctly. If I wanted to print out the design of your site, I would take a screenshot and then print that. If I want to print the content of the website, I should be able to just hit and get a nice readable layout.

Bad browser compatibility

If you call yourself a web developer and only test your sites on Google Chrome, you're not a web developer, you're a Chrome developer. A website has no excuse for looking bad on any of these six platforms: Chromium, WebKit, Firefox, Internet Explorer 11, Lynx, and W3M. Bonus points if your site supports Netsurf.

The most overlooked of this list are Lynx and W3M. These are the two most popular text based browsers. While most people don't use them to do their daily web browsing, they are essential when missing access to a graphical session or mobile device to look up web documentation. Obviously the layout of your website will be rendered differently, and there will be no images (unless using W3M under special circumstances), but the content should be readable.

Firefox, Webkit, IE11, and Chromium all have very slight differences in how they display certain CSS rules and execute Javascript, so its important to always test on all four platforms. One of these engines is used in essentially every modern web browser, so if a site works on all four, then compatability should not be an issue. Chromium also has some technologies which are specific to it like WebUSB. Don't use WebUSB! See the next point.

Websites doing things that websites shouldn't do

If your website is interacting with lots of hardware, needs to stay open for an extended period of time, or needs a brand new web technology for core functionality: it shouldn't be a website! Instead, develop open source desktop applications. The browser is a place to share documents, not a way of running hyper-interactive applications (although it has become this).

Bad image optimizations

Many websites don't properly optimize images, leading to slow load times and wasted bandwidth. Images should be converted to WebP (or some other modern format) on the server and compressed. If possible, preserving a copy of the original image so it isn't lost, however only serving the optimized image to the end user. For reference, the portrait on the front page of this site, started as a 232kb jpeg, and after being resized, converted, cropped, and compressed, it is now just 4.7kb. That's two percent of the original size! If every website did this, the overall size of the web would decrease massively.

No compression

Adding gzip and zstd compression to a website is just a few extra words in any modern server config, and on modern hardware, does not add much toll to the CPU. In exchange, you save lots of bandwidth both for the server and the client. There really is not reason not to do it.

Bad accessibility

There are two easy ways to improve accessibility on the web: high contrast mode, and screen readers.

Personally, I don't use high contrast mode when browsing the web, however many people do, usually to compensate for visual impairments. Supplying an alternate stylesheet with a few rules increasing the contrast of text can go a long way in making the web accessible to all.

In addition, "skip to content" buttons that only appear when focused are a major help to those using screen readers and text-based browsers, so they don't have to waste time listening or scrolling past all the junk in the menu system if they are already at the page they want to be at.

Useless loading spinners

Nothing makes a website feel slower and less responsive than a loading spinner that spins before each page is loaded. I appreciate a loading bar with a verbose output telling me what is happening if the website actually needs to prepare things behind the scene, however if the website is just fetching more resources, I don't need to be shown a spinning wheel with no actual indication of progress on it.

Javascript where CSS would work

CSS can be surprisingly powerful with animations and calculations. Oftentimes Javascript (escpecially jQuery loaded in from a CDN) is used to replace CSS where pure CSS would do fine. This just makes the site less accessible, and further makes the web reliant on Javascript.

Basic content not loading without Javascript

I generally don't mind sites that include Javascript for basic extra features, animations, and menus, however if not enabling Javascript stops the text of the webpage from loading, then this is a big issue. It makes it impossible to view the site without enabling Javascript, which means that it can only be viewed in a GUI browser. This usually means loading in Javascript from external sources as well, which is an attack on the user's privacy.

No RSS/Atom feed

RSS and Atom are great standard systems for sharing blog content. I don't want my inbox mucked up by your mailing list, and I'm not going to visit your website just to see if you've posted something new on your blog. RSS lets all the blog content from any website be viewable right from a central system. Luckily, most site generators still generate RSS feeds, even if the web admin does not put a clear link to them. Usually the feed sits at /rss.xml, /atom.xml, or /feed. If you purposefully disable RSS generation, or create your own SSG/CMS without RSS support, you will alienate a large portion of your audience who rely on RSS to keep track of multiple blogs.

The links of the post