目前为了加快网站首屏在手机端的渲染速度，提升用户体验，各国和网速较慢的地区，提高在谷歌测速网站上的分数，同时为了以后的seo需求做准备，需要对网站手机端的各个页面进行优化。网站后台基于php框架开发，手机端使用vue.js作为前端框架。所以首屏渲染方案需要兼顾前后端php和vue，以及交互问题。什么是“straightinstraightout”straightinstraightout其实是指ssr（serversiderender）服务端渲染，服务端渲染静态页面直接返回给客户端，然后客户端激活这些静态页面，使这个页面变得具有交互性并能够影响后续的数据更改响应。方案研究Vue首创的画面优化方案主要包括主流的vuessr(serversiderender)服务端渲染和前后端同构方案。vueSSRvuessr采用服务端渲染，前端获取数据进行激活。这种形式目前适用于前后端分离的项目，需要在服务器上部署前端机器。优点是方便SEO要求，页面加载速度快。缺点是会增加一些服务器开销。前后端同构。前后端同构主要是选择一种前后端都支持的模板语言（如php-v8js、mustache.php）进行同构处理。不同的项目不一样。而且结合现在网站的项目结构，前后端分离的vuessr模式和前后端同构的形式似乎不太适合用于网站项目结构。因此，从这两种模式中总结出最适合网站项目的形式。比较合适。当前网站渲染流程解决方案分析PC端：php处理数据->渲染数据到模板->显示htm到浏览器->加载js等数据->js改变一些数据或样式。m移动端：php处理数据->将数据渲染到模板->将htm显示到浏览器（空白）->加载js和其他数据->vue.js构建并挂载到dom节点。预期网站渲染流程m手机：php处理数据->渲染数据到模板->显示htm到浏览器（首屏数据）->加载js等数据->vue.js构建并挂载到htm（激活）。类似于前后端同构的思路，我们需要一个中间桥接模板来连接php和vue来做首屏渲染方案。理想状态是php直接将不需要大量交互的结构化内容渲染到模板中，然后客户端在模板中。当获取到html后，可以直接显示不需要交互的静态页面内容。此时客户端加载js文件，加载完成后直接激活页面上需要交互的模块和数据。所以采用服务端先渲染，前端二次渲染的模式，简单页面元素的服务端渲染，不需要大量交互的原生Vue组件，前端需要的数据似乎更接近网站现有结构可以支持的内容。计划。当然，以上只是网站项目结构的一些设想。针对不同的网站项目结构，在不重构网站项目的前提下，选择最适合当前网站的方案。基于以上假设，在正式采用该方案之前，似乎应该关注一下vue渲染的生命周期，说不定能找到一些新的突破口。vue的生命周期如下：（vue生命周期详解）可以注意到在created和mounted之间似乎有一个我们要关注的地方：1.在created阶段，如果有模板参数选项在vue实例对象，它会被编译成一个渲染函数作为模板。如果没有模板选项，外部HTML将被编译为模板。可以看出，模板中模板的优先级高于外部HTML。这意味着我们在编译vue时似乎可以使用外部html进行渲染，这与我们之前的想法不谋而合。我们可以在php中第一次渲染，然后返回html给客户端进行第二次渲染。2、在beforeMounted阶段，可以看到此时vue实例对象中添加了$el成员，并替换了挂起的DOM元素。因为之前控制台打印的结果可以看到el上的beforeMount还是undefined。这好像是说，在js正式加载之前，我们可以在空白页面做点什么，让首屏页面不至于空白。反正js加载的时候，el会挂载到根节点上，貌似是可以的。体验得到了改善。方案的可行性经过上面对vue生命周期的分析，对于网站结构得出了两个看似可行的方案，分别是混合渲染方案（php渲染第一次渲染，vue第二次渲染），第一种屏幕替换方案（首屏直接通过html显示，由vue.js加载，直接替换）混合渲染方案，在前端渲染中加入编译器。这里需要注意运行时和编译器（compiler）的区别和应用，使用前端编译，即webpack打包时不再生成模板，而是在前端重新编译渲染根据后端渲染的模板结束。这样一来，js文件的大小会比只使用runtime的版本大30%左右。这种方法有优点也有缺点。优点是可以加快首屏渲染，减少白屏，方便手机网站的SEO需求，提升用户体验，特别适合网速慢的用户；缺点是有些组件模板的js代码会被分离出来，代码的可读性会降低，可能会增加js体积。因此，本方案的组件或模块需要反复考虑，慎重选择。对于一些不涉及重要或复杂逻辑的页面，您可以选择使用此方案。一些注意事项vue在模板化的时候对dom中的htm比较敏感，所以写的会严格一点，比如v-if等vue语法，都需要用
