71–80 of 356 posts
Earlier quoted context omitted.
1MB per photo is massive. Its easy to compress photos down to 100KB or less.
If it’s an illustrative photo for an article, sure. If it’s a gallery photo for a site promoting a photographers skill or library, nah…
Honestly, "should" is a bit of a click-baity exaggeration. In this day and age where internet speeds are faster and more stable than ever, these kinds of tips should be at the very bottom of your optimisations checklist. I don't care if your website takes 3 seconds to load or 5, what I do care about is that once the website has loaded, my inputs respond as quickly as possible. Reddit for example is total garbage when…
That's only doable with a text-centric website. I'm currently finishing a photography section for my personal website, and the gallery pages are several hundred kBs in size, while single photo page is almost 1MB in size (provided you load it on a 28" screen; browser will load smaller variants on smaller screens). Most of that weight is the thumbnails (and almost-full-size photo in the latter case). The only JS I have…
1MB per photo is fine. It's the content after all. Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text. I don't think the point is the size itself, but it's the content vs. bloat ratio.
I wonder... am I good if the static render is Probably for a blog, if the readable content is in that static render, it would be a reasonable experience. A couple of seconds later the cool interactive parts come to life. === PageSpeed Insights scores: Performance: 100% First Contentful Paint: 0.9 s Time to Interactive: 0.9 s Speed Index: 0.9 s Total Blocking Time: 0 ms Largest Contentful Paint: 0.9 s Cumulative Layou…
It sounds like you might have rediscovered this concept, and if so, yes, good, please do it. I'm not sure if React will even let you work this way, though.
Do you get the benefits if your HTML and CSS are under 14kb, but your images and JS requests aren't?
If that 14kb just loads a progress animation while JS loads and then starts doing a bunch of AJAX queries and DOM manipulation in the back end before you can even see anything on the page, you're still barking up the wrong user-unfriendly tree.
Shameless self-promotion: the homepage of plaintextsports.com is 5.2kb today [1], an in-progress WNBA game (4th quarter) is 11.2kb [2], and an extra inning MLB game is 8.8kb [3]. I wasn't aware of this size threshold, and I'm not at this level of optimization, but I'm always pleased to find more evidence of my playful claim that it's the "fastest website in the history of the internet". [1]: https://plaintextsports.c…
I wonder... am I good if the static render is Probably for a blog, if the readable content is in that static render, it would be a reasonable experience. A couple of seconds later the cool interactive parts come to life. === PageSpeed Insights scores: Performance: 100% First Contentful Paint: 0.9 s Time to Interactive: 0.9 s Speed Index: 0.9 s Total Blocking Time: 0 ms Largest Contentful Paint: 0.9 s Cumulative Layou…
> I wonder... am I good if the static render is Ten years ago, we had a best practice in client-side web development called progressive enhancement. The idea was that you load a web page which is fully functional without JavaScript, then use JS to add whatever glitzy client-side interaction you want to add - but importantly, just as enhancement, so whatever needed to be done on the page could be done, perhaps in an u…
NextJS helps with this kind of thing by letting you statically generate server side the first render in React (you can load data in prior from a source if needed) and then you can CDN that page.
You could also do this in rails but NextJS saves you needing say a moustache or ERB version of the same page for the static render. You use the same code for build time, back end runtime and front end.
Lovingly called isomorphic programming or as cynics call it: monoglot!
I knew of the progressive enhancement concept but what I didn’t know was the 14kb thing. It is motivating me to experiment!
Earlier quoted context omitted.
1MB per photo is fine. It's the content after all. Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text. I don't think the point is the size itself, but it's the content vs. bloat ratio.
Omg just disabling custom fonts in Firefox speeds up the internet so much!
Someone should invent an HTML tag for putting images on a page.