Popular posts

More observations -- I had a spare moment and took a look at the waterfall -- you do know that typekit is blocked by just about every JS safety out there, right? ABP, Ghostery, ScriptSafe, it's even blacklisted by anti-anti-adblock's anti-mining list because even though it's from Adobe it isn't considered trustworthy? It's bad enough that on a page using CSR for navigating from a sub-page to the home-page for... well... this:

I'm lucky I'm on fiber, most people I know aren't.

That two dozen of those file requests are blocked and are all for the typekit scripting junk? 56 images on a page that (before lazy loading on infinite scroll) doesn't even have a third that in content images; none of which seem to be caching even though I was just on that page? (I suspect a cache miss due to poor cloudfront management), 22 separate XHR requests when at most it should be doing three, and best case should only need one? (ah, JWT, how we loathe thee when it comes to the impact on load time)

Then this little detail certainly isn't helping:

Many of the image requests are of the same basic monochromatic .png with a minimum of variation in size -- do you really need five separate 1k to 2k .png files for a red exclamation point? Handshaking for nothing and around 30 to 40 of those image requests are UI related, meaning they should 1) already be cached, and 2) really shouldn't even need to be IMG files, that's what using webfonts for vectors are for so you can have a single file request in the ~30k range at the start. One 30k file is more likely to remain cached than 60k spread out over 40 files. With the massive scripting bloat browsers are likely flushing the smaller stuff.

I mean, why is it re-requesting and re-downloading in a complete cache-miss the various thumbs-up / beer / clap icons? That's a problem! Much less since you have a fixed number of those why aren't they leveraging CSS sprites?

So... yeah. Maybe instead of trying to use fancy tools you could just fix the markup using separation of presentation from content (by kicking the framework trash to the curb) and leverage file count reductions better?

Are these emoji images downloaded? They exists on almost any platform as default font as far as I know?

Emil Moe They are indeed static images loaded from a CDN... and yeah, whilst they do appear slightly different across platforms, many of them do indeed exist in UTF-8, and on some platforms with the new colour TTF support do so in colour.

Making all those files even sillier, and outdated in methodology. But even as images using the incorrectly named "CSS Sprites" technique could reduce the number of handshakes speeding page-loads.

I'm more concerned about the fact that even when there isn't a page-load and new content is SSR'd in, they don't seem to be caching locally.

What would your advice for amount of files loading per request be? And the total size with disabled cache?

I remember back in the days the golden rule was 8 SQL queries, but I think that was with MS Access. However it should be sufficient, otherwise async.

Emil Moe

It's actually a bit tricky that -- the file counts -- because the rules are different between http, https, and https with Google's... whatever the hell they called it that turns multiple requests into fewer (or even just one) connection. Gah, what was it called? SPDY? Yup. That's it.

chromium.org/spdy/spdy-whitepaper

That one throws a monkey wrench in the works to a degree as it does multi-requests across a single connection, but requires both browser and server support you can't rely on existing in all UA's... and the best rule of thumb for speed is to target lowest common denominator, not bleeding edge not everyone has. If anything, the bleeding edge folks don't matter because if you make it good enough for the bottom end, it's just fine and dandy if not stellar for the high end!

That said, I try to limit myself to the 1:2:2:6 model. That's 1 HTML file, 2 CSS files, 2 JS files, and 6 presentational images, presentational media, or font files.. That's not counting content images. Things like the social media buttons, site logo, likes, and so forth are not content and as such have no business as IMG, OBJECT, or SVG tags in the HTML.

Content you often just don't have a lot of choice, but that's why you need to keep the template lean so there's room for the content. Kind of like design itself, the best design being one that goes unnoticed as users happily get to the only thing that really matters on a page -- the content!

But again part of why I say a site -- even one as complex as hashnode -- has no real business wasting more than 48k of CSS for the entire site. They're not doing anything to warrant more than that if the starting HTML and the content they CSR in were structured properly. There are very few websites in existence that have any real legitimate reason for more than 48k of CSS in two files (and that's me Mr. Scotting those figures) apart from bad choices in technologies (aka "frameworks") and a general ignorance of how to use HTML and CSS the way they were meant to be used. Same with the Javascript where we see endless "JS for nothing" on sites that would use less bandwidth, load faster, and be easier to maintain if all that garbage were thrown off a cliff into the sea. Who knows, maybe the blood will churn in the foam and turn into something beautiful -- not.

But really, lowest common denominator is plain HTML. If you're making templates for others you should assume that and work from there. If nothing else it will still work better when things like SPDY kicks in as it's less files for it to juggle across connections. It also plays well when people are on connection-starved plans, such as sitting there at Panera bread or Starbucks leeching the web during lunch.

To that end, the common wisdom of figuring out the impact cache-empty is:

first eight files = 500ms every connection past that is 200ms.

That's the "average to best case" range. Sure, we fortunate few sitting on fiber or less than a mile from the backbone might see as little as 30ms for each -- but la-di-dah for US. It's not about "oh it's fast for me" -- it's is it fast for everyone.

(What do you mean everyone?)[youtube.com/watch]

Worst case it ends up a second per file. Yes, that happens. So a page with 68 files can end up taking a minute or more cache-empty first-load.

As to cache full when properly caching, that's a big long topic with one simple answer: The only thing that shouldn't be pre-cached after visiting the first page is HTML and any new content media not already loaded, so move as much of the stuff that doesn't need to be in the HTML -- like presentation and behavior -- out of the HTML.

Which is another of the many reasons that when frameworks do things like this:

    <div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow">
        <h5 class="my-0 mr-md-auto font-weight-normal">Company name</h5>
        <nav class="my-2 my-md-0 mr-md-3">
            <a class="p-2 text-dark" href="#">Features</a>
            <a class="p-2 text-dark" href="#">Enterprise</a>
            <a class="p-2 text-dark" href="#">Support</a>
            <a class="p-2 text-dark" href="#">Pricing</a>
        </nav>
        <a class="btn btn-outline-primary" href="#">Sign up</a>
    </div>

It ends up like they need a stern talking to by Robert Downey Jr's character from Tropic Thunder. Whilst I tend to go R. Lee Ermey on their tuchas'

All those pointless presentational classes defeat the point HTML and CSS are separate, and reek of HTML 3.2 mentality -- proving the people who make and promote this framework idiocy are utterly unqualified to write a single line of HTML, much less tell others how to do so.

A claim only further proven by that H5 and lack of block level separations inside the NAV... but tell me again how good Bootstrap is.

Any competent developer would have written this:

<body>

    <div id="top">
        <h1>Company name</h1>
        <ul id="mainMenu">
            <li><a href="#">Features</a></li>
            <li><a href="#">Enterprise</a></li>
            <li><a href="#">Support</a><li>
            <li><a href="#">Pricing</a></li>
            <li class="signup"><a href="#">Sign Up</a></li>
        </ul>
    <!-- #top --></div>

You shouldn't even need NAV if you bother using H2 (or even HR) properly to start the bloody content!

Creating bloated markup that relies on a massive CSS library for NOTHING whilst also using JavaScript to do CSS' job is not going to make for a fast website. Nor does it make it "easier", "simpler", or "better when working in a group" despite the wild unfounded claims to the contrary.

Speedy sites is easy, people make it hard. Keep the total file counts low, avoid using JS for nothing, avoid using JS for things CSS or HTML can do without the scripting, and move anything you possibly can out of the markup where it can be cached across page-loads.

There's a reason my specialty 15 years ago was taking websites so bloated they were choking out the dual Xeon servers of the time with gigs of RAM and hosting them comfortably on P3 era hardware with half a gig. (about equal to a cheap VPS plan today). I bothered paying attention to why CSS existed, accessibility rules and guidelines, and the intent/reasoning behind the creation of HTML 4 Strict.

Whilst the rest of the world seemingly shoved it's head up the 1990's backside and spent a decade slopping out 4 transitional -- literally meaning "in transition from 1997 to 1998 practices"... which is why so much of what people are doing in HTML 5 reeks of HTML 3.2 style browser-wars era mentality. Emphasis on the "mental".

