content-visibility 就是解决这个问题的，没有这个特性，html必须计算高度，只能全部计算渲染完毕了。
你把页面保存成html，用浏览器打开应该也是一样的。
脚本执行最占用时间的是牛津9的OL版，从审查元素那里看是 oald9.js里第388行很占时间：
var __OALD9_appHeight = document.body.clientHeight;
词典应该只要计算自己词典的高度就可以了，像这种js，计算的应该是所有词典加载后的页面高度。
所以会慢。
1 个赞
所以这个 content-visibility 是不是最好还是先保留着，先不要删这两行了？ 
content-visibility: auto;
contain-intrinsic-height: auto 600px;
下面这个contain-intrinsic-height是干嘛的？只删这一行可以吗？只保留content-visibility这个特性
contain-intrinsic-height: auto 600px;
节省渲染时间的。如果用户不看的话，不渲染。
这个是还没渲染的时候，占位用的，比如一个词典实际高度800px，还没渲染之前，按600px计算整体的高度。 如果后续翻到了这个词典， 这个词典的高度后续就按照800px使用。
1 个赞
好的。我先不删除这两句，再对比试试看哪个效果好
可以，启用这两行css的一个后果就是， 滚动条的高度可能会一直变动。
滚动条高度一直变动的问题，第二行改小点会好一些吗？比如改成0px 或者10px
contain-intrinsic-height: auto 0px;
content-visibility的实现机制就这样，除非已知词典内容的高度，不然怎么改都有问题。
1 个赞
还有些类似双解切换的词典，会在脚本加载完后切换内容，导致整个网页重新计算高度，单本词典看不出来，加载的词典多了，这个过程就异常耗时。
如果是从文本PDF生成的MDX，可能每个字符都有单独的样式控制位置，这种也是渲染引擎的杀手。
1 个赞
重新加上那两行css，又试了下，目前非常流畅了 
看来之前的js耗时影响挺大的…
终于找到症结了，原来是在词典中加载“识典古籍”的网页造成的，将其停用就没有这个问题了，加载其他网页和在线词典都是正常的。但在老版本中却不会出现这一情况，大家使用goldendic的在线网页时注意一下这个网站。
1 个赞
问下是不是每次查词的时候，goldendict都会在线下载一些js文件，比如下面的hm.js, piwik.js这些，不知道这些js文件有什么作用。
性能测试的时候，发现这个hm.js执行耗时达4.8秒，很好奇这个是做什么的 
ps：下面源码是通过查询结果“保存文章”后得到的
统计跟踪你的使用行为用，通常是网站用来统计流量的。看到hm.baidu.com www.google-analytics.com引用的资源都可以直接删除，都是统计跟踪你的使用行为，删除不会影响词典的。如果觉得删除后有JS错误，找到相关JS代码并删除就可以，没必要把信息发到服务器。
关键这个hm.js 不是任何一个词库引入的，所以用户应该不好控制吧
更新：
piwik.js 好像green slang 词库使用了
green slang的bundle.js 耗时24秒… 太夸张了
更新2:
hm.js 是海词词典引入的…
1 个赞
应该是词典引入的
选项里面禁用广告看下
上面的jquery是gd引入的
1 个赞
原来如此，还没找到hm.js是哪个词库引入的
主要hm.js在源码的最前面，还以为是goldendict引入的
我再找找看看
1 个赞
