Archive of Our Own ^beta

 Don't   panic. 

 

 

 

 

Preamble  ^{Contents ↑}

 

---

 

Recorded for a year, instead of sleeping:
“Sleep — those little slices of death, how I loathe them”
  — E. A. Poe, attrib. [apocryphally]  

Let's start off with a bang, mostly because I can't think of anywhere better to place this item.  For the record, the research was done by refreshing my tabs every 30 minutes (in conjunction with a few tricks of browser setting and forcing it not to close if accidentally clicked) and copying the relevant data manually.  Maybe a script would've been better, and have it dump to a .csv for a .db, but skip it: there's a lot to unpack there (more on that at the very bottom of this work, if you're curious).

1. this bookmark search
2. this work search
3. this >0 comment search
4. this >0 hit search
5. my own stats page
6. and this >0 kudos search

This was an interesting (and not terribly well thought through) endeavor.  It all kicked off ultimately because of a Facebook group's weekly stats post, and the occasional thread in FB and Reddit about the “best time” to upload to AO3.  I started tracking my fics' weekly stats, then got curious about the dailies, then wondered how each day of the week looked w.r.t. the others, and then the actual change over time per day.  For my own fics, that was easy enough: just check in the first and third quarters of the hour (once I figured this out) at xx:00-xx:14 and xx:30-xx:44 only (at any time during the second and fourth quarters of the hour, xx:15-xx:29 and xx:45-xx:59, your own personal stats page is in flux, and your Hits can update multiple times [your other stats though, the Kudos and so forth, are volatile all of the time, so any refresh can bring an update, regardless of the quarter hour]).
  Any time that I missed a slot (sleep or whatever reason) or was late by even a minute, I annotated the next half hour's average of the two (if I'd missed the one) or the approximate half hour's value (the value is exact, not approximate, but it's not a half hour, hence unlikely to have been the same, so I consider the actual half hour's unknown value to be approximately the known non-half hour's average in my annotation), but still didn't permit them to be counted in the rows' averages.  That latter might sound pointless if it's only a minute or two, but consider this real-world example from 08 Dec 2023:

19:31  11799614 Kudos
20:01  11799730 Kudos  = +116
20:31  11799714 Kudos  = -16
21:01  11799828 Kudos  = +114

Had I missed the 20:31 data-check, then I'd know only 20:01...21:01 = +98, and could guess that the approximate changes of 20:01→20:31 and 20:31→21:01 were probably around their mean average of 98 / 2 = 49 each, but would clearly be wrong about the actual values having been -16 and +114 instead.  That's why I permitted only known changes in the computations (though as to why I still annotated them... OCD habit: one never knows when some surely irrelevant datum might become important); a caveat to this is that while the data do seem a bit more jumpy just before and at the turn of the half hour (see the Results tables & graphs and Verbose mode sections for more detail), I'd probably (no guarantee) be somewhat safe in taking a value that was a minute late (and even then, were the value different in that next minute, it would typically vary by only some small amount — ~1/30 being on the order of ~{+99.85(-) bookmarks, +20.28(+) new works, +2.24(+) comments, +3.51(-) hits, and +3.45(-) kudos} per minute, over the relevant spans of this study).  One important item to note is that there could be hidden variables, such as tabulation time vagueries in the servers (maybe the best time to check the numbers is 47 second before the hour, or every 32 minutes, or some other weirdness); another is that if I were truly dedicated, then I could have accounted for the off-time numbers by simply plugging in the exact timestamp second of every single datum and crunching those... 60s * 60m * 24h * 366d (to account for the leap year) * 6 variables = 189,734,400 cells to plunk data into (and 1,799/1,800 being empty), unless I were to take the time to learn the necessary programming skills instead of using a simple spreadsheet... no thanks to either option; this project wasn't that vital.

Poking around early on, I found a bunch of material on the “best time” to post on Insta, Twitter, various subreddits, etc., but eventually concluded that this didn't really apply to AO3 since it's an archive where stories are read from any given date (yes, even a decade later).

I still posited that the initial time and date might give slightly better or worse initial traction and consequent cross-traffic to other fics (though honestly, cross traffic seems a bit low [the only ones that seem to see much of it are the ones cross linked from my smut-fic]; I'm pretty sure that I get more from fics being in other peoples' thematically similar collections), but that sounds simpler than it is, and is likely misleading in that even if one could ascertain a particular time for something, that wouldn't apply to everything — e.g.: if you were to upload a Halloween story in June, it would still get read, but will see a higher initial hit rate were you to upload it in October; a year or two later, it'll still see hits all through the year (I can attest to this with my own), with an uptick toward the end of October, so there's possibly some slight advantage to uploading at an appropriate date, but probably not a big deal overall because the mean average slope of a curve over time is what determines things in the end, rather than the initial y-coordinate (i.e.: if you post two fics, and FIC A gets +100 hits on day one, +50 day two, +25 day three, +12 day four, +6 day five, and onesy-twosy after that, nothing but crickets and tumbleweeds, and FIC B gets +10 hits on day one, and maintains this [somehow], then FIC B will outstrip FIC A quite soon; on day six or seven, FIC A reaches its watershed of less than one hit per day with a running total of 194-195 hits, at which time FIC B, chugging along slowly, will have only 60-70 hits, but in this scenario will reach parity with FIC A on day twenty, with both at around 200-201 hits).  In that same way, you might get better or worse traction by uploading a fic for your favorite TV show right before or right after its daily or weekly showtime... assuming that such a time means anything, since the Big Name shows probably show at different times in different time zones (not just offset hours by n-many hours due to an n-many zone offset, but also switched around some relative to local schedules and other shows' local popularity, and marketing).
  Caveat:  Let's say that you live (well, no, it doesn't matter where you live — say that your readership lives) in Australia and you write for some absolutely enormous fandom there, but for some reason no one else in any time zone in the world outside of Australia's several time zones reads it.  Then even assuming that one could say with assurance that “the best time for any nightly TV show's fanfics is always time such-and-such w.r.t. local time zone X” for a given fandom, the fics that you write for that fandom would do best at that local time, but the fics that you write for some fandom that's big only in the UK or only in Brazil, etc., would need to be uploaded at that time w.r.t. their local time zones.  Bit of a pain, even if it were worth it.

