4.4: Set up necessary error pages and redirection links - low page weight goal for 404s

[codewordcreative]

Original:
"4.4 Setup necessary error pages and redirection links
Success Criterion: Error pages Machine-testable Resources

Maintain sites by ensuring links are correct, and if errors occur, provide suitable way-finding within optimized pages for each error type to ensure resources can be identified to help visitors complete the task they started.

This text is already under review, but I checked and the content issue I am raising here is still present and needs to be discussed transparently, as it affects the content. It's in the hosting section, but it is arguably also a UX matter, maybe even a web dev one.

Arguably, a 404 page is one of the most visited pages on any website. Any crawler looking for vulnerabilities will hit it - hence this being a concern even if your security is fine.

As such, the page should be kept as lightweight as possible. The trend towards fancy animations and large images just isn't sustainable.

For example, skipping the global CSS, using system fonts, and maybe at most a lightweight SVG are all possible alongside links to help people on their way.

Incidentally, this belief that 404 pages need to be tiny is already supported by one of the existing resources, which points out how these are often over 1 MB.

Related proposal: Review the resources to ensure they fit this principle. This one, for example, suggests having a large graphic. I beg to differ, since the majority of visitors to a 404 page won't even be human...

[airbr]

This idea makes a lot of sense to me, although unsure of what the exact wording could potentially be.

The 404 page should be more durable than a regular page in terms of a guideline, keeping in mind progress over perfection and so on. It could still be designed to be welcoming or charming, just the other longer term and wider needs would argue in favor of a more durable page to help reduce emissions from bots and such.

Supported by considering another Guideline:

• Use the most efficient solution to implement your service

Good stuff 👏

[codewordcreative]

There's already a good rewrite of the existing guideline behind the scenes. But yeah, I think it just needs a couple of words. Maybe... "Keep the size of 404 pages minimal, as the full HTML is transferred alongside every 404 response. It is one of the most visited pages on every website." - Maybe? Could mention non-human and crawlers etc., but yeah. It needs to be user-friendly but it should do that without images and animations. :D

[AlexDawsonUK]

The reason why the "404 and redirect pages" guideline is located within the hosting section is because it is server software that defines how HTTP status messages are handled like redirects (301) and not found (404) are actioned upon. You may of course use cPanel or third-party software to establish these pages using a user-friendly GUI but this is (again) done within the remits of server software and therefore it makes sense to have the content where it is.

The content within that page has UX and Web Dev implications (naturally), but those implications are already well covered by other guidelines (excepting a gap that isn't already done as such). Talk of keeping things lightweight, using system fonts, and other such matters is a duplication of what we already have elsewhere in the WSG.

[airbr]

Good point about the other content, we do have the guideline for using optimized fonts already elsewhere

[codewordcreative]

Yeah, I was more thinking of what can be done than what to specify.. Perhaps a note simply to consider/remember that the full HTML is sent with every response, so avoid unnecessary data? I do think we should be specific because of the whole custom 404 page trend among web devs. Arguably, a static html 404 would also be good even for sites otherwise using a database-led CMS.

[AlexDawsonUK]

Custom (dynamic) 404's have many benefits:

• Rather than being a generic "you're lost, oh well" page, they can help people locate what they were actually trying to find within the information architecture thereby reducing clicks, wasted pageviews/sessions, and data transfer.
• Unlike static html files, personalizing each page allows for better engagement when issues do occur to encourage feedback on serious errors to resolve them properly rather than to "move on" or abandon the effort.
• For certain types of HTTP responses, they can be customized to improve things like accessibility and data privacy (depending on the type of information that is required as part of the response).

A site should go totally static only when a site doesn't use a database (a simple site/app/SPA) or if it suffers downtime and thereby the interaction capability will be at risk of issues, though we don't need to mention this within the WSG as again issues of downtime or connection instability are covered by other guidelines.

There is no link that I can find between static over dynamic in HTTP response codes and being more sustainable. At least nothing that isn't reaching into other Success Criteria (that is other subject-based).

[codewordcreative]

Regarding those objections - that's all valid, if you have the setup to work with whatever the 404 response is. So perhaps let's not instruct that static 404s are a must have. Dynamic can have benefits...

However, none of that goes against advising to keep the page weight small. The videos, animations, and large images do not add to user experience enough to justify the data transfer. Links to helpful content can be incredibly small - and even on a dynamic page, that can be done with little page weight.

Custom 404 pages are a trend, but I've seen many that are over 2 MB.

Regarding static vs. dynamic in HTTP response codes - see the link I shared. It's strongly implied, because the author is clear about the majority of hits being from crawlers. People underestimate the number of 404 responses.

[AlexDawsonUK]

Again, you're covering material that is already covered by other guidelines and SCs.

We are not a regulatory body and have no governance over third-party content. We provide resources that can assist with either reinforcing best practices or provide materials regarding how people may wish to consider a task - but these should be taken with consideration of the WSG as we do not endorse them (it explicitly states as such in the Resources header).

Further duplication of efforts will not be accepted into the WSG.