本机服务器网址_本机服务器地点「本机服务器地址是多少」

　　本文由伯乐在线-LaughingJacky翻译，weavewillg校稿。未经答应，克制转载！

　　英文出处：smashingmagazine。欢迎参加翻译组。

　　在StaticGen，我们有一个关于静态站点天生器的开源目次，在这一年多我们追踪了高出一百个天生器。在那段时间里，我们见证着这些项目标数量和盛行度在Github上高涨得不可思议——从只有50个到高出100个，直到有关静态站点的库得到了高出10万的Stars。

　　像Nest和MailChimp如许专注于计划的着名公司，已经将静态站点天生器用于其主网站的开辟。VoxMedia围绕Middleman创建了一整套体系。Carrot，一个大型的纽约中介、Vice帝国的一部分，用它本身的开源天生器Roots给天下的一些大品牌建站。一些Google的产物，像“AYearInSearch”和“WebFundamentals”也是静态的。

　　StaticGen’sGraphofgrowthoverthelastyear.(看大图)

　　静态站点不是新事物，可以追溯到Web伊始之时。为什么会有发作性的关注度？发生了什么？为什么是如今？

　　静态是什么时间产生的

　　第一个网站——TimBerners-Lee的万维网童贞页——就是静态的。当时的站点仅仅由一个文件夹下的一组HTML文档构成，而且HTML文件只包罗18种标签。欣赏器只是简单的文本导航器，它从服务器端抓HTML，终端用户可以由超链接导航。Web根本上是静态的。

　　随着欣赏器和HTML的演进，我们渐渐看到了纯静态站点的限定。

　　早先，网站只是无样式纯文档，但很快便被经心计划，带有图形头和复杂导航。从当时开始，管理本身网页的每个文档失去意义，模版语言进入大众视野。

　　显然，利用HTML作布局、CSS作计划，无法抽象内容（像故事板、产物、零挂件等等）与计划分离的理念。

　　险些同一时间，基于SQL的关系型数据库开始成为主流。对于很多在线公司而言，数据库成为了他们存储内容的圣地，由鉴戒的长胡子数据库管理员看管着。

　　像Dreamweaver和FrontPage一类的桌面应用也有创建内容驱动型网站的办理方案——利用所见即所得的编辑器——页面可以被分离成可重用组件，比方导航、头部、尾部。这些内容很洪流平上也能被存到数据库中。固然它们有很大的缺陷，从某种程度上讲，这就是最原始的静态站点天生器：从模版、部件、媒体库乃至是SQL数据库得到资源创建站点，通过FTP发布静态文件。直到2004年，我才得以在大型内容网站工作一段时间，成千上万的页面在差别的编辑组传播，全都通过Dreamweaver管理。

　　纵然Dreamweaver在某种程度上可以或许与数据库整合，它却不具备内容模子，没有内容与情势分离的概念，无法将内容与情势用符合的工具独立编辑。

　　最主流的办理方案是LAMP栈和像WordPress、Drupal和joomla如许的CMS，这些在推动Web2.0演进有着不可或缺的作用。2.0期间很多网站的关键功能是用户天生内容。用户从点击超链接变成了订购商品、参加社区，以及创建内容。

　　动态题目

　　我15年前第一次创建动态站点时，我依照着MySQL文档的LAMP栈手册。如许创建的站点，每次有访客时都要实行一次这种流程，意识到这些时我简直疯了！

　　Web服务器尽快把我的代码加载到PHP表明器里，然后打开数据库毗连池，来回发送查询语句，利用模版中的数据并将文本字符串拼接到HTML文档中，之后出现给访客。太神奇了！

　　不得不承认，几年之后当我再访问这个网站时就没那么风趣了。整个网页都被黑客的消息更换了，指出了设置中的安全弊端。他很宽弘大量，只是在网站上涂涂画画，而不是把它当作传播恶意软件的媒介。

　　动态网站的布局推动Web前行，但也打开了蠕虫的蜜罐。守旧估计，当下高出70%的WordPress源很轻易受到已知的弊端利用（同时WordPress驱动着高出23%的Web站点）仅仅几个月前，几天时间，一百二十万的Drupal安装源被感染恶意软件一千两百万的Drupal站点必要告急补丁，任安在弊端关照7小时内没打补丁的站点都该思量是不是被注入了恶意软件…不到一周，我从交际媒体到站点的超链接就成了“数据库毗连错误”。规模化动态网站的本钱很高，想要保持站点的活力，动态站点地点的署理不得不百般警备网络攻击。否则的话就得殊死挣扎让网站重新上线（每每发生在非工作时间）。

　　我们为跑在服务器上每个哀求的复杂代码付了高额费用——要是不必这么复杂，就不消再花一分钱了。

　　动态网站和缓存

　　偶然，我们实行用缓存办理题目。没有WPSuperCache这类插件的话，那些着名的WordPress站点不大概跑起来。大型站点无疑要依靠其上层的署理缓存，比如Varnish、Nginx和ApacheTrafficServer。

　　然而缓存的错误是污名昭著的，而且纵然是相称优化的动态站点通常也会比静态的办理方案慢几倍。

　　SmashingMagazine显然是由最关注性能的团队做的，大要上是深层性能优化过的。以是，为这篇文章我做了一个实行。我用HTTrack抓了这个网站的一级拷贝，然后把静态版本摆设到了Netlify上，后者是一个基于内容分发网络（CDN）的静态主机平台。我除了用深度CDN整合把静态版本摆设到主机上之外，没做任何优化。

　　SmashingMagazine比大部分网站都快，但全部哀求是一个数据中心承载的。(查察大图)

　　接着我又跑了几个测试看看第一比特传输时间和主页index.html下载完成所用时间。这是Sucuri’ssuper-usefulperformancetool的结果。

　　哪怕和高度优化的动态网站相比，静态版本均匀要快六倍以上。诚然，不是每个静态主机都有这种差别。但不颠末手动设置，这种基于CDN缓存的动态网站是做不出来的，至少没有相称失常的缓存神器是不可的。

　　同样的HTML，运行在高性能静态主机上(查察大图)

　　缓存，更确切来说是缓存失效，在动态网站上很难做好，尤其是必要充实利用CDN的分发缓存机制。对于一个WordPress站点，无法包管同样的URL会返回同等的HTML，这取决于用户登录状态、查询参数、多次A/B测试等等。跟踪缓存失效的正确时间是个困难的任务：任何批评、全局站点设置、标签、种类或数据库里其他内容的变动都大概影响到列表里相干文章、索引页、归档、批评计数器等等。

　　从这个角度来看，静态网站有天壤之别。他们依照一个非常简单的缓存规则：对于任何访客的URL都返回雷同的HTML，直到对应的URL有了明白的更新。

　　在开辟时依照这些规则会有些束手束脚，但假如网站按照这些规则创建，那么在性能、运行时和花销大将产生巨大变革。

　　当代静态网站天生器

　　比年来，传统动态架构的更换品渐渐出现。静态站点天生器不是什么新玩意。乃至当时WordPress最大的竞争对手MovableType，如今都有切换静态网站天生器的选项。

　　GoogleTrends有关”静态站点天生器”（查察大图）

　　当时开始，静态站点不再因那些限定黯然失色。如今的天生器是饱受前端开辟者喜好的、更当代、更具生命力的发布引擎。

　　每周都有更多的静态站点天生器发布，跟上发展很难。但总的来说，最盛行的静态站点都有如下特点：

　　模版

　　静态站点天生器的根本思绪之一是把网站分别成布局和组件以克制重复。有很多的模版引擎可供选择，它们各有利弊——有些是较无逻辑的、有些将模版和代码混用，但都能让你摆脱重复的头部、尾部和导航。

　　MarkDown支持

　　MarkDown的鼓起很大概是静态站点天生器变得云云盛行的重要缘故起因之一。险些没有人乐意全部内容都用BBCode或纯文原来写，然而MarkDown很轻易上手，用MarkDown编辑器来写作、记条记、发博客貌似快速盛行起来。

　　全部的主流静态天生器都支持Markdown。有的声称支持reStructuredText，或一种可更换的标记格式。大要上讲，都答应内容开辟者在布局化格式中利用纯文本文档。

　　这种方法将内容与计划分离，并保持文件的纯文天性。作为开辟者，我们开始把握神奇的工具套件来应付纯文本。相比于把全部内容作为二进制blob堆砌在数据库中，这是很大的进步。

　　元数据

　　内容每每不会孤立存在。读者总想找到博文的作者、发文日期、文章种类等等。

　　Jekyll推动了静态网站天生器的演进：如今可以由MarkDown模版驱动

　　当Github拥有者TomPrestonWerner编写Jekyll作为博客引擎时，他想到了一个代表元数据（重要用于MarkDown文档和模版）切实风趣的办理方案——开头形貌。

　　开头形貌是少量元数据，重要以yaml格式位于文档最前面：

　　XHTML

　　1

　　2

　　3

　　4

　　5

　　6

　　7

　　title:

