Posts with Tag
Recently I have been annoyed when my weekly WebPerformance Report email from WebPageTest shows a failure on Compress Transfer.
This failure, reported in red was done by just one small file… favicon.ico.
Recently I have been annoyed when my weekly WebPerformance Report email from WebPageTest shows a failure on Compress Transfer.
This failure, reported in red was done by just one small file… favicon.ico.
If you read my other post, you will find out that I recently rediscovered Progressive Web Apps (PWA).
Following this lead, I decided to implement it on the websites, where our main audience browses it from mobile phones. Later I decided to implement it gradually on all of my websites, independently of whether the main audience is on mobile or desktop. As you will see, PWA is quite useful for desktop users as well.
If you are not a first time on my website you already know, that I like simplifying things and using a minimal approach with a complex solution. Overall, if something complex can be done that same, but simple, why not try?
This time I want to cover Favicon during website design.
“A favicon is a browser icon that represents a brand or website. Most often seen next to a web page’s title in browser tabs, favicons can also be found in address bars, bookmark lists, search results pages, toolbars, browser history, and other places across the web.”
I don’t want to reinvent the wheel, as there is already a perfect solution for that, well written and documented by Andrey Sitnik from Evil Martian.
Over the last years, I forget about something called Progressive Web Apps (PWA) until one day I added to my Home Screen a bookmark to Homebridge, and, believe me, or not, I do not add bookmarks that way very often.
When I added this bookmark to my Home Screen on iOS I noticed, that it looks unusual. The icon was like a native app. When I click on the icon it didn’t open inside Safari like other bookmarks but it run on full screen like a normal native app.
Of course, it was still Safari in the background but highly limited to the scope of that single website, that it feels like a native. It certainly can be confused with an app.
Just today, on the 23rd of July Yummy Recipes UK is celebrating the third month from the lunch of the website. We (me, from the development side, and my friend, from the content) didn’t see what was coming.
At the lunch the ambitions were high, but also reality brings us down a bit, as we saw plenty of cooking websites around that we will need to compete with.
During the first two months social media, mainly Facebook, dominates in popularity. Over 1000 people on average viewed each recipe that we shared, whereas our website got only a portion of visits.
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.
My site is using a system font stack, mostly because I would like to have the lightest website possible.
If I want to be listed in the 512kb.club, every kB added to the website matters.
My featured images, heavily optimised, still account for large LCP (Largest Contentful Paint) and adding custom fonts can increase the overall weight of the website, way above 512kB.
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 have a negative impact on CLS (Cumulative Layout Shift) if loaded incorrectly. As CLS is part of essential Core Web Vitals, its poor score can drop down 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 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 CLS.
A widely recommended method is to self-host your fonts (even these from Google). This, in most cases, may improve an impact on CLS, however not always. There are plenty of factors on 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.
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).