探討webapp的SEO難題（上）

前言

網絡蜘蛛無法解析javascript，至少百度是不能的，神馬搜索差的更遠，而我們的webapp的渲染展示完全由javascript驅動

所以蜘蛛訪問webapp頁面會得到一個白頁面，比如，我們期待SEO看到的是這個樣子的網頁

其實他看到的是這個樣子的代碼：

那么這個問題應該如何處理呢？比較早的處理方案是提供兩套代碼，一套用於webapp一套用於SEO，比如：

webapp/blade/demo/debug.html是用於webapp的

而html5/blade/demo/debug.html就是用於SEO訪問的

這樣做確實是解決了SEO的問題，業務團隊卻需要寫兩套代碼，這個情況是開發也不是不可接受的，舉個例子來說

webapp一般是純粹的前端開發，而且邏輯會相對復雜，而seo開發一定是會服務器端語言的

也就是說要完成此等開發需要預期1.3-1.5倍的工作量（SEO頁面往往比較簡單只做純粹展示），而開發需要掌握前后端，而這個后端可能是php，java,.net

這個樣子除了有點耗費人力之外沒有什么問題，因為從重構角度來說，不相關的模塊就是應該分離，顯然這里的webapp與seo就是兩個東西

這里是典型的業務關聯，而非功能關聯，寫在一起總會遇到適配問題，但抱着一套代碼解決兩個問題的信念，我們今天來探索如何使用一套代碼完成webapp與seo兩個功能

PS：此文只是個人粗淺的理解，若是有誤請您指正

.net解決思路

這里要webapp與SEO使用同一套代碼完成不同的渲染的話，其實基本前提是必須的：

① 數據為先，而且是所有需要的數據必須事先定義，是否允許異步我們不予理睬，但是必須是實現准備好數據接口定義！

由於數據接口事先定義好了，webapp的數據請求就有兩種方式，同步、異步

② 數據可以與html一起返回，寫入到頁面，不然就是先吐出html，然后前端解析后Ajax請求數據，渲染模板

這里處理的一個重點大家都發現了，他就是 首屏渲染！所謂SEO其實就是要做到首屏渲染

PS：這里可能會發生數據交錯依賴的需求，我們這里暫時不予理睬

而對於SEO，瀏覽器訪問后需要直接返回完好無損的HTML，這里便必須同步處理，所以我們首屏的webapp的數據也采用一並返回的方法

這里服務器只會提供統一的restful接口，webapp使用underscore渲染頁面，需要產生相同的數據就需要一個前提：

服務器需要解析前端webapp underscore模板的能力！這里便提供了初步的方案，簡單模擬如下index.html：

<script type="text/blade_config">
  {
    url: 'restful/index',
    template: 'indexTmpt'
  }
</script>

<script id="indexTmpt" type="text/blade_template">
  <ul>
    <% for(var i = 0, len = data.length; i < len; i++) { %>
      <li><%=data[i].name %></li>
    <% } %>
  </ul>
</script>

//模擬數據返回
data = [
  {id: 0, name: 'item_0'},
  {id: 1, name: 'item_1'},
  {id: 2, name: 'item_2'}
]

這里期待的webapp處理邏輯：

① 服務器解析config中的data，請求url后封裝為數據

② 服務器處理模板與data，生成html，返回返回

當然這里可以將data返回頁面由前端渲染，但是這樣意義不大，不然直接渲染算了

期待的seo處理邏輯：

① 解析config，請求url生成data

② 根據前端模板，生成最終html

其實SEO的邏輯與前端一致了，沒有什么不同，只不過生成靜態html后的處理邏輯差距便大了

為什么不直接服務器吐出完整html？

到這里其實很多朋友就會開始質疑了，既然如此，我們何必要定義config中的url，或者template，這里直接使用服務器端渲染給給前端不好么？

這里還省了很多看似莫名其妙的配置，其實這樣做還是有道理的

本來SEO需要會服務器端語言的，而一旦我們給出config中的約定與模板后，事實上整個便與服務器端沒有任何聯系了

雖說他與服務器端吐出差距不大，但是我業務開發人員事實上只需要掌握前端技能，這個設計的原因便是如此

整個程序對前端來說依舊只需要restful與模板，我可以單個前端同時完成webapp與seo，這就是其意義所在

這個方案的代價是：

① blade中的靜態html需要變成動態腳本，這樣服務器才能解析內容（比如index.html->index.aspx）

② 之前形成的編寫方式需要改變，這里只是需要onShow、onHide事件點

③ 需要按套路出牌，必須定義url與template等東西

凡是有優點就有缺點，這樣做的優點是：

① 一套代碼解決webapp seo難題