　　Titleofthedocumentcategories:

　　CategoryA

　　CategoryB

　　#Actualcontent

　　Thisisthedocument

　　这种标记使包罗元数据的单文件文档注解一览无余，也让那些通常在数据库里存储的不透明格式成为了浅显可读的文本。

　　资源管道

　　如今前端开辟险些总要涉及一些开辟工具和编译器。我们想要资源最小化打包，CSS预处理惩罚器从小众走向主流，Coffee和ES6转译使编译器整合进欣赏器。

　　大部分当代静态站点天生器包罗一个资源进程，处理惩罚资源编译、转换、最小化和打包事件。有一些基于构建工具，比方Grunt、Gulp和Broccoli，你可以牢牢围绕整个生态体系的任务和构建阶段。剩下的更专注于精简此中某个过程，或让某些工具在不颠末复杂设置的条件下运作精良。写入文件及时革新欣赏器也成为了很多天生器的标准。

　　汇总

　　通常静态站点天生器建站时都有下令行UI，大概把网站挂在一个本地服务器上用于开辟。

　　拿Jekyll来说，你用jekyllbuild下令时本地文件夹会天生一个Jekyll项目源文件，在_site子文件夹输出一个静态网站。

　　下面是源文件夹的样子：

　　XHTML

　　1

　　2

　　3

　　4

　　5

　　6

　　7

　　8

　　9

　　10

　　11

　　12

　　13

　　14

　　_posts/

　　2015-03-01-first-post.md

　　2015-03-11-amazing-post.md

　　_layouts/

　　default.html

　　_includes/

　　main-nav.html

　　index.html

　　about.md

　　js/

　　app.coffee

　　css/

　　style.css

　　_config.yml

　　这个文件夹是完备的静态网站，可以传到任何静态主机、跑在任何平凡的Web服务器上。

　　为什么如今

　　假如全部东西听上去很酷，那样它简直很酷。但为什么静态网站技能如今鼓起，而早期的天生器未能给WordPress的统治带来打击？有什么变革？我们可以用多久？

　　如今的天生器和先辈们所处的生态体系完全差别，从前由于很多束缚不得不选择动态网站。如今谁人根本的在线手册已颠末期了，只管有些还能用。

　　欣赏器成熟了

　　当TimBerners-Lee发布第一个www站点时，欣赏器只是简单的文档查察工具，可以表现超链接、超文本。

　　如今，我们在积极安葬扯Web后腿的末了一个欣赏器（IE8安息）。当代欣赏器本身就是一个操纵体系，不但是展示从Web下载的文档，也可以跑成熟的Web应用，对任何的CORS兼容的API发起外部调用，本地化数据存储，向流媒体服务器打开WebSockets，乃至通过WebRTC处理惩罚其他欣赏器的点对点毗连。

　　随着欣赏器的成熟，很多之前必要服务器动态代码环境支持的特性可以完全移到客户端。想要站点批评吗？添加Disquz,Isso或Facebook批评。整合交际功能？把Twitter或Facebook的JS插件加进来。想要你网站有及时数据更新？用Firebase。想要搜刮？加上Swiftype。想要支持在线谈天？Olark就可以。哎呀，你都可以用Snipcart给站点加电商。

　　功能列表越来越多，基于纯欣赏器插件的整个生态体系就形成了。除此之外，用Ember.js、Angular.js或React的当代欣赏器app通常完全作为静态网站摆设，由一个纯API后端的CDN伺服欣赏器UI和移动端。

　　CDN成为主流

　　当Akamai在1999年启动第一个内容分发网络时，只有天下上最大的Web公司负担得起由CDN边沿节点分发web资产的服务。不久前CDN也只是CNN和Facebook规模的公司在用，而不是平凡大众。

　　Akamai仍旧保持企业级报价，而如今任何人都能注册AmazonAWS，把CloudFront放在本身站点前面。而且，小型企业负担得起像Fastly、MaxCDN和CloudFlare的CDN服务报价。

　　你可以在动态网站利用CDN，但缓存失效不停是盘算机范畴的一个棘手题目。至少，有关边沿节点的缓存和专门用来做哀求盘算的后端动态体系之间的均衡，是很棘手的。

　　另一方面，静态站点可以直接摆设到CDN上，从本地缓存伺服附近终端用户。折腾设置花时间，缓存失效很棘手，但也可以用Netlify实现主动化。

　　性能很紧张

　　移动装备的发达在很多方面改变了Web的面貌。越来越多的访客从移动装备进入Web，偶然是3G毗连。性能从未像如今如许云云紧张。

