Forem: Tim etc.

A not useless guide to sustainable websites

Tim etc. — Thu, 17 Oct 2024 13:43:03 +0000

Let’s shut up about the planet, all that doomsday panic and start with why you would want to make your website sustainable? You are building the website or paying for it, what’s in it for you?

More performance, more better. It will speed up your website, improving your productivity, your visitors will love the snappy website, resulting in higher conversion and Google gives you SEO bonus points. For high traffic sites it can even save money.

Oh yeah, it will make the planet happy. Since IT has a growing impact on earth because it uses a lot of energy. If we all chip in we can make a big impact.

You are not only helping the planet. It’s a valid business case.

Green hosting! Am I using that?

Using sustainable energy for your applications and websites have a great impact since servers use a lot of energy and are turned on day and night. It’s a good place to start.

Curious if you are using sustainable energy? The Green Web Foundation have a great tool to check that: The Green Web Check.

If not, that same foundation has a Green Web Directory. There you can find a lot off sustainable hosting providers, both local and global.

Is my website sustainable by using green hosting?

It’s a great start, but there is more to it than that. Having a resource munching chunky boy website will use a lot of energy and transfer slowly, even on green hosting.

Shall we get to the performance part where all the interesting things happen?

Optimising assets, small is fast

For a lot of projects this is where you can make a big difference. Assets can be chunky and waste a lot of bandwidth and resources. A bunch of tips:

Minimise the amount of fonts you need and load, those hit hard (try to use max 3, but less is better).
Use SVG’s where you can, they are small and scale well.
Scale and crop images to the size you need, systems like WordPress have tooling for this and the srcset attribute can help switch size.
Use modern formats for images and video’s, like WebP and WebM/AV1. Those offer improved compression and quality.
Lazy loading images is a matter of using loading="lazy", just load what you need. You don’t need any scripts for this anymore.
For video, only use autoplay if your really need to.
Use compression (next up) and don’t load things you don’t need :)

Bonus for Tag Manager users: check all the third party scripts and tools you have. Do you use them? Do you get any value out of them? Periodically grooming is necessary. It’s not only about the assets you are loading, big data processing needs a lot of energy.

Serve it fast and small: cache and compression

Enable compression. All modern webservers have it, make sure you use it. Modern options like Brotli are better, but even GZIP or Deflate can make a big difference in bandwidth. Mobile visitors will thank you even more.

Caching depends on the project, but try to cache data that as close to the visitor as possible. For static assets like CSS/JS you could start with a proper cache header for the browser, reusing the downloaded file over and over.

Do you have a content page that has more reads than updates? Serve it statically from disk or CDN. A framework like Astro can statically generate to a CDN or a plugin like W3 Total Cache can serve WordPress pages from disk.

Keep your friends close, but your data closer

Talking about CDN’s. Think about your visitors, where do they come from? Do you need a global distributed multi zone setup with edge workers to serve your local bakery website?

Probably, but that’s your inner geek having fun. Don’t over use overkill solutions and keep your servers close to your users. It will save resources for both compute and transfer, keeping latencies low.

Stop using JavaScript, CSS is awesome!

A lot of devs love writing JavaScript, doing all kinds of fancy animations, page transitions and other shenanigans. Not using vanilla JS or CSS, but big frameworks or libraries. That includes jQuery. You don’t need jQuery to get a DOM element and toggle a class! Don’t even get me started on Next.js.

I got worked up, sorry. And honestly, those websites can be beautiful. The thing is that vanilla JS and CSS are great nowadays. Full of features that enable you to build all kinds of cool interactive components, animations and even page transitions.

By using those you can write, ship and run less code. It’s all handled by your browser. Even smoother animations without blocking the main thread.

You don’t have to make it boring

I’ve seen a lot of articles talking about using dark colours, system fonts and saying you should drop every little bell or whistle.

That sounds like a public service announcement to make life dull. I don’t want that. Websites, apps, design, tech, should be fun, inspiring, alive.

I’m not saying you have to build stupid features without any value that uses a lot of resources, be mindful, but don’t be boring.

Okay, bye.

That’s it for now, but it is a topic that interests me. Expect more articles about the nitty gritty details. Any questions or tips? Please drop a comment or send me a DM on Xwitter or LinkedIn!

How to use Angular i18n with the built in @angular/localize and XLF

