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

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

github.com

Post reply on HN
Print view View original

41–50 of 65 posts

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

#41

Post by chrismorgan »

kibwen wrote: post #9

I'm interested in the notion of identifying "critical" CSS that should be inlined rather than live in its own stylesheet. I was hoping there was some principled way of identifying critical and non-critical CSS (e.g. user interaction effects like :hover would always be considered non-critical), but it looks like the library it's using just tries to render your page and do a best-effort detection on which rules are con…

If you have less than 50KB of CSS, inline it. (And if you have more than 50KB of CSS, you’re probably doing it wrong. Well, OK, maybe you’re inlining fonts too, that’s understandable. But if you have more than 50KB of other styles, you’re probably doing it wrong.)

Seriously, inlining is absurdly good for performance, even compared with a warm cache, and the threshold where external stylesheets or scripts perform better is surprisingly high, into the hundreds of kilobytes for some common markets.

The notion of critical CSS… it’s a defeatist attitude, trying to grasp back some squandered performance, rather than fixing the underlying problem.

I regret to say this is just based on casual experience and observation, not any methodical technique. I would really like someone to run with this concept and measure it more fully. I just doubt it’s going to be me.

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

#42

Post by chambored »

lelandfe wrote: post #29
chambored wrote: post #18

This is exactly what I've been looking for. I had been using my own scripts with Sharp for image optimizations like this, but this eliminates the need for the that entirely and works much better! I ran Jampack after building my Quarto static site and got a 32% smaller folder with no noticeable drawbacks yet. Here are my metrics before Jampack and after using PageSpeed Insights: before Jampack: - mobile: - 52 Performa…

Remember that Lighthouse (and therefore PageSpeed Insights) scores fluctuate. Consider running multiple times and taking median scores when doing comparisons of performance like this. "The median Lighthouse score of 5 runs is twice as stable as 1 run" https://developers.google.com/web/tools/lighthouse/variabili...

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.

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

#44

Post by rrr_oh_man »

samstave wrote: post #34
nolok wrote: post #33

Earlier quoted context omitted.

I would say it's exactly why I miss the network of forums of old internet, where this interaction was common on pretty much any subject matter from video game saves to tooling to whatever. Facebook groups, discord rooms, reddit subs and the likes just aren't the same, they all feel so impersonal and detached, in some people compete for internet points, in others everything is ephemeral and closed off ... Maybe it's j…

Sam's Law: "As an idea or subject gains wider popularity and interest, the level of passion and laser focus on the _outcomes_ of the idea or subject gets diluted to the average level of understanding of the interested audience for the core subject" (my weak attempt at describing this issue)

The Peter Principle of communities: They grow until they become useless.

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

#45

Post by aendruk »

me_bx wrote: post #40
xnx wrote: post #5

This reminds me of the PageSpeed modules for Apache and Nginx https://developers.google.com/speed/pagespeed/module

I believe the project is not maintained anymore. Github repository is archived: https://github.com/apache/incubator-pagespeed-ngx . Or has it perhaps moved to some other location?

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

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

#47

Post by georges_gomes »

rkagerer wrote: post #28

This looks great! Although personally I hate it when I scroll a page beyond the 'fold' and have to wait for images to load. By default, does this load the remaining below-the-fold content in the background once the above-the-fold stuff is complete?

As user @lelandfe pointed out here, Jampack is using browser native loading="lazy".

There is currently no way to change this behavior but I could add an option that would preload the below-the-fold images in the background when all the page is loaded. It's actually a pretty nice idea.

I'm just afraid it will load unnecessary images at the bottom of the page but if it's an option, anybody can choose to have it or not!

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

#48

Post by georges_gomes »

chrismorgan wrote: post #41
kibwen wrote: post #9

I'm interested in the notion of identifying "critical" CSS that should be inlined rather than live in its own stylesheet. I was hoping there was some principled way of identifying critical and non-critical CSS (e.g. user interaction effects like :hover would always be considered non-critical), but it looks like the library it's using just tries to render your page and do a best-effort detection on which rules are con…

If you have less than 50KB of CSS, inline it. (And if you have more than 50KB of CSS, you’re probably doing it wrong. Well, OK, maybe you’re inlining fonts too, that’s understandable. But if you have more than 50KB of other styles, you’re probably doing it wrong.) Seriously, inlining is absurdly good for performance, even compared with a warm cache, and the threshold where external stylesheets or scripts perform bett…

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

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

#49

Post by samstave »

rrr_oh_man wrote: post #44
samstave wrote: post #34

Earlier quoted context omitted.

Sam's Law: "As an idea or subject gains wider popularity and interest, the level of passion and laser focus on the _outcomes_ of the idea or subject gets diluted to the average level of understanding of the interested audience for the core subject" (my weak attempt at describing this issue)

The Peter Principle of communities: They grow until they become useless.

Petering out, as it were :-)

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

#50

Post by rkagerer »

lelandfe wrote: post #36
rkagerer wrote: post #28

This looks great! Although personally I hate it when I scroll a page beyond the 'fold' and have to wait for images to load. By default, does this load the remaining below-the-fold content in the background once the above-the-fold stuff is complete?

It does not. It leverages native lazy loading. All major browsers treat a `loading="lazy"` attribute as meaning "do not load this image/iframe until it is nearly in view." https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im... However, this does inline aspect ratios, so the layout won't change after they're done loading - the cardinal sin of lazy loading.

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.

Post reply on HN