Production Build & Deployment

Hey gcob!

I really appreciate the nice words *and* the feedback / idea ❤️. About the lazy-load optimized image, I *do* think that image optimization would have been a good topic to talk about. We have a pull request to add support to Encore directly - https://github.com/symfony/... - but I need to actually review it - things are especially busy these days ;). But can you tell me more about the lazy-load part? Are you referring to when images are loaded on-demand (e.g. as the user scrolls near them)? Or something else? I just want to make sure :).

Cheers!

Hi Ryan,

I really appreciate that you took the time to reply even with these busy days ;) . And thanks for sharing the pull request, that is one important part of the optimisation I was thinking.

For the lazy-load part, it would be 3 important points :
1 - As you already mentioned, it would load the images on demand.
2 - Matrix images should be pre-processed in multiple sizes (mostly mobile, tablets, laptops and desktops for a large image.) In my opinion, it should be the client side to <i>decide</i> which image size to download rather than the server side, because JavaScript can determine a screen size and and server cannot. This is why the first images to load on the screen also need the lazy-load part: JavaScript need to <i>check</i> the screen size before <i>asking</i> the server for the right image. In this point, I use Grunt to build and minify every images in each sizes when adding them to a project. I use Bootstrap sizes to be constant.
3 - Because webp is always lighter than others matrix images types, each matrix images should have a webp version and its original for compatibility. Again, JavaScript is better to <i>know</i> if the client can read webp images rather than the server, so the lazy-load script can <i>ask</i> for the right image type.

In short and to give an example, a large image would have 9 versions of itself : image.original.jpg, image.xs.jpg, image.xs.webp, image.s.jpg and so on. A user can now download the right image size and type for his browser at the right time to save loading time and bandwidth!

I want to mention one last point: the reason I felt lazy-load images was missing to your tutorials, appart hearing you telling awesome jokes, giving us great advice, for all the extra-learning and making programming super fun (I can hear people telling me that I am a “lèche-botte”), is that Webpack Encore is a powerful tool and it is already ahead for optimisation in many ways, so it would be a huge part missing to not include image process.

One last thing: it is by using the Chrome Audits tool that I tweaked my client-side optimisations knowledge. I think sharing this super cool tool could be also very nice for the other developers :D .

I hope you’ll find this topic interesting! As I already mentioned, keep the great job. By the way, I live in Canada and as you said in a previous class, poutine is great ;)

-Your fan, Jacob.

Hey gcob!

Great information here - I would *love* to have something like this work out-of-the-box, as I'm sure it would normally require quite a lot of setup to get working. But if you *could*, what an awesome optimization. It looks like 2 separate parts:

A) The lazy-loading part
B) The "responsive image" part where you have multiple image sizes

Part (A) I think can't be done by Encore because it's up to your JavaScript to be loading those images lazily. That's not a good or bad thing - this is a fairly common problem to solve. But solving it would be different in a "traditional" server-side-loaded app vs React vs Vue, for example.

Part (B) *would* be something you could with with Webpack. But, I see very little support for this. I only find these 2 Webpack modules - https://www.npmjs.com/packa... and https://www.npmjs.com/packa... - the second is *fairly* popular, but hasn't had a release in 15 months (that's a decade in Node land). I was surprised by that. So, Encore could in theory integrate that second library... but we try to leverage best practices instead of "forging our own way". I'm just simply surprised that there's not more conversation on this topic. I wonder if you have any thoughts on this.

> By the way, I live in Canada and as you said in a previous class, poutine is great ;)

Ha! SO glad you caught that - I've had the pleasure to enjoy it *just* a few times... but what's not to like? :D

Cheers!

Hi @Michele-A!

Thank you for the kind words!

Ok, let's see. Generally, your code looks correct: that is how you should add a plugin. But I'm not familiar with PurgeCSS myself... though I know many people are using it successfully with Encore. My best advice might be to check out a post like this - https://www.phproberto.com/en/41-integrating-purgecss-with-symfony-encore - that has a few details that you don't... but I'm not sure how important they are :).

Cheers!

Hey @simfonyace!

Hmm, that's super weird! So let's see if we can debug. On production, when you all encore_entry_link_tags() what does output? Is it nothing? An error? Or CSS files without the correct "hash" in their filename?

Anyway, these functions work by reading your entrypoints.json file, which is present. The logic lives right here - https://github.com/symfony/webpack-encore-bundle/blob/2.x/src/Asset/EntrypointLookup.php#L106-L142