As far as I can tell (as I've noted elsewhere, but it seems to bear repeating here), AO3 traffic in general (which might not reflect your own fics' readership in the least) seems to be mostly in accordance with North American time zones' wake/sleep cycle; you'll see my reasoning for this farther down, given the timing of the peaks and troughs of traffic, but it's backed up a little by AO3's country percents partial data of 2Q15 of the incomplete list totaling {22,788 hits, 86.7(-)% being US+CAN+BRA at 17,500+2,010+237} and indirectly by FFN's U.S.-majority of its readership's IP addresses (from what I've seen in Sunday Stats posts in Facebook groups, and the IP address basis is my own assumption, since my essentially-never-used FFN profile doesn't seem to have an entry for one's country, but if correct, it's unlikely that any significant percentage of readers are spoofing their addresses).

I don't know if you can use the data in any useful way in order to increase your Hit rate, and/or your {Kudos/ Hit, Comments/Hit, and/or Bookmarks/Hit} ratios, though I suppose that it's plausible (it would seem so at first thought, then not so much on second thought, but not exactly out of the question upon further reflection), but if nothing else, then the data herein should at least satisfy your idle curiosity and any burning question regarding the basic background reader and writer/author traffic patterns for AO3 overall.  How well any specific {fandom, crossover, tags, ratings, archive warnings, categories, tropes, genres, characters, 'ships, squicks, language [maybe], etc.} (and all of this is aside from one's {title and summary wording, style, catchiness, etc. — perhaps even work skin special effects, or recc.s and interaction on social media platforms}) might match this is anyone's guess, and surely varies wildly from one to another, but by the nature of averages, it's safe to assume that they'll follow similar distributions for the most part, with what would be glaring outliers if we had the data to compare and contrast.
  Good luck, and I hope that this proves to be of some use to you. ❤️

  Top of Preamble section  ↑

 

 

Building it:  ^{Contents ↑}

  “Ook,” said the Librarian.

NB:  Unless otherwise stated for any specific instance, all times are in Central.  That means, for example, that Nov-Mar (northern hemisphere's winter) CST 15:01 = UTC 21:01 and that Mar-Nov (northern hemisphere's spring-summer-fall/autumn) CDT 15:01 = 20:01.  I live in central time, so I record my data relative to what time it is for me.  You might live anywhere in the world, so my converting it to UTC wouldn't do you any more good than my leaving it as-is or converting it to any other time zone, since for ~23/24 (95.83̅%) time zones in the world (plus a few anomalies), you'd then still have to convert UTC (instead of CDT/CST) to your time zone.  To make it easy, here's a set of online time converters that you can pick from (instead of directing you to just one that could always cease existing): time zone converter online.

Before diving into the tables, let's cover how the data were obtained and how the values below were then derived.  Sometimes grokking a result is done more easily through grokking the process that arrived there.

I started this year-long study on 08 Mar 2023, but basically jumped into it, adjusting things as I went.  That began with the reasonably obvious choice of how many uploads occur per half hour (since I was already checking my own fics' data every half hour in any event, this seemed like as good a period as any).  Over time, it dawned on me that there were other variables that I could check, and that these might bolster the conclusions greatly (and there were some surprises along the way, of course).

The variables are listed below in order of when I began tracking each one.  I chose not to go a full 366 days on the later ones because the 1Q-2Q period is pretty dead when looking at publicly available graphs of pages served per day and so presumably wouldn't add much value to the data that would be already obtained by then (though in looking at the graphed slopes of the actual collected data... Boots On The Ground Trumped Intel (seemingly), and the old axiom of The Map Is Not The Territory proved out once more in the known 1Q/2Q-dip of pages served [that are generally bandied about re. overall traffic, which seems in retrospect more of a general server-thing than a metric of use to readers or writers] wasn't then paralleled by the clearly smooth slopes of the searched variables relevant here, so maybe I should've stuck it out, but then it'd be 2 further months of sleeplessness and the OCD-maddening issue of having extra data from the head of the curve).  The number of days counted below include the first [full] day of data and last [full] day of data for each variable, such that had I started at some time on some day and gone for exactly 48 hours to that same time two days hence, then that would be 2 days of data and 1 day of the slope of change (so: in all cases, I end on 07 Mar, but not at the start of 07 Mar, instead going all the way through that and ending at the half hour that would have begun my 08 Mar data) — note that, as such, this means that while the collected 04:01 end-of-day values span however many days as are listed below, the derived instantaneous slopes (dx/dt) necessarily involve one day fewer (i.e.: a span of one single day alone is just a scalar; you need two [or more] to take the derivative(s)).
  When you get to the Results tables & graphs section, you'll note that the raw totals' slopes are exceedingly smooth.  That didn't drive my stopping with the later-begun variables, it only indicates that the trends over the respective spans were extremely stable (leading me to conclude that having continued instead wouldn't have added value to the results).

1. Uploads 08 Mar 2023 → 07 Mar 2024 = 366d
2. My works' upticks 22 Mar 2023 → 07 Mar 2024 = 352d of 48/7
     Full 366 of 04:01 values used for the daily tally graphs
     (cf. subsection on your stats page [in my reader traffic flow tutorial])
3. Bookmarks 15 May 2023 → 07 Mar 2024 = 298d
4. Comments >0 18 May 2023 → 07 Mar 2024 = 295d
5. Hits >0 18 May 2023 → 07 Mar 2024 = 295d
6. Kudos >0 18 May 2023 → 07 Mar 2024 = 295d

