Something about this menu approach feels so clever but wrong at the same time.
So this menu felt very normal to me, but it may be off-putting to newer users of the web who are used to contemporary conventions such as slide-out hamburgers (not to be confused with slider hamburgers :-) ).
I'm gonna go with "it's a bad idea".
Generally when a user opens the menu they're trying to go to a different page.
But there are other issues like bookmarking or sharing the page with the menu open. People won't expect the result.
It's really not difficult to create an on-page menu so this seems more trouble than it's worth.
I think it is a beautiful, simple solution that just works (and also did work perfectly in the past when we didn't have JS)
The most interesting thing I learned is that the number of HTTP requests (not just the total file size) really affected page load times. So for example, WordPress has profile pictures called 'Gravatars' that can be shown alongside comments. By default, your browser will make HTTP requests to fetch all the Gravatars before showing the headline of your post! So we lazy-loaded them instead.
And we used the same plugin shown in this article (Autoptimize) to combine multiple CSS files. You can take this to an extreme by just putting the CSS inline too (but too much markup might make the page slower on mobile).
This plugin also defers all scripts and tries to simulate all the events that occur during a normal pageload so that the scripts still run as they normally do.
So, with less than half the kilobytes, I have a more readable, usable, and maintainable page. How? By jettisoning WordPress and SEO entirely. I use a static site generator (in my case, Gutenberg) to generate the page--no WordPress backend required. And, by respecting my user's privacy and not trying to play the SEO game, I don't need any of the code many sites devote to tracking/SEO.
I believe that static sites and respect for privacy are the better path forward. Instead of tweaking WordPress, we should be looking to build the next WordPress--and build one that is static, and minimalist, by default.
"but the meta stuff added by Yoast bumped it up almost a whole KB! However, given I'm trying to spread a message [it's worth it]"
They would not be transistor radios in the 1930s. Battery radios had valves/tubes in them and two kinds of battery. The picture is a very late 1950s/early 60s transistor radio.
Nice site, interesting content, have you ever come across the British judge Lord Denning? He was a mathematician to begin with then turned to law having decided that teaching was boring.
You of course keep your code readable internally, but what your users get should be minimized and as small as possible, unless your users are there to peak at the source code.
Probably. But just because plastic bags dwarf plastic straws as an environmental problem doesn't mean we can't address both.
I think that there is far more that can be shaved off. The SVG logo can be placed in the CSS as a data url so it only gets downloaded just the once. Currently it is in the file and weighs in at 1.19Kb. If this is drawn with more elegant SVG rather than what Inkscape churns out then it could be easier to edit and a lot smaller. There is no need to use three decimal places for the points and since there are no fonts in the SVG there is no need to bloat it out with any styles.
As well as serving via NGINX there is also mod_pagespeed to remove whitespace, comments and create src_sets for any blog images. In this way a client project based on this theme need not lose all gains as soon as an image is uploaded.
I also think the classless methodology has to be considered as the way to go with a pure document and all decorative chintz done in CSS with pseudo elements and more advanced selectors.
CSS Grid also reduces CSS size significantly and would help here. Block based layouts are fine for people that have been hacking away with margins and floats and padding things since IE6 but are absurd for newcomers to learn. CSS Grid is more maintainable as well as lighter on the download.
Not so sure about the menu being a separate page, a web page should be part of a 'book' and navigation with proper HTML5 markup for it is important for accessibility.
The motivation for this is superb and it is a lot more easy to explain to clients than accessibility. Page speed and conversion rate can be hard enough to get buy in with as it is, going green might be an easier sell.
Removing the main menu (which is very small) while also having twitter meta info in the head and other unnecessary tags is an odd choice.
One slightly amusing thing is that in the web 1.0 era we had menu's as separate pages as our pages were built out of 'frames' and the menu frame simply targeted the main frame. So no we've come full circle again. The more screen real estate I have the more designers intend to put less information in it I've noticed.
This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.
This unfortunately means, for most websites, some amount of CSS in a style tag in the head to get a basic structure of the page together to start rendering. Then you also include a full stylesheet with the high-fidelity version.
I'm leaving out a lot of details here :)
I have done things on my site like inlining CSS and minimizing requests because it feels fast, without knowing exactly why. I didn't know that a single request can actually have multiple round trips!
My WordPress homepage is 2.4kb gzipped and just a single request :) so it is fast but its, uhh, a little boring and only 158 words.
If you load something from a third-party origin (e.g. 23789dz89asd789s.cloudfront.something), then it can actually be a lot worse than that. DNS needs resolving, which can take quite a while, depending on if and where things are cached. Then you get a full TCP handshake (since TFO doesn't work for the first connection), a full TLS handshake and then you get to roundtrip your request(s).
2) Consolidate your CSS and JS files into one per type and minify it. For extra points, inline the critical CSS needed to show the important content of the page directly into the head.
3) Move your script tags to the end of the body to avoid blocking rendering, or inline it if it is absolutely needed to be there before the page loads and is not too big.
4) That web font loader script is not necessary at all.
5) You might get a smaller size out of those buttons as SVG.
For example, you use Google Fonts. For that you need to load CSS. So that's three roundtrips for rendering your page: 1) your page, 2) the Google Fonts CSS, 3) the font files.
We've build a WordPress plugin called PhastPress (fast press) that helps you reduce the request count and those roundtrips without building your own theme. https://wordpress.org/plugins/phastpress/
Among other things, it inlines the critical CSS needed for rendering the page, defers all script loads, and optimizes images. Cuts page size by ½ on the stock theme, and the amount of additional roundtrips to 0.
Well, before we get to the Google Fonts CSS, we first have to open another connection there, do a TLS handshake, and maybe we even need to look that host up first before any of that.
The one "logical" roundtrip (an additional request) would indeed count for many if you consider DNS, TCP and TLS handshakes.
Even more of a reason to get rid of them.
"I would have written a shorter letter, but I did not have the time."
It takes time to make lean sites look good.
(Maybe you think that Underscores is another CMS? It’s not, it’s a WP theme. https://underscores.me)
That really isn't that fast, not for your / landing page.
I guess I was hoping for something more insightful.