Hence the code bloat messes we see today. When most developers, even alleged "experts" don't even seem to realize what numbered headings are even for, don't expect quality markup as a result.

... and it's how Hashnode likely got duped into thinking that this: (formatting added for clarity)

<div class="dropdown-menu">
    <p class="dropdown-label">Select one:</p>
    <div class="d-flex flex-row flex-wrap">
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35484">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-1-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35485">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-2-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35486">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-3-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5abf">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-4-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5abd">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-5-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5abc">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-6-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5abb">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-7-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5ab9">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-8-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5ab8">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-9-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35487">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-10-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35488">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-11-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d35489">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-12-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d3548a">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-13-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5aba">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-14-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5ac0">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-15-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="5c090d96c2a9c2a674d3548b">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-16-min.png"/>
        </a>
        <a class="dropdown-item  d-flex align-items-center" href="#" data-reaction-id="567453d0b73d6a82ac8c5abe">
            <img src="d3h1a9qmjahky9.cloudfront.net/app-17-min.png"/>
        </a>
    </div>
</div>

Is how a page should be written... where's the ALT attributes? Why all the classes when the perfectly good parent has a class? Why all the separate images? Why the hash links or even anchors when this seems to be scripting only functionality? Where are the block level separators or text to tell users what these even are on image failure/blockage? What makes "select one" a grammatical paragraph?!? All for images I'm not even certain belong in the markup and are prime candidates for CSS sprites and/or font replacement. Worse, being scripting only in functionality they have no business in the static markup in the first place and should be built post-load on the DOM.

... but your average react developer wouldn't even bat an eyelash at that; then they wonder why their sites are slow bloated hard to maintain messes that often land them face to face with fines and court dates in some industries.

Just to explain that last snippet, I would probably have this instead as the structure:

<div class="likeSection">
    <h3>Select Type of Like</h3>
    <button type="button" class="like"><span>Like</span></button>
    <button type="button" class="love"><span>Love</span></button>
    <button type="button" class="unicorn"><span>Unicorn</span></button>
    <button type="button" class="notWorthy"><span>We're not Worthy</span></button>
    <button type="button" class="applause"><span>Applause</span></button>
    <button type="button" class="beer"><span>Have a Beer</span></button>
    <button type="button" class="cheers"><span>Cheers</span></button>
    <button type="button" class="trophy"><span>Trophy</span></button>
    <button type="button" class="crown"><span>Crown</span></button>
    <button type="button" class="flames"><span>On fire</span></button>
    <button type="button" class="crush"><span>I've got a Crush</span></button>
    <button type="button" class="peace"><span>Peace out</span></button>
    <button type="button" class="cash"><span>Bag o' cash</span></button>
    <button type="button" class="star"><span>You're a Star</span></button>
    <button type="button" class="cool"><span>Cool</span></button>
    <button type="button" class="party"><span>Party on</span></button>
    <button type="button" class="target"><span>Spot on</span></button>
</div>

Except generated by the scripting since it's scripting only functionality. It's 1/3rd the code, the images being loaded as CSS sprites or from fonts from the stylesheet. The scripting to generate that not even being a handful of lines even as vanilla.

... and moving that out of the static markup means less markup to send when a pageload triggers since external scripting can be cached. Moving the images into the CSS means less markup since the external stylesheet can be cached.

Assuming cache-control isn't screwed up and such things are actually being cached.

Also means you could hook them as you generate them instead of slopping all over the markup with that data-react-id trash even further reducing the bloat.

Just part of why I call things like React and Bootcrap incompetent garbage. They take something so simple and make it so pointlessly bloated and aggravatingly difficult to work with.

When you explain in details your opinion I have to say I strongly agree and I follow you, in opinion and practice, most of the way. I ain't gonna put down Sass or Vue, but my software are specialised and locked applications, so only a few access it and there's just so much ease of work when using something that actually structures your work and I have, forgot what it's called, but the option to make it only load the actual JavaScript pieces a given page needs. Same reason I chose Laravel, but that not in the topic here.

On the other cases with bunch of classes and missing attributes, I completely agree. It looks like those templates from ThemeForest. I have bought a few, and always end up creating my own version as they are so poorly made.

