社区中心

登入的用戶可自由切換簡/繁字體喔!

了解更多

社区中心
Advertisement
社区中心
本頁使用了標題或全文手工轉換

隨著網路(以及支援網路的服務和網站)的發展和變化,像Fandom這樣網站的技術部分必須進行調整以適應我們使用者的習慣並保持現代化。對於像wiki這樣的資訊服務來說,愛好者可以從其無窮無盡的資源中找到關於幾乎任何主題的「答案」。

虽然我们很想假设用户直接输入网址进入某个Fandom社区,但现实情况是,超过80%的Fandom访问量来自搜索引擎结果。[1]在世界上的大部分地区的整个搜索领域,Google平台几乎完全独占[2]此外:大多数导向Fandom的wiki的搜索不是“某wiki”,而是特定页面的标题或主题的搜索,这些搜索更为常见。这代表了随着网络发展和搜索引擎的强大影响而发展的用户习惯变化。

Google经常对其搜索服务的算法进行改动,并偶尔向较大的网站通知他们的计划。由于wiki的发展和编辑方式,他们发布的三个这样的改动[3][4][5]预计将会对Fandom产生重大影响。如果不对这些变化进行回应,任何单个wiki以及整个Fandom平台的曝光度都会降低。因此,本指南将讲解技术(和人类)会如何查看wiki,以及社区可以进行哪些必要的调整。

衡量標準

定义wiki性能的因素有很多,而每个都有不同的衡量标准。

MediaWiki效能

在维基文本页面进入网络之前,它必须先成为 HTML。解析和“渲染”过程发生在MediaWiki服务器中,在那里它被逐层翻译成网页的基本语言。处理和提供这些内容通常在两秒内完成。通过使用“缓存”,服务器第二次提供相同且未更改的页面时可以更快。

MediaWiki页面性能是用消耗的时间、内存资源以及以及HTML结果的复杂程度(因为浏览器需要解析HTML代码并将其转换为人类可以理解的内容)衡量的。从服务器的其他部分获取信息(也就是“嵌入”)的页面会使用更多时间和资源。使用模板是一种嵌入的形式,因此模板的复杂性和嵌套深度会影响页面性能。根据编写方不同,这也适用于将内容从一个页面移动到另一个页面的某些扩展(如動態頁面列表(DPL))。

渲染流程图

網站體驗核心指標

最近,Google开始关注三个关键性能指标,它们会影响网站排名。[6]总的来说,这些網站體驗核心指標(Core Web Vitals)是:

大部分網站體驗核心指標衡量的内容取决于Fandom的页面分发方式,但编辑者和社区也能采取行动提升wiki的这些“指標”。虽然在桌面页面上注意这些指标也很重要,但Google在这方面主要关注(未登录用户的)移动端视图。出于某些原因,Google在排名时会考虑单个wiki,但另一些情况下Google也会将所有Fandom站点视为一个整体。網站體驗核心指標对整个平台影响更大(因此可以提升搜索频率较低的小wiki),但对于单个wiki而言,了解它们并进行可能的更改也很重要。

使内容容易理解

在单纯的指标之外,让您的wiki页面充分公开且可发现是性能的重要因素。

盲人摸象

Google算法的重要部分涉及“段落排名”和“总页面索引”。Google通过页面中的链接和网站地图访问它可以找到的所有页面,并在其数据库中制作副本,然后对其进行处理以查找信息。这一过程包括Google(从它创建的索引中)阅读句子并“理解”它们的上下文——例如,如果一个页面(的一个完整的句子中)中有“X是Y的母亲”而另一个页面中有“Z是X的父亲”,那么即使没有明确写出,Google的“大脑”中也会有一个“Z是Y的外公”的模型。这个理解语义的过程帮助Google在用户寻求信息时回答问题。很久以前,搜索引擎爬虫依赖于页面中的关键词,而段落排名使用自然语言和数据(如表格和信息框)来开发模型,以便Google将搜索者导向正确的地方。从某种意义上说,这种使用不同的信息片段来拼出整体框架的做法很像古老寓言“盲人摸象”[7]。这就是为什么使用更多的背景信息和叙述(尽管它们使页面更长)有助于Google构建一个可以参考的完整概念。这种方法也更适合人类理解wiki主题。这并非巧合,因为Google的许多方法旨在模仿人类的思维方式——如果Google理解某一页面在说什么,它预测该页面(以及同一wiki上的其他页面)也是人类了解信息的最佳来源并提高这些页面的排名。

页面的可理解度可以通过它们的所含内容的数量和优劣来衡量。具有较少参考内容的短小页面对数据库类的网站更有帮助,但在Fandom的wiki中,比起单纯的事实,读者对社区的声音和智慧更感兴趣。一个社区如何决定何时将独立的主题从长文章中分离出来或何时合并相互关联的小文章是一项不易量化的重要衡量标准。

用户体验

体验差劲的页面留不住读者。与写得不好或质量低下的页面一样,信息过于密集或难以理解的页面也会赶跑读者。

Google也在以多种方式系统地衡量用户体验。客观上,Google可以记录在页面上花费的时间,通过分析来为用户体验建模。Google还雇佣质量评估员来验证该算法是否能有效地把搜索者发送到正确地方。这些评估员对资源的有用性和可用性提出专业意见,这些意见可以通过影响Google的算法调整间接影响网站排名。

但最有效的用户体验衡量标准始于理解网页的难易程度——尤其是在移动设备上的理解和交互。任何添加到页面的精致样式和小工具都无法掩盖资料组织或编写得不好的问题。如果用户无法通过页面的花哨装饰(原文:frippery)或隐藏面板找到他想要的资料,这些花里胡哨的噱头实际上可能会使用户体验变得更糟。

实际调整

作为编辑者,有一些可行的方法可以提高wiki的性能。这些方法中,许多是需要重新考虑的习惯,部分原因是网络的性质与wiki首次引入时发生了变化。单个改变影响很小,但它们在一起时能更好得提升wiki的性能。

原创页面内容与小作品

虽然MediaWiki工具可以自动化解读页面的技术方面的性质,例如页面长度和相互链接程度,但这些工具无法识别小作品或浅层内容。小作品是一个传统的wiki名词,它指的是那些被手动标记为不完整且需要添加更多信息的页面,而浅层内容指的是那些不能回答读者所带的疑问的页面。因此,大多数小作品也被认为是浅层内容,尽管不是所有的短页面都是小作品。虽然Fandom上的wiki目前不会因为拥有大量浅层内容被惩罚,但有证据表明Google的算法在遇到浅层内容时会对wiki站点(或整个Fandom)做出假设,并且未来可能采取相应行动。

短页面存在體驗核心指標的问题,而小页面更是同时存在可理解性和用户体验问题。例如,短页面的内容区域较小,有时它们过小以至于标题和工具栏成为最大的页面区域。因此,较小的内容区域会相对更容易得被工具栏之类的元素取代,导致更高的CLS分数(越低越好)。由于它们的交互性,标题和工具栏的加载速度比内容慢。如果它们是页面上最大的内容(按 HTML 大小计算而不是视觉大小)并且加载时间最长,则LCPFID分数将不太理想。

小作品由于其深度较浅的性质而无法应答深层次的查询,因此在Google的排名往往很差。如果一个站点的小作品相对完整文章的比例很高,Google会降低它对该wiki回答相关主题问题的能力的整体信心,因此可能会降低同一wiki上页面的排名(即使那些页面不是小作品)。因此,最好通过删除页面、全面补充页面或将其合并到相关页面来尽快(短于30 天,届时Google可能会定期重新索引 wiki)消除小作品。请记住人类访问者也会以相同方式思考,比起不完整和孤立的信息,我们更喜欢在一个“大图景”中看到短小的信息。有空的部分,尤其是空的简介(也叫“lede”)的页面,对Google的解析器和人类用户体验都有负面影响。因为这种留空代表死胡同而不是机会。

红字链接(或指向不存在的占位符的链接)曾被认为是编辑者和潜在编辑者构筑新页面的机会。撇开在红字链接吸引编辑的有效性方面的调查不谈,红字链接会破坏网站体验指标和搜索引擎爬虫;这也是红字链接在非登录的移动体验上显示为纯文本的原因。红字链接将搜索引擎爬虫导向不存在的区域,导致搜索引擎因为页面不存在而把它们计为错误。无论是否为wiki站点,在网站上遇到的总错误计数,都会降低算法对其可信度和可靠性的判断,因此快速减少红字链接的总数将有助于提高页面性能和排名。

Wiki站点通常不会优先考虑编写分类页面,但是如果Google的模型根据推断信息可能会认为他们和文章页面的排名一样高。当这些分类页面上没有简介时,它们会以乱码的形式出现在Google的搜索结果上。因此,每个分类都应至少在页面的内容区域有一些文字说明。

页面的鲁棒性和移动可用性

内容划分时一个常见的误解是将文章划分以选项卡方式(通过页面顶部的链接或交互式选项卡)划分为若干段落。当这些页面链接到其他页面时—Fandom把这一过程叫做页面标签导航—它们天然地造成或体现了不完整的概念将通常单个文章概念(人物、剧集、武器等;也称为内容实体)的信息散布到多个页面会使Google更难以理解并创建该概念的模型。类似地,人类读者不太可能乐意访问和通读多个页面来了解同一项目的各个方面。这种效应有时被称为“但我们的公主在另一座城堡中”[8],因为读者必须通过不同的链接来寻找他们想要的东西,就像是顺着信息的气味追踪以找到他们真正想知道的。

拥有一个搜索者希望找到的“完整图景”并且在单独的页面上对各个方面进行更深入或更长的解释会更好。“概述”页面(通常称为“基页面”,因为其标题不是子页面)应至少包含理解文章概念所需的要素。正文中的链接(可能在段落标题下方使用{{Main}}{{See also}}模板)可以引导搜索者阅读他们想要的更深入、详细的信息。这些链接与摘要及背景解释同时使用时效果更好。例如,在顶部有“传记”和“历史”链接的页面上,搜索者如何知道每个页面上有那些信息?因此,所有的文章都可以而且应该是完整的概念,而不是需要收集的信息碎片。

还应注意的是,如果此类页面选项卡是使用模板或JavaScript创建的布局,它们将只能用于桌面浏览而无法在移动设备上正常运行或显示。这样的链接也无法作为语义辅助与Google的算法相联系(由于上下文不会被理解,它们看起来就像漂浮在文章顶部的孤立链接)。与其添加一些视觉效果和功能不佳或对大多数读者来说根本不显示的链接,不如将导航链接放在信息框的<navigation>部分,这样就能产生一个移动用户和搜索引擎都容易理解的页面间的桥梁。

在这个模型中,页面顶部的“标签形链接”与页面上其他地方(包括标题)的图标链接或指示器(通常称为EraIcons)之间几乎没有区别。这两种形式的链接都难以在移动设备上查看或操作,因此都建议移动到信息框的导航部分

对文章而言,没有任何块状元素(即:非文本)像信息框一样重要。从某种意义上说,信息框和文章的介绍部分(也就是“lede”)一起提供了有关文章主题的上下文和数据。因此,它们在手机皮肤上进行了特殊处理,会向Google的算法发出强烈信号。它们突出的地位使它们成为放置导航和指向其他密切相关页面链接的理想位置。

包含图像、表格和图库的部分和段落有一个问题,即它们通常没有说明性的“锚点”来把图片放在上下文中。这些“锚点”可以起到语义说明(以便Google理解它创建的模型与锚点对应的图片或表格之间的关系)和确保可访问性(以便屏幕阅读器和其他辅助设备在解释表格或图片之前显示一个说明,告知信息是否相关)的作用理想情况下,所有图片都应该有对应的说明(将图片放到文章概念中的文字。例如:“蝙蝠侠,2020年前后”)和/或替代文本(alt-text,即用文字为无法看到图像的人描述图像。例如:“在夜间屋顶上沉思的古装角色”)。换句话说:替代文本解释它是什么,图片说明解释它为什么在那里。对于可以按照逻辑分组的大型图库,将它们划分为较小的图库有助于优化渲染性能和方便读者理解。最好将这样的图片与叙述性文本相互穿插从而相辅相成,这种布局适用于所有设备。

缩短页面

长页面本身并没有错(以搜索引擎的角度看)。如上所述,长页面更有可能被Google的段落排名解读为具有完整内容的模型,因为整个页面都会被分析。如果页面内容组织得很好,读者应该能得到大量的信息和娱乐度,而不会很难找到某些信息点。

但应注意的是,将内容块放置在交互式选项卡块(通常称为“Tabbers”)中存在技术障碍。大多数编辑者使用的可视化编辑器在编辑复杂代码(比如在解析器函数中)内部的wikitext块时会比较困难,而使用源代码编辑器时也会出现编辑者难以识别元素的开始和结束位置的问题。由于需要渲染元素,交互式JavaScript层增加了首次輸入延遲(FID)分。如果tabber在首次加载时位于页面的初始可见区域,它也会因为元素替换而增加累計布局偏移(CLS)分。显示内容的选项卡本身可能根本无法在移动设备上正常运行。网络上的多份报告表明隐藏在第二标签中的内容可能不被Google重视。