Every half hour, I refreshed the relevant pages at xx:01:01 (exact seconds I didn't try to worry about, other than to do so the second that the alarm went off: at this level, the noise would be louder than the signal).  This cycle typically took ~5 seconds to go through all 6 pages.  Initially I had ordered them by which ones seemed to be a sensible starting point (Uploads before Hits, Hits before Kudos and Comments, Bookmarks after these, and last my own upticks since those weren't volatile 'til xx:15), but some of the values were too similar, and I failed to notice when pasting that the CTRL-C hadn't copied that variable, which sometimes meant that it was too late to correct by the time that I noticed and had to throw out that datum, so I shifted to alternating the columns by dissimilar values.  I also found that the Bookmarks were the slowest to respond, so I just began with that tab in order to resolve the data within the briefest span of time (for greatest consistency).
  Just to be clear: while the search results for [visible] bookmarks is definitely a volatile number that climbs (or drops) every minute (or, frankly, every single time that you refresh, back-to-back, separated by mere seconds), as is the number of [visible] works that can be searched for, and one's own statistics page is stable for the first 15 minutes of every half hour, the comments, hits, and Kudos values are more metastable — that is, they do change their values throughout every half hour span without some 15 minute reprieve, but they're liable to show blocks of a few minutes at a time where the values remain constant... and then they go nuts climbing rapidly with every refresh during xx:29 and xx:59; this means that I could have, in principle, kept the values that I got when I screwed up and didn't refresh 'til xx:32 or xx:52, and still have gotten reasonably accurate results that might have been the same values one minute earlier, or had been different by ±5 or ±10 (but since I couldn't guarantee their being the same, the added variation struck me as unnecessary noise that I'd rather not pile onto the already fluctuating value of the one minute window that I sought).
  An example is shown below — sorry for this one being lousy low-res, and not really much point in zooming, other than a slightly clearer view of a basically irrelevant example of color-coded changes with fuzzy timestamps; it happens with Pinterest when there's too much white space (I think that they de-res it, but might be wrong), and possibly with the aspect ratio (if you know a reliable and free image host that doesn't screw up the images and is easy to work with the embedding URLs for AO3 and doesn't have any TOS against that, then please let me know); the later pics are better though, and this one isn't an important one:

Example of variables' values' fluctuations over the course of 3 hours (zoom).
* Firefox users:  sorry for the previous format; I hadn't realized 'til 08 May 2025 that figcaption, which works on AO3 in Chrome, was borked in FF.

Since I was doing a full 48 half-hour cycle all day every day, the start and end times didn't matter as such, so I continued with each day's data beginning at 04:31 Central time simply because I was already in this habit from my own fics' daily data collecting, which serendipitously seems to be almost the least active [i.e.: least volatile] time.  I then plunked that half hour's value into the next cell in the column and subtracted the previous half hour's value from that in order to obtain the amount of difference (KEY POINT THERE).  That gave me the source data from which to derive the mean average changes of each half hour of the day.  I made a separate spreadsheet page for each variable, to keep it simple and manageable (and aside from crashes... OpenOffice not being the most stable program sometimes... it went well enough and the whole thing ended up weighing in at 4,070.6 KB after all of the data had been collected — and these pages were in addition to a few others for tracking other things).

I'd give you an unnecessarily long and detailed song and dance here about manually entering data so that it's not counted in the mean averages and =count( of numeric cells (for my own reference, I entered things like “[~123]” for a value of 123 that was a minute or more late, “?” if I missed an entry, and “[123]” for the average of some missed span(s) and the next known half-hourly value — sometimes the site was DDoS'd or Cloudflare was having a conniption, or my ISP was refreshing my router at ~4 AM, or I slept through an alarm, etc.), and then trying (but failing) to work out a way to count how many of which type of error were present, but at the end of the day the only thing that matters is having gotten enough data points to work with.

The percentages (more the mean averages [since these include weird spikes that are bound to happen] than those of the TRIMMEAN [which I set to ignore the 20% head and 20% tail of values, to home in on the more typical results]) are the key.  The specific average values are irrelevant, as long as the basic traffic pattern is the same (give or take a little due to minor entropic noise in any given year); if these patterns are identical to say, 2013's, then the same basic high and low traffic times will show up, approximately, just with much larger specific values in a given half hour (millions more AO3 users, now, but people still need to eat, sleep, get their mail...).

  Top of Building section  ↑

 

 

Results tables & graphs:  ^{Contents ↑}

  everything, everywhere, all at once

So, at the end of the day, here are the tables.  The bottom line, though, is that while they might reasonably reflect pretty much the same as the full traffic pattern, you should keep in mind that they look only at how many fics' Bookmarks / Comments / Hits / Kudos went from zero to ANY non-zero amount (and any drops of the number of fics for a given variable, of course) per half hour, not at the raw numbers of how many bookmarks/etc. there are (that's a different can of worms):

• it doesn't matter by how much, only that they became >1 (the only ones that I can vouch for are my own fics' total Hits uptick, regardless of how many they have from one half hour to the next);
• even if there's essentially no significant caching delay (which would move the pattern backward to some extent), these still don't reflect how many new upticks of these variables occurred to all fics.
• It could be that a ton of fics jump from 1 or 2 to 20 or 200 in the next half hour (which would move the pattern forward a bit), but I can't know that.
• I also don't know if these numbers change when fics are moved into or out of Unrevealed Collections (which might not actually affect the net visible total fics that I count as total uploaded fics, I know only that the works [testing HTML and CSS within AO3's limitations, and keeping a semi-blank template ever ready to use for each new chapter / fic / tutorial / etc.] that I keep in my own Unrevealed Collection don't count toward the total works on my Statistics page, though if a ton of fics were to be deleted, then that might affect things — though [also] to be fair, my results might actually be ballpark-right, if one considers destinationtoast's Fandom Stats page's AO3 works posted .csvs, which show Sep 2017's daily uploads at around +2,000 to +4,000, with the stats going back to 2008, where things like the ~6000-10K works being updated per day and ~7000-12K chapters added per day show data that I can't search out).
• Note, however, that AO3 reached 11M net [search-ably visible] works on 03 May 2023 at 06:05:~58.
    I gave a summary of how the numbers differ when logged-in vs. the ~92% visible results of logged-out (yes: when logged-out, you're missing ~8% of things).
    AO3's 23 Apr 2023 Twitter (10:42) and Tumblr (10:47) official announcements were made 9 days 19 hours ~15 minutes before that (which I take to mean that they're understandably counting all works, to include Admin Mode's God-level super-ability to see more-complete black-box numbers that I can't see [hence my constant attention-to-detail use of the terms “net” and “public” and “visible”] in unrevealed collections and possibly drafts.
    Curiously enough though, these were themselves preceded distinctly earlier by Wayback-saves showing AO3's front page fic count topping 11M on 22 Apr 2023 N.L.T. Wayback's [UTC] timestamp in the URL showing 21:23:04's exactly 11,000,000 gross count works [the next-most-recent Wayback-save was ~24.5 hours earlier with 21 Apr 20:56:24's 10,990,000]; this is the earliest record of 11M that I know of, and at that time the net count that I got was CDT 16:01's 10,954,734.  When the 11M was actually reached or even first displayed on the logged-out frontpage, I don't know, but that's the earliest Wayback-save with that count or higher, and the count could, in principle, have been reached at any time before the 22 Apr Wayback-save.  06-08 Jun 2023, I compared the total works count increases of the logged-in and logged-out values for a couple of days.  The logged-in count was a bit bumpy as usual, but went up at the usual overall rate; the logged-out count remained steady at 11,210,000 until flipping straight to 11,220,000 (though the logged-out search count of all variables — including total works — stayed a given value for an hour before diminishing with {Upl, Kd, Cmt, Ht, & Bm} averaging {-249(-), -254(+), -206(-), & -253(-), and -7,686(-)} per hour).  Shortly after uploading this meta, I again compared the logged-in total works search count with the logged-out frontpage value 31 Mar through 02 Apr and the same behavior occurred.  Comparing the numbers of Jun with those of Apr, they showed a mean average increase of 5,010(-) new uploads per day in the logged-in search result count vs. 5092(-) on the logged-out frontpage, over a span of 300.5 days.  The Jun case I had checked every half hour, so can only say it went up +10K between 10:31 and 11:01; the Apr case I was checking every couple of minutes and can guarantee went up +10K at 22:44:36-22:45:06.  Since I had missed the exact time of the 01 Apr update, I know that to only a span of three hours (00:01:13-03:00:14 CDT), hence whether the frontpage only coincidentally updated on 02 Apr 12 hours after the time of day that it had on 08 Jun (22:45 [+6s or -24s] vs. 10:45 [+16m or -14m]) or it does so at xx:15 and xx:45 or every 15 minutes or every 10 (but offset from the hour by 5) or every 5 or the very minute that its source reflects the next 10K value I'd have to test further to say.  The observation here isn't when the frontpage updates though, but that the difference between the two is increasing: ~5,010 vs. ~5,092 per day means that they're not looking at the exact same total set of works: the logged-out frontpage accounted for ~24,635 more works in that time than the logged-in search results.
    Bottom line: unless AO3 misquoted something, that ~10,949,338 net visible works count was 99.54(-)% of their first recorded 11M gross (i.e.: a 0.46(+)% search results deficit at that time), or more simply a raw count difference of 50,662 — and as a lower limit to whenever the number changed, the 10,944,454 net visible works count is 99.59(-)% of their next-most-recent-recorded 10.99M gross (i.e.: a 0.41(+)% search results deficit at that time), or more simply a raw count difference of 45,546; as of the Apr numbers, the logged-in works search's net visible count is 99.32(+)% of the logged-out frontpage's gross, for a 0.68(-)% deficit, or a raw count difference of 76,587.  Non-zero in either case, true, but relatively trivial enough not to really fuss over unless you really want total accuracy; the net visible counts are accurate enough for the basic purpose of looking at the overall traffic.
• How many Kudos or Comments are real vs. 'bot, I don't know, though the fake kudos won't be removed (OTOH, comments that get deleted do affect things, as do cases where sock puppet gaming is detected with fics' kudos counts).

I can say that all of AO3's total pages served per day (which surely includes dozens of pages served every time that someone makes one little edit after another, and might(?) plausibly include popup alerts and downloads and reasonably include AO3 news and Admin Posts, and presumably every error page thrown, and surely every single [served] page of search results and edited searches and re-sorting the results, and obviously every refresh click; I don't know about back-buttons, except if one let the tab go to sleep and it had to refresh without a cache — there are several raw data sources straight from AO3 linked in the previous meta's bibliography though, if you want to see their total pages' stat.s) are way the hell more than the meager numbers that I see in the day-to-day increase to the daily tallies of searched Hits results (as quoted, for example, per a Tumblr thread re. the infamously-misconstrued-Minecraft-streamer-rpf-fic-update-41K-Twitter-follower-crash of New Year 2021:

“[AO3] saw a total of 65.6 million page views on Sunday, January 3rd, which was a new record. That's an average of 2.73 million pages served every hour (more at peak times, less when a majority of users are asleep), or 45,555 pages per minute, or 759 pages per second.”

— and similarly, 2020 showed daily rates of ~35-~60M pages, and 2021 ~60-70M [with a Dec spike ~75M]... so yeah: pages served is magnitudes greater than hits, hence not the same variable — in fact, when you get to the graphs, you'll find that 2020's ~35-~60M and 2021's ~60-70M daily rates are magnitudes greater than even this 2023/2024 analysis's entire combined daily averages of Bm+Up+Cm+Ht+Kd = 162,740(+)/d).

 

Below, we see the entire set of variables' paired columns of [mean] average and TRIMMEAN half-hourly AO3 traffic at a glance (with my own works' Upticks present only for comparison and contrast in order to give you some idea of more-or-less how much variance you might expect to see in anyone's incoming traffic vs. the overall background AO3 traffic [though honestly, you can see in my tutorial on analyzing one's own reader-traffic flow that the peak-and-trough days when actively uploading {four paragraphs into that subsection} don't differ much from when spending a year not uploading {four more paragraphs below that}]), with the cells of this first set calculated with source-data-cells that matched the CST/CDT time that they came in (i.e.: pretending that every single AO3 person uses the idiotic daylight savings garbage... I didn't adjust the source-data entry for November's change of summer's daylight savings time to winter's standard time [04:01 = my clock's 04:01, 23:31 = my clock's 23:31, regardless] or vice versa in March — all times listed are in CENTRAL time [and technically one minute later than written in the columns], and the days in these pictures, by quirk of TL;DR reasons, ended up with their tallies and 24-hour-increases being taken at 04:01 [hence each next new day's numbers beginning at 04:31]).
  As with the previous meta (on looking at one's own fics' reader traffic), the heatmap coloring is backward from the norm.  Blue here is high activity, red low.  That's simply because I associate blue's high frequency and red's low with the high and low numbers, rather than the usual red being hot and blue not (which actually makes zero sense if one looks at temperatures and spectra...).  To quote So long, and thanks for all the fish : “We apologize for the inconvenience”. 😉
  Sometimes the numbers look a little skewed, but they make sense after a moment: Hits>0 is the number of works with >0 hits, not total-hits-full-stop (and pages served incl. others for edits, searches, etc.); there are ~5K Hits per day (for what constitutes a hit, which has varied a little over the years), but ~144K new bookmarks per day, which sounds way out of kilter (~144K bookmarks = 28.8 * ~5K hits) but is presumably because one needn't enter a fic in order to bookmark it — one can browse through someone's profile's bookmarks or the bookmarks in a collection and save a copy to one's own bookmarks, for example.
  The pale yellow column on the left hand side of each variable's table lists the number of [counted] samples (i.e.: the sample size) for each half hour's row (these were counted automatically: I didn't count any values that I got that weren't on time, writing those within brackets [just for my own reference] instead of as raw numbers, so the =count function didn't count those).
  At the bottom of the average half hours, I did include a few averages of the averaging column partly to see what the average half hour itself would be, and partly as a sanity check w.r.t. taking the average of the days' tallies (bump one against the other to see if they're in the same ballpark; if they're not, then something went wrong).  You can ignore the non-functional geometric and harmonic means though: they really aren't appropriate to this, just my having fun playing with them (and the zeroes in the set meant too much fiddling to fix them).

If one considers US East Coast, Central, Mountain, and Pacific, then these times (a bit spread out) make sense.  For whatever it might be worth, this might be backed up some by AO3's slight-but-visible traffic dip from ~45k throughput to ~40k as New Year 2020/2021 arrived (05:00 UTC = 00:00 midnight EST East Coast).

 

Here we see the same again, except this time pretending that absolutely nobody at all anywhere on AO3 observes daylight savings (I can't say how many actually do or don't, hence my presenting both extrema; either they all do, or they all don't, or it's a bit of a mix, and though I don't know the ratio, it's a good bet that it's a mix [though only a vanishing probability of 50/50] — plus it affects 1/3 of the year, shifting things back and forth by only one hour [which, granted, could be a key hour for some fandom or something]), by referring to their normal source-data cells in the CST columns and referring to those of one hour earlier in the CDT columns:

 

This time, let's look at the individual days' half-hourly fluctuations (pretending that everyone does observe daylight savings — that set above is the only one that I bothered with the nobody-does-daylight-savings, for demonstration purposes); this first set is the mean averages only, no trimming of outliers:

 

Individual days' half-hourly fluctuations again (still pretending that everyone does observe daylight savings, for simplicity), this time using TRIM averages (ignoring the highest 20% and lowest 20% of values, taking the average of only the central 60%):

 

And just for funsies, how does each day (as a whole) compare to the rest of the days of the week?  Let's see:

Each variable's weekly AO3 wave of days (zoom).

 

What does it all amount to, per month?  Here's the amount that each variable increases by; we'll get to the raw totals in a moment, as well as some fun graphs:

 

So, the graphs.  The first two sets don't differ much, being just a mean average set and then the complementing trim average set, but I have them, and you might enjoy them or find something useful in them, so here's the first set for you:

 

...and the second set, the TRIM averages (don't worry, the next two sets after this are reasonably juicy, I promise):

 

This is where it begins to get kind of interesting.  The graphs in this set are jagged as hell, but you can get some sense of things from them.  They show the count of how many more insert-variable-here there are from one day to the next, per the 04:01 central recording of the respective value.  They're broadly stable: maybe 14K more bookmarks shown per day (I say “shown” because that could be 14K new bookmarks, or 6K deleted or turned into private bookmarks [from public status before that] and 20K new, or who knows what — and similar reasoning applies to the other searchable variables).  But if you look at {Comments, Hits, Kudos, and Uploads}, then you'll see some activity jumps; I can't say if the upload rate was causal to the others, or if all correlated because of everyone having time off of work / some new movie / various holiday spirits etc., or what, and so I can't say with any certainty that the same would be seen in prior years, but look: first week of October, very end of October, two peaks at the end of December and a third that looks like the beginning of January, and one more right around 10-15 Feb?  Uh-huh...

 

Now for the pièce de résistance, at least as far as this subsection is concerned.  The set below shows all of the recorded 04:01 raw values and their slopes for all variables.  The visuals are misleading, so I've included their slopes explicitly:

It's tempting to look at the raw totals or their slopes and say that the average ratio of one metric to another is such-and-such and therefore the expected value for any given work at random is the same, but don't give in: you'd be comparing apples and orangutans.  Yes, the ratio of one to another is such-and-such (at the moment), but that's across every single [publicly visible] work on all of AO3.  Some of these have had 10+ years to accumulate hits and comments and kudos and bookmarks, others are newer but in hugely popular fandoms with now-millions of potential readers, and sometimes it's just the [good/bad] luck of the draw (and the good/bad luck or general background interest could suddenly reverse at any point, whether tomorrow or a year down the line).
  For example, that comment:hits ratio (which could be a zillion fics with no comments and one single fic with a zillion comments, mind you) is probably “worse” than 3.9(+) comments per 5.0(+) new uploads because while they could be going to either new fics or old fics only, they're definitely going to a few of each, which makes the whole comparing thing one more step removed from reality.
  The ratio is slightly better-looking for hits:uploads at 5.05(-):5.01(+), but that same caveat applies here in that the hits are definitely split with some going to new fics and some to old, so it's certainly less than 5.05(+) as such (though how much/little less I don't know — someone could, in principle take a data-dump, day after day, of all of AO3's stats [complete with the upload dates and every single update date] and run a monster program to watch the uptick of every variable of every fic, I guess, but that'd be the only way to be sure of the [still incomparable for numerous other reasons] ratios).
  With somewhere in the area of 12M works on AO3 (more or less, depending upon when you read this, and ignoring how many are public vs. in concealed collections, etc.), and positing one new comment plus one author-reply (ignoring how many comments might not get replies, or how many are actually a thread of a dozen comments and replies back and forth on a single work), that's basically ~2,000 new comments (a bit less, yes, and assuming a balance of author replies) spread out across ~12M fics (where ~5K new works in a day is a tiny portion thereof) = ~2K/~12M = ~2/~2K ≈ 1 new comment per day per 1,000 [new or old] works (so... if you have 100 works and get 1 single comment in toto per 10 days [~3 per month], then you're more or less getting the average; change any of these up or down by ~10x, and it's reasonable to say that you're getting unusually high or low rates [depending upon which value you change, and pretending that all fandoms, tags, etc. see absolutely average numbers... which they definitely don't]).  That same logic is why any given ratio of one variable to another is way beyond a simple at-a-glance comparison — it could be done, but you'd need heavy duty statistical analytic tools (and presumably access to AO3's no-shit source numbers) and they'd need to be applied by an actual statistician to hopefully avoid fallacies and misapplications (and it's been 18-19 years since I took stats, so...).

 

  Top of Results section  ↑

 

 

Verbose mode:  ^{Contents ↑}

 ►▒
 
 ►_v
Maximum verbosity.
 
 ►_
 

 

“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair....”
  — Charles Dickens
  A tale of two cities
 

So, all of those tables give you a quick clue.  The rest of this is just talk.  Can you use the tables (the average half-hourly traffic overall, the average half-hourly per specific day, and/or the average day of the week) to figure out the “best time” to upload and/or “best day” to upload?  No, not really, I don't think (at best, you can take them as an indicator of when you might typically expect high and low traffic rates to hit your works, over time) — but I could be wrong, so have at it and have fun!  To the extent that it might matter at all, I think that ocalhoun had the right idea: you want the least competition and the most readers, which is probably(?) after the upload rate peters off some, but before the Hits really start rising.  (But does it actually matter, fundamentally, beyond some initial extra traction gained or lost, when a week, a month, a year, or a decade down the line, people will still read it at whatever frequency of hits they read it, and the exact time and date/day of its initial upload will be just a blip in their rearview mirror?)

And... that's where we start getting into something of a grey area.  I ran these searches, yes, but what are they, precisely?  Aside from seeing them suddenly lose hundreds of instances in a half hour refresh (many times), I don't even know their fundamental nature — are they absolutely all of the data on AO3, or do they exclude those fics that are in Unrevealed Collections, and do they presumably drop when hundreds of fics are deleted in a given half hour span?  What about the time of the data — are the numbers about as fresh as possible in fact, or do they cache every few minutes, or is there a redundancy factor of several caches deep (to reduce risk of data loss or other reasons), and if they're cached then do the caches have a set amount of time delay to the results seen or is it a bit of a dice roll, and if it's a dice roll then how much variance do they display, and is it pretty much the same for all searches' servers or do different searches query different servers and hence have different cache update delays (as is the case for one's own fics' statistics page, where the Hits sometimes update 30-60 minutes later than the Kudos, which I've seen several times when friends were reading my stuff on AO3 while also chatting with me on FB IM, and so I knew precisely when they opened things etc. vs. the data updates on my stats page — though since I have my settings set to e-mail me when a new comment comes in, I can attest to the Comments count going up when the next refresh comes, rather than delayed; Bookmarks I don't know)?

That whole paragraph calls into question just how reliable the timing of the traffic averages is, but at least it sets some limit to the possible cache delays from my much smaller data set of direct and measurable experiences.  The data that the tables draw from are probably fairly accurate, with Hits' updates having some non-zero delay at least some of the time (how often I don't know), which means that the actual overall average peaks and troughs of Hits might occur slightly earlier than the tables indicate (I'd say probably only a few minutes, rather than 30-60).

I have another 4,261 words about specific observations about all of the holidays (plus another ~5K of other narration and outline)... but I won't.  Maybe I'll add a bit of that if there's some diamond in the rough there, but I'm pretty sure that I was just going stir-crazy at that point (and having said that, we went from 7,188 total words upon posting to 8,133 [8,155 now] within 12 hours).  All that it amounts to (aside from something that I might be forgetting) is that some days had surprisingly large or small or erratic numbers (normally, you'll see the numbers climb almost-steadily, a little faster or slower at moments, but only jerky; in this case though, we're talking about sporadically sprinkled days [one here, half a dozen or more there] where shit started jumping up and down every single half hour that I checked [usually only the uploads, comments, hits, and kudos though; only a few times did the bookmarks drop as low as a few hundred or into the negatives], including plenty of negative slopes — severe cache thrash, maybe?), and probably a small joke or two tossed in.
  The one random fact that seems interesting enough to mention is that Bookmark searches' numbers aren't exactly on what you'd call a one-to-one with the ID number of the most recent n^th bookmark created: on 02 Mar 2024 I bookmarked something (a jumpchain-like BtVS fic; I say “-like” because it involves sliding, but controlled, though the author does have a cool jumpchain-fic too); that bookmark's ID, as you'll note, is 1,617,834,580.  That occurred at 08:10:46.  The half-hourly AO3 data checks were 08:01:12 and 08:31:11.  Their values were 284,996,375 and 284,999,183, respectively — that ID number is ~5.68(-) times the size of the Bookmark Search value of that whole half hour's start and end values; maybe people delete a lot of bookmarks (and accounts with bookmarks-to-read in them and/or on those accounts' works), maybe it indicates ~4.68(-) private bookmarks per public bookmark (and since even my fonts tutorial, totally not an embarrassing subject or rating, is at 54% publicly bookmarked out of 935 currently...), and/or bookmark ID numbers are assigned with skips (much as with account ID numbers).  Long story short, I started down another ADHD rabbit-hole, but stopped almost immediately upon finding that the numbers would prove intractable (...the one teency weency little fly in this ointment, preventing my truly trusting the AO3 data), based upon the known bookmarks in toto and the public of my two most-bookmarked works and subtracting to find the remaining public and private totals (how the hell do you get a remainder of -11, especially in light of other works definitely being bookmarked?!?):

Showing the negative 11 remainder
(zoom)
* Firefox users:  sorry for the previous format; I hadn't realized 'til 08 May 2025 that figcaption, which works on AO3 in Chrome, was borked in FF.

  The 4^th of July and Hallowe'en and Turkey Day (whether Canadian or American) were all quiet on the — ahem — “Westron” front (c'mon, I know that it's a groaner, but ya gotta gimme credit for that one — we're talking about fanfic traffic rates, here, and at least I stuck with a Tolkien language the name of which fits better alliteratively than the geographically more appropriate option of GRRM's Westeros!).  The others I can get, but... Hallowe'en ?!?  No, don't go and say “Well, everyone just shifted focus is all...” without giving it a moment of thought first; yes, I'm certain that if we were to deep-dive into the tagged fics uploaded at certain times of the year, then we'd see a percentile shift from tag-A to tag-B, etc., but that doesn't explain why there was no particular total traffic volume surge of increase (or decrease) writ large for a few weeks there.
  Ditto for the definite Christmas / New Year and Valentine's spikes: those spiked for a couple of days, but no real ramp-up (nor ramp-down).
  Then there are a few tabs in my spreadsheet with... more words (10,399 in general, including an abortive study of how many fics have {>1, >10, >100, >1K, ...} kudos, comments, etc., over a six month span, complete with screenshot-able tables).  Basically a bunch of my bitching and griping about putzes writing huge ephemeral GIGO (e.g.: multi-hundred-K repetitions of “Such-and-such-character will [live/die]” spanning about 10-12 fandoms as a toxic meme, or 1M repetitions of the name “Rody”... and this is why we can't have nice things, guys...), and some unrelated details about my having been struck by

 The AO3 Curse 

(yes, it struck a few times this year, with my router dying, the brand new router being broken before I bought it, a tornado hit nearby, my car's power steering died [and there was a wobbly hub, and it needed a new tie rod], my 'phone mic. died [and when the repairmen fixed it, the screen's haptic sensor “coincidentally” developed a strip of lost sensitivity {and upon re-reading that, Strip of Lost Sensitivity sounds like a gauche 3.x D&D wizard spell [or worse: necromancer?] out of Encyclopaedia Arcane Nymphology [blue magic], or a few similar third party books — Book of E. Fant. and Book of C. Knowl., I'm looking at you}...], and a bunch of nitnoid nuisance-level issues; such is life, no?).

There are a few unrelated programs that I would love to yammer about, but I'll stick to the point instead: if you ever make the mistake of undertaking some damned-fool's errand like this one, and your browser is dumbed-down by some exec's idiotic design choice (hint: they show you only your most recent visit to any specific URL, and they don't list the seconds, only hour and minute), then do yourself a huge favor and look into something that will actually show you the URLs and timestamps that your browser skips for streamlining.  I needed NirSoft's [freeware ] MZHistoryView, ChromeHistoryView, and BrowsingHistoryView (though you do have to refresh the utility to see new timestamps of newly opened or refreshed webpages, and for the purpose here of checking only the AO3 variables' search-page times, I gave the utility the terms {Bquery, Bhits, hits&, Bbookmarkable, Bbookmarks, tag_search}, minus the braces [the Bbookmarkable term is there only if one wishes to see when one last checked one's own fics' bookmarks by others], and it does give some other variables [irrelevant to my purposes here] such as visit count, referrer, visit duration [to the millisecond], though which variables and {the sequence of which page in a set is presented first} and whether the history file is listed varies a bit in layout from one utility to the next) — most of the stupid extensions available just pull up the browser's regular history and expect you to thank them for it, but these pull straight from the .dat file (I think, based upon its deeper dive than the browsers' native history presentation and the slightly telling fact that inspecting a URL property in the utility program will show the History File source's file path as C:\Users\Your_Computer-User_Name\AppData\Local\Google\Chrome\User Data\Default\History or C:\Users\Your_Computer-User_Name\AppData\Roaming\Mozilla\Firefox\Profiles\alphanumeric_gibberish.default-release\places.sqlite [this Firefox History File path being an example of something showing up in the multi-browser BrowsingHistoryView utility and not in the Firefox-specific MZHistoryView utility, though each of the three utilities shows some things that the others don't, and some items are merely named differently]) and permitted me to check everything in all of my Firefox history [for this device only, not previous devices; I don't know if it could show across synched devices], and everything in the most recent 90 days of Chrome (that seems to be an actual case of data tossed out the window, rather than simply not retrieved — though there's a longer history-search available through the slow My Activity).  Don't fool yourself into thinking that your browser wouldn't do that just because it's a different make: many different browsers use the same core structure.  NirSoft is an older name, for those who haven't run into them, but if you're concerned, you can always bump any given file or URL against VirusTotal which submits them to 79 online malware scanners simultaneously for files and 96 for URLs (though if you're actually concerned, then you wouldn't click that link either, instead doing your own research for safety purposes: trust no one — not me, nor anyone else, even if for no other reason than that a webpage or AO3 account or your own browser could be compromised and the links go instead to a cloned site [or a bunch of other potential mal-hacks]).
  CAVEAT:  With all of that said, your Firefox local data will stick around for more than 90 days, sure, but if you swap out to a new computer because your old one is just about to die, then the old one's data won't be available to you anymore (unless one were to copy the profile to the new computer, I suppose)... ask me how I know (says the me of Mar 2025, after having to replace my old computer...).
  dy/dx of caveat, 06 May 2025:  I noticed on the 28^th that Firefox suddenly had history only as far back as 21 Apr, but figured that I had accidentally (perhaps in my sleep?) deleted it.  Today though, my history showed only through the 4^th, and it dawned on me that I had restarted the browser about 2 days ago for an update (now on build 138.0.1), coincidentally (and I think that the same applied to the previous history erase).  Hmm...: an update, huh?  My settings were of course set to Remember History (though I checked Custom Settings, just to be sure); going into about:config and searching the history and clearOnShutdown lines for any that looked reasonable to swap from TRUE to FALSE [or vice versa] seems to have fixed that (I restarted and my whole 2 day history was still present... this time) — I'm not an expert, I just poked around, so I can't say whether this would work for you (or even which one(s) that I changed was/were the salient one(s), or if it might go tits-up with the next browser restart [or update] due to my changing a flag value better left as-is; on the other hand, maybe it's an every-other-Monday thing or some other crazy shit [I've seen weirder glitches and defaults]).
  OK, time for me to shut up; I'm beginning to sound like a late night cable TV infomercial combined with an after school special and PSA.
  That said, if you are a script monkey with an interest in AO3 scripts, then check out Dianafortyseven's (Diana47 on AO3) recommendations, along with Flamebyrd's bookmarklets (note the plural) on AO3's Unofficial Browser Tools page — though for numbers-scraping research purposes, cf. Admin Post 25888 and AO3's /robots.txt (esp. the Disallow: /works/search? and Disallow: /bookmarks/search? lines) for more details.  If you're simply looking for some juicy stats info, then you might want to check the bibliography in my tutorial on finding one's own works' reader traffic patterns (that's where it is, but the bibliography goes far afield).

