网页形态的发展

在正式开始之前,先介绍一下网页形态发展的历史,方便大家理解。

远古时期:纯静态

发明 HTML 的目的是方便大家看论文文献,所以早期的 HTML 都是静态的,放在服务器上,直接映射本地文件目录结构。

当然那个时候也没多少网页,很多服务并没有网页版本,比如论坛,是以 Telnet 形式提供服务的;文件共享,大多使用 FTP。

古典时期:动态网站

所谓“动态网站”,就是根据用户请求,返回合适的内容。或者换用技术的说法,接受请求之后,从数据库中读取数据,生成页面,返回给用户。其实现在没什么网站不是动态网站了,感觉这是个上个世纪的词,比如去京东上搜“动态网站”,能搜到一大堆书,大多有着深刻的时代印记,比如《ASP+Dreamweaver动态网站开发》,简直辣眼睛。

文艺复兴:伪静态

相比于纯静态网站而言,动态网站通常需要更长的响应时间,而且 URL 也经常难以阅读。比如:/post.php?id=157,没人知道它是什么意思。这个时期的搜索引擎也比较弱,面对类似的网页,会降低权重。所以网站运营方要想办法改进 SEO,就用服务器 rewrite 的方式,把形似静态页的路径指向动态路径,提升搜索排名。

伪静态常常和真静态共同工作,这个阶段 CDN 还不够普及,所以生成静态页面并部署到终端服务器的操作也很常见。

近代:SPA

随着各项技术的发展,浏览器在整个互联网产品中的地位越来越重要,承担的职责也越来越多,最终单页应用(Single Page Application,简称 SPA)脱颖而出,成为最流行的产品形态。关于它的好处我就不一一叙说了,相信大家都了解。

而接下来,MVVM 框架横空出世,一统江湖,更是大大提升了 SPA 的开发体验,同时大大降低了入门门槛。然后,类似的产品如雨后春笋搬涌现。

现代:SPA + SSR

SEO 的问题在 SPA 这里更明显:对于一些不思进取的搜索引擎爬虫来说,SPA 应用里什么内容都没有。而不思进取,是很多统治级公司、统治级产品的常态。所以没办法,它们不适配我们,我们就得去适配它们。然后,服务器端渲染(Server-Side Rendering,简称 SSR)就显得非常必要。

SPA 的 SSR 和以前的伪静态不同。伪静态时期,业务逻辑都是通过后端完成的,前端主要用来收集数据;SPA 时期,大部分业务逻辑已经移到前端,后端只负责数据校验和必要的存储。此时 SSR 的目的是让用户尽快看到第一波需要的数据,接下来的操作仍然由 SPA 负责。所以我们就面临两种选择:

  1. 前后端共用一套模板,渲染后的页面拥有全部功能,可以继续与用户交互
  2. 部分页面生成纯静态内容,可以部署在服务器上;其它重交互的部分保持 SPA,独立工作

现代分支:在本地写作的纯静态网站

随着云服务发展,现在很多网站都提供基础的静态网站托管服务,比如 GitHub Pages,我们可以使用一些工具在本地完成静态页面的批量创建工作,然后上传到服务器,拥有自己的网站。

本文的工作实际应该算到这个分支。

results matching ""

    No results matching ""