Is this abandoned? #73
Comments
|
Related issue #70 |
The problem with all of the suggested solutions, is that they require an existing Magento store to already be running to determine the requirejs dependency graph etc. The promising feature of using baler is it determines the requirejs dependency graph using the existing code of the theme, |
|
Sadly I think it has been abandoned, it has now been removed from the docs magento/devdocs#7876 Improving performance on Magento is hard, the javascript situation is "a bit of a mess" (a very polite understated version of how I want to describe it). Not helped by the contradicting documentation, the place where you should be able to get definitive answers on how things work is all over the place.
Sounds good. But 8000 on this page https://devdocs.magento.com/guides/v2.4/frontend-dev-guide/themes/js-bundling.html you are told:
Hmmm, ok but it still does say to use the minify and inbuilt bundling features. So that's good.
You are also told to minify and bundle on https://devdocs.magento.com/guides/v2.4/performance-best-practices/configuration.html#client-side-optimization-settings but futher down the page you are told:
and
🤦 |
|
I still use baler on Magento 2.4 I forked the magento module to include PHP 7.4 as supported. Baler is unfinished, but the core-bundle is javascript that is loaded on each page and can thus be safely bundled without needing to worry about dependency graphs. The next step would be for baler to generate dependency graphs for pages so that the javascript downloads get initiated much faster and thus improve page load, but since development seems to be paused, that seems unlikely to happen any time soon. Other tools don't really seem to provide better outcomes in my experience, some of them providing even worse performance than default js delivery. Of course on second page load they perform way better, but that isn't useful for drawing in new customers and it's not useful for Search Engines that check your pagespeed. |
|
@Quazz the way you're using it is good, for setting up individual stores, but when we're doing agency type work and have 5-10 stores to setup, using the baler for each store becomes very tedious and hard to automate. It would be awesome if this project continued to grow, but at the moment it seems to be very stale. Obviously with PWAs the project then becomes obselete. I suppose this is just another thing that is forgotten about between the stores running M2.x with themes and the new shiny PWAs. Just with this repository still being in docs and things it becomes a little confusing when trying to figure out the "right" solution before the jump to PWAs. It seems core is simply saying "Go to PWAs", so I guess that's what we have to do. I'll close this |
|
Regarding the below, magepack v2 does this, and we run it in our pipeline.
It has to be magepack v2 to run in the pipeline, it won't work with magepack v1. Magepack 2 uses a custom bundler based on Baler. You need v10+ of node in your CI pipeline for it to work. |
|
I will leave a short summary of my thoughts and tricks to achieve good FE-performance in the current Magento 2 frontend; and let me tell you, Magento 2 FE CAN be very fast without having to go down the road of Venia/Vue Storefront etc. What are the main problems with the
LazyloadingNative lazy loading is now available, but according to our experience it still does not help FE performance much (this could very well change in the near future where Native Lazy Loading could be the best way to approach this) and an PreloadMagento 2 does not make use of "new" preload techniques Preload resources article. It is not good to preload too much stuff, but things like:
Magento 2 JavaScript initialization issuesTo let the browser "breathe" it is worth looking into the concept of an Another thing to take a look at is using the Browser Cache API or ServiceWorkers to leverage better caching in the browser; either of these is one of the things needed by the PWA specification (you don't need React, Vue or Venia to be a PWA). See Google's advices on how to make you page faster for example using SummaryNone of the above are really "low-hanging fruits" so to say since each of them usually needs specific tweaking for each site since all sites are different, but I hope I shared some interesting insights from our experience. |
@frno-morita 🤨 such a thing (a Magento 2 si 8000 te with a score of 95-100) doesn't exist :) |
|
@digiltd yes it exists. Check out the recently released hyva.io |
|
@woutersamaey indeed, though that is essentially redoing everything that Magento "provides" in terms of js, layout, templates etc. I applaud @wigman for what he has done, but it was a massive task and ditches everything frontend that Magento provides, but I think realistically, it was the only way :) |
|
@digiltd Exactly. I can only recommend this route. You'll never need to consider anything like Baler or otherwise. |
|
@digiltd @woutersamaey And don't forget of course Magento's own PWA studio https://github.com/magento/pwa-studio ... We're using that commercially and it's working well so far |
After spending some time to get this up and running locally, found that the only bundle created was the
<theme>/balerbundles/core-bundle.jsDid some digging and found this document, which seems to imply other solutions should be used instead https://github.com/magento/baler/blob/master/docs/WHY_CUSTOM.md#how-are-folks-working-around-this-today
I just want to know for definite that this repository is not the intended way to do things.
Is that correct? Or am I missing something here?
The text was updated successfully, but these errors were encountered: