Open Main Menu

How I evaluate websites/website developers

October 29, 2020

I recently made mention that when evaluating website developers, I recommend you: check examples of completed work (live sites), check raw code (HTML, CSS, JS, PHP, etc), but also check the size and structure databases (tables, rows, overall size, etc). The question arose, “sure, but how would a layperson do this?”. A wonderful question, and here is my response.

*Please note, much of this can be done by anyone willing to take the time. There are things that are more or less technical, but much of it is pretty straightforward.

What is your standard?

I have a publicly stated quality standard. https://somecodeiwrote.com/website-quality-standard.html I don’t claim perfection, but do my best. In talking to developers, firms, and agencies, I often encounter folks that do not have any formal standard. Of those that do have a standard, it is often a guarded secret. I don’t understand either of those approaches, but the point remains. I would start my evaluation by asking, “What is your quality standard?”.

If the candidate does not have a standard, that would be concerning. If they have a standard but are unwilling to show it to you, that is equally concerning. A lot of firms tell me, “The client wouldn’t understand our standards”, which is a poor excuse at best and I don’t buy it. If the candidate has a quality standard, but it seems “flimsy”, it probably is.

The standard a candidate has or does not have is not a deal-breaker, but it is incredibly insightful as a step one.

Checking completed work (websites)

When I am looking at completed websites, I am looking for a lot of things. However, these things can be boiled down to:

Good accessibility (ADA compliance)

I use the WAVE extension but the online tool works well. Visit https://wave.webaim.org/ to learn more.

Quality code

I check for HTML errors/warnings via https://validator.w3.org/.

I check CSS errors/warnings via https://jigsaw.w3.org/css-validator/

I check for JS errors via a browser and console. This is done by right-clicking, choosing inspect element (or inspect), and clicking on console. Ideally, there will be nothing of note in the console. Warnings and errors are pretty easy to spot but this may be beyond a layperson.

Lastly, I check to ensure the site is using HTTPS and has a padlock on all pages. The padlock varies a bit by browser, but it is fairly simple to spot. Errors in the code can cause an open or missing padlock.

Website Speed

I use https://gtmetrix.com/, https://tools.pingdom.com/, and https://developers.google.com/speed/pagespeed/insights/.

A good experience across multiple browser/device combinations

This is subjective, but https://search.google.com/test/mobile-friendly is a great place to start. https://www.responsinator.com/ is my next stop, and then I check https://www.browserstack.com/.

I am not looking for anything in particular, just a good experience. Pro-tip, check your analytics to see your desktop/tablet/mobile split, as well as the browsers that your user base uses most. These data points are unique to each and every website. Then, test according to your specific needs. E.g. Below are snapshots from two of my websites. One is 89% desktop while the other is 81% mobile. These websites have dramatically different audiences and website needs.

SEO fundamentals

I am not going to grade a developer too harshly on SEO but I am going to say the SEO fundamentals are the developer’s responsibility. Using WAVE and validating the HTML will spot silly issues like duplicate h1s or missing h1s. Similarly, WAVE will catch when heading levels are skipped. These things fall on the developer’s plate and are inexcusable.

I inspect the page source code and give the metadata a quick look. 9 times out of 10 this is added via a plugin like Yoast. So long as it is there, great. This is probably beyond what a layperson would do, and honestly, a site missing metadata wholesale is not something I have seen for some time.

I do, however, check for an XML sitemap at /sitemap.xml or /sitemap_index.xml (either location is fine). I check /robots.txt to ensure that the XML sitemap’s location is noted there. I also check /sitemap for an HTML sitemap. These 3 checks are pretty simple but I still catch developers forgetting to add these basic SEO items.

Checking raw code

Ideally, you will be given samples of raw code. This is important because raw code (what I write) and rendered code (what a browser shows) are not the same. Also, there are server-side languages, like PHP (sometimes JS) that you can’t see via the browser. So, seeing raw code samples is really handy.

Worth considering, many website developers today use tools to build websites and they can only write fairly limited code. I am not going to say this is an inferior method, but it does tell you a lot about what they can produce. If you ask for code samples and they hem and haw, or say they don’t have any, you might be dealing with someone who is not fully code literate. Again, this can be just fine, but you have to understand what you are bargaining for.

All languages – look for minimal code

The less code one uses, the better it tends to work. Programming languages are languages, and the particular way you assemble it all can be efficient or verbose. Developers with a better programming vocabulary tend to write less code. Junior developers tend to wander around and eventually get to what they were trying to do.

When I hand over code samples, I am often hit with “This is it? That’s all?”. That is music to my ears. I am not trying to impress people by writing the most code per hour. I want to build really robust sites with the least code possible. To chop a tree down in 5 minutes, spend 4 sharpening your axe. The same is true with code.

All languages – look for excessive or inappropriate comments.

