diff --git a/i2p2www/pages/site/about/performance/index.html b/i2p2www/pages/site/about/performance/index.html
index 1335a7ed08e1ab0e72e21b7fb6bc266e2781114d..27aef93f67b2f1a8914c8a58dfabbd4f64cb0b1b 100644
--- a/i2p2www/pages/site/about/performance/index.html
+++ b/i2p2www/pages/site/about/performance/index.html
@@ -2,26 +2,19 @@
 {% block title %}{{ _('Performance') }}{% endblock %}
 {% block content %}
 
-<h2>{% trans %}How does I2P work, why is it slow, and why does it not use my full bandwidth?{% endtrans %}</h2>
+<h2>{% trans %}I2P Network Performance: Speed, Connections and Resource Management{% endtrans %}</h2>
 
 <p>{% trans -%}
-Probably one of the most frequent things people ask is "how fast is I2P?",
-and no one seems to like the answer - "it depends".  After trying out I2P, the
-next thing they ask is "will it get faster?", and the answer to that is a most
-emphatic <b>yes</b>.
+The I2P network is fully dynamic. Each client is known to other nodes and tests locally known nodes for reachability and capacity.
+Only reachable and capable nodes are saved to a local NetDB.
+During the tunnel building process, the best resources are selected from this pool to build tunnels with.
+Because testing happens continuously, the pool of nodes changes.
+Each I2P node knows a different part of the NetDB, meaning that each router has a different set of I2P nodes to be used for tunnels.
+Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free when the second router tests.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-I2P is a full dynamic network. Each client is known to other nodes and tests local known nodes for reachability and capacity.
-Only reachable and capable nodes are saved to a local NetDB (This is generally only a portion of the network, around 500-1000).
-When I2P builds tunnels, it selects the best resource from this pool. For example, a small subset of 20-50 nodes are only available to build tunnels with.
-Because testing happens every minute, the pool of used nodes changes every minute.
-Each I2P node knows a different part of the net, meaning that each router has a different set of I2P nodes to be used for tunnels.
-Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free if the second router tests.
-{%- endtrans %}</p>
-
-<p>{% trans -%}
-The above describes why each I2P node has different nodes to build tunnels.
+This describes why each I2P node has different nodes to build tunnels.
 Because every I2P node has a different latency and bandwith, tunnels (which are built via those nodes) have different latency and bandwidth values.
 And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets.
 {%- endtrans %}</p>
@@ -45,22 +38,21 @@ server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client
 </pre>
 
 <p>{% trans -%}
-As most traffic on I2P (www, torrent,...) needs ack packages until new data is sent, it needs to wait until a ack package returns from the server.
-In the end: send data, wait for ack, send more data, wait for ack,..
-As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until a ack package comes back to the client.
-With some internals of TCP and I2P transport, a data package has a limited size and cannot be as large as we want it to be.
-Together these conditions set a limit of max bandwidth per tunnel of 20-50 kbyte/sec.
-But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the 
+Traffic on the network needs an ACK before new data is sent, it needs to wait until an ACK returns from a server: 
+send data, wait for ACK, send more data, wait for ACK.
+As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until an ACK comes back to the client.
+Because of TCP and I2P transport design, a data package has a limited size.
+Together these conditions set a limit max bandwidth per tunnel of 20-50 kbyte/sec.
+However, if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the 
 latency and other limitations.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Due to encryption used and other setups in I2P (howto built up tunnels, latency, ...) it is quite expensive in CPU time to build a tunnel. This is 
-why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could 
+Encryption, latency, and how a tunnel is built makes it quite expensive in CPU time to build a tunnel. This is 
+why a destination is only allowed to have a maximum of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could 
 use roughly 300 kb/sec traffic combined ( in reality it could be more if shorter tunnels are used with low or no anonymity available).
-Used tunnels are discarded every 10 minutes and new ones are built up.
-This change of tunnels (and sometimes clients that shutdown hard due to usage of "shut down at once" or situations where there is power loss) does 
-sometimes break tunnels and connections, as seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget.
+Used tunnels are discarded every 10 minutes and new ones are built.
+This change of tunnels, and sometimes clients that shutdown or lose their connection to the network will sometimes break tunnels and connections. An example of this can be seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
@@ -72,28 +64,27 @@ If one distributes these limited numbers across the number of I2P nodes, there i
 
 <p>{% trans -%}
 To remain anonymous one router should not be used by the whole network for building tunnels.
-If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to grab IPs and data from the clients. This is not good.
-I2P attempts to spread the load across a lot of I2P nodes because of this reason.
+If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to gather IPs and data from clients.
+This is why the network distributes traffic across nodes in the tunnel building process.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Another point is the full mesh network. Each connection hop-hop utilizes one TCP or UDP connection on the I2P nodes. With 1000 connections, one sees 
-1000 TCP connections. That is quite a lot and some home and small office routers (DSL, cable,..) only allow a small number of connections (or just go mad if you use more than X connections).
-I2P tries to limit these connections to be under 1500 per UDP and per TCP type.
-This limits the amount of traffic routed across your I2P node as well.
+Another consideration for performance is the way I2P handles mesh networking. Each connection hop-hop utilizes one TCP or UDP connection on I2P nodes. With 1000 connections, one sees 
+1000 TCP connections. That is quite a lot, and some home and small office routers only allow a small number of connections.
+I2P tries to limit these connections to under 1500 per UDP and per TCP type.
+This limits the amount of traffic routed across an I2P node as well.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-In summary, I2P is very complex and there is no easy way to pinpoint why your node is not used.
-If your node is reachable and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic.
-If it is down in between, the testing of your I2P node done by other nodes will tell them: you are not reachable. This blocks your node for at least 
-24h on other nodes. So, the other nodes which tested you as down will not use your node for 24h for building tunnels. This is why your traffic will 
-be lower after a restart/shutdown for a minimum of 24h.
+If a node is reachable, and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic.
+If it is down in between, the testing of an I2P node done by other nodes will tell them it not reachable. This blocks a node for at least 
+24 hours on other nodes. So, the other nodes which tested that node as down will not use that node for 24 hours for building tunnels. This is why your traffic is
+ lower after a restart/shutdown of your I2P router for a minimum of 24 hours.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Also: other I2P nodes needs to know your I2P router to test it for reachability and capacity. It takes time for other nodes to get known to your node. 
-It will be faster if you use I2P and build more tunnels, e.g. use a torrent or www for some time.
+Additionally, other I2P nodes need to know an I2P router to test it for reachability and capacity. 
+This process can be made faster when you interact with the network, for instance by using applications, or visiting I2P sites, which will result in more tunnel building and therefore more activity and reachability for testing by nodes on the network. 
 {%- endtrans %}</p>
 
 <h2>{{ _('Performance Improvements') }}</h2>
diff --git a/i2p2www/pages/site/get-involved/guides/new-developers.html b/i2p2www/pages/site/get-involved/guides/new-developers.html
index ffd6d8994cd16933793a75e6bbe0bf3413fb6dc3..3cee6484e1cc1cb2b246f18c4b6bea1f3cc79952 100644
--- a/i2p2www/pages/site/get-involved/guides/new-developers.html
+++ b/i2p2www/pages/site/get-involved/guides/new-developers.html
@@ -3,7 +3,7 @@
 {% block lastupdated %}2021-01{% endblock %}
 {% block content_nav %}
   <ol>
-    <li><a href="#basic-study">{% trans %}Basic study{% endtrans %}</a></li>
+    <li><a href="#basic-study">{% trans %}Get to Know Java{% endtrans %}</a></li>
     <li><a href="#getting-the-i2p-code">{% trans %}Getting the I2P code{% endtrans %}</a>
     <ul>
       <li><a href="#git">{% trans %}The new way: Git{% endtrans %}</a></li>
@@ -28,10 +28,10 @@ Not quite ready for coding?
 Try <a href="{{ volunteer }}">getting involved</a> first.
 {%- endtrans %}</p>
 
-<h2 id="basic-study">{% trans %}Basic study{% endtrans %}</h2>
+<h2 id="get-to-know-java">{% trans %}Get to Know Java{% endtrans %}</h2>
 
 <p>{% trans -%}
-Basic development on the I2P router or the embedded applications uses Java as the main development language.
+The I2P router and its embedded applications use Java as the main development language.
 If you don't have experience with Java, you can always have a look at <a href="http://www.mindview.net/Books/TIJ/">Thinking in Java</a>.
 {%- endtrans %}</p>
 <p>{% trans intro=site_url('docs/how/intro'), docs=site_url('docs'), techintro=site_url('docs/how/tech-intro') -%}
@@ -52,7 +52,7 @@ you need to get the source code:
 <h3 id="git">{% trans %}Our current way: Git{% endtrans %}</h3>
 
 <p>{% trans trac="https://i2pgit.org" -%}I2P has official Git services and accepts contributions via Git at <a href="{{ trac }}">our own gitlab</a>.
-Trac issues have also been migrated there and the former Trac is not available anymore by now. Two-way syncing of
+Trac issues have also been migrated to Git issues. Two-way syncing of
 issues between Gitlab and Github is a work-in-progress.{%- endtrans %}</p>
 
 <li>{% trans git_url='https://git-scm.com/' -%}
@@ -100,9 +100,8 @@ see the <a href="{{ apps }}">application development guide</a>.
 {%- endtrans %}</p>
 
 <h2 id="development-ideas">{% trans %}Development ideas{% endtrans %}</h2>
-<p>{% trans zzz=i2pconv('zzz.i2p'), todo=site_url('get-involved/todo'), trac='https://i2pgit.org/i2p-hackers/i2p.i2p/issues' -%}
-See <a href="http://{{ zzz }}/forums/3">zzz's TODO lists</a>,
-<a href="{{ todo }}">this website's TODO list</a> or
+<p>{% trans todo=site_url('get-involved/todo'), trac='https://i2pgit.org/i2p-hackers/i2p.i2p/issues' -%}
+See <a href="{{ todo }}">the project TODO list</a> or
 <a href="{{ trac }}">the issue list on GitLab</a>
 for ideas.
 {%- endtrans %}</p>