Tim etc. — Sat, 03 Sep 2022 14:58:19 +0000

In Angular you have the @angular/localize package, which is Angular's own build in tooling for translations. This will be sufficient in most cases, it takes a few steps but it's easy to use.

The translations are done through aot compiling, all translations are compiled into the app ahead of time (when building your project). The upside is you have multiple builds of your app which enables different strategies for serving them and best of all: it has great performance. The downside is that it isn't optimized for dynamic logic, which is possible and I will explore in a later article.

1. Let's start! Add the localize package

Assuming you have an Angular project already, let's start with adding the localize package to the project. If you haven't follow the Angular installation instructions and run ng new your-project-name for a new project (you can replace the project name with a custom one, without using spaces)

Angular's CLI makes this job very easy:

ng add @angular/localize

Make sure to use a recent version of Angular and the CLI, it will make it a lot easier.

2. Start marking translations

Translating components is done by adding i18n attributes to elements. This can be almost any element, ex. block elements like h1 and p, even inline elements like span.

Format:
<element i18n="{meaning}|{description}@@{id}">Your text</element>

Example:
<h1 i18n="{auth login headline|A warm welcome for the login screen@@authLoginHeadline">Welcome!</h1>

In the example you see the i18n element with a value, this value has three sections:

meaning: provide info about the meaning and intent
description: ability to add context or additional information
id: unique identifier

All parts are all optional. Even the id, if you don't add one yourself it will be generated each time you export your translation source files in a later step. They will change every time you do this, so it will make maintenance of your translations a bit harder.

It is best to do this on elements that wrap the text. So try not to translate a div containing p elements or an ul containing li elements.

Tip: you can even use a ng-template element when you don't want any additional DOM-elements, so you don't have to use span elements if you need a few translations.

3. Generate translation source files

A really satisfying step in the proces. Make the Angular CLI walk through all of your code and find i18n attributes. From that it will generate a translation source file, with all translation sources.

ng extract-i18n --output-path src/locale

You now should have a XLF file in you src/locale directory with a XML structure.

Tip: use npm scripts

Make it easier on yourself, you don't have to remember this. Open up your package.json file and add a line in the scripts section:

"translate": "ng extract-i18n --output-path src/locale",

Now you can just run npm run translate or yarn translate for the same result. That's a lot easier for future self and your team members.

4. Translate your app

Working with this XLF file is quite hard to do from an editor, especially when you need to merge it with changes later on. That's why I made a tool called What?!

Open What?!
Throw in your translation source file src/locale/messages.xlf
Translate the app to the targetted language
Press 'Download' when you are done and save it to src/locale/messages.[lang code].xlf (replace lang code with your language code, ex. nl or fr)

Tip: when you have a source and translation file, you can drag in both. It will automatically match the files and you can continue translating your app with ease. You can even see which sources have changed or filter on empty translations.

5. Configuration of Angular

Now we have to do some final configuration to make Angular use the XLF files you just created and compile them into your project in the build process. Open up angular.json in your code editor, you can find it in your project's root folder.

First we need to add the i18n configuration with the primary (source) language which is used with the text in your components.

Add the following piece of JSON inside your-project-name found in projects, I have put it in between prefix and architect.

"i18n": {
  "sourceLocale": "en-US",
  "locales": {
    "nl": {
      "translation": "src/locale/messages.nl.xlf"
    }
  }
},

Do not forget to change nl in this example, found in the object's name and filename. Change it to the language code you just translated your app to. You can also change the sourceLocale if you haven't used English inside your app code.

Now you can use the defined locales inside the build process, add this piece inside configurations above production (the one inside of build).

"nl": {
  "localize": [
    "nl"
  ]
},

The last thing we have to configure, being able to serve the development version of your app while using another language. You can do this inside configurations, this time in serve. Duplicate the development configuration and rename it to the language code you want to use. Add ,[lang] at the end, so it will use the configuration we created before. For example:

"nl": {
  "browserTarget": "project-name:build:development,nl"
},

If you copied the snippet above, do not forget to replace the project-name with yours and language code (in both places).

6. Party time!

We now have generated language files, translated them and configured Angular to use those. Let's check out the end result!

Production build

To make a build you can just use ng build or npm run build, just like before. You will notice a little difference inside the dist folder, there is one build per language.

Serve development

Run ng serve --configuration=nl to serve your app, of course replace the language code with the one you used.