Comments (code that does not “do” anything) vary by the language. HTML comments, CSS comments, JS comments, and PHP comments. If you happen to use a text editor (sublime, atom, vim, brackets, etc), comments will be highlighted in a specific color (varies by user and editor).

Comments are used for planning and reviewing, code description, algorithmic description, resource inclusion, or debugging only. So, you do not want to see sections of code that are “commented out”, as this is an inappropriate way to address a problem. It is also indicative of a developer who is unsure about what they are doing. Commenting out code is a way to disable something without actually removing it. This is like adding a paragraph to an email and then saying, “Please do not read this paragraph. I wrote it, but am not sure I could write it again later.” This is just silly.

Also, you do not want to see comments that are just inappropriate. You would be amazed by the things developers write into comments and it is very telling. Profanity or statements like “no idea how this works” are extremely common. I regularly see comments in code that are from the tutorial that the developer copied the code from. All of this is indicative of a developer who is in over their head.

HTML and CSS

These can be checked via the upload section of https://validator.w3.org/#validate_by_input and https://jigsaw.w3.org/css-validator/#validate_by_input. I don’t do this much, because I check sites via the URL validators. I do, however, like to see raw HTML and CSS. So many website developers today use a tool of some sort to build websites as opposed to actually writing the code. If someone can give me samples of their raw HTML and CSS, I am more confident in their ability to spot and correct errors.

One note, here, you might be told that the developer uses a preprocessor. This is perfectly valid. The one problem I have with this approach is it can generate a lot of code as opposed to really good code. Not that it always does, but it can.

JS (JavaScript)

I don’t use a lot of JS, so my ability to evaluate it is admittedly limited. There are countless JS validators online, which is a good start. Beyond validating the JS, I simply want to see as little JS as possible. I am biased here, but JS heavy websites are often buggier. (shots fired!)

PHP

Spoiler alert! I am a PHP developer so this is one area I am extra critical of. However, there are a few simple things anyone can look for.

Do not use <?, use <?php. <? is a short open tag and is only supported when it is activated on the server.

  • Using <? might work on this server but not that one.
  • <?php is universal.

Do not open and close PHP unnecessarily. PHP is started with <?php and then is ended with ?>. It is really common for developers to use this to group their PHP, but that is wasteful and technically inappropriate.

  • This is incorrect: <?php Some PHP is here, to do one thing. ?><?php This is more PHP that does something else. ?>
  • This is correct: <?php Some PHP is here, to do one thing. This is more PHP that does something else. ?>

Do not have a closing tag at the end of a PHP file. PHP automatically closes at the end of the file. If you end a PHP file with ?>, it can cause unwanted whitespace that can cause bugs. A really common issue in this regard is a “headers already sent” error.

Size and structure of databases

Databases are often overlooked. A good developer will build sites with very small and efficient databases. Average developers tend to have big, ugly, bloated, databases. The million-dollar question, how could the layperson tell? You can start by asking.

When vetting a developer, ask them, “How big of a database do you think our website would require/use?”. They do not have to hit the nail on the head, but they should have a reasonable guess. If they answer your question with a blank stare, they probably do not spend much time looking at their database structure/size.

As a point of reference, I build websites for small businesses, so my databases are fairly tiny. A small site would be 25 tables, 1,000 rows, and under 2MB. A fairly big site might be 30-35 tables, 20,000-50,000 rows, and 10-15MB. I have seen plenty of medium-sized but inefficient sites where the database is 50 tables, 200,000 rows, and 50-60MB. I’ve seen worse than this. Databases get out of hand quickly which is why this is so important.

Secondly, you can ask for examples of their database size and structure. This is actually really easy to provide. A snapshot of one of my personal site’s database looks like this.

I have obscured my database prefix, but other than that, nothing to hide. It is a pretty standard WordPress database. This site is small, but bigger than you might think. I keep my database clean and tidy via regular optimization, but also by using the database efficiently. In this snapshot, you can see the totals at the bottom. This database has 19 tables, 703 rows, and is 1.2MB. You can also see which tables are the biggest. It tells you a lot.

I have not given away any sensitive information. I have just shown you what my database looks like and how big (or small) it is. If a potential client asked me for 5-10 samples, like this, I would gladly hand them over. I would happily discuss what I thought was a reasonably sized database for their site. The thing is, nobody knows to ask, which was my original point.

Final thoughts

I get that this is technical stuff. For the cost of a website, and the potential cost of having a bad website that negatively impacts your business, I would take the time to become an informed consumer. The alternative I suggest is this, at the very least, get the opinion of someone who is qualified. This is not all that different from having a mechanic look at a used car before you buy it.

I recognize the Catch-22, you need a good developer to know if you have a good developer. I am always happy to give my opinion, particularly if it means people are getting better quality websites. I have to believe I am not the only one. However, if you do not have someone you can ask, give these steps a shot. I think you will find that by asking the right questions you get much better answers. The wheat will separate from the chaff.