Image switch to webp, crush remaining png. Drop > 50% of image bytes.

markdown/2006-03-16-spanning-tree-protocol-introduction.md

@@ -7,7 +7,7 @@ I’ve been considering increased network redundancy for awhile. After trying a
 
 STP is, simply, an ethernet-level protocol for disabling redundant links until they’re needed to avoid loops (which effectively kill ethernet networks). It works by electing a root “bridge” (meaning switch in this case). Every other bridge checks to see if it has more than one link to the root; if it does, it puts every link but one in blocking state. This lets you build neat redundant networks:
 
-<img src="data:image/png;base64,<!--# include file="images/stp.png.base64" -->" alt="">
+<img src="data:image/webp;base64,<!--# include file="images/stp.webp.base64" -->" alt="">
 
 (__A__, __B__ and __C__ are switches; __1__ and __2__ are servers)
 

markdown/2006-12-05-fixing-your-home-soho-network.md

@@ -18,7 +18,7 @@ You get what you pay for
 ### Sorting out the devices
 
 1. Diagram your network. Knowing what you have and how it’s all connected together is a critical first step toward fixing any of it. A complete diagram looks like:<br>
-   <img src="data:image/png;base64,<!--# include file="images/sample-network.png.base64" -->" alt=""><br>
+   <img src="data:image/webp;base64,<!--# include file="images/sample-network.webp.base64" -->" alt=""><br>
    (the diagram above was made with [dia](http://dia-installer.sourceforge.net/), a free diagramming software)
 1. Count up devices doing Network Address Translation (NAT; sometimes referred to as PNAT). These are usually marketed as routers or firewalls. It’s common (and completely acceptable) to have __one__ such device, directly connected to the Internet and “in front” of all other devices. There should never be more than one; doing multiple translations will cause nothing but problems. The one such is device is also the most likely failure point; this is the place to spend real money. However, avoid anything labeled “firewall” unless you really know that you need some feature that it offers. NAT alone is enough to keep out any attacks that connect in from the Internet.
 1. Repeating myself form the previous step: look __hard__ at your diagram. Do you see any routers that could be replaced with switches? Do you see any wireless routers that could be replaced with wireless access points?

markdown/2010-03-26-fun-with-map-visualizations.md

@@ -11,7 +11,7 @@ The most elegant solution seems to be a [force-directed graph](http://en.wikiped
 
 Today, I got to build a visualization that [went public](http://www.google.com/appserve/fiberrfi):
 
-<img src="data:image/png;base64,<!--# include file="images/fiberrfi-map.png.base64" -->" alt="">
+<img src="data:image/webp;base64,<!--# include file="images/fiberrfi-map.webp.base64" -->" alt="">
 
 We had lots of data from the fiber-to-the-home request-for-information site, and needed a way to visualize it. This is a [geo map](http://code.google.com/apis/visualization/documentation/gallery/geomap.html) that uses markers. Unfortunately, the API limits you to 400 points, which wasn't enough, so I (at nmlorg's suggestion) screenshotted the map with 400 points at a time and stitched the results; hacky, but functional. We couldn't have used the direct rendering anyway, as it does one AJAX call to Google Maps to look up each point (we were passing in ZIP codes), so it takes ~10 minutes to render.
 

markdown/2011-08-08-database-best-practices-for-future-scalability.md

@@ -10,7 +10,7 @@ There’s a perpetual debate about how much effort to put into scalability when
 1. Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, [protocol buffers](http://code.google.com/p/protobuf/), etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient.
 
 1. Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br>
-   <img src="data:image/png;base64,<!--# include file="images/db-hierarchy.png.base64" -->" alt="" style="background: white;">
+   <img src="data:image/webp;base64,<!--# include file="images/db-hierarchy.webp.base64" -->" alt="" style="background: white;">
 
 1. Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO\_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables.