【前端】“局部页面跳转”的作用与缺陷

这篇文章也可以在我的博客中阅读。

关于本文

• 本文讨论局部页面跳转，而非单纯局部加载
• 我的建议是：千万不要在可拓展站点中使用“局部页面跳转”

局部页面跳转

为了提高页面跳转时加载速度，pjax、turbo drive(turbolink)等js库实现了前端基于ajax与pushState的局部跳转功能。

它们通过发出ajax请求，获取指定的html文档，并将其有用部分“移花接木”至当前页面；并使用pushState修改导航历史与url。
这样有以下两个好处：

1. 可以复用原页面有用的资源，减少网络请求，提升加载速度
2. 用户不会感知到局部跳转与全局刷新跳转的区别

局部跳转有好处？

好处是有，但比较有限。

减少环回？

如前所述，这个做法是为了提高跳转速度。
网页加载速度的最大瓶颈在于：向服务器获取资源。
局部跳转因为利用了原页面已有资源，因此可以减少向服务器发起重复请求，从而提升加载速度。

但是涅！目前的主流浏览器都是有缓存机制的（除非你的用户故意点了控制台中的Disable Cache搞你心态）。也就是：虽然全局跳转会再次加载资源，但是在发起请求前，会先试图在本地查找已有的缓存文件。即同样不会向服务器发起重复请求，而且缓存命中仅需花费数毫秒。

减少执行时间？

局部跳转随之带来的，还有节省了脚本重新执行的时间。但相比于网络连接时间，省去执行脚本的几毫秒真的算不上什么新引人的特点。（它甚至引发了下文所说的“缺陷”）

总结

局部跳转并没有为你带来多大好处，但如果它也没有给你副作用，不妨一试。

局部跳转的缺陷

什么问题？

局部跳转根本就不算是跳转，而是利用ajax请求与pushstate技术模拟而来的结果。

最大的问题在于：

• 它们不会再次触发页面生命周期函数（如window.onload, $(document).ready()）
• js中缓存的HTML标签变量在页面内容替换后无效

为什么？

因为页面没有实际上刷新挑战。文档在第一次完成加载后，这些函数就已被触发；在随后的局部载入时，只做了内容替换，而没有真的跳转。因此没有生命周期函数，也没有清空/更新js中旧的HTML变量

但它们本也可以利用一些技巧主动模拟这些操作，但没有一个局部跳转脚本这么做，因为：

• 浏览器没有提供最直接的方法，需要用一些奇技淫巧再次触发这些效果
• 别忘了，有些脚本是继承于第一次加载的，它们不应被再次初始化，但没有办法在代码层面上区分新/旧脚本

换言之，无论是重新触发，还是不再触发，其实都并不完美。而且重新触发还需要做额外功夫，所以没人愿意做这种吃力不讨好的事。

怎么办？

自己的js脚本

局部跳转库一般都自带自己的生命周期函数。对于自己写的脚本，应该避免使用默认的生命周期函数，而使用它们提供的回调。

不要在js中用变量缓存html元素

第三方库

我们无法修改第三方库的代码，但对于用到的库，可以：

1. 先祈祷它不要出错😅
2. 在出错时根据报错进行专门化的修复（具体问题具体分析）
3. 找找相关平台，查找是否有前人经历并解决过类似问题。比如turbolink提供了一些脚本兼容性修复参考

等等！那可拓展性呢？

哈哈，这就是我想说的。如果你的站点需要支持用户自定义插件（即难免引入未知的第三方js脚本。说的就是你，WordPress），你就无法进行针对性的处理；而且也不存在一个通用性的解决办法。

所以，你无法阻止这些错误。你唯一的选择就是，关闭局部加载，让浏览器照常刷新。因为所有js脚本的开发都是针对浏览器一般环境的，因此这些脚本都会按预期的行为执行，也就不会出现问题。

总结

• 这是一个花里胡哨的东西
• 如果它没有给你带来副作用，不妨一试
• 千万不要在可拓展站点中使用局部页面跳转