Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I fixed my blog's performance issues by writing a new Jekyll plugin

arclight.run

Post reply on HN
Print view View original

41–49 of 49 posts

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#41

Post by arclight_ »

dewey wrote: post #14
est wrote: post #7

I have a blog with pagespeed score of 98 but still got several pages de-indexed from google. Guess my content isn't that important.

In the Google Search console you can usually see the reason why it's not included. Page speed is rarely a reason for indexing / non-indexing unless it's really bad.

I've clicked into my non-indexed pages, and everywhere that people say it should say the reason why the page is not indexed, there simply isn't a reason mentioned. It just says the generic crawled but not indexed even when clicked into specific pages.

I've even watched YouTube videos of people going into their Search Console dashboard to make sure I'm not missing anything (and indeed I've seen where those people for some pages do see a reason, but for mine I do not).

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#42

Post by exiguus »

maccard wrote: post #4
bentocorp wrote: post #3

I use Jekyll for my company website [1] and managed to get a lot of speed optimisations simply by using a post-processing tool on the statically generated output. The tool I use is Jampack and I'd highly recommend it: https://jampack.divriots.com For my product website, it reduced the overall size by 590MB or approximately 59% in size, along with changing the HTML/CSS to make the optimisations that this article notes…

Do you mean KB or do you have a 1GB website??

I guess mostly picture. If you have 500 posts, one picture for each, and then optimize image for responsive and browser compatibility, there should be 3 to 12 images per image source set:

Mobile, Tablet, Desktop as breakpoints / AVIF with webp or jpeg fallback, Retina/Normal.

And this will increase the overall-size to 12 x 500 x 50kB = 300MB

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#43

Post by exiguus »

pavel_lishin wrote: post #33

Is 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.

It saves bandwidth for the user. Especially if you imagine that the user does not read the entire article. And it may load the images that are in the viewport faster, as the bandwidth is not taken up by images that the user cannot yet see.

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#44

Post by arclight_ »

firefoxd wrote: post #34

When 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…

Thanks for sharing, those are good points.

Another aspect of image optimization that I'm aware of, but haven't even bothered with yet, is handling the art direction problem of responsive images.

Like "pan and scan" conversions of widescreen movies to the old 4:3 TV size, if you're serving a narrower image to mobile devices than say a desktop browser, the ideal image to serve is probably not a generic resize, or center-cropped version of the image. Mozilla has a nice page on responsive images that explains it better than I could: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Res...

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#45

Post by exiguus »

firefoxd wrote: post #34

When 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…

If i see it correctly it is avif with webp and png fallback. My browser load the screenshots in avif.

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#46

Post by arclight_ »

bentocorp wrote: post #3

I use Jekyll for my company website [1] and managed to get a lot of speed optimisations simply by using a post-processing tool on the statically generated output. The tool I use is Jampack and I'd highly recommend it: https://jampack.divriots.com For my product website, it reduced the overall size by 590MB or approximately 59% in size, along with changing the HTML/CSS to make the optimisations that this article notes…

This looks fantastic! I really like how it's static site generator-agnostic, and the intelligent CSS and above-the-fold optimizations.

I'll definitely give this a try - only wish I knew about it before I wrote my thing!

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#47

Post by bentocorp »

maccard wrote: post #4
bentocorp wrote: post #3

I use Jekyll for my company website [1] and managed to get a lot of speed optimisations simply by using a post-processing tool on the statically generated output. The tool I use is Jampack and I'd highly recommend it: https://jampack.divriots.com For my product website, it reduced the overall size by 590MB or approximately 59% in size, along with changing the HTML/CSS to make the optimisations that this article notes…

Do you mean KB or do you have a 1GB website??

It is a 991MB website, before optimisations.

The large majority of this comes from large header images for the Insights post content: https://www.magiclasso.co/insights/

These are png images that are relatively large in size until optimisation creates smaller, multiple image set versions.

I wouldn't say that this is an unusually large site. Any site with a medium amount of content would likely grow to such a size.

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#48

Post by ZanderEarth »

est wrote: post #7

I have a blog with pagespeed score of 98 but still got several pages de-indexed from google. Guess my content isn't that important.

Canonical tags set up correctly? Basics in place like meta data? Content rendering in the HTML? Google will generally index a page pretty quickly, even from a site with lower authority.

Re: How I fixed my blog's performance issues by writing a new Jekyll plugin

#49

Post by broken-kebab »

exiguus wrote: post #42
maccard wrote: post #4

Earlier quoted context omitted.

Do you mean KB or do you have a 1GB website??

I guess mostly picture. If you have 500 posts, one picture for each, and then optimize image for responsive and browser compatibility, there should be 3 to 12 images per image source set: Mobile, Tablet, Desktop as breakpoints / AVIF with webp or jpeg fallback, Retina/Normal. And this will increase the overall-size to 12 x 500 x 50kB = 300MB

I doubt there's a practical reason for an average website, especially something blog-like to have pre-optimized pictures for that many screen types.
Post reply on HN