在我的 Typo3 扩展中,我使用了一个 <f:for
遍历几个项目。恰好 184 项。
我由此生成了一个 slider 。
问题是这个迭代非常慢。有没有办法让它快起来。后端速度不到一秒。只有前端渲染需要很长时间。
我的完整前端代码如下所示:
<f:if condition="{videos -> f:count()} > 4">
<f:then>
<f:for each="{videos}" as="video" iteration="i">
<f:if condition="{i.isFirst}">
<f:then>
<div class="item active">
</f:then>
<f:else>
<div class="item">
</f:else>
</f:if>
<div class="col-lg-3 thumbnailParent">
<f:link.action controller="FrontendVideo" action="show" arguments="{video : video}">
<f:render partial="Video/ShowThumbnail" arguments="{video : video, userAuthorization : userAuthorization}"/>
</f:link.action>
</div>
<!-- adding slider-class to one of all slides. condition: slide must have more than 4 videos for slide-effect -->
<f:if condition="{i.isLast}">
<f:then>
<script type="text/javascript">
addClassForSliding('{myCarouselID}');
function addClassForSliding(myCarouselID) {
$("#myCarousel"+myCarouselID).addClass("isCarousel");
if(!$("div.videoSlide").find("div").hasClass("thisIsTheOnlySliderWhichSlides")){
$("#myCarousel"+myCarouselID).addClass("thisIsTheOnlySliderWhichSlides");
}
}
</script>
</f:then>
<f:else></f:else>
</f:if>
</div>
</f:for>
</f:then>
<f:else>
<f:for each="{videos}" as="video" iteration="i">
<div class="item active">
<div class="col-lg-3">
<f:link.action controller="FrontendVideo" action="show" arguments="{video : video}">
<f:render partial="Video/ShowThumbnail" arguments="{video : video, userAuthorization : userAuthorization}"/>
</f:link.action>
</div>
</div>
</f:for>
</f:else>
</f:if>
最佳答案
- 确保您的缓存已启用 - 如果未启用,请不要根据未缓存的渲染来判断性能。
- 尽量避免您使用的许多条件。并且绝对不要留下像
<f:else></f:else>
这样的空节点。 . - 将您在上一次迭代中所做的事情移到循环之外(从而节省另一个条件和大量节点构造)。
- 避免
iteration
变量尽可能。它为每次迭代添加了额外的处理和变量分配。 - 我假设您使用 JS 来激活组件。所以用JS设置
active
CSS 类,从而避免 1) 像您一样错误地打开和关闭标签,以及 2) 避免另一个只为真一次的条件,就像另一个条件一样。 - 检查您渲染的部分。它可能无法编译。并且每次渲染它时,都必须解析部分。注意:在这种类型的用例中,部分几乎总是比部分表现更好。我写的一个工具,你可以使用,它也预编译你的模板,如果任何模板不兼容,它可能会失败:https://github.com/NamelessCoder/typo3-cms-fluid-precompiler
- 一般来说:不输出
<script>
在 Fluid 中,除非你有非常充分的理由。尽可能从外部加载脚本并存储脚本需要的任何值,例如data-
特性。更快的解析,更快的循环。 - 使用实际分析工具准确定位瓶颈。您的代码使用 ViewHelpers 并且对配置也很敏感,例如您对路径等的设置越多。在
f:render
中需要完成的处理越多电话。不要在开发环境中分析! - 不要分析 Docker 设置 - 除非您运行的是 Linux。即便如此,也要对结果有所保留:文件系统性能永远不会相等。
避免 iteration
和你的条件,并将最后一个 block 移到循环之外,应该可以减少 80% 的成本(不计算你渲染的部分中发生的事情 - 它的性能可能非常糟糕而且我们永远不会知道,因为你不知道'不要粘贴那个)。
最后,在选择是渲染部分还是部分时,需要考虑几件事。其中大部分完全取决于您的用例(例如:您需要如何构建模板 - 与您不能覆盖的部分相比,您可以覆盖的部分是否更有意义?)但是可以说一些一般性的事情性能:
- 当您呈现存在于同一模板中的部分时,呈现通过单个函数调用进行,以切换到具有一组新模板变量的该部分。
- 但是当您渲染局部时,必须先解析该局部的模板文件,然后才能进行渲染。
- 无法编译已解析的模板,因为必须可以在多个不同的上下文中呈现相同的已编译模板。
- 因此,部分模板的解析可能只在每个上下文中缓存一次,这意味着如果同一个模板在页面上的多个上下文中多次呈现,与使用部分(已编译)相比,性能可能会受到很大影响到一个普通的函数调用)。
- 您拥有的模板路径越多,文件解析就越困难。
您始终需要为任务选择正确的工具 - 这是我们作为开发人员的工作之一 - 所以这些要点非常通用。有些用例在部分和部分之间的性能上根本没有区别,有些用例不会因使用 iteration
而受到明显影响。 ;这完全取决于您的设置要求和您呈现的数据。分析您的模板肯定有助于找到正确的解决方案,因此我强烈建议您这样做。
关于html - typo3 流体 f :for is extreamly slow,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48421433/