Afterthought, re. counting fics w.r.t. updates that change things (prompted by the whole scripts-thing):
  One could search “7 days ago” (or whatever number) and find the number of fics uploaded/updated in that day's 00:00-23:59 (UTC), and maybe compare it with the day-to-day total count change (I guess to see data on fics that show published dates different from when they actually were published), but that would really need to be scripted.  This study was only looking at half hours' traffic peaks and troughs for overall traffic purposes, not deep-diving into how many works get fore/backdated (or by how much), but I mention it in case anyone else has the scripting know-how (assuming that the relevant pages permit 'bot-scraping) and inclination, but the thought occurred to me, and it's halfway relevant to traffic in tangential way.
  Updated or not only matters in terms of fics going to the top of any given tag's most recent list (whether simply normal upload or update, or someone trying to game things for numbers).  Uploads might be able to determine deletions-and-concealed (which could be slightly useful for the purposes of accurate work counts for any specific UTC date or window of dates), but only if I could exclude “updates” (specifically: if the update were the published-date having been changed) for upload-only numbers (and again: not the focus of this study, so I didn't much pursue this line of reasoning).  Cf. Admin Post 10851 on Hidden Operators; the backdate: false for works that have not been backdated, in the By date section, explains that it's for “going by the day they were originally published (if backdated) or had a chapter added”, implying to me that one can't differentiate uploads vs. updates — though I still tried turning “backdate: false” into “update: false” and “updated: false” in Any Field; no dice.
  Maybe there's a way to see the MySQL timestamp data (and hence use it in the search's Boolean), but it's definitely not in the page source, so one can presumably see it only if one is an Admin (which would probably mean that one could simply use Admin-only operators in some rather more powerful Admin-interface).

 

Final note, re. this meta's layout:  For those of you wondering how to place multiple pictures (which must be hosted elsewhere; I use Pinterest for that, but you might find other places preferable / necessary for one reason or another) side-by-side in a neat array, as with the charts and graphs above (unless something's gone terribly wrong with your display), the secret lies in making a table.  I used three columns, since I wanted the pics in rows of three, and merged the cells of the plaintext to become single-column cells of three columns' width.
  NB:  Some portion of the right side of the tables might cut off.  I've included a scrollbar (OK: scroll bar) at the bottom of them that should appear only if your screen is too narrow to fit the full width of the table, and it should work (site skin, browser, settings, and third party extensions permitting, of course), but if it doesn't work, then please let me know so that I can attempt to adjust the CSS as needed (NB: Firefox barely shows the vertical or horizontal scrollbars until you hover over whichever one.).  For the curious, the CSS work skin rules (not repeated here so as not to add even further unnecessary noise) are included here, in my ConLang walkthrough, beneath another such table appropriately enough (of which there are many different table layouts in that tutorial, and I'm not going to try to explain all of the fancy jazz for those; for that, just check out its page source [and here's how to view page sources]).

Here's the HTML for the tables' layout (yes, the figcaption borks shit in Firefox, but seemingly only for free-floating image captions, not those within tables):

<div align="center" class="scrolldiv">
 <table class="border">
 <tbody>
 <tr>
  <td align="center" colspan="3">Header words describing a set of pics.
  </td>
 </tr>
 <tr>
  <td colspan="3"><small>&nbsp; </small>
  </td>
 </tr>
 <tr>
  <td align="center"><img src="FirstURL.jpg" alt="First image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 1 name (<b><a href="FirstURL.jpg" rel="nofollow">zoom</a></b>).<br />
  First pic's description here</figcaption>
  </td>
  <td align="center"><img src="SecondURL.jpg" alt="Second image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 2 name (<b><a href="SecondURL.jpg" rel="nofollow">zoom</a></b>).<br />
  Second pic's description here</figcaption>
  </td>
  <td align="center"><img src="ThirdURL.jpg" alt="Third image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 3 name (<b><a href="ThirdURL.jpg" rel="nofollow">zoom</a></b>).<br />
  Third pic's description here</figcaption>
  </td>
 </tr>
 <tr>
  <td colspan="3"><small>&nbsp; </small>
  </td>
 </tr>
 <tr>
  <td align="center"><img src="FourthURL.jpg" alt="Fourth image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 4 name (<b><a href="FourthURL.jpg" rel="nofollow">zoom</a><</b>).<br />
  Fourth pic's description here</figcaption>
  </td>
  <td align="center"><img src="FifthURL.jpg" alt="Fifth image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 5 name (<b><a href="FifthURL.jpg" rel="nofollow">zoom</a></b>).<br />
  Fifth pic's description here</figcaption>
  </td>
  <td align="center"><img src="SixthURL.jpg" alt="Sixth image placeholder alt-text." width="40%" height="auto" /><figcaption align="center">Pic 6 name (<b><a href="SixthURL.jpg" rel="nofollow">zoom</a></b>).<br />
  Sixth pic's description here</figcaption>
  </td>
 </tr>
 <tr>
  <td colspan="3"><small>&nbsp; </small>
  </td>
 </tr>
 </tbody>
 </table>
</div>

...and the CSS work skin rule for a simple border (used here around the sets, but useable around pretty much anything):

#workskin .border {
  border: 1px solid;
  padding: 10px;
}

(and if you don't know how to make a work skin, then just click that link there and it'll walk you through the steps).

  Top of Verbose section  ↑

 

“A year of this, 48/7... oh, what a mistake-a to make-a!”
— Capt. Bertorelli, paraphrased
'Allo 'Allo

Stay shiny, and aim to misbehave!
❤️

 

---

 

Also in this series:

• Part 1 — How to AO3
    (general info. for newb.s, but includes tips and information that years-long veterans often don't know)
• Part 2 — How to make and fix a series on AO3
    (plus unrelated tips re. Wayback, different spaces and dashes, TTS problems)
• Part 3 — Analyzing AO3 reader traffic flow
    (one's own fics' reader traffic)
• Part 4 — A year-long AO3 overall traffic analysis
    (when do people upload, read, comment, kudos, and bookmark?  Reader and new-upload traffic in general, across all of AO3⁠ ⁠)
• Part 5 — Fonts, and colors, and work skins, oh my!
    (change your letters and ink color, see others' work skin secrets, etc.)
• Part 6 — Chess puzzle extravaganza
    (256 randomly selected preconfigured chess puzzles, a new one with every refresh
    [secret message-reveal from BBEG, because of course];
    no JS: just HTML and some CSS)
• Part 7 — Targeting specific AO3 work sections (not site) with CSS effects
    (wanna put some color into your CSS-verboten summary?  Maybe drop an image below your series link, or style your comments section? 😉)
• Part 8 — Inside, Outside, Upside-down
    (a showpiece of fun that one can have with CSS — a challenge puzzle, rather than a tutorial;
    incl. CSS on a single paragraph within the work summary, among other things;
    try to navigate it, work out its little puzzles, and work out how it was all done;
    caution re. volume in ch. 1, and flashing lights on :hover in ch. 2)
• Part 9 — Green Rain font, from The Matrix
    (several ways to drop Green Rain into your background, simulating the digital rain effect)
• Part 10 — Building ConLangs, with a concrete example
    (going about constructing one's own invented language: words, grammar, writing, etc.)

NB:  If the work skin [for this piece or any other] was stripped by downloading, so that you can't see any red ink or yellow highlighting or any other special effect, then please see my fonts tutorial's sub-section on re-inserting rules.