② 可以使用.net解析模板，整個服務器來說比較穩定

缺點是：

① 對前端規范約束太多，碰到復雜業務邏輯會比較頭疼，比如模板嵌套，數據依賴，這里的配置就麻煩了

② 不太“webapp”，誠然，此種做法不太webapp

③ 脆弱，問題同樣來源於模板，一次模板語法解析錯誤，會造成服務器端拋錯，整個程序便死掉了

這個問題的提出其實有點吹毛求疵，因為模板就前端解析也會經常出錯，但是這里的不同點是前端稍微好調試點，如果拋給服務器端的話其調試成本會增加

.net解析javascript

扯了這么多，小釵這里為了證明自己原來是搞.net的這里做一個簡單實現，這里便出現了第一個難點：

因為我們模板是underscore的語法（模板暫時不考慮嵌套），那么.net如何解析javascript代碼呢？？

.net解析javascript需要引入第三方庫，借助一些javascript引擎，就如node之於V8；.net的話我們這里暫時使用IronJS做處理

https://github.com/fholm/IronJS

這里小釵不得不汗顏，一件事情，就是C#已經變成這個樣子了，我卻根本不知道......

PS：尼瑪這個狗東西，我看得懂個毛線啊！！！所以本着不丟臉的原則，我們這里省略一萬字

我們這里直接提供一個思路即可，因為該方案不是今日的重點，我的重心依舊是放在nodeJS上的，這里的思路是：

① 解析頁面的config信息，取出url以及template

② 根據url發出請求返回數據，這里由於是局域網應該很快

③ 解析template，根據data生成靜態html

④ 其它處理，返回客戶端

模擬處理邏輯

我們這里略去url請求一步，假設數據已經返回，否則這里又要寫.net程序

var data = [
  {id: 0, name: 'item_0'},
  {id: 1, name: 'item_1'},
  {id: 2, name: 'item_2'}
];

這里的模板字符串為：

var template = [
  '<ul>',
    '<% for(var i = 0, len = data.length; i < len; i++) { %>',
      '<li><%=data[i].name %></li>',
    '<% } %>',
  '</ul>'
].join('');

然后我們要做的就是解析這個模板，生成對應的模板解析函數，這里是調試代碼：

var data = [
  { id: 0, name: 'item_0' },
  { id: 1, name: 'item_1' },
  { id: 2, name: 'item_2' }
];

var template = [
  '<ul>',
    '<% for(var i = 0, len = data.length; i < len; i++) { %>',
      '<li><%=data[i].name %></li>',
    '<% } %>',
  '</ul>'
].join('');

var templateHandler = function (text, data) {

  var noMatch = /(.)^/;

  var escapes = {
    "'": "'",
    '\\': '\\',
    '\r': 'r',
    '\n': 'n',
    '\t': 't',
    '\u2028': 'u2028',
    '\u2029': 'u2029'
  };

  var escaper = /\\|'|\r|\n|\t|\u2028|\u2029/g;

  var templateSettings = {
    evaluate: /<%([\s\S]+?)%>/g,
    interpolate: /<%=([\s\S]+?)%>/g,
    escape: /<%-([\s\S]+?)%>/g
  };

  var render;
  settings = templateSettings;
  var matcher = new RegExp([
      (settings.escape || noMatch).source,
      (settings.interpolate || noMatch).source,
      (settings.evaluate || noMatch).source
    ].join('|') + '|$', 'g');

  var index = 0;
  var source = "__p+='";
  text.replace(matcher, function (match, escape, interpolate, evaluate, offset) {
    source += text.slice(index, offset)
        .replace(escaper, function (match) { return '\\' + escapes[match]; });

    if (escape) {
      source += "'+\n((__t=(" + escape + "))==null?'':escape(__t))+\n'";
    }
    if (interpolate) {
      source += "'+\n((__t=(" + interpolate + "))==null?'':__t)+\n'";
    }
    if (evaluate) {
      source += "';\n" + evaluate + "\n__p+='";
    }
    index = offset + match.length;
    return match;
  });
  source += "';\n";

  if (!settings.variable) source = 'with(obj||{}){\n' + source + '}\n';

  source = "var __t,__p='',__j=Array.prototype.join," +
      "print=function(){__p+=__j.call(arguments,'');};\n" +
      source + "return __p;\n";

  return source;

  try {
    render = new Function(settings.variable || 'obj', source);
  } catch (e) {
    e.source = source;
    throw e;
  }

  

  if (data) return render(data);
  var template = function (data) {
    return render.call(this, data);
  };

  template.source = 'function(' + (settings.variable || 'obj') + '){\n' + source + '}';

  return template;
}

templateHandler(template, data)

首次調試爆了很多錯誤，而且服務器端的調試比較費力，錯了只能靠經驗去猜測

這里返回的是需要構造成函數的字符串，但是我們看到我們的“ul”等標簽被吃掉了！！！

var __t,__p='',__j=Array.prototype.join,print=function(){__p+=__j.call(arguments,'');};
with(obj||{}){
__p+='';
 for(var i = 0, len = data.length; i < len; i++) { 
__p+=''+
((__t=(data[i].name ))==null?'':__t)+
'';
 } 
__p+='';
}
return __p;

我們這里一旦調用就拋了一個錯誤，這個時候一般是模板或者傳入數據出錯了，可惜的是他是對其中一段語法不可解析！這里從側面反映出一個問題：

該方法若是模板出錯會導致程序無法運行，如果是node的話很可能就crash了！

PS:這里由於CLR4解析javascript的時候字符串的replace遇到正則時有問題，在此逗留3小時，這里把我搞慘了，定位就很久最后還得重寫模板解析！！！

var data = [
  { id: 0, name: 'item_0' },
  { id: 1, name: 'item_1' },
  { id: 2, name: 'item_2' }
];

var template = [
  '<ul>',
    '<% for(var i = 0, len = data.length; i < len; i++) { %>',
      '<li><%=data[i].name %></li>',
    '<% } %>',
  '</ul>'
].join('');

var templateHandler = function (text, data) {

  var noMatch = /(.)^/;

  var escapes = {
    "'": "'",
    '\\': '\\',
    '\r': 'r',
    '\n': 'n',
    '\t': 't',
    '\u2028': 'u2028',
    '\u2029': 'u2029'
  };

  var escaper = /\\|'|\r|\n|\t|\u2028|\u2029/g;

  var templateSettings = {
    evaluate: /<%([\s\S]+?)%>/g,
    interpolate: /<%=([\s\S]+?)%>/g
  };

  var render;
  var settings = templateSettings;

  var matcher = new RegExp([
      (settings.interpolate || noMatch).source,
      (settings.evaluate || noMatch).source
    ].join('|') + '|$', 'g');

  var index = 0;
  var source = "__p+='";
  var _text = text;

  var _treg;

  while (1) {

    var matcher = new RegExp([
      (settings.interpolate || noMatch).source,
      (settings.evaluate || noMatch).source
    ].join('|') + '|$', 'g');

    (function () {
      _treg = matcher.exec(_text)
    })();

    var t_str = _treg[0];
    var t_len = t_str.length;
    var t_index = _treg.index;

    source += _text.slice(index, t_index).replace(escaper, function (match) { return '\\' + escapes[match]; });
    _text = _text.slice(t_index + t_len);

    if (_treg[2]) {
      source += "';\n" + _treg[2] + "\n__p+='";
    }
    if (_treg[1]) {
      source += "'+\n" + _treg[1] + "\n'";
    }
    if (_text.length == 0) break;

  }
  source += "';\n";

  if (!settings.variable) source = 'with(obj||{}){\n' + source + '}\n';

  source = "var __t,__p='',__j=Array.prototype.join," +
      "print=function(){__p+=__j.call(arguments,'');};\n" +
      source + "return __p;\n";

  try {
    render = new Function(settings.variable || 'obj', source);
  } catch (e) {
    e.source = source;
    throw e;
  }

  //return source;

  if (data) return render(data);
  var template = function (data) {
    return render.call(this, data);
  };

  template.source = 'function(' + (settings.variable || 'obj') + '){\n' + source + '}';

  return template;
}

templateHandler(template, { data: data })

我這里使用生命在調試啊！！！因為服務器解析javascript時候，很多東西都不支持，感覺有點回到了c++！！！

小結

這里字符串解析成功，我們這部分也就告一段落了，本身.net方案也不是這次的重點，這里提供基本思路各位自己去看看吧，總之調試很坑

下期預告

對javascript來說，nodeJS自然是親爹，我們這次的主要方案其實是基於nodeJS的，這里的期望：

① 用戶請求過來時候首先判斷是否為網絡爬蟲

② 網絡爬蟲訪問seo/index.html，用戶訪問webapp/index.html

當然，我們做demo時候不會這么麻煩，我們直接為其添加一個seo=true的標志位在url即可

nodeJS實現SEO的方案重點依舊在首屏渲染，我們這里首先基於blade做兩個頁面，然后以此擴展seo的方案

當然此塊內容有點小復雜，加之，小釵對nodeJS停留在學習階段，這塊需要學習，而且最近有些其它事情擾心，暫時便擱置了

這塊的內容可能與RapidJS（clouda前身）有關，有興趣的同學可以先去看看

文中有誤請您指出，若您對webapp的seo有什么好的想法請留言