Thanks a Lot for Making Hugo Docs Better

I appreciated to Hugo developer who has to build the new Docs.
Thank you so much.

And, because Hugo has predicted as fastest Static Site Generator, it will be awful to see that on themes section.

You can check the score here: https://gtmetrix.com/reports/themes.gohugo.io/dSyKX6l5

Again, Thanks a lot as gohugo.io fans.

1 Like

The “fastest static site generator” slogan refers to the build speed; i.e. time it takes to generate a site.

That said, I don1t think that measurement is taking the “lazy loading” of images into account.

I choose Hugo because it makes my site faster too, not only on building time.
And, of course, theme.gohugo.io can do it better right? :smiley:
I want to do something with the source from GitHub - gohugoio/hugoThemesSite: The source for https://themes.gohugo.io. but, the file is incomplete, and I can run that.

The images on that page lazy load. Just look at Pingdom speed results which take that into account (618ms load time):

1 Like

Even without lazy load, that page can perform faster. It only needs to be optimized images size and resolution.
Why is this like a nightmare for me?
Of course, some people live at fast connection around the world. But, honestly, I don’t have a fast connection to open it quickly like other.

I agree that the page sizes of the theme website are much too big, especially if there’s a decent amount of mobile visitors coming.

But it might also be Netlify, which isn’t a very fast website host (even when the cache is warm).

I just hope that the majority of Hugo’s target audience lives in the US, because the page speed from other regions is quite poor (even on desktop).

For example:
theme website from California, 1.09s load time:


theme website from Australia, 7.96s load time:

And:
documentation page from California, 485ms load time:
https://tools.pingdom.com/#!/bFQOfb/https://gohugo.io/content-management/formats/#emojis
Same documentation page from Australia, 2.76s load time:
https://tools.pingdom.com/#!/bHEQz0/https://gohugo.io/content-management/formats/#emojis

What other CDNs are faster than Netlify?

My answer is localhost.

Netlify is blazing fast as free service because it was using Amazon CloudFront CDN.

Likely a CDN that has a PoP/data center in the region that you’re interested in.

I cannot find on Netlify’s site where there PoPs are, but I suspect there isn’t one in Australia or Souteast Asia. Otherwise the load times between the US and Australia for the same page with a warm cache would be much more similar.

For me Cloudflare is quicker because they have a wide network and I don’t target a specific country or continent.

1 Like

Just out of curiosity: shouldn’t the new Hugo website be HTTPS only? My understanding of switching from HTTP to HTTPS is that, after enabling HTTPS, all HTTP requests should be redirected to HTTPS. That way search engines also index the right one.

Google advises to use 301 redirect when moving to HTTPS here.

But I see that http://gohugo.io/getting-started/configuration/ doesn’t redirect to the HTTPS version. If that’s by design and deliberate, I’d suggest to use canonical URLs so that Google (and other search engines) know whether the HTTP or HTTPS is the preferred version of the page.

Just my 2 cents. :slight_smile:

No Problem.
Hugo Docs is using Netlify server. It’s only need to setup Force SSL on netlify dashboard.
this is my 1 cent. :sweat_smile:

I know, but we have a “mixed setup”, and forcing SSL is non-reversible (for a year), and I wanted @spf13 to do that and to make sure that it does not break anything else. So the “does it break anything else” is the problem.

I’ve seen this problem so much, there ought to be a tool to scrap a sitemap and report mixed content that needs to be fixed, prior to a switchover. Anyone know of a thing like that?

I don’t care about the broken links (or, I can fix that), I care about any “broken domain”. We have the DNS at Amazon and SSL at Netlify.

  1. I’m not familiar with the setup (i.e. it is not my domain)
  2. I would hate if switching on SSL for gohugo.io would somehow break some other subdomain and we’d have to wait a year to fix it.

Answer to 2) is “most likely not”, but that is why I have delegated to @spf13 to do the switch.

That’s disappointing since Netlify prides itself in its flexibility. A fixed Strict-Transport-Security header of 1 year doesn’t go well with that.

By the way, I see that this tutorial uses Netlify’s headers feature to override the default value for that header. Perhaps it can be set to a very low value (like 5 minutes) for testing purposes too. Might be worth verifying with their support for the person(s) doing the switch.

You can use Netlify _redirects to redirect any and every query to https, so you don’t have to do the HSTS for a year.

I don’t think that is possible, but please prove me wrong (i.e. what would be the syntax?).

this is what I’m using and it’s working well. I use the https:// version as my baseUrl. or the more generic // at times.

http://example.com/*        https://www.example.com/:splat    301!
http://www.example.com/*    https://www.example.com/:splat    301!
https://example.com/*       https://www.example.com/:splat    301!

works for me as far as I can tell. This doesn’t protect from man-in-the-middle attacks but… the only way to do that is the HSTS.

Are the “Sites Using Hugo” showcase and Hugo related Articles gone from the new site? or just not yet integrated?

I have found the cause of the problem to solve “Why Hugo Themes Pages are Slow?”.
It’s at https://github.com/gohugoio/hugoThemes#media.

Then, what to do?

  • Hugo should ask for more efficient and optimized images. For example, all images must be optimized using TinyJPG or another compressor that minimizes size but maintains the quality of the picture.

  • Do not ask for a png file. Because, a .png file is transparent and a web page screenshot does not have to be transparent, for better performance, let’s use .jpg as image sources.