I will give you that Vue adds an overhead of 20kb, again, that's a balance decision to make. I also need to make a living out of it and as long as I can use a public CDN for the Vue, it's most likely 20kb the user won't have to load when they visit my site.

My apology for the poor grammar, I haven't slept for 24 hours and last night was just 3 hours

Emil Moe Vue is light in terms of itself minified, it's what it does and how it does it that creates unnecessary bloat. Painfully so.

The moment I see something like this:

<div id="app-4">
    <ol>
        <li v-for="todo in todos">
            {{ todo.text }}
        </li>
    </ol>
</div>

At least in client-side scripting, I'm pretty much "yeah, we're done here". Scripting only elements in the markup. No. Oh hell no!

Sure... just actively encourage the inaccessible disaster that is CSR with no fallbacks. Why not? What could go wrong... If nothing else, if you're gonna CSR only (which is bad) at least do it, and get scripting only code out of the flipping markup where it has no business being!

It's why I think webComponents is one of the dumbest things ever, much like HTML 5's stupid "structural tags" or the idiotic "aria role" bull it's a broken stupid methodology I would wave people off from. It reminds me too much of that inaccessible broken "XSL Transforms" trash that turned XHTML into a technological dead-end.

Maybe if I were building a standalone application in something like nw.js or electron, then I could see it... but on something served over the Internet to a normal web browser? Nancy Reagan that bekaptah nonsense.}

But long term I shouldn't complain, just means more companies for me to go into and bail out when this type of rubbish ends up used in the wrong industries.

... and yeah, not been sleeping too good myself. I suspect Holiday stress. I've had to fight off the dreadful urge to be merry.

And how would you dynamically render stuff on the website without some sort of content creation through JavaScript? It has to be either this or document.createElement('li') then again making it reactive easily becomes a pain if handheld.

I still agree the the simple solutions are the best, but simplicity should be considered from both sides. Developer and user.

To another point earlier, of course CSS would always be in favour of JavaScript. That should be common sense to anyone in this business, that CSS is 99% of the time much faster to render and much more optimised in browsers.

Emil Moe I think you missed my meaning.

And how would you dynamically render stuff on the website without some sort of content creation through JavaScript?

I would do it exactly there, in the script - using createElement, createTextNode, textContent, and so forth. A simple 'make' helper to speed up generation being all that's needed.

In that example code for vue I lifted straight from their tutorial, I would not have the DIV, the OL, or the LI in the markup. I would figure out what element is before/after where I want the DIV (assuming it even needs a DIV, which usually it doesn't, OL's a perfectly good block-level container), generate it from the scripting and insertBefore/appendChild it as appropriate.

Then it doesn't even need ID's or bizzaro curly bracket BS to hook it, as you just made the element.

IF it's going to be scripting only functionality, it doesn't go in the markup... Any of it. Not one line. Because if it's used across multiple pages in the same fashion, you just missed a caching opportunity. Because if someone is visiting with scripting blocked, it's a bit obtuse to have a bunch of non-functional garbage in the markup.

Though again, 99% of what I deal with is built with accessibility first, fancy "dynamic" stuff second... which means a lot of what we're talking about has zero business being implemented client-side, and if there is a client side to it that's an enhancement replicating and improving an already working page, not the only means of providing functionality.

Hence why the majority of scripted "apps" are an annoyance that when duped into using them screws over the clients I'm called in to "consult" with. By their very nature such "dynamic" scripting if no scripting off fallback is provided violates accessibility norms.

It's OK to do it, if you know the risks, plan for the risks, and have a fallback plan, and do it in a rational gracefully degrading manner. Otherwise you're just gambling on how long before it whips around and bites you in the backside.

Aka where pretty much everything I've ever seen built with these "front end frameworks" fail spectacularly.

I'm missing your point on how to make it reactive then?

As I have read your opinions right now. It's not an impossible task to create a 'mini JavaScript ''framework''' allowing to add, remove stuff and create it reactive and support for AJAX. Not sure what else the frameworks provides.

Just trying to get your ideas. I still believe some sort of framework is good for faster development, but maybe it can be simplified without too much payoff.