-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hexo g的效率问题 #13
Comments
还有一个html首尾注释时间戳的问题,发布后会导致所有页面缓存失效。 |
一个比较土的解决方法:将_config.yml中的neat_enable设为false,然后将其复制一份(例如neat.yml),在neat.yml中将neat_enable设为true。 这样在平时 缺点是要保持两个配置文件同步,可以用脚本实现。 |
(如果不执行hexo clean的话)好像原版的hexo g是只处理有变化的文件,但是添加插件后好像全部都处理,然后就导致速度慢,有没有办法改善啊? |
我重新分析了下,可以确定两点:
内容不同的无法处理,因为确实是不同,所以就想办法让内容相同的,从多次压缩改成一次压缩,将压缩后的内容存储起来,下次遇见直接调用。所以这里的判断我是分两部分:1.判断当前被压缩的文件是否是模板文件,2.判断压缩的内容是否相同(这里是直接简单的判断了内容的长度),大致的代码如下: var html_map = new Map(); // 全局变量
function logic_html(str, data) {
//...
var path = data.path == null ? "no_path_value.ejs" : data.path;
var exclude = options.exclude;
var tempMap; // 临时变量
var checkFlag = minimatch(path, "**/*.ejs"); // 模板文件
if(checkFlag){ // 模板内容
if(html_map.has(path)){ // 如果存在相同路径
tempMap = new Map(html_map.get(path)); // 取值
if(tempMap.has(str.length)) // 判断是相同的长度
return tempMap.get(str.length); // 直接返回值
} else tempMap = new Map();
}
//...
var log = hexo.log || console.log;
var result = Htmlminifier(str, options);
if(checkFlag){ // 只记录模板文件的内容
tempMap.set(str.length,result); // 存储压缩后的内容
html_map.set(path,tempMap); // 存放到全局变量中
}
var saved = ((str.length - result.length) / str.length * 100).toFixed(2);
log.log('neat the html: %s [ %s saved]', path, saved + '%');
return result;
}; 这里,我只开启了 html 文件的压缩( 修改后,生成用时: 好了,这次才算是完全修改,完结撒花~ |
@inkss 你好,能请教下你,具体是改哪个文件吗? 我的重复压缩模板文件,(大概100+博客)好像耗时半个小时以上了。 |
今天抽空看了下这个问题。先说结论:这里其实是有两个问题:一是重复渲染,二是重复生成。重复渲染是 问题分析记录从名字上来看,本插件注册的 一,旧的检测检测资源是否被修改的方式https://github.com/hexojs/hexo/blob/850ffbcb157c51268b0a4b9c88bd46cca56bbcc2/lib/plugins/console/generate.js#L41 但实情是 二,生成文章与否的判断上面有同学也提到了,假如不实用本插件的话,就没有问题。其实这个话是不严谨的,无论使用与否,都存在问题,只是本插件放大了此问题。(hexo原有体系在渲染时不会输出,所以用户无法感知。本插件在文章比较多时,压缩会比较慢。) 但无论如何,不使用本插件时,hexo不会重新生成文件。 这个结论是正确的,但是为什么会这样呢?继续往下分析 这里要想和保持和hexo的结果一致,就需要保证插件每次渲染后的结果要一致,而显然可能是结果不一致的。经过分析,最终发 至于重复渲染,hexo并未提供相应的接口或者方式能解决此问题,我将尝试自行造轮子解决。 |
没用的,hexo clean 后就全没了,我上面的观点也有不对的地方,主要是 不同页面间有可能传递参数(无法判断同一路径下的相同模板文件是否相同(接收参数的部分) |
除非是改变监听方式,对渲染完成后的完整的 html 文件执行压缩 |
现在就是监听的渲染完成,但问题是hexo本身是无差别渲染的。 |
为了解决这个问题,我又新造了一个轮子 |
大佬,我可以厚颜无耻地提个性能方面的issue吗?
是这样的,在使用hexo-neat进行压缩的时候,我需要花费至少三分钟的时间,如果不压缩的话只要几十秒就可以了。
我看hexo-neat在压缩页面时,分别压缩了html, swig, js, css, md等文件;这些花费了大量的时间,swig和md文件只是模板和初始文件而已,应该没有必要去压缩的吧,能不能改成只对生成后的html静态页面进行压缩呢?
因为我发现一旦使用了
neat_html:
里的exclude
来排除掉md和swig文件,会导致最后的html是没有被压缩的,而且当md文件里使用到了next主题自带的tab标签,还会有语法错误导致压缩失败。。The text was updated successfully, but these errors were encountered: