探討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有什麼好的想法請留言