不过,也许最重要的是用户体验:辅助标签后面的内容“眼不见心不烦”,不太可能被读者查看。第一个之外,每增加一个选项卡,它被访问的频率都会逐渐降低。大多数时候,读者甚至不知道在他们直接可见的部分之外还有信息的存在。因为隐藏在视线之外,读者会忽略他们正在寻找或享受的东西。

因此在大多数情况下,使用Tabber来“缩短”页面对性能和体验来说都远非理想。如果一定要使用tabber,请务必遵守用户体验专家的可用性指南中的建议:

  • 不要使用嵌套标签
  • 标签显示时不能多于一行
  • 标签说明应简洁清晰

在该流程图中包含数据表(DataTables)突出了我们想要强调的功能:很快可以作为Dev Wiki脚本[9]提供的DataTables将会为较长的数据表格添加许多改善使用体验的新功能。另外值得注意的是,(考虑到处理时间和搜索引擎解析)不鼓励在页面中使用多个信息框。建议使用panel功能合并多个信息框。

首页和导航栏

由于种种原因,wiki的首页是特殊的。对只输入基URL(而不是某一特定页面)访问网站的机器人和人类读者来说,主页代表了链接传递的主要入口。Google将主页(以及本地导航栏)中的链接当作理解wiki主题的重要位置。当Google第一次查看查看wiki,它对主题一无所知,这时它会假定所有的链接都具有同等的权重和重要性。当那里有10到20个指向页面或分类的链接时,事情很简单,但当小部件(widget)或面板(panel)向首页添加了数百个链接时,每个链接的相对权重就都接近于零。正如本文多次提到的,这也是大多数人的思考倾向:人们在选择太多的时候会患上“选择困难”。这就造成他们不知道该从那里开始理解这个站点。

因此出于技术和用户体验的考虑,我们强烈建议缩减首页上的链接到只包含那些理解wiki主题所需的最重要的文章和类别。我们还建议不要使用交互式小部件列出大量页面,因为它们会影响渲染、网站体验指标和抓取性能:如果一个页面能被其他页面链接到,则终会被爬虫访问到。另外值得注意的是,在大多数情况下,Google会被系统被指示不要抓取wiki的特殊或讨论页面,因为它们可能会收到错误消息或被重定向。因此我们建议不要在首页上添加这些页面的链接(在许多情况下,这些页面可以从本地导航栏或Special:社区页连接到。这些地方不会被Google一眼看到)。

有很多机会可以在wiki中包含视频,但我们建议最多使用两到三个嵌入式视频,因为在经常访问的页面上放置更多视频导致的性能和视觉影响都会限制每个视频的有效性。

字体和资源导入

某些特殊字体看起来很棒(当考虑到基本排版规则时),但它们也会影响到wiki的性能。在wiki上有两种字体:导入的网络字体和上传的字体。考虑性能因素,理想的选项是使用Google Fonts提供的字体,并且当导入多种字体时将导入它们的URL合并成一行。如要上传字体,请仅使用WOFF2格式。WOFF2是一种经过压缩的TTF/OTF文件格式,它对网页使用进行了优化且被所有主流浏览器支持。有很多在线工具可以把其他格式的文件转换成WOFF2格式。请不要使用过多种类的字体,即不超过三种,这能保持你的wiki看起来整洁和专业。并且请在导入时把这些字体的链接合并成一行(如使用Google Fonts)以提升性能。

除了(有着强大而快速的内容交付系统的)谷歌字体之外,请避免导入(或向外链接到)任何Fandom系统之外的字体、[[Help:Including additional CSS and JS |JavaScript、CSS]]、图片或其他类型的资源。导入外站资源存在潜在的安全问题和切实的性能影响。它们会影响网站体验指标,因为有时每一刻都很关键。

模板和页面复杂程度

长页面并不一定复杂,反之亦然。由多层嵌套的模板构成的页面需要更长的时间才能生成HTML,而几乎完全使用单个模板(例如页面布局模板)构成的页面尤其难以处理从而消耗更多服务器资源。相反所有的wiki可以要求并尝试新启用的Page Forms扩展(它可以构建页面并方便持续编辑)。这些表单可能在创建特定类型的新页面时比预载模板更好用。

