Theme Quality -Filter for Best Practices, SEO optimization, etc


#1

Hi all,

Is there a way to rank theme quality in terms of best coding practices, page speed, SEO optimization, etc? Is there some kind of quality control for the themes?

Some of the themes are very good (After Dark) and some aren’t -and aren’t actively maintained!

Thanks,


#2

All that’s really needed is someone to volunteer to do so and to commit to keeping the list up to date. Otherwise, as you point out, the ranking wouldn’t be actively maintained.


#3

I was thinking about this myself. It’s a daunting task, to be sure, but I think it would be possible to set some standards and highlight those that meet them. While the upfront work would be hard, doing so would likely lead to fewer support requests here in the forum. Maybe someone like @sethm who has created themes has ideas?


#4

Just adding some things. I’m not a theme developer, so this might be obvious to those who do.

I’ve started to put together a Hugo version of the Wordpress “theme unit tests,” which are a variety of basic and edge-case pieces of content meant to test the versatility of a theme.

Thinking out loud here, but perhaps, with that there could be a repo of a sample site (I’ve already started one for my own work, and note there’s a basic example for theme display), and with that Hugo instance, there could be a checklist that shows:

  1. Community Review, using the unit test content and a general review of the code with standards like
  • archetypes in place
  • more stuff here
  1. Run a Hugo benchmark command for build-performance.

  2. External tests: webpagetest.org, Lighthouse, webdevchecklist, HTML proofer.
    *Note: as a user of these tests, I know they can be maddening. I think some minimum standard could be identified as acceptable.

Not saying that every theme should go through this, but, setting something like this up and identifying/highlighting themes that meet these “standards” would be a good incentive to theme developers.


#5

Re: standardization, a default Hugo theme will go a long way (see #2864). I like the idea of highlighting themes that meet standards.

I’ll make up a list of issues I’ve run into when porting themes…even little things like whether or not the baseurl should have a trailing slash. That’s caused path issues even with .LanguagePrefix.

I created a repo for a default Hugo theme. I didn’t do much yet – I just wanted to get something up. I’ll work on it more this week.


#6

Food for thought, gents. I think @bep would appreciate the feedback too:


#7

I really like the main features of Hugo and want to use it regularly to build websites. The main barrier is assessing theme quality. I am definitely planning on building my own themes, but for quick website builds I would love to be able to trust some of the designs up.

I like the suggestion @budparr has of specifying a relevant list of tests/questions that can be applied to each theme. We could have some place to put the reviews for each theme and developers could add to the list when they’ve had enough experience with the theme.

I could give a run-down of the “MDL” and “Landing Page” themes at this point. (^-^)


#8

Perhaps the easiest way to do this would be to add some combination of the following to the themes page:

(1) a voting mechanism;
(2) a meter tracking github forks and stars of each theme’s repo;
(3) a place to comment on themes, e.g. a link to a sticky forum post about the theme or a Quora/Stack Exchange -style page for each post.


#9

Yeah, totally. Those things could go a long way.


#10

I see the importance of quick webpages, but wonder the added values of testing this upfront. There are a lot of variables that go into Hugo’s performance and external tests, ranging from the kind of content, amount of content, to where you deploy the website and whether you incorporate external libraries (disqus etcetera).

Performing those two kinds of tests as a grade for a theme might give more confusion and disappointment with Hugo in general. At least, I can see topics springing up about “why is my Hugo so slow, the theme should built in x ms” etcetera.

Those two tests also implicitly favour lightweight and simple themes. I don’t know if we should give a penalty to more complex themes that took considerably more amount of time to develop. It might give people an odd incentive to port over lightweight and simplistic themes if those rank well.

Just my two cents. :slightly_smiling:


#11

@Jura - you make valid points. I didn’t elaborate it on it much, but I was only suggesting a set of minimal standards, and not that all themes should have to go through them, but if they meet the standard, they get singled out for better placement.

I do client work, so I know well the tyranny of these tests that favor an unreal minimalism (Note, I didn’t mention Google’s pagespeed test, which is among the worst, and mostly just silly), and I did not mean to imply a test would be for things that have nothing to do with the theme, like deployment considerations.

However, the tests I mentioned help make sure one is following best practices. HTML proofer just makes sure there’s nothing broken. The others contain information that a subset of which could be created to say to users that a theme has a certain level of integrity. Webpagetest alone (currently the gold standard for performance evaluation) can tell us if a theme is missing files, like icons, if it’s loading a lot of scripts in a non-performant manner, and that sort of thing.

And, I didn’t mention it, but I think as a community, we should encourage best practices in accessibility. Again, only supporting the the good ones, not penalizing the others.


#12

Awww, man! I worked so hard to get a 99 on the docs, haha. (But I know what you mean about its silliness.)

YES! :thumbsup:


#13

Nothing wrong with that. There’s good information in there. The silliness is that they gameify it with scoring, yet the scoring itself can be a bit arbitrary and a high score isn’t necessarily an indication of a good website.


#14

So was this in fact built into Hugo 0.20? It’s no where in the Docs.


#15

You’re correct. At the time of writing this feature wasn’t documented. But there is an open issue about it.