What’s the acronym for “it took me three seconds after page load to read any of this because the designer either neglected or aggressively shaved off a media query and I had to wait to enable reader view”?
Edit: I’m not trying to overly criticize the page. I hope this is taken in the spirit of the article. A few extra bytes down the wire would’ve made that a much faster and lower friction experience for me.
Not a web developer but I feel like text only/small websites should be promoted. Unnecessary images on this page, weird backlink stuff between comments.. and this is a website about web development. Not looking good to me(I’m a dumb user) yet still better than many others.
It’s a propos that this article took ~10 seconds to load for me the first time, but <1 second the second time and <1 second again with the cache cleared. Unfortunately I didn’t have dev tools open to figure out why.
That’s an interesting theory. I checked though and didn’t find service workers on this page [1] so it could just be something with the server itself. I caught another slower load just now and server timing showed a long wait for the first byte.
Interestingly enough, both the best and the worst experiences I've had on the web lately both belonged to tools-and-hardware suppliers: McMaster.com and HomeDepot.com, respectively.
Everything about McMaster-Carr's site is built for speed and ease. I can literally have an idea, find the category, identify the specific part, and complete an order in about twenty seconds. (I've done this during a phone call. In the time it took my coworker to articulate the part he was looking for and finish his sentence, I was able to reply "It'll be here tomorrow.")
HomeDepot on the other hand sometimes takes 20 or 30 seconds to render the page to the point that I can see prices. I just checked with a page whose URL was already in my history, an unusually brisk 7 seconds. (Gag!) How do they screw it up so bad? I honestly don't understand how a web page can take so long to do anything.
There is something _wrong_ with HomeDepot.com. It managed to send my poor laptop into swap hell/thrashing, which wasn't too surprising as that machine is always short on RAM. That it could do the same to a beefy workstation (16 cores, 64GB RAM), though... that was impressive. Whatever is wrong there, it hits memory especially hard.
I made a web proxy about 10 years ago - you can stick it on a raspberry pi or some cloud server and then use it to browse from that machine's IP. It doesn't work for everything (e.g. OAuth) but it's fast and convenient for a lot of things.
I don't keep a copy of it online anymore because the ones I put up got a little too popular, but if you don't tell anyone else, you should be able to use it indefinitely.
It's not: they don't operate in the EU, they don't want to give up their tracking, and they don't want to conform to EU privacy measures. That's perfectly fine, and simply denying EU visitors is the easiest and cheapest solution.
So "big brother" that want to track everything use a reference to 1984 to criticize a law that protect against it ? Perfect double speak in action (sadly).
The 451 code (which, by the way, is a reference to Bradbury's Fahrenheit 451, not Orwell's 1984) just says that a resource is "unavailable for legal reasons". These "legal reasons" may be user-hostile (e.g., censorship) or user-friendly (e.g., GDPR).
Having said that, it's just good form to specify why exactly a request was denied rather than spitting out an "access denied" response and call it a day. Be liberal in what you receive, conservative in what you send, yada yada.
So more explicitly, since they don't operate in the EU, don't seem to be owned by a multi-national that does, they wouldn't have to worry about GDPR, someone else is worried? And that's likely whatever ad slinging network or tracking they use?
The page loaded fairly fast in my case, but my laptop sounds like it's about to take off. An excellent example on how a web site should _not_ be built. :D
I am impressed by McMaster's search engine : every product is standardised and the search options really works.
Amazon should really take note, their search engine is stuck at Stone age.
Maybe a search engine that doesn't quite work and pushes a lot of unwanted crap at you on the offchance you'll buy it on a whim benefits Amazon, if not the customer.
Why single out their mobile web site? The non-mobile site is just as wretched. I just tried it and it took 24 seconds to finish loading (17 seconds before it was useful). Over 300 round-trip queries, and I have all ads and trackers disabled.
They obviously know how bad their experience is because they throw up an animated splash screen while waiting for their page to load.
It's kinda small for my liking, but I've got a big screen and didn't bother zooming in. Only niggly thing is that page clicks create a spinner; one thing they could do to improve is to pre-render everything, given that what I clicked on was just category pages.
I've had great experiences with Gatsby on Netlify in that regard, we've built a number of websites using it. With Gatsby you get the benefits of a React webapp but without the downsides, things like preloading on hover, instant rendering, service workers acting as content caches, etc.
> With Gatsby you get the benefits of a React webapp but without the downsides
Instead Gatsby just brings its own set of downsides. Gatsby does not scale very well and has horrific dev and build times when it needs to ingest a medium quantity of entries.
Yeah, it's way better than Conrad or Manomano, who both use the same shitty layout you get from every etailer : gigantic full-page promotional material and some top categories in the middle to start navigating things. And in the end you have to tinker with filters for 5 minutes before narrowing it down to probably maybe the right part.
Haven't tried Conrad, but Manomano it's a mess if you wanna look for something concrete. Once you enter in a category, it's like searching in eBay. It's so difficult to search by brand, model or specs...
I think one of the reasons that it is so fast is that all the small images are monochrome PNGs. Really well thought out and to my eyes it looks rather stylish.
Yup, worked in a US lab back around 2005. Now back in the EU, I find that in most areas online stores have caught up, but on hardware nothing yet comes close to McMaster-Carr.
One thing I only realized when living in the US is that the reason that online shopping is so much more advanced in the US than in the EU is not just the more homogeneous market. Due to tax rules (state sales tax on mail orders) mail order has always had a competitive edge in the US, leading to a many companies already being set up with a deep back-catalogue and strong inventory metadata when the internet hit.
When buying electronic components, either RS or Mouser (can't remember which one right now) is super slow and fails a lot. Something like this would be awesome. (I know it's millions of references, but...)
Wow. I know absolutely jack shit about home improvement etc., but that McMaster.com site is just a joy to browse. A temporary relief from the "modern web".
It's like I'm querying a well set up database, but without having to type SQL.
While not horrible on mobile, it could do with some work. It would be easy to make it perfect on mobile while retaining basically the same UI and with zero performance penalty
Just checked McMaster, I would wager that a lot of what makes it great is the information architecture, from how it's probably modeled in the DB and how it's queried, to how it's presented in terms of UX.
I think the difference is the marketing approach. HomeDepot takes a very modern approach of controlling and measuring everything the user does. This needs a ton of code and some absolutely ridiculous stuff no one here would ever build if they were told to redo the site.
The McMaster-Carr mug is an example of marketing done right. It says "we're here to do precisely what you want in exchange for money."
That's funny, I was just thinking this exact same thing the other day. HomeDepot.com has been getting seemingly worse and worse (especially this year if I'm not mistaken), but had to get some stuff from McMaster a few months back and it was refreshing to be reminded of how useable their website is.
I’ve been a mechanical engineer for some time. McMaster is an institution. Their catalog is still an iconic presence in engineering departments and you’re right, their site is incredible.
Even for professionals you often don’t know what to call a part, but punch in a few words and it “gets” what you’re going for. Add tot hat pretty reliable next day shipping even when ordering at 4pm and it’s not so surprising that Amazon hasn’t eaten them, even though they launched Amazon Industrial like ~7-10y ago
I've always been curious about HD's website. Surely being so slow costs them a lot of missed sales? I would think a large successful retailer understands that. Is it just bureaucracy or do they genuinely think their website isn't important?
I would also shoutout to Mouser for a powerful interface for narrowing down what you want to buy, but its performance does leave something to be desired.
When dealing with 'troublesome' internet connections, or just in general:
Keep page load to less than 50k, or 100k if you're feeling fancy.
Have a responsive design, unlike this website does, as a lot of people use phones, don't have a PC or are not on a PC.
Don't link everything under the cloud because you can - fonts, frameworks, huge pictures, because it makes your life easier. Self host everything, make it small.
And don't use JavaScript to add an unnecessary layer to 'manage' linking. Clicking on a link is expected behaviour. As are scroll bars. HTML links work perfectly fine and it degrades, nay I say disgraces, user experience.
These basic rubrics will ensure when serving things to 'troublesome' connections, be that bandwidth, blocked 3rd party CDNs or latency, and will largely make sure life will be easier.
Oh man I agree with everything you have written. You should have prefaced with "Trigger warning: I talk about scr#ll b#rs in this comment" because I am 100% triggered :-D
Rant incoming - sorry it's been done to death already but I never weighed in before. I will never understand the desire to mess around with custom scrolling on a "normal" page. If you have one of those weird parallax-scrolling visualisations that news sites are often fond of, fine - I don't like them but I understand it's there to present some photography or graphs or whatever in a novel or fancy way. But so many sites that are just serving an article with some pictures override a browser's scroll behaviour in a way that not only adds nothing, but often breaks things. By that I mean it can either just slow or interfere with scrolling in a way that will annoy technical or observant users ... or it can prevent scrolling altogether for a subset of browser/OS or for touch/non-touch users.
I totally understand. Scroll behavior is uniform in all windows on my desktop but some websites think they are so special that they should change that just for them. I personally hate smooth scrolling and have it disabled, I can't understand why people like waiting for a useless animation when the operation could be done instantly. I feel like the computer is wasting my time! So when a website re-enables it with its own buggy JS implementation, well it's disturbing. (Thanks for giving me an excuse for my own rant!)
There are thousands of different device-configuration-user possibilities, and for each one you get working, several more you'll never know about will also have an easier time of using your site.
It gets kind of addicting, to be honest. The more browsers I try, the better I get at fixing various compatibility issues and removing all but the absolutely necessary from my pages.
I started out with a pretty minimal design and featureset to begin with, but I've been able to actually expand my compatibility matrix while also adding new features by coding minimally and using "historic" LCD JS for most things.
It's shown me that a) each browser has its beauty and unique features and feel b) most browsers are totally valid access devices and I would like to support them all c) we're at risk of losing all the knowledge of how to build a decent website, and I'd like to preserve that knowledge.
Worst sites are not slow, right. Worst sites are those that break visual contracts (cls in the article), and half of “fast” sites do that. You can see it when page is already loaded for few seconds, you scroll/interact with it and then suddenly it behaves as if it was reloaded or jumps to another position right under your finger. You misclick on a link, go back, repeat. It does that not because a top banner loads, but on its own programming quirk. That’s annoying af and should be downranked to the bottom just like any snail-paced site.
Google treats this as an important ranking factor. That being said, it also values authority, and the websites that pull such nonsense tend to have such authority.
The bigger your website is, the more annoyances you can get away with.
I find this to be happening with YouTube in Firefox Mobile. For some reason my "watch later list" (or any playlist, I think) jumps like crazy when scrolling through it. It's a real mess and leads to lots of misclicks. Almost feels "broken by design", so I stick to their app.
You might want to try out https://vancedapp.com/ - it's basically a modified version of the official youtube app that gets rid of some of the annoyances.
A fast web page is not mythical. It's also not some unknowable or untestable thing. If you make a page of X bytes, Y number of resources of Z bytes, you can pretty easily calculate load time ranges for a variety of network conditions.
You're never going to be able to overcome physics so you aren't going to somehow make a ten megabyte JavaScript monstrosity load instantly over a spotty 3G connection in the middle of nowhere.
What you can do is give some worst case connection the best chance you can to successfully load your page.
Instead of building it all in the DOM with JavaScript send the client the damn HTML. Send some baseline CSS in a style tag. Use CSS patterns instead of big header images or backgrounds. Use box/text shadows to make elements stand out without images. Bundle as much as possible (CSS sprites, JS bundles, etc) to cut down on external resource requests. Minify and compress the shit out of everything. Include a viewport meta tag.
It's not that difficult to have a good looking and functional page that's literally a single HTML page. A single compressed resource that has everything it needs in a single load.
We're actually in an era where the average web browser is extremely capable and isn't some version of IE. Even super low end Android phones have a very capable browser installed by default. You've got HTML5 and CSS3 along with at least ES6 everywhere. The same is true on the desktop in most areas.
There's also just so much shit you don't need in most pages. Far too many people treat a web page like it's some full blown mini OS. There's also a seeming generation of web devs that have no idea what browsers do and think they need to include the kitchen sink to display some text or load resources. You definitely don't need to override scroll events.
You can never make a universally fast page because you don't control the user's environment. But you can make pages and fast and as light as possible so they're not wasting anyone's time or battery. You can also focus on uncached loads because honestly that's going to be a majority of visits.
I don't know if current super low-end Android phones have what it takes to browse the web, but on all the devices I've had, all web browsers have been consistently unusable. Maybe that's changed in the last couple of years.
I ended up moving off the 5X because it didn't have enough memory to keep a firefox page loaded when switching between apps. Have a Moto X4 now which works pretty well.
To be pedantic, content size is not the only factor, the amount of work the browser needs to do to render your page, the amount of visual effects, etc also have an impact on the perceived speed of your webpage. https://js1k.com/2019-x/demo/4130, the winner of last year's JS1K competition, has a total downloaded size of 10kB, but probably won't run well on low end devices.
You're right that size ≠ complexity. However there's a vast difference between a web page with some fancy CSS and some JavaScript demo scene project.
You can have a very fancy looking page with a few KB of CSS that will render just fine on even low end modern devices. You'd have to go back almost a decade to find devices that would struggle on such non-demoscene-yet-fancy CSS.
Layout engines in browsers are pretty efficient and a fancy looking page without a bunch of JavaScript churning in the background fucking with the DOM or making a bunch of requests is not that demanding.
The CSS Zen Garden [0] did some fancy ass layouts with CSS 2 and launched in 2003 running on browsers and computers far shittier than today's low end phones and PCs. With CSS3's advancements like transforms, transparencies, and animations there's a lot of effects that can be done entirely in CSS that those old designs needed images to do.
> If you make a page of X bytes, Y number of resources of Z bytes, you can pretty easily calculate load time ranges for a variety of network conditions.
To expand on Cthulhu_'s point: I agree with the gist here but I think this is a bit of a simplification. From the user's point of view, fast downloading is only part of the picture. There's also the matter of render time, the dreaded flash of unstyled content, and related irritations such as banners and popups that appear after the page has seemingly finished rendering. (Wikipedia's current fund-raising drive commits this sin, perhaps deliberately.) All of these things contribute to a sense of the page 'getting in your way'. edit Another one for the list: distracting autoplaying videos. The Ars Technica site does this, for instance.
Sites like Pinboard and HackerNews are compact in terms of avoiding bloated JavaScript, but importantly they also stay out of your way in terms of UX.
The flash of unstyled content, even on slow shitty connections, is unnecessary and entirely my point. If you include a style tag with some bare minimum CSS (or even all your CSS) there will be no unstyled flash because the browser's already got CSS for the document.
A 50KB page, about ten pages worth of text (20kb) and the rest markup and CSS, will load in under two seconds on a shitty 3G connection. There will be no unstyled flash and even on super low end devices first paint will happen a fraction of a second after the document finishes loading. You can do a lot of nice styling in 20kb of CSS. You could even include some inline SVG graphics/logo out of that budget.
With compression which every browser supports you've got an even large budget because you can easily see 2:1 compression ratios on text with just GZip.
If you include explicit sizes for things like image and video tags (width and height attributes) the browser won't need to reflow the layout as those resources lazy load in after the page load. There's no popping or things "getting in the way" if you don't write your page like an asshole or pretend you don't know anything about the content ahead of time. Anymore browsers support explicit lazy loading and media source sets. Not using those sorts of features is just laziness or ignorance on the part of web devs.
My first experiences on the Internet were at the end of a shitty dial-up connection with at best a quarter second of latency. Those experiences have stuck with me and I'm appalled and even a bit offended when a "web page" is larger than a copy of Doom. It's especially egregious when a page weighs that much to display a couple paragraphs of text.
Unfortunately, the challenge seems to be "how fast can we render a cookie notice that will waste 2-5 seconds and content that deliberately hides answers to keep the user on the site".
It's pointless to make a website ridiculously fast before making the experience as user-hostile as permissible.
Is there a way to pre-approve cookies for all sites? The law to require those pop ups has done more to ruin the web for me than ads have (since you can block ads).
Do you know if there's an "I Do Care About Cookies" extension to automatically always decline?
(If not, than an extension just to find and show the correct decline option when it's cunningly encrypted in a sequence of hidden yes/no/no/no/yes/no type slider options with ambiguously written labels would be nice instead!)
Cookies aren't only for ads.
And the pop ups wouldn't be necessary if the site owner would stop that tracking bullshit.
Just turn it off and give me an option to activate it if I want.
- Overly-defensive company policies, which ask for consent "just in case"
- A bandwagon effect of "everyone else is doing it"
The first is quite understandable, and has been policy at every company I've worked for/with. One decided to remove all cookies rather than adding a consent popup; the only cookie we used was for "remember me" on login, so we changed the default to false and put a note next to the tick box. Every other company I've worked for/with has decided to add a popup instead; unsurprisingly, they were also setting a whole bunch of tracking and adware cookies.
The problems I have with the "bandwagon" are that (a) popups are more obvious and memorable than not having popups, which biases the bandwagon effect towards the obnoxious behaviour (availability heuristic); and (b) users seeing all these popups think they must be necessary, and misattribute their cause (e.g. thinking GDPR requires them, rather than companies either playing it safe or refusing to stop surveillance).
Cookies aren't inherently evil or anything. They are a really important tool for a lot of situations. It's misuse that is the problem, persistent client-side storage is actually pretty critical for some stuff.
Consent is implied for everything needed to deliver a service to the user (e.g. cookies for a shopping cart, local storage for gaming high-scores, etc.).
Anything that's not required to provide users with the service they're after must either not track them or ask for explicit consent before doing so.
At a previous job, a significant percentage of the feedback we received was about the feedback prompt itself. Users just want to get what they came for and then leave the site. They rarely do anything that doesn't directly benefit them, unless they're really happy, or really angry. For everything else, there's analytics.
Analytics answer questions like "is this content worth translating", "is that element a good use of screen real estate", "is this browser worth supporting", "how do people find this page (and what are they looking for)". You can't get that out of a feedback form.
Fast web pages unquestionably exist. This just spends a lot of text (and 2 pointless images, as noted by the top comment in that article) to pretend they don't. Now there's a reason for trying to fudge the question but it's not clear why. Someone's up to something, pushing something, selling something.
Every web page should load in 200 ms or less. There is no deep technical reason for humans to wait for computers for simple loading of data. We can get this right.
I'm sure lots of people know this but I had no idea. Chrome has 'lighthouse' built in. Seems to be a reasonably thorough client-side site usability/responsiveness report tool.
Hit F12 and go to the Lighthouse tab(?) in dev tools. Very cool!
I'm having a bloody nightmare with my blog, https://www.thedetechtor.com, must be something to do with wix but it takes for ever to load, going to have to migrate to Wordpress
Well, part of it is probably the 355 requests it makes on a fresh load. Have you considered reducing the number of JavaScript libraries you use? You have quite a lot of them…
Wix is perfectly usable as long as you limit the number of components on the pages, especially if those components are not static which you clearly make a lot of use of.
Your usage and content has probably outgrown Wix unless you plan to simply the structure a bit.
It's physics, not perception. Just make your website fast.
Am currently consulting big ecommerce bussiness on how to improve page load. I made them this 'fastest page in the world' demo:
https://turboeshop.com/fastestpageintheworld/ - kindly please check it out. And here is fastest page with Google Analytics:
https://turboeshop.com/newstackonly/. 325 ms for fully loaded time CSS + images + HTML + JS + GA loaded + Measurement Protocol hits sent.
This is what fast website is: a) inline purged css; b) everything loaded from one domain, 100% cached. c)inlined js(vanilla + web component if you need one); d) inlined images up to 4kb; e) larger images loaded from cache from same domain. f) gtag.js and analytics.js -> from cache; g) Measurement protocol hits sent from async proxy on edge. h) 100% cloudflare cache hits; i) Cloudflare workers for dynamic bits; That's all what it takes. Don't read articles- just make it fast, it's really that simple :)
And as svelte was mentioned - if you want to improve a website that is bigger than your personal blog, you don't use svelte, react, gatsby or any other of that breed as it's impossible to do serious marketing with a website that's hydrated (svelte's web components is a wonderful thing though and is totally nice addition to marketing stack). I mean no insult to anyone with my strong opinions and would be glad to have discussions in comments.
UPD: Added note on Cloudflare & Cloudflare workers.
Thanks a lot for sharing, will look into it for more tricks. Yet gtmetrix.com scores it at 1.0 s. Time-to-first-byte is 0.5 as CF gives 90-130ms TTFB out of box.
Just a random note: both versions of your website seem as fast (instant) to me ona PC with good LAN connection. I wouldn't know there is a loading time difference unless looking at the numbers. Things might be different on 3G mobile though.
I've have set page load monitoring for employees and clients in grafana. Been asked to add device/locations dimensions. That's OK to know and understand how tech stack influences customer's journey. But that info has no impact on looking for a ways to optimize site even further. On slower device - site will be somewhat proportionally slower, but will remains times/percentage faster than any alternative being crafted without taking care about performance - related aspects. Key to understand that once you put your website under Cloudflare or any other CDN, it'll always be very close to where you live. I do not know for sure but I think I live 1.5km from data center where Cloudflare is hosting their server :) Of course here comes the rendering part. But if you have minimum JS, and sane images, and class-based CSS (they say it's fastest) - what is it what can slow you down? If delivery is fast because of cdn, rendering is fast because of sticking to basics and best practices, I think you have it all covered.
All is nice but a lot of the slowness in our bank's site comes from fetching the client's data, I'm sure this can be improved but the requirement for layers of abstraction and security to fetch a customer data is a tougher problem.
Is there a way to securely pre-fetch data from the db? If I have a valid cookie why is my account snapshot not getting fetched when I hit Citibank.com?
If I mark "remember my username", and I hit citibank.com, can't the banking back end start fetching my account snapshot when my browser hits / and then send over that data as soon as I authenticate?
I'm out of the loop so maybe this is already done or too complicated?
What about encrypting every users account info, and then when a GET comes in the server sends over everyones data that has ever logged on from that IP address? The client would then decrypt their own data. If compressed, then encrypted it could be small enough? Probably too complex tho...
If you're going to send data speculatively by keying on IP address, why not key on long-term user-id cookie instead? That is more accurate and potentially more secure, and for many people the cookie changes less often than their ephemeral IP address anyway.
But if the client data is small enough, that wouldn't actually reduce the latency to speed up the page load, if these assumptions hold:
- Getting the decryption key is subject to an authorisation round trip; current data fetch is subject to the same round trip; and the client data is small so sending it takes about the same time as sending the key.
But the round trip can be brought to a minimum by not requiring a large page full of HTML/CSS/JS to be send on auth - just requiring the client data (or key as you suggested).
All the parts which don't depend on client data can be preloaded asynchronously after the login page is shown, including a template for the page ready to be populated when client data is received.
So:
- Make the login page as fast as possible, using inlined data etc. like any static page. Make the page cacheable, probably validated with an Etag. The remembered "your name" field can be populated, that's fine even if it's cached because the browser cache ("Cache-Control:private") is unique to the user.
- Have the login page preload all non-client-data dependent resources for the next page asynchronously, but ensure these don't start fetching until all resources for the login page itself have finished being fetched.
- When password is entered, perform auth and get client data in a single round trip, combine with the templates just loaded to load the new page.
- Use 0-RTT TLS for everything.
Each interaction will be about as fast as possible while validating with the server, but you can go further if you're ok with relaxing that:
- Make the first page load "instant" by changing the cache policy to validate after a timeout instead of just on Etag.
- Asynchronously preload all the resources for the authenticated next page except the client data.
- Make the authenticated next page "instant" by detecting when the user appears to have paused typing in the password field (or immediately without pause if it's refilled by a password manager or user paste into it), and before they hit enter or click submit, send speculative auth requests which return client data if they succeed, but don't treat the user as properly authorised until they do enter/submit. When they do, use the preloaded client data if it's already arrived (and the password field hasn't changed), and also send an auth-confirm request.
At one company we tried to do better than this. The bank login form version of the feature we shipped would be to send an XHR (well, in current year, a websocket message) per keystroke in the login form and preload the front-page data for all the users with the appropriate prefix once there are few enough of them. When the front-page request comes, the data should at least be in a memcached instance used by the relevant service, rather than in a DB owned by a different service.
The "remember your username" usually means persisting a user ID in the cookie session, and the core banking backend does not know shit about cookies or front-end users, the request needs to be mediated and properly authenticated in a way that is compliant with security regulations.
You could conceivably pre-render the backend results before hand but then on first load the visiting user would not see her latest transactions --which is a very frequent use case.
As a side note, it's amazing how modern banking sites keep being really fancy interfaces to years old COBOL backends.
Thanks a lot for your comment. I think it is important to note that max page speed is not a top priority in most of the cases. Banks, SaaS self service, etc. etc. - it's where it's probably not that much crucial. But - as always - it depends. Having that said - I am planning to develop 'fastest SPA in the world' toy demo with auth0.com, https://github.com/signalnerve/workers-auth0-example edge-side auth0 authentication and faunadb.com instantly-consistent cloud DB. The auth part of SPA sign in is just way too annoying for me. But yeah, hardly bank would ever sign for such stack, or at least a single part of it :)
You can get the best of both worlds with Gatsby plus gatsby-plugin-no-javascript. Gatsby inlines critical css and small images and does just about every trick available to minimize page load, then the plugin kills the hydration. The plugin can run on a per page basis, so you can still keep your hydration on your pages that need them. For complex webapps that also have marketing/documentation/landing pages, it's a really nice combo.
Gatsby devs or advocates would argue removing the js removes the preloading of pages that helps make Gatsby faster. Although this is true, in my experience removing hydration is often a better trade off. It of course depends on the site.
Hey! Sure - been there done that https://stackoverflow.com/questions/57556599/how-to-render-n... :) Sapper, however, will not let you do that easily https://stackoverflow.com/questions/64507516/how-to-disable-... . I think with next.js it's somewhere in between - possbile, but not easy. And I totally buy the approach of being able to use and mix both according to the needs. My personal favorite for html+css composition is to develop components with react, deploy them on bit.dev and render with react.renderToStaticMarkup in backend with express.js Turboeshop.com is made exactly that way. BTW, there is identical website to https://turboeshop.com/fastestpageintheworld/ built with next.js(never mind the domain name): https://gatsbyeshop.com . Will update my initial comment as well.
I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance. Gatsby gets there largely by accident and in a crude way. I'm hopeful over time all these tools will get there explicitly. It sounds like Remix might also be a nice catalyst in this department.
So glad to hear someone else feeling that way :) Thanks a lot for sharing - feel exactly the same way. We'll surely get there, fingers crossed for that happening sooner! :)
I personally am 100% that site should work without JS (as well). Some UX might demand dom manipulations, so at least personally of having both. And for excluding GA - that's firstly a topic of specific business and it's philosophy. Technically if you collect server logs - you still have to get user's consent probably.
3. Gzip stuff(as one commenter below commented, not done in turboeshop.com/fastestpageintheworld/).
4. Everything from same domain and subdomain. If you want cloudinary or friends, I guess they are only allow subdomain. This is totally OKeish exemption. Or maybe there is a way to work around that cloudinary serves, Cloudflare caches.
5. JS - inlined. Cash.js maybe if you need jquery replacement, or just vanilla. Little content on vanilla js nowadays :), https://gomakethings.com/articles/ is something interesting. Don’t want to flame here, am not js expert, maybe someone can elaborate.
6. For compex components - svelte web components (or stencils or lithtml) - I’d prefer svelte but am not sure what’s best.
7. Google analytics a) - there is new google analytics (GA4) with measurement protocol2 and new server side google tag manager. Serve side gtm does two things a) serves gtag.js; b) accepts measurement protocol hits and sends to GA. Take a look how it’s done - https://www.simoahava.com/gtm-tips/build-custom-universal-an... , it’s very similar as cloudflare workers, cool stuff. But it’s hosted on Google App Engine, thus - slow. But you don't need google's server anymore, you control full infra, so why not setup simple cache here.
8. Google analytics b) To owerome latency to Google App engine, so you make async proxy in cloudflare workers - one worker to proxy for gtag.js download, one for serving gtag.js from your own domain. <script src=“http://yourdomain.com/workers/gtag/js?id=G-1234455> . Basicly just serve from js cache and check every once in a while if google hadn’t changed their code. Same for GA hits. It used to be google-analytics.com/collect endpoint, server side gtm allows to host collection yourself. You again make worker-proxy, define it in gtag’s transport_url:'https://turboeshop.com/measure' setting and make sure worker returns non-blockingly, and just then forward
the measurement protocol hit from worker async-ly with event.waitUntil().
10. All the stuff (fb tracking pixel, etc.) you are used to just ‘putting in html’, you instead send as measurement protocol hit dimension and do ETL in google tag manager.
An additional micro-optimization you can do is strip the excess whitespace from the output HTML. I'm seeing tabulation spaces and useless linebreaks there between tags.
A lot of the comments here are saying that js and css should be inlined to make loading faster. I disagree.
They should be small (or nonexistent in the case of js), but I believe they should be separate, and proper caching enabled. This means that the first page load may be milliseconds to a second longer, but any other page loads after will be instant since those resources will be pulled from cache.
Note: I am assuming that the web page under load is really small, 50 kb or less.
I welcome anyone who disagrees to say so. I acknowledge that I could still be wrong.
Seems to me that you could do both. Inline the minimal set that makes the front page renderable, and then background-load the full css to warm the cache for when the user clicks on a link.
Whatever happened to the idea of progressive enhancement?
I know it's a often a matter of limited time and resources but honestly I would take a bet that more than 50% of the websites you could visit would be unusable or at least functionally unusable without JavaScript.
Well established research tells us that anything below 3 seconds latency+render is over optimization in terms of customer acquisition and retention in spite of anecdotal loudmouths who claim otherwise.
What I like about this article is that discusses the issue of layout changes during load. I can not stand websites moving text around while I’m reading. Part of the blame is on browsers: why bother to render a page before all cached resourses (fonts) are loaded? But sites should insert image/ad placeholders af the appropriate size.
167 comments
[ 3.4 ms ] story [ 232 ms ] threadEdit: I’m not trying to overly criticize the page. I hope this is taken in the spirit of the article. A few extra bytes down the wire would’ve made that a much faster and lower friction experience for me.
(WYSIWYUDGBTAURM/A)
Edit: For what it's worth, it loaded instantly and legibly for me with noscript enabled.
We've built a tool to help measure speed with these sort of issues in mind - https://www.browserstack.com/blog/announcing-speedlab-test-w...
[1]: https://devdocs.io/dom/serviceworkercontainer/getregistratio... "navigator.serviceWorkers.getRegistrations()"
Everything about McMaster-Carr's site is built for speed and ease. I can literally have an idea, find the category, identify the specific part, and complete an order in about twenty seconds. (I've done this during a phone call. In the time it took my coworker to articulate the part he was looking for and finish his sentence, I was able to reply "It'll be here tomorrow.")
HomeDepot on the other hand sometimes takes 20 or 30 seconds to render the page to the point that I can see prices. I just checked with a page whose URL was already in my history, an unusually brisk 7 seconds. (Gag!) How do they screw it up so bad? I honestly don't understand how a web page can take so long to do anything.
Access Denied You don't have permission to access "http://www.homedepot.com/" on this server.
Reference #18.669a1702.1607500613.3482d63b
I lol'ed.
For example Safeway, a popular grocery chain, is blocked.
Sometimes the block comes with a scary warning saying that the site has detected a hacking attempt, and stopped your IP at the firewall.
Core library: https://github.com/nfriedly/node-unblocker Example web app: https://github.com/nfriedly/nodeunblocker.com
I don't keep a copy of it online anymore because the ones I put up got a little too popular, but if you don't tell anyone else, you should be able to use it indefinitely.
- EU IP? Blocked.
It's beyond silly.
Having said that, it's just good form to specify why exactly a request was denied rather than spitting out an "access denied" response and call it a day. Be liberal in what you receive, conservative in what you send, yada yada.
They obviously know how bad their experience is because they throw up an animated splash screen while waiting for their page to load.
I've had great experiences with Gatsby on Netlify in that regard, we've built a number of websites using it. With Gatsby you get the benefits of a React webapp but without the downsides, things like preloading on hover, instant rendering, service workers acting as content caches, etc.
Instead Gatsby just brings its own set of downsides. Gatsby does not scale very well and has horrific dev and build times when it needs to ingest a medium quantity of entries.
One thing I only realized when living in the US is that the reason that online shopping is so much more advanced in the US than in the EU is not just the more homogeneous market. Due to tax rules (state sales tax on mail orders) mail order has always had a competitive edge in the US, leading to a many companies already being set up with a deep back-catalogue and strong inventory metadata when the internet hit.
It's like I'm querying a well set up database, but without having to type SQL.
The McMaster-Carr mug is an example of marketing done right. It says "we're here to do precisely what you want in exchange for money."
Even for professionals you often don’t know what to call a part, but punch in a few words and it “gets” what you’re going for. Add tot hat pretty reliable next day shipping even when ordering at 4pm and it’s not so surprising that Amazon hasn’t eaten them, even though they launched Amazon Industrial like ~7-10y ago
I would also shoutout to Mouser for a powerful interface for narrowing down what you want to buy, but its performance does leave something to be desired.
Keep page load to less than 50k, or 100k if you're feeling fancy.
Have a responsive design, unlike this website does, as a lot of people use phones, don't have a PC or are not on a PC.
Don't link everything under the cloud because you can - fonts, frameworks, huge pictures, because it makes your life easier. Self host everything, make it small.
And don't use JavaScript to add an unnecessary layer to 'manage' linking. Clicking on a link is expected behaviour. As are scroll bars. HTML links work perfectly fine and it degrades, nay I say disgraces, user experience.
These basic rubrics will ensure when serving things to 'troublesome' connections, be that bandwidth, blocked 3rd party CDNs or latency, and will largely make sure life will be easier.
Rant incoming - sorry it's been done to death already but I never weighed in before. I will never understand the desire to mess around with custom scrolling on a "normal" page. If you have one of those weird parallax-scrolling visualisations that news sites are often fond of, fine - I don't like them but I understand it's there to present some photography or graphs or whatever in a novel or fancy way. But so many sites that are just serving an article with some pictures override a browser's scroll behaviour in a way that not only adds nothing, but often breaks things. By that I mean it can either just slow or interfere with scrolling in a way that will annoy technical or observant users ... or it can prevent scrolling altogether for a subset of browser/OS or for touch/non-touch users.
But then the warning talks about scroll bars itself.
It's almost impossible not to talk about scroll bars on the web.
There are thousands of different device-configuration-user possibilities, and for each one you get working, several more you'll never know about will also have an easier time of using your site.
It gets kind of addicting, to be honest. The more browsers I try, the better I get at fixing various compatibility issues and removing all but the absolutely necessary from my pages.
I started out with a pretty minimal design and featureset to begin with, but I've been able to actually expand my compatibility matrix while also adding new features by coding minimally and using "historic" LCD JS for most things.
It's shown me that a) each browser has its beauty and unique features and feel b) most browsers are totally valid access devices and I would like to support them all c) we're at risk of losing all the knowledge of how to build a decent website, and I'd like to preserve that knowledge.
The Website Obesity Crisis https://youtube.com/watch?v=iYpl0QVCr6U
https://idlewords.com/talks/website_obesity.htm
The bigger your website is, the more annoyances you can get away with.
You're never going to be able to overcome physics so you aren't going to somehow make a ten megabyte JavaScript monstrosity load instantly over a spotty 3G connection in the middle of nowhere.
What you can do is give some worst case connection the best chance you can to successfully load your page.
Instead of building it all in the DOM with JavaScript send the client the damn HTML. Send some baseline CSS in a style tag. Use CSS patterns instead of big header images or backgrounds. Use box/text shadows to make elements stand out without images. Bundle as much as possible (CSS sprites, JS bundles, etc) to cut down on external resource requests. Minify and compress the shit out of everything. Include a viewport meta tag.
It's not that difficult to have a good looking and functional page that's literally a single HTML page. A single compressed resource that has everything it needs in a single load.
We're actually in an era where the average web browser is extremely capable and isn't some version of IE. Even super low end Android phones have a very capable browser installed by default. You've got HTML5 and CSS3 along with at least ES6 everywhere. The same is true on the desktop in most areas.
There's also just so much shit you don't need in most pages. Far too many people treat a web page like it's some full blown mini OS. There's also a seeming generation of web devs that have no idea what browsers do and think they need to include the kitchen sink to display some text or load resources. You definitely don't need to override scroll events.
You can never make a universally fast page because you don't control the user's environment. But you can make pages and fast and as light as possible so they're not wasting anyone's time or battery. You can also focus on uncached loads because honestly that's going to be a majority of visits.
on iPhone 6 everything is still pretty responsive.
https://www.gsmarena.com/motorola_moto_g7_power-9527.php
3GB of RAM 6.2" screen CPU Octa-core (4x1.8 GHz Kryo 250 Gold & 4x1.8 GHz Kryo 250 Silver) GPU Adreno 506
The battery lasts days, it has an actual compass and it even comes with both a sdcard slot and a headphone jack.
That isn't the lowest of the low but it is 11-16% of the price of a flagship.
You can have a very fancy looking page with a few KB of CSS that will render just fine on even low end modern devices. You'd have to go back almost a decade to find devices that would struggle on such non-demoscene-yet-fancy CSS.
Layout engines in browsers are pretty efficient and a fancy looking page without a bunch of JavaScript churning in the background fucking with the DOM or making a bunch of requests is not that demanding.
The CSS Zen Garden [0] did some fancy ass layouts with CSS 2 and launched in 2003 running on browsers and computers far shittier than today's low end phones and PCs. With CSS3's advancements like transforms, transparencies, and animations there's a lot of effects that can be done entirely in CSS that those old designs needed images to do.
[0] https://github.com/mezzoblue/csszengarden.com
To expand on Cthulhu_'s point: I agree with the gist here but I think this is a bit of a simplification. From the user's point of view, fast downloading is only part of the picture. There's also the matter of render time, the dreaded flash of unstyled content, and related irritations such as banners and popups that appear after the page has seemingly finished rendering. (Wikipedia's current fund-raising drive commits this sin, perhaps deliberately.) All of these things contribute to a sense of the page 'getting in your way'. edit Another one for the list: distracting autoplaying videos. The Ars Technica site does this, for instance.
Sites like Pinboard and HackerNews are compact in terms of avoiding bloated JavaScript, but importantly they also stay out of your way in terms of UX.
A 50KB page, about ten pages worth of text (20kb) and the rest markup and CSS, will load in under two seconds on a shitty 3G connection. There will be no unstyled flash and even on super low end devices first paint will happen a fraction of a second after the document finishes loading. You can do a lot of nice styling in 20kb of CSS. You could even include some inline SVG graphics/logo out of that budget.
With compression which every browser supports you've got an even large budget because you can easily see 2:1 compression ratios on text with just GZip.
If you include explicit sizes for things like image and video tags (width and height attributes) the browser won't need to reflow the layout as those resources lazy load in after the page load. There's no popping or things "getting in the way" if you don't write your page like an asshole or pretend you don't know anything about the content ahead of time. Anymore browsers support explicit lazy loading and media source sets. Not using those sorts of features is just laziness or ignorance on the part of web devs.
My first experiences on the Internet were at the end of a shitty dial-up connection with at best a quarter second of latency. Those experiences have stuck with me and I'm appalled and even a bit offended when a "web page" is larger than a copy of Doom. It's especially egregious when a page weighs that much to display a couple paragraphs of text.
Edit: fixed autocorrect typo
It's pointless to make a website ridiculously fast before making the experience as user-hostile as permissible.
https://addons.mozilla.org/en-US/firefox/addon/i-dont-care-a...
(If not, than an extension just to find and show the correct decline option when it's cunningly encrypted in a sequence of hidden yes/no/no/no/yes/no type slider options with ambiguously written labels would be nice instead!)
- Overly-defensive company policies, which ask for consent "just in case"
- A bandwagon effect of "everyone else is doing it"
The first is quite understandable, and has been policy at every company I've worked for/with. One decided to remove all cookies rather than adding a consent popup; the only cookie we used was for "remember me" on login, so we changed the default to false and put a note next to the tick box. Every other company I've worked for/with has decided to add a popup instead; unsurprisingly, they were also setting a whole bunch of tracking and adware cookies.
The problems I have with the "bandwagon" are that (a) popups are more obvious and memorable than not having popups, which biases the bandwagon effect towards the obnoxious behaviour (availability heuristic); and (b) users seeing all these popups think they must be necessary, and misattribute their cause (e.g. thinking GDPR requires them, rather than companies either playing it safe or refusing to stop surveillance).
You can have as much design as you like.
Bloated website designs don't need tracking cookies, and tracking cookies are the only type that needs explicit consent.
Anything that's not required to provide users with the service they're after must either not track them or ask for explicit consent before doing so.
Analytics answer questions like "is this content worth translating", "is that element a good use of screen real estate", "is this browser worth supporting", "how do people find this page (and what are they looking for)". You can't get that out of a feedback form.
> which is not vital
Not every website is run as a charity.
Hit F12 and go to the Lighthouse tab(?) in dev tools. Very cool!
Full disclaimer, haven't used Wix before, so maybe I'm misunderstanding what it is.
Your usage and content has probably outgrown Wix unless you plan to simply the structure a bit.
Am currently consulting big ecommerce bussiness on how to improve page load. I made them this 'fastest page in the world' demo: https://turboeshop.com/fastestpageintheworld/ - kindly please check it out. And here is fastest page with Google Analytics: https://turboeshop.com/newstackonly/. 325 ms for fully loaded time CSS + images + HTML + JS + GA loaded + Measurement Protocol hits sent.
This is what fast website is: a) inline purged css; b) everything loaded from one domain, 100% cached. c)inlined js(vanilla + web component if you need one); d) inlined images up to 4kb; e) larger images loaded from cache from same domain. f) gtag.js and analytics.js -> from cache; g) Measurement protocol hits sent from async proxy on edge. h) 100% cloudflare cache hits; i) Cloudflare workers for dynamic bits; That's all what it takes. Don't read articles- just make it fast, it's really that simple :)
And as svelte was mentioned - if you want to improve a website that is bigger than your personal blog, you don't use svelte, react, gatsby or any other of that breed as it's impossible to do serious marketing with a website that's hydrated (svelte's web components is a wonderful thing though and is totally nice addition to marketing stack). I mean no insult to anyone with my strong opinions and would be glad to have discussions in comments.
UPD: Added note on Cloudflare & Cloudflare workers.
It's a bit ugly but I imagine with some proper CSS the could make it nicer looking but still fast.
The fonts kill it. On my iPad the page had finished loading but I could not see any text until finally the font had finished loading.
Don’t use external fonts!
If I mark "remember my username", and I hit citibank.com, can't the banking back end start fetching my account snapshot when my browser hits / and then send over that data as soon as I authenticate?
I'm out of the loop so maybe this is already done or too complicated?
Obviously you can "cheat" by having a start page with no data or something similar, but that's not what we are trying to achieve
But if the client data is small enough, that wouldn't actually reduce the latency to speed up the page load, if these assumptions hold:
- Getting the decryption key is subject to an authorisation round trip; current data fetch is subject to the same round trip; and the client data is small so sending it takes about the same time as sending the key.
But the round trip can be brought to a minimum by not requiring a large page full of HTML/CSS/JS to be send on auth - just requiring the client data (or key as you suggested).
All the parts which don't depend on client data can be preloaded asynchronously after the login page is shown, including a template for the page ready to be populated when client data is received.
So:
- Make the login page as fast as possible, using inlined data etc. like any static page. Make the page cacheable, probably validated with an Etag. The remembered "your name" field can be populated, that's fine even if it's cached because the browser cache ("Cache-Control:private") is unique to the user.
- Have the login page preload all non-client-data dependent resources for the next page asynchronously, but ensure these don't start fetching until all resources for the login page itself have finished being fetched.
- When password is entered, perform auth and get client data in a single round trip, combine with the templates just loaded to load the new page.
- Use 0-RTT TLS for everything.
Each interaction will be about as fast as possible while validating with the server, but you can go further if you're ok with relaxing that:
- Make the first page load "instant" by changing the cache policy to validate after a timeout instead of just on Etag.
- Asynchronously preload all the resources for the authenticated next page except the client data.
- Make the authenticated next page "instant" by detecting when the user appears to have paused typing in the password field (or immediately without pause if it's refilled by a password manager or user paste into it), and before they hit enter or click submit, send speculative auth requests which return client data if they succeed, but don't treat the user as properly authorised until they do enter/submit. When they do, use the preloaded client data if it's already arrived (and the password field hasn't changed), and also send an auth-confirm request.
You could conceivably pre-render the backend results before hand but then on first load the visiting user would not see her latest transactions --which is a very frequent use case.
As a side note, it's amazing how modern banking sites keep being really fancy interfaces to years old COBOL backends.
Gatsby devs or advocates would argue removing the js removes the preloading of pages that helps make Gatsby faster. Although this is true, in my experience removing hydration is often a better trade off. It of course depends on the site.
Additional benefit: privacy
If you leave out the cookies as well, you don't even need to ask for allowing cookies.
I use this approach for my cryptocurrency portfolio site [1], comments welcome
[1] https://www.cryptoport.net
1. Tailwind CSS classes extracted with purge-css, all inlined.
2. Favicon inlined, small images (<4kb) inlined. Not sure what’s the best threshold. Here is all https://turboeshop.com/inlinedimages/ is all page in one requests. Meaning two big images that are https://turboeshop.com/fastestpageintheworld/ were inlined - results are way worse. So larger images - definitely excluded.
3. Gzip stuff(as one commenter below commented, not done in turboeshop.com/fastestpageintheworld/).
4. Everything from same domain and subdomain. If you want cloudinary or friends, I guess they are only allow subdomain. This is totally OKeish exemption. Or maybe there is a way to work around that cloudinary serves, Cloudflare caches.
5. JS - inlined. Cash.js maybe if you need jquery replacement, or just vanilla. Little content on vanilla js nowadays :), https://gomakethings.com/articles/ is something interesting. Don’t want to flame here, am not js expert, maybe someone can elaborate.
6. For compex components - svelte web components (or stencils or lithtml) - I’d prefer svelte but am not sure what’s best.
7. Google analytics a) - there is new google analytics (GA4) with measurement protocol2 and new server side google tag manager. Serve side gtm does two things a) serves gtag.js; b) accepts measurement protocol hits and sends to GA. Take a look how it’s done - https://www.simoahava.com/gtm-tips/build-custom-universal-an... , it’s very similar as cloudflare workers, cool stuff. But it’s hosted on Google App Engine, thus - slow. But you don't need google's server anymore, you control full infra, so why not setup simple cache here.
8. Google analytics b) To owerome latency to Google App engine, so you make async proxy in cloudflare workers - one worker to proxy for gtag.js download, one for serving gtag.js from your own domain. <script src=“http://yourdomain.com/workers/gtag/js?id=G-1234455> . Basicly just serve from js cache and check every once in a while if google hadn’t changed their code. Same for GA hits. It used to be google-analytics.com/collect endpoint, server side gtm allows to host collection yourself. You again make worker-proxy, define it in gtag’s transport_url:'https://turboeshop.com/measure' setting and make sure worker returns non-blockingly, and just then forward the measurement protocol hit from worker async-ly with event.waitUntil().
9. Google analytics c) The gtag.js/analytics.js is a huge file and you have no control, so maybe just use https://github.com/segmentio/analytics.js instead or check out https://www.thyngster.com/app-web-google-analytics-measureme... (search “navigator.sendBeacon”) - craft measurement protocol yourself and send it to gtm. I plan on investigating this but have not yet done that.
10. All the stuff (fb tracking pixel, etc.) you are used to just ‘putting in html’, you instead send as measurement protocol hit dimension and do ETL in google tag manager.
11. All the...
For speed, also check cryptomarketplot.com - essentially the same techniques
A few other things: GZIP and HTTP2 help a lot
I guess both counts. :)
But I agree with you that core problem is that many websites are ACTUALLY slow and bloated.
They should be small (or nonexistent in the case of js), but I believe they should be separate, and proper caching enabled. This means that the first page load may be milliseconds to a second longer, but any other page loads after will be instant since those resources will be pulled from cache.
Note: I am assuming that the web page under load is really small, 50 kb or less.
I welcome anyone who disagrees to say so. I acknowledge that I could still be wrong.
Edit: spelling.
I know it's a often a matter of limited time and resources but honestly I would take a bet that more than 50% of the websites you could visit would be unusable or at least functionally unusable without JavaScript.