[
https://issues.apache.org/jira/browse/CAUSEWAY-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber updated CAUSEWAY-3857:
---------------------------------
Description:
When rendering tables with around 1k rows, a problem starts to become apparent,
that is, the browser is getting very busy to repeatedly request Prism resources
(CSS and JS) from the server.
Those requests are hitting the browser cache, however when the number of
requests becomes large, page loading times go through the roof.
+Example Request:+
...de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/prism/components/prism-java.min-ver-5604F7C290AE9E1F2BBCB4F77D769FD2.js
+Potential Solution:+
I recall that Prism's JS needs to run on every single DOM element, that
requires syntax highlighting. However, this does not mean, that we need to load
the underlying resources more than once per page render. Hope is, that we can
trigger the Prism JS code to be executed client side on all DOM elements that
require it, while only requesting the resources once per page rendering.
+Actual Solution:+
We ended up doing the syntax highlighting now server-side using the GraalJs
Engine. The Engine requires ~3s to get instantiated (once per application
launch). Each DOM element of type '<code>' will then be processed taking around
100ms. This is not great from a performance perspective, but I'm happy with the
approach, as AsciiDoc and Markdown source to HTML conversion is also done
server-side. And it allowed for removal of quirky code in the Wicket Viewer.
was:
When rendering tables with around 1k rows, a problem starts to become apparent,
that is, the browser is getting very busy to repeatedly request Prism resources
(CSS and JS) from the server.
Those requests are hitting the browser cache, however when the number of
requests becomes large, page loading times go through the roof.
+Example Request:+
...de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/prism/components/prism-java.min-ver-5604F7C290AE9E1F2BBCB4F77D769FD2.js
+Potential Solution:+
I recall that Prism's JS needs to run on every single DOM element, that
requires syntax highlighting. However, this does not mean, that we need to load
the underlying resources more than once per page render. Hope is, that we can
trigger the Prism JS code to be executed client side on all DOM elements that
require it, while only requesting the resources once per page rendering.
> [Performance] Wicket Viewer Table Rendering triggers a lot of XHR for Prism
> Resources
> -------------------------------------------------------------------------------------
>
> Key: CAUSEWAY-3857
> URL: https://issues.apache.org/jira/browse/CAUSEWAY-3857
> Project: Causeway
> Issue Type: Bug
> Components: Viewer Wicket
> Reporter: Andi Huber
> Assignee: Andi Huber
> Priority: Major
> Labels: end-user-visible
> Fix For: 3.3.0
>
>
> When rendering tables with around 1k rows, a problem starts to become
> apparent, that is, the browser is getting very busy to repeatedly request
> Prism resources (CSS and JS) from the server.
> Those requests are hitting the browser cache, however when the number of
> requests becomes large, page loading times go through the roof.
> +Example Request:+
> ...de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/prism/components/prism-java.min-ver-5604F7C290AE9E1F2BBCB4F77D769FD2.js
> +Potential Solution:+
> I recall that Prism's JS needs to run on every single DOM element, that
> requires syntax highlighting. However, this does not mean, that we need to
> load the underlying resources more than once per page render. Hope is, that
> we can trigger the Prism JS code to be executed client side on all DOM
> elements that require it, while only requesting the resources once per page
> rendering.
> +Actual Solution:+
> We ended up doing the syntax highlighting now server-side using the GraalJs
> Engine. The Engine requires ~3s to get instantiated (once per application
> launch). Each DOM element of type '<code>' will then be processed taking
> around 100ms. This is not great from a performance perspective, but I'm happy
> with the approach, as AsciiDoc and Markdown source to HTML conversion is also
> done server-side. And it allowed for removal of quirky code in the Wicket
> Viewer.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