Tip: you don't want to type this every time, at leas I don't. It's easier to make some npm scripts inside package.json like before:

"start": "npm run start:nl",
"start:nl": "ng serve --configuration=nl",
"start:en": "ng serve",

So you can just run npm start or yarn start for the Dutch version in this case, or npm run start:en (yarn start:en) for the English one. A lot easier.

What's next?

That's it, you now have a multi language Angular app! From now on you can continue working on your app, just repeat steps 2, 3 and 4. Making sure to mark all text in new components and generate new source files.

Like I mentioned before, with a tool like What?! you can throw in your new source file and your existing translations. It will automatically merge them and show any changes. You can work through them and add any new translations as well. You only have to check changes, translate additions and include the result in your project. You are ready to build and launch!

Tip: do a walkthrough or PR review to make sure all text is going through the translation process.

That's it!

This is all you need to get started with the Angular i18n module, there is a lot more to tell. You can follow me on Dev.to or Twitter for new articles.

Any questions or feedback? Let me know in the comments or hit me up on Twitter!

Angular with clean URL's using Apache's mod_rewrite

Tim etc. — Sat, 07 May 2022 08:37:06 +0000

In Angular you have a really nice router which takes care of all the things you need. Prefetching data, guarding specific routes and it will even lazy load modules. That all works out of the box, which I think is really awesome.

When you are using Apache to serve your public/production environment you want to have beautiful clean URL's, for example 'whatwhat.app/page/3'. You need some additional configuration to make sure Angular's routing also kicks in when people visit those pages directly and not coming through the index/homepage.

By default you will get a 404 page, because that file is not physically on the server. With mod_rewrite you can adjust this behavior in Apache, if that module is turned on (which is often the case). Configuration for Apache can be changed per folder using .htaccess.

Apache's mod_rewrite and .htaccess

Just copy the configuration below and drop it in a file named .htaccess in the same folder containing your index.html file. That's it!

# Check if mod_rewrite module is available
<IfModule mod_rewrite.c>

  # Turn the rewrite engine on and set URI base
  RewriteEngine On
  RewriteBase /

  # Serve files when they are found 
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR] 
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d 
  RewriteRule ^ - [L] 

  # When file is not found, serve index.html instead
  RewriteRule ^ /index.html

</IfModule>

Optional: Run your Angular app from a sub directory

You need some additional configuration for this, because Angular needs to know the path above it. The easiest way is to add a base tag in the <head> tag of the index.html like this: <base href="/app/path/">. Where the path should be adjusted to match yours of course, make sure it is the path above your Angular app (which should be ignored).

Another way is to inject it, that can be easier if you have different configurations per environment (ex. dev/acc/prod). You can find more information in the documentation of Angular APP_BASE_HREF.

When using a sub directory also change that in your .htacces like this:

RewriteBase / should change to RewriteBase /app/path/
RewriteRule ^ /index.html should be RewriteRule ^ /app/path/index.html
Make sure the .htaccess file is in the same directory as Angular's index.html.

What mod_rewrite will do for Angular

For this of you who want a little background information about what is happening.

What Apache does is serving files to your visitors when they ask for it. In the case of a homepage like 'whatwhat.app' it will serve the index.html. With the configuration from the .htaccess it will change a bit:

When a file is found Apache will serve that to your visitor, which will make sure assets like js, css and images can be loaded. That also includes your Angular project. That is done with the RewriteCond and RewriteRule. Which will just use the URI from the request.
After that there is another RewriteRule as fallback and is only executed when a file is not found. It changes any URI to /index.html. Which makes Apache look for the index.html file and serve that instead. In that case your Angular app is served to your visitor.
That is exactly what you want because when you move from 'whatwhat.app/' to 'whatwhat.app/page/3' Angular will do the work, but if you visit 'whatwhat.app/page/3' right away Apache will try to find it. Which it can't. By serving your app instead, the Angular router will get loaded and take over and resolve it afterwards.
Any 404 page is a route that can't by found by the Angular router, which should also show an error page. That is up to you.

Even more possibilities

You can use hashtags routing too, which won't be send to the server. That is an alternative in some cases and it can be good for security too (if you have params you don't want to send to the server). I will probably write about this in a separate article as well.

Also using Angular's i18n and want some clean URL's? I have written an article called Serve Angular i18n with clean URL's using Apache's mod_rewrite. To make translating Angular apps itself really easy you might like a tool I have made called What?!.