If possible, on production (hopefully it's not actually "live" with users yet), I would put some debugging code in this function to see what's going wrong. Why isn't entrypoints.json being loaded correctly? Or is it instead, for some reason, loading his data from the cache in that class... but it's out of date? Or is returnedFiles causing an issue - https://github.com/symfony/webpack-encore-bundle/blob/2.x/src/Asset/EntrypointLookup.php#L87 - indicating that, somehow, your app thinks that these functions were called multiple times?

Sorry I can't give you a better answer yet - I've just never seen different behavior like this in dev vs prod before! But if you're able to do a little debugging, I think we can figure it out.

Cheers!

Hey Lechu85,

Thank you for the kind words about SymfonyCasts tutorials! Yeah, we do have a tutorial about deploying, I'd suggest you to check out this Ansistrano course: https://symfonycasts.com/sc... - it's based on Ansible, and even if it's recommended you know this tool, you don't required to know it. But in case you want to know more about Ansible too - we have a separate course about it too: https://symfonycasts.com/sc... . But you can totally skip it and start learning Ansistrano directly, it should not be too complex.

P.S. Yeah, deploying your app manually via FTP client is a bummer... people usually automate this process with a shell script to deploy automatically via SSH instead, and a long time ago we had such an automated shell script, but then we moved to Ansistrano :) Well, right now we do not use Ansistrano because moved from Amazon to SymfonyCloud that has its own deploy tool :)

Cheers!

Thank you very much, I'm starting learning Ansistrano. Maybe in the future I will also switch to symfony cloud :)

Hey Lechu85,

Awesome, good luck with Ansistrano - it's a great tool we all loved! As always, if you have any questions following the course - let us know in the comments below the video :)

Cheers!

Hey Matteo S.!

I think you're the first person that's ever asked about this! First, about this:

> Actually I don't understand why minification is still a thing: do the additional whitespace and newline characters really make a difference in download speed when all the transfers are going to be gzipped anyway?)

Honestly, this is something I've wondered from time to time also. You finally pushed me to look into it. At least according to this site, https://css-tricks.com/the-..., gzipping is the MOST important by far. However, you get a slight improvement if you do both (but at least in the example, it is slight).

Minimization is hardwired into the "production" build of Encore because nobody has ever asked or made a case for it being disabled in the "production" build. The same is true for the filenames. In prod, many of the filenames - the split files specifically - change from things like vendor~bootstrap~....js to just 0.js. That's there to "protect" from exposing your filesystem structure via your filenames. It's a pretty standard thing in Webpack to do this (but leave the longer filenames for dev because they're more descriptive).

Btw, you CAN still (though I haven't done it before) dump sourcemaps in production - that is configurable.

So, this isn't exactly the answer you were looking for, but I hope it clarifies.

Cheers!

Thank you, that's actually quite the kind of answer I was looking for.
I hadn't realised the readable filenames in dev are based on file paths and I understand you wouldn't want that in production. I don't love them per se, but at least they tell me roughly "what file contains what", and _that_ is something I do want in prod as well as in dev. Actually I often get the impression that many people consider the gibberish filenames (and partly the minification too) as an "added bonus" in that they obfuscate things, making it more difficult to reverse-engineer the website for whatever malicious purposes (e.g. stealing your code or hacking - actually that's two pretty different scenarios). And I think that's a flawed approach: If one is really interested in protecting the intellectual property on their code (assuming that's a legitimate goal) they should rely on something way more robust than randomizing filenames and minifying code; and if security is the concern, well then even more so. I know that is not the philosophy behind these design choices, but it is the only reason I can think of that would make it so widely accepted to have garbled unintelligible filenames for css/js files, which to me is a complete abomination.

Hey Matteo S.!

> And I think that's a flawed approach

Totally agree! You can always reverse engineer that if you care enough. And if you have something to hide, someone WILL care enough ;)

Specifically, for the files in the "dev" built files, it is "kind of" a different situation. You can't hide your JavaScript code via obfuscation in any way. However, the filenames in dev mode contain details about your system that do *not* need to be exposed. Specifically, it contains the *source* file paths on your system. I can't really imagine how they would be sensitive, but this is information that does not *need* to be shown to the user (unlike the JavaScript itself), and so Webpack hides it in prod mode. It's probably not a big deal in reality, but hopefully that gives you some idea of why they do that.

Cheers!

Yes I get that. I wish there was an alternative to get readable/understandable/informative file names that were also "clean" and "nice" and suitable for production. If there was I'd advocate in favor of using that as the default for production (and actually, why not, for dev too). Short of that, for my own projects I'll use the dev names both for dev and production, and maybe in the future I'll look into generating my own file names.

Hey Matteo S.!

I understand :). This is something you can control via Webpack's output.filename and output.chunkFilename - https://webpack.js.org/conf... - but I don't remember exactly how that all works (it's been a LONG time since I put that code into Webpack Encore). Here is where we build the "output" Webpack key in Encore: https://github.com/symfony/...

Cheers!

Hey PhpFan!

Good question actually! Well, first of all, versioning obviously will take more time to compile your assets, also it modifies file names too - those things are not something you want for production I think, but it still depends. There might be more things I didn't think about or don't know right now... But, in theory, why not? You can definitely enable versioning for dev mode too for your project. It might be tricky to apply this change globally in the Symfony recipe for the reasons I mentioned above, but it's easy to do on per project basis. So, if you need this - please, just change this behaviour in your webpack.config.js file and that's it :)

