页面静态化方案 第1篇
不在一个项目中传输数据麻烦,也起不到提高效率的作用，而且修改数据时也要修改静态页面
WEB服务器的 URL Rewrite的方式
URL Rewrite方式特点同样鲜明，由于是服务器内部解析的地址，所以内容是实时更新的，也不存在文件管理和硬件问题，维护比较方便。在服务器级URL Rewrite重写技术并不影响页面的执行速度。但是URL Rewrite的门槛比较高，国内虚拟主机大多不支持，而且虚拟主机是目录级的URL Rewrite,通过遍历目录读物URL转发规则的方式将大大降低页面的执行速度。
将页面分成子数据块
把页面划分成子数据块，每个数据块可能是一个inc文件，也可能多个数据块包含在一个inc文件中。具体的数据块划分根据页面的业务结构来处理。比如：网站头尾等公共数据块可以独立成一个文件。
对于一个大型网站来说，生成的页面数据会非常多，管理这些页面文件又是一个问题。例如有的页面被删除了，而已经生成的页面数据还会存在各个web服务器上。这时就需要通过后台系统记录这些页面文件的部署位置，以便今后统一管理。同时业务组件的量也可能会比较多，特别是存在多版本的情况下，所以也需要把业务组件的配置情况记录到数据库中，便于统一管理。
在web开发里，除了需要浏览器处理的，其他技术都可以当做服务端来理解，如果我们网站使用到了CDN，使用到了静态web服务器例如apache，以及服务端的web容器例如jboss，那么按请求的行进路径，我们结果处理越早那么网站响应效率也就越高，所以当请求在CDN返回了，那么肯定比在apache返回效率高，在apache就返回了肯定比jboss返回的效率高，再则服务端的web容器本身因为服务端程序运行要消耗部分系统资源，所以它在处理请求的效率会比CDN和apache差很多，所以当我们按照动静分离策略拆分出了静态资源后，这个资源能不放在最底层的服务端的web容器处理就不要放在服务端的web容器里处理。
页面静态化方案 第2篇
静态化就是指把原本的动态生成的 html 页面变成静态内容保存起来，当用户客户端请求的时候，直接返回静态页面，不用再经过服务渲染，不用查询数据库，可以大大减少服务器和数据库压力，显著提升网站性能。
静态页面，即静态网页，是实际存在的，无需经过服务器的编译，直接加载到客户浏览器上显示出来。静态页面需要占一定的服务器空间，且不能自主管理发布更新的页面，如果想更新网页内容，要通过FTP软件把文件DOWN下来用网页制作软件修改（通过fso等技术例外）。常见的静态页面举例：.html扩展名的、.htm扩展名的。
动态页面是通过执行asp,php,jsp,.net等程序生成客户端网页代码的网页。 动态页面通常可以通过网站后台管理系统对网站的内容进行更新管理。发布新闻，发布公司产品，交流互动，博客，网上调查等，这都是动态 网站的一些功能。也是我们常见的。 动态页面常见的扩展名有：.asp .php .jsp . 等。 注意：动态页面的“动态”是网站与客户端用户互动的意思，而非网页上有动画的就是动态页面。
优点：
缺点：
页面静态化方案 第3篇
如果前端开发只有 react 组件（没有 redux、route 等）且对性能也没有太高要求（无需分片、无需压缩、无需样式分离），实现服务端渲染是非常简单的，相关的介绍文档也多如繁星，基本都是围绕 react 提供的2个支持输出HTML字符串的渲染方法来说的—— (element) 和 (element) 。为了实现前段不重复渲染，本项目使用后者生成HTML。
同步的关键是 checksum。服务端渲染返回HTML字符串后，会有一个 checksum 属性标记在根元素上，它是服务端生成HTML的指纹（hash计算）。到客户端进行 首屏渲染 时，会对这个 checksum 进行校验，如果校验一致仅仅生成虚拟DOM而不会发生真实的DOM渲染。 checksum如何确保不会重复渲染的原理可以看这里——React前后端同构防止重复渲染。
我们先从一个简单的模型开始——1_simple_server_render（以下简称 示例1 ）。示例1 仅用 react 组件实现了一个非常简单网站，他提供了三种启动方式：
示例1 的文件结构：
//浏览器端入口 //应用入口 //开发nodejs服务 //生产打包，用于生产nodejs服务 //koa服务器启动代码 //服务端入口 --webpack //webpack相关的配置文件 //生产服务器打包 //开发服务器运行 //使用webpack-dev运行React --dist //打包后生成的文件
请各位留意这个文件结构，在后面实现各种功能的时候这个结构很有大意义。
首先，客户端展示分成了 和 两个文件。在 中实现了所有的页面效果，而 仅仅是使用 ( element, container, callback ) 方法渲染App组件：
其实完全可以将2个文件合并成一个文件，先留着这个问题继续往下看。
其次，服务端渲染关联了4个文件， 、 、 middleware 、 。他们的关系是： 提供了 koa 服务的基础功能（ koa 是 express 团队设计的新框架，没用过的可以理解 koa 就是一系列中间件，一个请求发送到服务器由这些中间件一个接一个的处理。 需要了解请看：）， 一开始就require了 获取 koa 服务的实例，然后向 koa 实例中增加了 和其他中间件。
中使用 (element) 对App组件进行渲染生成HTML结构的字符串，然后调用通过模板生成页面：
在上面的过程， 在服务端和客户端渲染都使用到了，所以这一块是可以前后端同构的。而 和 分别负责将app在浏览器和服务端渲染出来，他们分别是浏览器端的入口和服务端的入口。
最后还剩下一个 ，仔细观察会发现他的结构其实和 是一模一样的——都是先获取一个koa实例，然后添加中间件，只是去除了许多开发用的工具：
是用来打包生产服务器的，打包完成后可以直接使用node启动。webpack文件夹里就包含了打包用的webpack配置。
在工程根目录运行以下脚本 ：
分别运行上面的脚本后，在浏览器输入 http:// localhost:8080 均看到相同的页面，但是打开开发人员工具，可以看到许多有意思的东西。例如查看首屏传输的数据，服务端渲染的首屏已经包含了完成HTML文档以及用React用于校验文本一致性的 checksum ，而运行 $ npm run 1-static 的 webpack-dev 启动时什么都没有。
服务端渲染，从服务器传递而来的HTML中#root中已经包含了DOM：
webpack-dev 启动，仅引入js文件，需要等 react 开始运行后，才会向#id元素中添加DOM：
至此，我们已经实现了非常简单的单页面应用服务端渲染。但是距离投入生产远远不够。我们的 .css 文件还没有分离；服务器只实现了渲染简单的dom，更多的情况是我们需要在服务端使用异步请求组装数据；单页面应用一次性加载资源过大怎么处理？我们需要将资源文件分离，并且按页面加载；我们还没有整合react-route 和 redux 。如果你还有兴趣请接着往下看。
页面静态化方案 第4篇
使用freemarker实现生成静态页面，将页面的实际存在于服务器的硬盘中，然后通过nginx反向代理服务器访问资源；
将动态页面转化为实际存在的静态页面这种方法，由于静态页面的存在，少了动态解析过程，所以提高了页面的访问速度和稳定性，使得优化效果非常明显。所以这种方法被广泛采用。但是它的局限性同样存在。对于大型网站而言，这种方法将带来不可忽视的问题。
一、由于生成的文件数量较多，存储需要考虑文件、文件夹的数量问题和磁盘空间容量的问题；
二、页面维护的复杂性和大工作量，及带来的页面维护及时性问题，需要一整套站点更新制度。
虽然静态页访问速度快，但实现起来毕竟还是比较麻烦了，维护也是一个麻烦事情。如果您的站点更新速度快那么就需要在你的后台数据更新部分调用相应的createHTML方法实时的生成静态页面。如果更新速度不慢可以在后台手动更新或者利用操作系统的定时任务功能去执行你的静态页面生成程序。
页面静态化方案 第5篇
Vue SSR的基本概念：
实现步骤：
import { createApp } from './app';
export default context => {
return new Promise((resolve, reject) => {
const { app, router } = createApp();
();
(() => {
const matchedComponents = ();
if (!) {
return reject({ code: 404 });
}
resolve(app);
}, reject);
});
页面静态化方案 第6篇
为了能将我们开发的工程投入实际生产应用，需要引入 react-route 来为单页面应用提供路由功能、引入redux 统一管理数据、将样式抽取到独立 .css 文件、在服务端异步组织数据。2_route_redux_render在前面所介绍的示例1 的基础上实现了所有这些特性。
2_route_redux_render（以下简称 示例2 ）是一个非常简单的搜索网站，会针对 的内容进行搜索。示例2 只有2个页面，一个搜索首页、一个搜索的结果列表页，这样布局仅仅为了便于说明问题。示例2 在示例1 的基础上增加了以下内容：
运行 $ npm run 2-static 启动 webpack-dev 后在浏览器输入 http://localhost:8080/ 可以看到下图这样的静态页面的效果：
在搜索框输入要搜索的内容按回车会跳转到搜索的结果列表页。
首页提供了3个下拉菜单，前两项用于搜索而最后一个下拉菜单可以选择 前端跳转 还是通过 服务器跳转。
现在我们停掉刚启动的 webpack-dev ，使用开发服务器启动。运行以下内容：
启动成功后（输出类似“webpack built in 4760ms”的内容）我们就可以分别尝试在浏览器端通过异步请求组装页面，以及在服务器端组装页面并以静态HTML页面的方式发送到浏览器。
在首页（localhost:8080）最右边的下拉菜单选择“前端”然后进行搜索，会发现 nodejs 服务器没有接收到任何请求，而浏览器会出现一个加载效果，等待十几秒之后完成数据组装。如果选择“服务器”，搜索时会发现 nodejs 服务器输出很多内容，等待十几秒后浏览器直接出现了结果页面而没有任何加载效果。
你也可以将代码打成生产包进行测试：
浏览器渲染和服务端渲染最大的区别可以看HTML的源码。没有服务端渲染的浏览器HTML结构是这样的：
没有任何内容，只有要运行的 .js 文件，等待 react 向#root中添加DOM。
而通过服务器去渲染HTML源码是这样的：
HTML源码已经有了实质内容。下面那一堆BASE64编码是首页的图片，已经通过后台加载好了。
各位童鞋可以通过各种方式运行DEMO来验证效果。
如何实现？
首先，和示例1一样，将浏览器端渲染和服务端渲染分为2个入口。
依然是仅仅使用 React 实现的页面组件， 是用于浏览器端渲染的入口，而 middleware/ 是服务端渲染的入口。与 示例1 相比 引入了 和 组件，他们分别用于 react-redux 和 react-router ：
其次，使用redux组装异步数据。
redux 在这里起到一个很核心的作用是同步前后端的数据。数据会在服务端渲染 react 组件之前就通过action 完成数据的组装，然后在渲染时传入携带数据的store进行渲染。
所以 示例2 将koa的中间件分为2个，一个用于组装redux的数据，一个用于完成渲染。middleware/用于组装 redux 数据：
reduxStore(ctx, next) 方法是 koa 中间件的常规入口，而组装数据的关键是 processStore(resolve, store, url) 方法，执行以下内容：
当访问列表页时，通过以上过程会完成一次 store 的数据更新。然后在 middleware/ 中会将这个更新之后的store直接传入 用于组装组件。同时，store 中的数据也会通过页面模板写到页面上让前端也同时使用他初始化 store 数据。
最后，分离样式。
在转换成 .css 文件之前经过了4步处理：1）sass-loader 转换 sass；2）postcss-loader 生成浏览器兼容样式(生成 -ms- 或 -webkit- 这样的前缀)；3）css-loader 生成命名规则；4）生成 css 样式并统一提取到一个 .css 文件中。如果工程使用其他工具（比如 less 等）需要适当修改这个过程。