WebApp Insight: 链接到“上一篇”和“下一篇”

风行水上 @ 2014-05-30 17:19:44
标签:

    需要给页面添加两个链接到“上一篇”和“下一篇”文章。

    假设当前页面为 /article/123,最直接的写法:

    <a href="/article/122">上一篇</a>
    <a href="/article/124">下一篇</a>
    

    问题是“上一篇”和“下一篇”的ID很可能不能轻易计算出来。如此,则需要后端多一步查询才能得出。

    其实就语义来讲,下面的写法可能更合适:

    <a href="/article/123/prev">上一篇</a>
    <a href="/article/123/next">下一篇</a>
    

    这样一个潜在的语义好处是可以在服务器端动态地计算排序规则。

    可这样则会有新的问题:

    • URL的长相不好看
    • 链接指向的内容有自己的URL标识
    • URL指向的内容可能会发生变化(比如,删除了其指向的内容),因而不利于链接的分享

    解决办法1:重定向

    不管是服务器端重定向,还是客户端重定向,都可以解决问题。

    但显然多了一次对服务器的请求。服务器端增加了负担,用户端增加了延迟。

    解决方法2:history.replaceState

    借助HTML5的history.replaceState方法在客户端替换页面地址。

    <link rel="canonical" href="http://noyesno.net/article/124" />
    
    <script type="text/javascript">
      var $canonical=$('link[rel="canonical"]');
      if($canonical.length && history.replaceState){ 
        history.replaceState(null, null, $canonical.attr('href'));
      }
    </script>
    

    其中link标签是Google推荐的方法,用于标识有着多个不同URL的重复内容,是搜索引擎优化(SEO)的一个重要方法。

    反思

    用形如"article/$id/prev"和"article/$id/next"的方法是否会给缓存管理带来不方便呢。

    如果删除了文章"article/$id",清除其本身的缓存是容易的,但如果要清除其对应的"article/$id/prev"和"article/$id/next"缓存就不是那么方便了。

    你会点击“上一篇”和“下一篇”链接吗?

    其实很多时候,对于文章或者新闻来说,你可能不大会频繁点击“上一篇”和“下一篇”链接的。

    因为简单的“上一篇”和“下一篇”链接并不是高效浏览的方法,而更像是“跟着运气走”。

    这时,一个目录列表可能会更有用。恰巧通常目录列表在网页中是很常见的内容。

    这个问题的另一面是,如果你在当前页面提供了目录列表(即使是部分目录列表),那计算出“上一篇”和“下一篇”的真正URL可能也就不再是问题了。

    “上一篇”和“下一篇”描述了一种关系

    “上一篇”和“下一篇”有时是在描述一种关系。

    对于文章来说,可能并没有实质上的“上”“下”关系。但对于,比如说一本书,这种关系则是显然的。

    这种关系在HTML中可以用以下两种属性来表示:

    • rel="prev"
    • rel="next"
    <link rel="prev" href="/article/123/prev" />
    <link rel="next" href="/article/123/next" />
    
    <a href="/article/123/prev" rel="prev">上一篇</a>
    <a href="/article/123/next" rel="next">下一篇</a>
    
    标签:

      分享到:
      comments powered by Disqus

      21/24ms