I really, really, really doubt the "crawled but not indexed" status can have anything to do with page loading speed. Lower ranking, sure; although Google doesn't say how much weight they give to page speed when ranking. But not exclusion from the index.
How I fixed my blog's performance issues by writing a new Jekyll plugin
31–40 of 49 posts
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#32Earlier quoted context omitted.
Yes, those are reasonable metrics. But ive seen too many people outright dismiss using a library that has been stable for a long time for not having had an update in like half a year and rather go for one that is only half baked but had one in the last few weeks. Thats why I push back against the notion that no updates = abandoned. Personal, painful, experience.
But "a few months" isn't 5 years, right? Last update in January 2025 seems fine for a lot of things. If that was January 2020 I'd probably bypass it as well.
This second comment was more meant as an elaboration on why I personally dislike the not updated recently = abandoned assumption that a lot of people take by default, rather than actually checking on whether its abandoned.
As in, "I've personally witnessed people passing over mature libraries that just don't need any more updates in favor of ones that aren't really production ready but get frequent updates, which causes quite a bad dev experience down the line".
I am not really good at articulating my thoughts properly, so thanks for making me write this longer comment.
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#33Is doing things like lazy-loading images further down the page actually good for users and readers, or only for making sure Google indexes your site?
I'd be hella miffed if I loaded a page on my laptop, then opened it up somewhere without internet access, and realized that half the page fully didn't exist.
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#34When it comes to images, developers tend to look for automation to resolve the format. But the optimization should come at creation time. Yes, it's a good idea to have multiple resolution to have the browser select the best size, but the image on the screenshot clearly should have been a jpeg or webp.
I commented a couple days ago about how I taught my team about image formats [0], and just published a blog post this morning [1].
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#35I have a blog with pagespeed score of 98 but still got several pages de-indexed from google. Guess my content isn't that important.
This might help: https://support.google.com/webmasters/answer/7440203?hl=en#s...
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#36And yet when I open the page it first loads without CSS and then after 0.5s applies the style.
Responsible: This is deliberate FOUC. Why, I have no notion whatsoever. It should read:
Yeah. Maybe they separated critical and non-critical CSS? and delayed non-critical CSS, that way you'll see a degraded version of the page on slow connections.
Can't think of any other reason why you would do this.
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#37When it comes to images, developers tend to look for automation to resolve the format. But the optimization should come at creation time. Yes, it's a good idea to have multiple resolution to have the browser select the best size, but the image on the screenshot clearly should have been a jpeg or webp. I commented a couple days ago about how I taught my team about image formats [0], and just published a blog post this…
The "mistake" of all PNG has its advantages: you can convert to JPEG (or whatever else) after the fact with equivalent results to if you had done it that way in the first place; not the case the other way around.
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#38Great effort - really happy to see people keeping Jekyll alive. Q: Why did you decide to rewrite the whole image handling instead of just relying on the jekyll_picture_tag gem ( https://github.com/rbuchberger/jekyll_picture_tag ) - I am using that since years and it just works just fine.
Simply because when I google'd my use case I didn't discover that plugin!
Maybe it would make sense to decouple the image processing code from my library so the `jekyll_picture_tag` could be used, since it's a bit orthogonal to the Propshaft-esque asset loading.
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#39And yet when I open the page it first loads without CSS and then after 0.5s applies the style.
Responsible: This is deliberate FOUC. Why, I have no notion whatsoever. It should read:
IIRC I followed the advice of PageSpeed or another Google page to do it that way. ¯\_(ツ)_/¯
Appreciate the feedback!
Re: How I fixed my blog's performance issues by writing a new Jekyll plugin
#40The page doesn't load any CSS, I get a 301 loop on main-e03066e7ad7653435204aa3170643558.css leading to ERR_TOO_MANY_REDIRECTS and over 100 requests and a nearly 1 second load time. Sections are displayed lazily and on each scroll I get dozens of requests sent to google-assets-formatavif-width672-4399f142b495ab9796b3b91053c097b9.avif with the same 301. This leads to section taking over 200ms for 4 lines of text. Whil…
No idea what would cause that as I'm just hosting static assets on Cloudflare Pages. But thanks for letting me know!