Not really as were on brix-cms, meaning we dont usually touch wicket and loading the complete JS in header is a bad idea as long as its not capable of beeing defered - the performance gets worse then in our tries
----- Ursprüngliche Mail ----- > Von: "Maxim Solodovnik" <solomax...@gmail.com> > An: dev@wicket.apache.org > Gesendet: Mittwoch, 29. November 2017 10:01:46 > Betreff: Re: 8.0.0 blockers > You can add your scripts to the "custom place" > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_put_javascript_inside_page_body > And provide your "minified and optimized JS file from webdesigner" jquery > version as the main one for wicket ..... > > On Wed, Nov 29, 2017 at 3:57 PM, Korbinian Bachl < > korbinian.ba...@whiskyworld.de> wrote: > >> Yes, you are right - it has to be optional at least, something even the >> current jQuery reference isn't yet (you only can provide an empty one js >> file - still a request); >> >> From my experience this all is worse than at the time before jQuery was >> introduced to wicket as this really slows down the DOM process. In my >> proposal I at least made the mistake that I didnt think of additional >> libraries adding more JS header items - but it should end up with better >> rendering overall IMHO? >> Maybe a concentation of all these header things in an external resouce >> file might be the better solution... (e.g.: <script defer src="/requesrt >> specific fake path"> ) >> >> I originally thought that this might also be put into the footer, right >> before the </body> tag, but Andrea del Bene was against it pointing to the >> new defer / async properties which is somehow right. >> >> In my app the problem is that I load 2 times the whole jQuery... and 1 >> only for wicket as 2nd one is from a minified and optimized JS file from >> webdesigner; >> >> >> >> ----- Ursprüngliche Mail ----- >> > Von: "Maxim Solodovnik" <solomax...@gmail.com> >> > An: dev@wicket.apache.org >> > Gesendet: Mittwoch, 29. November 2017 09:47:38 >> > Betreff: Re: 8.0.0 blockers >> >> > Hello Korbinian, >> > >> > I have analyzed this issue using our main application. >> > I have extremely bad report from Chrome Audit tool >> > Application took 16 seconds to display something meaningful >> > >> > My first intent was to work with Wicket internals to optimize load time. >> > BUT My initial page loads lots of scripts from wicketstuff, >> > wicket-jquery-ui and some internal JS files >> > >> > So I did the following: initially empty panel with of these pure CSS >> > loaders http://tobiasahlin.com/spinkit/ is loaded >> > Additionally jquery+wicket-ajax+wicket-event are loaded to register >> handler >> > >> > as soon as handler will get onload event it will start "main" loading >> > >> > This way user will see sort of progress while loading is being performed >> in >> > the background >> > >> > >> > Your proposal can be implemented, but there should be an option to turn >> off >> > wrapping every script with "window.addEventListener('DOMContentLoaded', >> > function() {" >> > >> > I can work on this issue but I would like to hear thought of "senior" >> > members first :))) >> > >> > On Wed, Nov 29, 2017 at 3:30 PM, Korbinian Bachl < >> > korbinian.ba...@whiskyworld.de> wrote: >> > >> >> I'd like some comment on WICKET-6498, as that wicket-JS impl. currently >> is >> >> just not good IMHO as its blocking the DOM with JS; >> >> >> >> Best, >> >> >> >> KB >> >> >> >> >> >> >> >> ----- Ursprüngliche Mail ----- >> >> > Von: "Maxim Solodovnik" <solomax...@gmail.com> >> >> > An: dev@wicket.apache.org >> >> > Gesendet: Mittwoch, 29. November 2017 03:32:48 >> >> > Betreff: 8.0.0 blockers >> >> >> >> > Hello All, >> >> > >> >> > do we have any blockers for 8.0.0? >> >> > >> >> > >> >> > -- >> >> > WBR >> >> > Maxim aka solomax >> >> >> > >> > >> > >> > -- >> > WBR >> > Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax
