21–30 of 49 posts
Earlier quoted context omitted.
They are most likely referring to the overall size of the whole website including all generated HTML for posts, static content, styles etc.
1gb is huge even for a whole website. Unless there are videos or hundred of high definition photos. Curious to know what makes up this space.
> And at this point, the library seems to have been abandoned as it hasn't been updated in over 5 years. Why is the automatic assumption foe something not being updated for a few years to be abandoned instead of done? Are libraries not allowed to be stable/done?
You really need to look at the issues/updates ratio. Are there 57 open issues that haven't been triaged or addressed? Are there multiple open PRs or requests that should be easily added and are just sitting there rotting?
On the YouTube embed aspect, using a component can take lots of time and efforts. Just sharing another approach where you keep the YouTube embed iframe, but replace the domain "youtube.com" by this specific domain "embedlite.com". It loads only the thumbnail of the video and when someone clicks on it, it loads the full YouTube player. More info: https://www.embedlite.com
Their example doesn't even seem to work on mobile at least (just iframes the homepage itself), which doesn't really inspire confidence.
The 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…
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…
> And at this point, the library seems to have been abandoned as it hasn't been updated in over 5 years. Why is the automatic assumption foe something not being updated for a few years to be abandoned instead of done? Are libraries not allowed to be stable/done?
Aside from the specific tools in use (JS has a higher maintenance burden than a golang lib, for example) You really need to look at the issues/updates ratio. Are there 57 open issues that haven't been triaged or addressed? Are there multiple open PRs or requests that should be easily added and are just sitting there rotting?
Thats why I push back against the notion that no updates = abandoned. Personal, painful, experience.
The 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…
The page is loading fine for me.
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.
> And at this point, the library seems to have been abandoned as it hasn't been updated in over 5 years. Why is the automatic assumption foe something not being updated for a few years to be abandoned instead of done? Are libraries not allowed to be stable/done?
The idea that this kind of project is "done" without even occasional chore updates just has no shot. It's obviously off of its maintainers' "rotation".
Earlier quoted context omitted.
Aside from the specific tools in use (JS has a higher maintenance burden than a golang lib, for example) You really need to look at the issues/updates ratio. Are there 57 open issues that haven't been triaged or addressed? Are there multiple open PRs or requests that should be easily added and are just sitting there rotting?
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.