docs: tweak values language

templates/docs.html

@@ -507,14 +507,14 @@ I'm <a href="https://snarfed.org/">Ryan Barrett</a>. I'm just a guy who likes <a
 
 <p>Bridgy Fed's second tier of product and engineering values, which also matter but less than the tier above, are:</p>
 <ul>
-<li><b>Accessibility</b>: users should mostly fall into a <a href="https://blog.codinghorror.com/falling-into-the-pit-of-success/">"pit of success"</a> with minimal work on their end. Discovering and following users on other networks should be as easy as possible. After that, all interactions should work automatically, trasnparently.</li>
-<li><b>Transparency</b>: It should be easy for users to understand what Bridgy Fed is doing. This includes per-user dashboard pages in the web UI, verbose public logs, and comprehensive documentation.</li>
-<li><b>Scalability</b>: we want to handle as much usage as we receive, as automatically as possible. This doesn't mean that Bridgy Fed is designed to handle millions of users today, just that it could be, and that we'd prioritize it.</li>
 <li><b>Safety and security</b>: Bridgy Fed minimizes harm to its users. The primary way this currently manifests is that it only bridges fully public data, and it enables and supports the networks' own moderation features (blocking, reporting, etc). It also uses modern secure coding and ops practices to <a href="#vulnerability">minimize vulnerabilities</a> that could expose private keys or other sensitive information.</li>
+<li><b>Accessibility</b>: users should mostly fall into a <a href="https://blog.codinghorror.com/falling-into-the-pit-of-success/">"pit of success"</a> with minimal work on their end. Discovering and following users on other networks should be as easy as possible. After that, all interactions should work automatically, trasnparently.</li>
+<li><b>Transparency</b>: it should be easy for users to understand what Bridgy Fed is doing. This includes per-user dashboard pages in the web UI, verbose public logs, and comprehensive documentation.</li>
+<li><b>Scalability</b>: we want to handle as much usage as we receive, as automatically as possible. This doesn't mean that Bridgy Fed is designed to handle millions of users today, just that it could be, and that we'd prioritize it.</li>
 </ul>
 </li>
 
-<p>Other possible values include maintainability, operability, feature velocity, innovation, debuggability, performance, standards compliance, user growth, and more. Those can all be good, and we may aim at some of them too, but less than the explicitly chosen values above.</p>
+<p>Other possible values include maintainability, operability, feature velocity, innovation, debuggability, performance, efficiency, standards compliance, user growth, and more. Those can all be good, and we may aim at some of them too, but less than the explicitly chosen values above.</p>
 
 <li id="compare" class="question">How do the different protocols compare?</li>
 <li class="answer">