当处理特别复杂的模板(即使用了很多的ifswitch、昂贵操作或其他解析器函数)时,将其转化为Lua(一种强大、高效且轻量级的替代模板语言)代码很可能能提升效率,特别是当这一模板频繁被别的模板使用时。尽管Lua是一个强大的工具,它并不那么容易学习。所以请尽管到我们的中文聊天平台英文社区中心寻求关于模板迁移的帮助(或决定是否应使用Lua)。使用Lua几乎总是比嵌套模板更快。

在页面上放置一个移动化信息框有效为Google提供信息(从而在搜索结果中更显眼)。信息框的在性能方面也很好,可以有效地处理其中的数据。相比之下,将表格当作信息框和其他布局元素在移动设备或其他响应式显示器上效果不佳。相互嵌套表格也是页面可移植性(即内容的跨平台/跨皮肤显示)的一个已知问题,因此应该避免。

数据和嵌入

在多个页面上显示相同数据的理想方式是将所有数据保留在显示它们的页面上(即去中心化)。虽然这可能更新起来更麻烦,但它可以加快页面处理速度。使用大量的自动化过程来生成文本往往会使新编辑者更难理解,并延长各个页面的服务器处理时间。

很多数据密集型wiki倾向于使用重量级扩展,例如SMW或Cargo,来存储和分发在各个文章页面中输入的数据。也有些社区使用中等量级的扩展,例如DPL或Labeled Section Transclusion,来从页面中获取内容并放置在另一个页面上。当这些不再可用时,剩下的社区转而将数据集中存储在Lua模块中并将其当作数据库。将数据集中存储在像Lua模块或模板中会降低性能并减慢页面加载时间,

伴網路前進

让Google满意很重要,因为这就是我们喜迎流量的方式。但Google基于人类的想法和习惯,所以Google所做的其实主要是让人舒服。这些不是Fandom对各个wiki施加的惩罚,而是使各个wiki在不断发展的网络中保持链接的措施。

  1. Google在我们的全球网络中的重要性不言而喻:没有Google,很少有信息网站能够持续吸引流量。这与广告、隐私或社交分享无关。在真正意义上,Google搜索比任何其他网络设施更能在混乱中带来秩序并驱动网络。
  2. 除中国大陆、日本、俄罗斯、韩国和土耳其外,Google维护着它在几乎所有国家所有语言搜索的主导地位。在这些提到的国家中,Google也保持着绝对多数的市场份额,亦或受到该国政府的限制。尽管用户个人可能偏好必应、雅虎、百度、Yandex或DuckDuckGo—但这些加起来也不到全球所有网络搜索的10%。Google实际上是唯一对Fandom网络运营重要的外部搜索引擎,因此我们也只考虑使它“保持开心”。Google的“快乐”可以扩展到为其他任何搜索引擎优化的良好实践,而为搜索引擎们提供更好的体验最终或有利于我们的社区。
  3. 巴里·施瓦茨(Barry Schwartz), “Google:优先移动考虑索引应为仅移动索引(Google: Mobile-First Indexing Should Be Mobile-Only Indexing),”搜索引擎圆桌会议(Search Engine Roundtable) (https://www.seroundtable.com/google-mobile-first-indexing-mobile-only-indexing-30270.html, n.d.)
  4. 罗杰·蒙蒂(Roger Montti),“Google如何为文章排名:你需要知道的16件事(What Is Google Passage Ranking: 16 Key Points You Should Know),” 搜索引擎杂志(Search Engine Journal) (https://www.searchenginejournal.com/google-passage-ranking-martin-splitt/388206/, November 2020)
  5. 德特莱夫·约翰逊(Detlef Johnson), “搜索引擎和开发者的核心网络要素指南(Guide to Core Web Vitals for SEOs and Developers),” 搜索引擎领域(Search Engine Land) (https://searchengineland.com/google-core-web-vitals-guide-for-seo-developers-337825, July 2020)
  6. 此段翻译参考:https://www.iprospect.com/zh/tw/news-and-insights/news/core-web-vitals/
  7. 盲人摸象的故事(图片“盲人摸象,”1907.)
  8. 译者注:出自《超级马力欧兄弟》系列中的经典台词“Thank you Mario! But our princess is in another castle!”
  9. https://dev.fandom.com/wiki/DataTables
Advertisement