I hope this helps!

Cheers!

"Those things are not something you want for production"?? Versioning IS enabled by default on production (and for obvious good reasons), we are talking about why it is not enabled on DEV by default.

The main reason one DOES want versioning on production IS that it modifies file names. So users that have the assets in their browser cache don't get the stale ones. And my point is I don't see how that doesn't apply in development. Stale cached assets are going to bite you in the a** at almost every page load during development. Sure I can enable that, but my point is why is it not the default when I'm obviously going to have to do that?

Perhaps your assumption is that while developing I'll turn off the browser cache? Or hit ctrl+Refresh all the time?

Hey Matteo S.!

I'm pretty sure I'm the creator or that Webpack code originally. So I've replied over on the conversation :).

Cheers!

Hey Stephane

That error usually happens when you forget to run install and compile your assets. If you have followed the course till here, you should have Yarn installed already, so just run yarn install and then compile the assets by running yarn dev

Cheers!

Hi Diego,

Thank to yours reply. I know that and I don't have this problem on mine local machine but the problem is on SymfonyCloud Server. On this server, I have only symfony deploy like command. no possible to do npm run build

Ohh, so you're using SymfonyCloud. That's even better! You have complete control of your deployment process but you have to do it in a specific way. I'll point you to the documentation, read the "Hooks" topic it's quite simple https://symfony.com/doc/cur...
but if you have doubts let me know

Cheers!

Thank for the link.
I think to know what I have this bug : I use npm 7 on my local machine with nodeJS 15 and this is no generated the yarn.lock file that it is use to SymfonyCloud to build the assets.
I don't know if it is possible to use npm on SymfonyCloud to build assets ?

Cheers.

Symfony in general works better with Yarn but you can also use NPM if you desire. I think you only have to add the npm install step in your "build" hook. Try this:

// .symfony.cloud.yaml
hooks:
    build: |
        set -x -e
        (>&2 symfony-build)
        npm install # This line may go before symfony-build - You may want to play with it and see how it goes.

Cheers!

Hey Marco

I think what you can do to improve your rendering is to move to the bottom of the page all of your javascript. And, if you are not satisfied, then, you could do what you say about using "critical" and loading asynchronously the other non-important assets. I haven't used that library but it seems nice

Cheers!

Hey mickael lutin

What's the output you get when running yarn build? Do you get any error in Browser's console?

Cheers!

hi thank you for the reply,
I have no errors in any of the consoles, i have the message who say the build is successfully but no other bad messages.

Hey mickael lutin!

You mentioned:

the design of my site is not the same before and after i run this command

Can you explain this more? If all of your CSS is being processed through Encore, I would expect that your site would basically be unstyled before executing Encore and styled after. Or, are you saying that your design looks different between running yarn dev versus yarn build?

Let us know!

Cheers!

Hey Anton Bagdatyev

If you go to the course overview or click on the chapter's list field on this page, you will see that all the chapters that you have fully watched has a little arrow to its left, if you see any without it, it means that you didn't finish watching it. You've to watch them all in order to get your certificate of completion.

Cheers!

Hey Felix!

Sorry for the slow reply! This is not a nice error! Is this all the output that you see? It looks like it doesn't actually contain the error :/. Are you able to look into the log file to see more information?

All my files in public\build (app.js / app.css / runtime.js) have no hash

About this part, you will only have the versioning hashes when doing the "production" build of encore. The error above IS using the production built, but in case you're running a command locally, just double-check that you're running a production build if you want to see the version hashes. You should also have a line like this in your webpack.config.js file:

Encore
    # ...
    .enableVersioning(Encore.isProduction())

Cheers!

Hey August S.

Thanks for your kind works :)
What I think you can do is to create an "admin" layout where you import the "main" assets that are used across the site and import the admin assets as well, but you will use that layout only on your admin pages. Does it makes sense to you?

Cheers!

I think I understand what you mean. I am already extending my admin.html.twig (where I have linked admin.js and admin.css) with my admin pages. The "problem" is that I can log out and still access the route to the asset and view them: i.e. mysite.com/build/admin.js is still accessible when not logged in.

Maybe this is an apache/nginx problem, but I'm wondering if there is some nifty Symfony solution even here?

Thanks!

Hey Dirk

If you need to pass a template's variable into a JS "entry point" you can do it via window object. We usually set some things on it (window object) and then on a js script, we just read it window.myData.value

Cheers!

Cheers ;) I'll give it a try. Is there also a solution for a template variable in CSS? For example I would use in my "'in-page-css":

background: url('{{ some_variable }}');

Hmm, I don't know a way to pass variables to a css file, probably you will have to keep those styles inlined in your template