Next.js: Static asset processing and optimization

[ccorcos]

any recommendations here? I usually use webpack with the image compression plugin, but it appears the standard approach is just to use file paths to the static directory. if I wanted to optimize my image assets, how do you recommend I do that without overwriting the full resolution images?

[arunoda]

Currently, we don't have a built in way to do it.
But you need to do it manually for the static assets in your app.

Also the best way is to move all static content into a CDN. We track that here: https://github.com/zeit/next.js/issues/737

[timneutkens]

@arunoda might be an interesting feature though

[ccorcos]

Hmm. Shouldn't it be as simple as adding a webpack loader?
On Tue, Jan 24, 2017 at 18:45 Tim Neutkens [e-mail] wrote:

@arunoda https://github.com/arunoda might be an interesting feature
though

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/next.js/issues/867#issuecomment-274782180, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABth3wC4F1s5IMI_83Sm4KaBfvsy0i4Sks5rVeQ6gaJpZM4Lr-zY
.

[arunoda]

@ccorcos It's true if that's only a client side app.
But since we do SSR stuff, we can't do everything in node which can be done with Webpack.

[ccorcos]

I'm confused, I figured next compiles all pages as different entry points
using webpack. Is webpack being used at runtime?
On Wed, Jan 25, 2017 at 18:33 Arunoda Susiripala [e-mail]
wrote:

@ccorcos https://github.com/ccorcos It's if that's only a client side
app.
But since we do SSR stuff, we can't do everything in node which can be
done by Webpack.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/zeit/next.js/issues/867#issuecomment-275085695, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABth34oEmigeL5oGCRxeApfXAOrUUbefks5rVzMlgaJpZM4Lr-zY
.

[arunoda]

Yes we do. That part is fine. But then we need to run those files on the server. Running that exactly on the server is impossible (and cost us with perf). So, we run it without webpack on the server for SSR.

That's why we can't simply use everything webpack support.

[ccorcos]

Ah, so on the server, you're just using babel plugins but in the browser, you're loading a bundle from webpack... That makes sense.

Although what's wrong with running the webpack build on the server? You can set Node.js as a build target.

Then we'd be able to create custom chunks and dynamically async load them inside getInitialProps...

[arunoda]

@ccorcos Even it's Node.js target it takes time and compile time(CPU). We don't need that.
We've a much efficient and speed setup.

[ccorcos]

Well you can compile only once before you deploy...

[arunoda]

@ccorcos What about dev time build and about dynamic pages. We need to work on that stuff too.
Anyway, we are not considering on going this approach at this time. (At least for 2.0)

[ccorcos]

What about dev time build

You can leave out the image processing plugin

What about... about dynamic pages

Well the pages are still built and split with webpack statically though right?

[ccorcos]

I'm just failing to understand what exactly is the limitation here.

[sedubois]

It might make sense to open a new issue to discuss the topic of "universal webpack". Sounds like it would have the potential to fix several limitations and reduce code complexities coming from the differences between server and client side.