5 ms·
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 pre
by giantrobot 6y ago
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.
- container 6y agoI 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.
- knuthsat 6y agoyes, on Nexus 5X that I've had since 2016, chrome and firefox are very slow until they render the page, then scrolling works ok. on iPhone 6 everything is still pretty responsive.
- ahelwer 6y agoI 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.
- michaelmrose 6y agoMotorolla G7 Power. Retails unlocked for around $160 bucks and available to safelink wireless aka free Obamaphone plan users for $110. https://www.gsmarena.com/motorola_moto_g7_power-9527.php 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.
- Cthulhu_ 6y agoTo 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 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.
- giantrobot 6y agoYou'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. [0] https://github.com/mezzoblue/csszengarden.com https://github.com/mezzoblue/csszengarden.com
- MaxBarraclough 6y ago> 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.
- giantrobot 6y agoThe 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. Edit: fixed autocorrect typo