　　我们都知道：57%的互联网用户放弃加载高出三秒的页面。人们已往乐意比及10秒，但如今等待更高。在移动端，不能处理惩罚多任务也做不了什么，等网站加载着实是太烦了。高出4%的人表现，当用着一个慢悠悠的移动网站时，他们简直要摔手机了。

　　无论你怎样优化动态网站的性能，大概在这上面投入财力，它都不如经心开辟一个静态站点那样包管性能，后者挂在一个月几块钱的CDN主机上。随着性能愈发紧张，难怪开辟者探求预天生HTML的方式，而不是让服务器把天生页面的时间和资源花在每个HTTP哀求上。

　　静态网站天生器在开辟过程中也消除了很多性能题目。

　　假如你在建一个数据驱动型动态网站，由于要支持每一个HTTP哀求，数据库查询的服从极其紧张。纵然在你的网站火线有个坚固的缓存层，总要碰到如许的风险，有的哀求会成为缓存克星，触发最坏的后端哀求，引起整个体系的延时停顿。

　　而利用静态天生的网站，把内容放到模版上多几秒少几秒无所谓：只有在你发布时才会出现，从不会给终端用户带来性能题目。

　　构建工具到处都是

　　编译器和构建工具已往是C和Java程序员担心的事，不是你建站时用的。如今也不知是好是坏，环境完全变了。

　　如今，前端开辟者采取了构建工具、包管理器和多种编译器混搭。Grunt是第一个成为趋势的前端构建工具，如今大部分新项目都有构建阶段。

　　随着构建工具的遍及，静态站点天生器融入了前端工具包，而传统动态站点的php衍生工具在当代的前端工具流眼中开始不入流。

　　遗失了什么？

　　全部这些因素连合到一起，创造出了静态站点天生器的潮流。难怪越来越多的站点开始静态搭建。

　　但并不都是功德。在静态站点天生器完全成为主流之前，有些东西必要进步。

　　初次上手静态站点天生器的项目仍旧很繁琐，可用工具、文档、资源上有很多的细节和提拔空间。

　　随着静态站点天生器生态体系的发展，离成熟的主题市场相距甚远，对传统动态平台的支持也不敷。

　　然而，最大的困扰在内容编辑方面。在一个文本编辑器里直接用Markdown然后发到Github上更像是前端开辟者的抱负工作流，并不是你会拉一个平凡、不懂技能的终端用户参加进来的事儿。

　　因此，很多用静态站点天生器搭起来的的网站整合了动态CMS。我们火急必要在在内容编辑器和静态网站天生之间搭个桥。在那之前，天生静态站点用于网站还只能是小众。

　　有一些风趣的”no-CMS“办理方案。Verge为Middleman用googlesheets作为内容层；StaticGen用Gist和GithubAPI作数据库；Carrot用Contentful作静态CMS供非技能职员为它们的静态站点生产内容。

　　其他人在致力于融合静态站点天生和内容编辑的最佳办理方案，接下来几年在内容和发布方面无疑会有新的工作方式。

　　像Contentful、prismic.io和GatherContent一样的体系将CMS层从实际的建站工具解耦，很受多频道内容管理者欢迎。在那边你不是给一个特定的网站写东西，也实用于移动app、Facebook页面或白纸。发布新内容触发构建系同一个Web钩子；然后静态站点天生器从内容API取数据建站，成品直接发到CDN。

　　编辑内容另一种方式是利用下面的库:

　　在静态天生器Prose.io上的MarkDown编辑器，无缝整合GithubAPI

　　prose.io已经有一阵子了，整合GithubAPI，给内容编辑者提供更友爱的UI在Github里编辑MarkDown文件。

　　在Netlify，我们在做一个开源CMS，不限定专门的静态站点天生器、Git主机或伺服平台。目标是实用于如今全部的静态站点天生器，我们以为这会是对当代静态站点技能的一个突破。

　　很显着，总会有网站不太得当静态天生——尤其是那些核心内容连续更新的，大概那些不停在推送消息、高度依靠搜刮和过滤的。

　　那也就是说，静态站点天生器会在本领和盛行度上继承演进，底子架构和生态体系愈发成熟。随着工具的进步，我们会看到开辟者在静态站点技能上的突破。

　　在Netlify，我们已经开始看到大型内容驱动站点。它们带有及时搜刮、多语言支持和私有板块，由静态站点天生器和内容API搭建。静态站点对性能和安全紧张性的意识也越来越强，将来布满等待。

　　1赞收藏批评

　　关于作者：LaughingJacky

　　Null.个人主页·我的文章·1·