> It devastates most benchmarks, with an average time to first byte (TTFB) of about 0.15s, and fully rendered within 0.5s.
That really isn't that fast, not for your / landing page.
Delivering WordPress in 7kb
41–50 of 59 posts
Re: Delivering WordPress in 7kb
#42Earlier quoted context omitted.
7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets. This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.
I'm trying to make a static website myself. Can you tell me if it's possible to optimize the network side of things? https://waivek.github.io/website/
1) Drop the web font if at all possible. If not, serve it from your domain to avoid DNS query and new TCP connection. For extra points, subset it to your content's character set.
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.
Re: Delivering WordPress in 7kb
#43Earlier quoted context omitted.
7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets. This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.
I'm trying to make a static website myself. Can you tell me if it's possible to optimize the network side of things? https://waivek.github.io/website/
You do five requests for resources that are in total 2 KB. Just inline them (including those tiny images).
Re: Delivering WordPress in 7kb
#44Earlier quoted context omitted.
If one really wanted to, couldn't they eliminate menu access from the user's history?
Yes. You can use replace() instead of push(). 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.
But would people really try to share / bookmark a page that at that very moment doesn't show the content they want to share?
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)
Re: Delivering WordPress in 7kb
#45Earlier quoted context omitted.
It depends on if you're loading from multiple origins (multiple TCP connections), HTTP 1.1 vs 2 (multiplexing, push, HOL blocking), but generally speaking: yes. If you can fit the content needed to render the page in the initial TCP congestion window, the page will be noticeably faster on high-latency connections. This unfortunately means, for most websites, some amount of CSS in a style tag in the head to get a basi…
Thanks for the explanation! 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.
> I didn't know that a single request can actually have multiple round trips!
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).
Re: Delivering WordPress in 7kb
#46Reducing the amount of requests and roundtrips required to render the page, and reducing the latency on those requests is key. 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 round…
> three roundtrips
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.
Re: Delivering WordPress in 7kb
#47I'm fully on board for creating leaner websites and writing less code, but if we're measuring energy usage, then doesn't streaming video pretty much dwarf all other internet traffic? With perhaps blockchain syncs in a distant second place?
if we're measuring energy usage, then doesn't streaming video pretty much dwarf all other internet traffic?
Probably. But just because plastic bags dwarf plastic straws as an environmental problem doesn't mean we can't address both.
Re: Delivering WordPress in 7kb
#48This is a great reminder of what can be done by just “rethinking everything” and saying why do I NEED that plugin, lib, script, font lib etc. one thing not immediately obvious to me was that the responsive menu goes to a new page https://sustywp.com/menu/ and because the site is so fast it actually doesn’t feel like a page load. I haven’t really thought about this but hamburger menus get so complex these days it migh…
I just opened and closed it a few times to try it out. Then I pressed the back button several times to get back here, cycling the menu open and closed again. I'm gonna go with "it's a bad idea".
I don't think opening and closing the menu is a realistic test.
Generally when a user opens the menu they're trying to go to a different page.
Re: Delivering WordPress in 7kb
#49While I mostly agree with the author's diagnosis, the cure proposed is a bit strange. First, it's not WordPress anymore. You could use any other solution then, including popular leaner alternatives. Moreover, the front-end is just a part of the equation. And if you're really focused on creating a realistic proposal, there are many other factors to consider, not just slimming down your blog and making it incompatible…
How is “I took a WP theme designed as a minimalist starting point for building your own theme and cut out a lot of stuff I considered to be cruft” not Wordpress? It’s still WP behind the scenes.
(Maybe you think that Underscores is another CMS? It’s not, it’s a WP theme. https://underscores.me)
Re: Delivering WordPress in 7kb
#50I think this is the wrong way to go about site minimalism. My personal site[0] is pretty minimalist--the home page has one request for 3.3 KB. But it doesn't sacrifice in the same ways this site does: it keeps readable source code, it still uses BEM classes for maintainability, and it has a working menu on the same page (rather than requiring visitors to load a seperate menu page). So, with less than half the kilobyt…
[deleted]