Architecture advice needed

Hello.

I need to or want to rebuild my hugo based website and I was wondering, if I could get some architecture advice from here. Especially, I am wondering about alternatives or better mechanisms to pull the metrics into the text.

Current Architecture

The website provides the level of a lake in Germany and is updated (almost) every hour.
See Level of Lake Constance (Bodensee) :: Current and historical information on the level of Lake Constance

The current architecture is given here:

In short, this is:

  • hugo website with re-learn theme
  • repository in AWS CodeCommit
  • AWS Amplify is being used to host the website
  • images are pulled from an AWS S3 bucket except for one, which I am allowed to pull from a governmental website
  • numbers for the text sections are pulled from a JSON file in S3

Updates Architecture

Overall, I am happy with the setup, but I need to perform some changes. For example, AWS decided to sunset AWS CodeCommit, therefore, I need to transition to e.g. GitHub. Furthermore, I am moving away from website scraping to get the data. I have API access to the underlying data set now.
The only thing, I would like to improve is the handling of the data, which is currently pulled from the JSON. E.g. “Level of Lake Constance: 320 (-2)”. The metrics tend to load a little bit slow, which creates an irritating experience when opening the website. And this is also not ideal from an SEO perspective. E.g. Google seems to update the website data now every day, I think. But the blurb a user would see on Google is not the same as the information on the website. I am wondering, how this could be done better.

I could re-build the website every hour instead of providing the data via JSON, but that feels like the wrong approach. I would be grateful for some advice.

In regards to SEO, the question is not how fast your website shows the user the current level of water in Lake Constance, but “why should a user that is interested in the current level of the water in Lake Constance go to that website?”.

  • Add a proper description to your website so Google knows what it’s about - this is what it should show in search results, not the current level.
  • Move the loading of the level data out of the onload-Javascript. For instance you could add a timeout of 400ms and then run the retrieval of the data. This way Google has a “page loaded” event that is not influenced by the duration of however you get your data. Add “loading” information, for instance, a nice animation of rising water level, so people keep entertained until the data is loaded. Historical data is always good, so add a list of monthly averages into the static parts of the site.

Like I wrote above, the lake’s level is more or less irrelevant to Google’s ranking. If another website shows the current level, then you compete against that page in the sense of “why would the user want to go to that website?” The winning bid is always the one with more relevant information. So add a little bit: Historical data, the highest level, the lowest level. A nice Google Map with markers about sights and events (flooding?).

Look into caching so that if I re-visit your site have data from my last visit available.

2 Likes

Thank you very much for your feedback. Really appreciate it.

I agree with the Google relevance. I just recognize that first website coming up, when searching for “Pegel Bodensee” (EN = Level Lake Constance, and you need to search in German for this to get the appropriate result) is always showing the current level of the lake already on Google (in this preview section below the link). Google does the same for my website, but the refresh rate seems to be lower.
But I guess, you are right. Focus on good content. And Google will take care of it. The fact that I am not implementing any trackers is probably not to my advantage.

Will definitely look into caching options to improve the performance. Animation also sounds nice. But actually, I like the plain and simple setup of the website. Nothing fancy. Data and content focus.