I am working on articles for other webservers and CDN's too, follow me on Dev.to to keep an eye out on those. Any tips or questions? Reach out to me in the comments or on Twitter. Thanks for reading!

Photo by Andrew Ruiz on Unsplash

Performance issues? Find your bottleneck with console.time()

Tim etc. — Fri, 08 Oct 2021 06:59:27 +0000

My, since a little while beautiful, app called What?! was a little slow when opening files. A lot slower since the version before the big redesign. When you changed a lot it is hard to find a starting point. What you can do about this? You already read the title so you know the answer. Tldr; just try it.

The console.log() function is something most JS developers know, you can output anything to the console (for Node as well as the browser). I think a lot of developers do not know about console.time() though. Probably something you will use a lot less, but can be very useful.

Okay, so let’s find that slow little bastard of a function. What you need to know:

console.time(‘example’) will start a timer, where you also give it a name. You can start multiple timers (simultaneously), if choose different names. It will not console anything though.
console.timeLog(‘example’) gives you the amount of elapsed milliseconds in the console. Make sure to start a timer first and same name. Tip: you can call it multiple times to see where the biggest time jumps in your process are made.
console.timeEnd(‘example’) will stop the timer and console log the amount of elapsed milliseconds.

Put the console.time() at the start of your slow process and drop a few timeLog’s through the process. In places where different things are done, or maybe expect performance issues. Do not forget to stop the timer at the end.

Do you have simultaneous tasks or a lot of steps? You can start multiple timers, measure the overal process and start separate timers for certain tasks/steps to get a better picture. Do whatever you need to see what piece of your code is taking too much time, just start and try.

Hopefully you did find the son of a gun. Now you may have some ideas to implement it differently, maybe >1 options. Let’s implement them! Now you can try out things, make a duplicate function with a different implementation. Keep console.time() in your code to measure the before/after.
When you do have multiple solutions, check all of them out (or some of them) and see which one is the fastest. You already have the test bench set up, now is the time!

Next up: pick your solution, remove your console functions because you don’t want them in production code, go to the store, buy confetti and celebrate! Your application got faster, congratulations :)

Of course there are a lot more options for debugging performance, and a lot more tools to work with. I like this one because it is easy and accessible for everybody who is in need.

It helped me to get my app What?! to be a lot faster. Especially on the larger translation files. Be careful with deep cloning large objects, lesson learned.

Serve Angular i18n with clean URL's using Apache's mod_rewrite

Tim etc. — Wed, 26 May 2021 06:12:25 +0000

In Angular you have some great internationalisation (i18n) out of the box, which builds the nice compiled and minified bundle your used to. You have a compiled version per language. If you work with another framework which does the same thing (export a language per directory), this approach will work for you as well.

My problem: the separate directories give you nasty URL's, something like whatwhat.app/en/. Okay, so that's just looks but it can also be a problem with sharing links. For example when user A shares a link with user B, but they have different native languages it will be annoying that the opened link does not have the language correct language for the receiver.

In my case I wanted to make it a setting that the user can adjust, with a default language as a fallback. Easy to make and accessible because every page and link is always in your preferred language.

Make it work with .htaccess, mod_rewrite and cookies

In the .htaccess file I added notes about what is happening if you are curious about that. Make sure to adjust example_locale which is the name of the cookie, (en|nl|de) for the allowed options and [E=LANG:en] will set the default language. To switch language, set a cookie and refresh the page from the app. That's it.

# Check if mod_rewrite module is available
<IfModule mod_rewrite.c>

  # Turn the rewrite engine on and set URI base
  RewriteEngine On
  RewriteBase /

  # Prevent recursive rewrites
  RewriteCond %{ENV:REDIRECT_STATUS} 200
  RewriteRule ^ - [L]

  # Check for the cookie, get value or set to default
  RewriteCond %{HTTP_COOKIE} example_locale=(en|nl|de)
  RewriteRule .? - [E=LANG:%1,S=1]
  RewriteRule .? - [E=LANG:en]

  # Check if file exists, if so serve it
  RewriteCond %{DOCUMENT_ROOT}/%{ENV:LANG}%{REQUEST_URI} -f
  RewriteRule ^ %{DOCUMENT_ROOT}/%{ENV:LANG}%{REQUEST_URI} [L]

  # Serve index by default, also when a file isn't found
  RewriteRule ^ %{DOCUMENT_ROOT}/%{ENV:LANG}/index.html

  # Disable browser caching to prevent serving old versions
  # It also solves issues when switching language
  <FilesMatch "\.(html|htm|js|json)$">
    <IfModule mod_headers.c>
      FileETag None
      Header unset ETag
      Header unset Pragma
      Header unset Cache-Control
      Header unset Last-Modified
      Header set Pragma "no-cache"
      Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
      Header set Expires "Mon, 10 Apr 1972 00:00:00 GMT"
    </IfModule>
  </FilesMatch>

