Show HN: Jampack – Optimizes static websites as a post-processing step

Just want to say this two comment interaction is a perfect distilled example of value of posting to HN for such things.

I've zipped it up and sent a link.

That's a fair point. There were certainly small discrepancies when I ran it multiple times, but I'll use the median metric moving forward.

Is it what you call "freeze opentype axes based on font-feature-settings" or is it something else?

I was talking in context of variable fonts which come with lots of features mapped to opentype tags and axes. font-feature-settings property selects (or activates) those features. Usually this is done at few CSS selector levels. The variable fonts can be trimmed by freezing those features. I did something like this with Fira Code a few years ago. [1]

I would like to do the subset font optimization. I'm just not sure how much of an improvement it's going to be. Have you done it manually before?

It can be quite an improvement for fonts like Inter which ship with massive number of glyphs to support different languages.[2] Doing this manually is a huge pain. Zach Leatherman created a tool called Glyphhanger to automate some of the usecases [3]

[1]: https://github.com/naiyerasif/FiraSourceMono

[2]: https://paulcalvano.com/2024-02-16-identifying-font-subsetti...

[3]: https://github.com/zachleat/glyphhanger

Because sometimes custom fonts are a design/product requirement. Using a system font stack is not a solution for everyone.

Rolled back, https://www.amazingcto.com/

There where many errors, I'll try again later and send you the vitals + errors.

[Edit] Generally I would love this.

Thanks.

10+ years ago I wrote a GreaseMonkey userscript for a dating site that collected all your results into one scrollable table. It exercised very explicit control over the image loading sequence. If I recall (and my memory might be spotty), it grabbed 1 thumbnail image per match initially, in the order they were displayed, to populate the table. Once all the thumbnails were pulled (which didn't take very long), it would start downloading full sized images, in the background. Hovering a match to view more details would immediately prioritize that matches photos, and if you hovered over one of said match's photo thumbnails (as if to click) that specific image would be placed at the top of the queue.

It was all done using Javascript (no frameworks) and XmlHttpRequest, and worked pretty well. This was back when servers only allowed you a couple (or handful) of connections at a time. I wrote a "TaskQueue" class in Javascript implementing a very simple form of cooperative multitasking (jobs designed to do their work in chunks). Tasks could "preempt" others, and you could define simple relationships so a group of tasks could block on one they were dependent on.

Funny story, I actually sent a link to the tool to a girl on the site who I eventually wound up in a long-term relationship with ("here, let me help you make it more efficient to browse for other guys...").

Anyway, at the time I felt like it was table stakes that a page like this should be able to exert some sensible control over the sequencing and prioritization of its image assets, in a fashion that has the user's best interests at heart. I'm glad browsers have finally evolved out-of-the-box attributes like "loading=lazy", but I kind of wish there were an option between "eager" and "lazy" that simply deferred the lazy content until all the other content is done. So I can still walk away to get a coffee (or switch to another tab) and come back to a fully, instantly-responsive page.

That repository links to a site https://www.modpagespeed.com/ which in turn links to a different repository https://github.com/we-amp/ngx_pagespeed

It only has one extra commit, which deletes RETIRED.txt which was added in the repo you linked.

So at the moment it seems someone is intending to continue development. And might even be working on it, but haven’t pushed any work to the main branch.

I haven’t seen a clear answer. https://news.ycombinator.com/item?id=37578513

https://tinonyman.com/archive

Not my site, but mine (in progress) is almost exactly the same UX/UI but with zero dependencies or libraries/frameworks.

I don't know if we are on the right track if we have to ship "super optimized assembly" for HTML and CSS

You know, I don't disagree. In fact I am 100% with you, it's just that we have to work with the realities presented in front of us. I'd think that nowadays we (as in, the general bigger tech community) know how would we do HTML+CSS much better from scratch but this is not ever happening -- I think we all know it.

So the next best thing in my view is (when it comes to generating static pages, that is, not sure about how viable this tool would be if you put it in the pipeline to improve all your dynamically-generated HTML -- it has to be hyper-optimized in order for it to not get in the way; having an nginx/Caddy plugin could also work):

1. Write Markdown or something else that's easier on the eyes and fingers;

2. Write your own CSS or use a theme from your SSG software;

3. Generate the HTML with your SSG software;

4. (NEW STEP) Run it through JamPack;

5. Deploy.

Personally as a techie I want my pages to have 100/100 lightweight / speedy / small score. That includes things like not loading images until they enter the viewport, that includes using all sorts of OS- / browser-specific hackery for faster loading, it includes the fastest time to first contentful paint... that includes everything that can be used in terms of tricks, in fact.

So again, I get your point and I really wish we lived in that reality but at one point I stopped believing that we ever will so I am trying to settle for the second best thing.

To back this up I would point to https://news.ycombinator.com/item?id=32587740