WebDev

From time to time I see and look at some SEO articles to see what others are writing about and what’s new that I need to look at.

I have started reading an article about some SEO mistakes to avoid, and the first thing that stopped me from reading further was a point about “Read more” links.

It was stated that the severity of using the “read more” link for SEO is high and that the developer of the site should remove the use of “read more” links in favour of article links (for example title as a link).

That particular author claimed that when that has been done, the site visibility “went through the roof”.

Partly I can agree with that, but removing “read more” links shall not be advised if it is done right. Here is why.

I have been reading for some time that one of your solutions for better SEO will be removing pages that are not performing well and just wasting a crawl time.

Redirecting them to the most relevant part (using redirect 301) or where such doesn’t exist, pointing back to the homepage and advising search engines that it’s gone (using redirect 410).

There is one problem with removing something from a page that you spend a lot of time creating. There is a sort of sentiment in it.

Even when I migrated from WordPress to Hugo I moved all pages to a new website. I have done an initial review and did some corrections, but never looked at the test from a merit point of view.

Generally, I am against using the rule of removing content that performs poorly in search engines. Not always the case, that the content is not desired. Sometimes simply is unique and targeting the niche that shall be here for some who will need it.

With such an approach, I am creating some of my posts. To give users something that I struggle to find. You can call it niche but in reality, this is something that some people are searching for and cannot find easily. If I struggle to find a solution and I will come up with my own, I would like to share this with the world.

When Google announced that they would force us to move away from Universal Analytics to Google Analytics 4 I wasn’t happy. Due to a lack of alternatives in minimal analytics, loading official (bloated) tracking code that weighs 171kB (in my instance), which is liable for blocking by various AdBlockers, wasn’t something that I had been looking forward to.

I started searching for a solution. Due to the lack of it, I decided, by hit-and-miss approach, to create my own, and I think I did it. It currently weighs 3kB minified (version 1.10). Its main purpose is to track page views (page_view, session_start and first_visit) on our website in Google Analytics 4 property. Since version 1.06 it detects and tracks site searches (view_search_results), from 1.07 search query (search_term), from 1.09 scrolls (scroll) capturing scroll events each time when a visitor gets to the bottom of a page (90% and below) and from 1.10 it got ability to track <a href links to files with specified extensions (see below) and all these links where there is a download attribute specified independently of the extension of the file.

My site, until recently, was using a system font stack, mostly because I would like to have the lightest website possible.

My featured images, heavily optimized, still account for large LCP (Largest Contentful Paint) and adding custom fonts, in the most common way, can increase the overall weight of the website.

I am happy with my site, but on others, I need to use specified fonts to get the right visual experience across all user devices. In that case, I need to load additional fonts to accomplish that.

The fonts not only add weight to the website but also can hurt CLS (Cumulative Layout Shift) if loaded incorrectly. As CLS is part of essential Core Web Vitals, its poor score can drop a website significantly in Google Search results.

Ironically, Google, on their Google Fonts website provides information (code) on how to implement the desired font in our website. The problem is, that their solution will have a huge negative impact on your website.

Not only they are loaded from an external source, but the speed of loading of your website and external fonts can also vary and cause, ironically, CLS, that Google will penalise you on.

A widely recommended method is to self-host your fonts (even these from Google). This, in most cases, may improve an impact on CLS, but not always. There are plenty of factors in how these fonts are delivered. If our hosting is poor and we are not using CDN (Content Delivery Network) then we can see worse results than loading fonts directly as Google advised.

Self-hosting fonts are the right approach, but it requires a couple of tweaks before it will work well for us in matters of web performance.

Let’s start with, how to load them correctly.

On the 16th of March 2022 Google announced its plans for a shutdown of Universal Analytics property and replace it fully with Goole Analytics 4 (v4) that been in the market since late 2020.

Google like to kill off their services. Luckily, this is not about shutting down Google Analytics but only the method, how analytics data are collected from websites. If you have been using Google Analytics for some time, then it’s more likely that you have been using Universal Analytics. You will know that by looking at your tracking code that will carry UA- on front of the numbers.

Analytics in its 4th version (UA is 3rd) has been developed for some time, but it wasn’t adopted as quick as Google could expect (or want), this is why they forcing a change by shutting down one in favour of another.

Over some time I have been looking for ideal Cookie Consent Banner implementation on my websites. The main goal was to make sure it’s not causing CLS (Cumulative Layout Shift) resulting in poor Core Web Vitals (and downgrading website in Google Search).

I found the solution that worked for me for some time.

Together with other optimisation works I managed to achieve my goal, however, from time to time I saw a spike in PageSpeed Insight for some pages and I couldn’t figure out what else I could do to make sure that Cookie Banner (Bar) is not causing CLS.

You may say what you want about Google Analytics, especially about how “they” are, apart from displaying data for you, using data gathered for “their” business purpose (forget about privacy). If you are a website owner and you are looking for a reasonable tracking method for your visitors, this is the solution that you will pick in the first place.

The problem with Google Analytics is that their tracking script weights a lot and that is slowing down your website.

When I moved into a static website made using Hugo I optimised almost everything, including the Google Analytics script. Instead of bulky code loaded from Google, I used Minimal Analytics.

Initially, I put it as always, in the head of my website. Later on, I added it to my 404.html page. I created my own 404 page to override the default Netlify landing page that appears when the visited URL was not found.

The idea was initially to find broken links that visitors are using and to fix them with relevant redirection. However, it didn’t take long until my analytics were spammed by stupid people (and their bots) trying to find a way to break in to my site.

When I moved to Hugo with my website, I looked to optimise everything and implement new techniques. Once Safari gain native WebP support back in 2020, I implement WebP following PawelGrzybek.com - WebP and AVIF images on a Hugo website. The post introduced not only how to implement WebP (at the time when Hugo <0.83 haven’t support it), but also shown how to go step further by implementing AVIF.

This method require you to have WebP/AVIF files stored along with PNG/JPG and not relay on rendering them when the site is build.

I was interested in implementing this as well, but after some tests in my environment I decided not to, and here I will explain why (and it is not about browser compatibility — Safari incompatibility).

For over a couple years my employers website been served from shared hosting solution on Namesco. On recent years however, we feel that we been left behind. It started with just PHP, where we stick with the 7.3 version without not plan to go into 7.4 and not thinking even with 8.0. Until significant issues with performance of the servers (where even Customer Support couldn’t help without persuading you to migrate to dedicated servers), it was time to think what’s next.