</IfModule>

To be honest, it has a downside. Caching is pretty much turned off. If you don't, the user can not switch languages after changing the cookie. Because the reload will hit the cache and serve the file for the old language. That is also the upside, you will have a bit more bandwith and load time, but if your product moves fast your visitors will likely be on the most recent version too.

When that's okay and you want to make your load times faster, look into lazy loading if you haven't already. It will split up your application and make the initial load much smaller. Only loading additional parts of the application when needed.

Still angry with me? Please, I have one more option. You can also make multiple builds and combine them. The Angular build process creates the one hash for the build, for all languages. By doing this you have different hashes per language. Removing |js|json in the example above will make sure js/json files are cached, but will always fetch the index.html file and therefor load the prefered language. A bit more work to fix your CI, but still.

That's how I use Apache to serve different languages of my Angular app. Let me know if you have any questions, I am happy to help. Feedback is welcome too! I am pretty new to this writing thing. You can also reach out to me on Twitter 🙂

If you want to make your translation process easier and less time consuming, I made a tool for myself to let me focus on the translations. What?! Yeah, that's the name, you can use it too if you want.

Itch? Scratch! (and share)

Tim etc. — Mon, 26 Apr 2021 22:56:51 +0000

Three years ago. It is a nice summer day with a soft breeze and it hasn't rained in days. I am at the office, working. It already sounds like a nice story, but honostly I don't know what kind of day it was three years back. What I do know is that I was at the office and that we started a new project (called HoorayHR).

Angular would be the front-end framework and ambitions bigger than just the Dutch language, therefor we needed internationalisation. Which Angular has i18n for, works out of the box and it works well. The only downside, the process for creating them was really annoying. This is where the itching starts.

New translations? Good luck finding them all, adding them to your existing translation file and don't forget to translate anything.

Any source text changed? You probably won't notice. That's just waiting for a mistake to be made.

The process was hard and time consuming, it's easy to make mistakes and I had no focus on the actual text (XML is noisy). You just want to know what you should translate, knowing all changes have been accounted for and that nothing is missing.

First thing I did: search the world wide web for a solution. Back then, I found a desert. In general there was a lot of stuff on the internet to find, sadly nothing related to this problem. Maybe somewhere, but not for me to find. Being a programmer and builder of digital products the first thing you think is "How hard can it be?" and you start hacking away.

That's the most fun part about creating things. Have an idea, dive into it, research new topics, collect some useful things and put things together. You make visual progress quickly and learn new things. It feels a bit like crafts back in the day at primary school. Taking some paper, glue, spend a bit of time and be happy about making something awesome.

I was in the flow, the result was a really useful tool that our team have been using for years now, it saved a lot of time and mistakes. Time well spent. It also hurts your eyes because it is ugly as a naked cat, that is just a bonus. The itch has been scratched.

Aside from some quirks you need to know, it actually works really well. You just drop in your stuff and you do your thing. Focus on the actual copy.

Now, a few years later, I was curious what the new options would be. To my surprise there are some new projects, but not a whole lot. Most of them lack the focus and simplicity. That's when I decided to share my creation with the world. I figured that it could scratch some more itch, helping digital creators like you to focus on creating great products without unnecessary distractions.

A nice opportunity to fix some quirks and do some design work to make it actually look nice. Something I wanted to do for a long time. As much as I like ugly UI's, I like good looking interfaces even more.

I am quite happy with the result, you can check it out at whatwhat.app! There are some details I want to fix and along the way I got even more ideas for improving the translation process. If you use Angular's i18n and/or XLIFF/XLF files, take it out for a spin 🙂

Please let me know if you have feedback. You can reach out to me in the comments or on Twitter @timetcetera. I love to hear what you think.