What I would like to do is run a simple and fast Javascript benchmark when a user first access my web application to detect his computer's capacity to animate elements. I remember a teacher did this in college to adapt the frame rate of his game depending on the user's machine.
Is it something that could be done without sacrificing too much user resources? Maybe a few seconds after the page is loaded? And if the results are not good, we just disable some or all animations for this user.
To answer the questions that you asked in your post:
1) It is possible to run a JavaScript benchmark when a person first loads your site that will test their capacity for CSS/JavaScript animation speeds, but it will sacrifice several resources. You have to consider the people who will be accessing your site. If they're going to be accessing your site via a mobile device, the last thing you want to do is bring their device to a standstill and either freeze their browser or bump other apps out of memory. You don't want either a desktop or mobile user to think that the site is unresponsive.
2) One of the issues with waiting a few seconds after the page has loaded is that, depending on what you want to do with the site, people will start to try to scroll through your content. If they start to scroll and realize that the site is "stuttering", they may think that something is wrong with their device.
Another caveat is that if you want the smoothest animations possible, you may end up using requestAnimationFrame (see https://hacks.mozilla.org/2011/08/animating-with-javascript-from-setinterval-to-requestanimationframe/). If somebody loads your site and then clicks away from it to a different tab while your test is running, browsers have adopted the practice of reducing the framerate in inactive tabs in favor of those in the active tab. Testing based on this (incorrect) framerate capability will result in parts of your site being disabled for people who are perfectly capable of running your site with all of the animations intact, so that's something you may need to take into account.
In some tests that I ran a couple of months ago, the CSS3 version of an animation was almost always smoother than the JavaScript version of an animation. However, there are now jQuery libraries that bridge this gap by using CSS3 animations when possible, such as jQuery Transit (http://ricostacruz.com/jquery.transit/).
Related
I've made a website that displays certain posts from Instagram, Facebook and Twitter. The website shows these posts in card form with certain animations and transitions. It works fine on the desktop but the goal is to run it on raspberry PIs and, when run from one of those, the animations and videos stutter. I want to reduce or eliminate the stutter and I'm considering several approaches:
web workers to offload some of the animation calculations to a separate CPU core
dynamic video compression on the server depending on what device will be playing the video
different animation methods
To figure out if any of these would help I'd want to first figure out what is actually causing the stutter but I don't know how to do this. I need a way to figure out what portion of the slowdown is due to what issue. Like, what's the impact of loading the images/videos, the impact of playing the video, of animating the elements etc. What is the best way of doing this?
Here is the working version of the site if that will help with the suggestions. Note that I'm not highly experienced with JS or programing in general and I was just starting out when I created this so it's far from optimal but now I need to figure out the best way to improve it.
This is probably a performance issue, but it could be something else. If you're using VNC Viewer or some other form of remote desktop, it could be because of that. If it's just wired to a monitor, though, it's most likely the fact that the CPU can't handle it. You could try to install a more lightweight browser, because Chromium can really take a toll on the CPU. Go to Chrome DevTools, and go to the performance tab. This should show you basically everything you need to know. I'm not sure if you're using CSS transitions or something else, so I can't really help you there. You could try NetSurf or Dillo as more lightweight browsers, though.
From about 2 months ago, I got back to work on my fully custom ecommerce regarding the optimization of the front-end on pagespeed, in view that googlebot now carries out measurements of parameters such as CLS and LCP for which they have the criticality and part of determining if that particular page goes under index in the google crawler.
I did all the optimizations that I managed like:
extraction of critical css online
all non-critical CSS merged and parsed inline
mod_pagespeed
image and JS under CDN
nginx optimization
moved non-core JS below close to body closure where possible
deferring non critical JS
preloading, prefetch and many other things that I don't remember now done during the long nights spent studying the template
So now, i reach a great result compared of the previous 2 months.
The only thing I can't explain is that I have high Time To interactive, CLS and LCP in mobile mode, When the desktop version is just fine.
I am puzzling myself, trying to find the key to the solution.
This is an example of a product page: https://developers.google.com/speed/pagespeed/insights/?hl=it&url=https%3A%2F%2Fshop.biollamotors.it%2Fcatalogo%2FSS-Y6SO4-HET-TERMINALI-AKRAPOVIC-YAMAHA-FZ-6-S2-FZ-6-FAZER-S2-2004-2009-TITANIO--2405620
and here is the homepage which has acceptable values compared to the product page, but still the time to interactive is much higher than the desktop: https://developers.google.com/speed/pagespeed/insights/?hl=it&url=https%3A%2F%2Fshop.biollamotors.it%2F
Thanks in advance to all expert mode users who will be of help to me.
Why are my mobile scores lower than desktop?
The mobile test uses network throttling and CPU throttling to simulate a mid range device on 4G so you will always get lower scores for mobile.
You may find this related answer I gave useful on the difference between how the page loads as you see it and how Lighthouse applies throttling (along with how to make lighthouse use applied throttling so you can see the slowdown in real time), however I have included the key information in this answer and how it applies to your circumstances.
Simulated Network Throttling
When you run an audit it applies 150ms latency to each request and also limits download speed to 1.6 Megabits (200 kilobytes) per second and upload to 750 megabits (94 kilobytes) per second.
This is very likely to affect your Largest Contentful Paint (LCP) as resources take a lot longer to download.
This throttling is done via an algorithm rather than applied (it is simulated) so you don't see the slower load times.
CPU throttling
Lighthouse applies a 4x slowdown to your CPU to simulate a mid-tier mobile phone performance.
If your JavaScript payload is heavy this could block the main thread and delay rendering. Or if you dynamically insert elements using JavaScript it can delay LCP for the same reason.
This affects your Time To Interactive most out of the items you listed.
This throttling is also done via an algorithm rather than applied (it is simulated) so you don't see the slower processing times.
What do you need to do to improve your scores?
Focus on your JavaScript.
You have 5 blocking scripts for a start, just add defer to them as you have done the others (or better yet async if you know how to handle async JS loading).
Secondly the payload is over 400kb of JS (uncompressed) - if you notice your scripts take 2.3 seconds to evaluate.
Strip out anything you don't need and also run a trace in the "performance" tab in Developer tools and learn how to find long running tasks and performance bottlenecks.
Look at reducing the number of network requests, because of the higher latency of a 4G network this can add several seconds to you load time if you have a lot of requests.
Combine as much CSS and JS as you can (and you only need to inline your critical CSS not the entire page CSS, find all items used "above the fold" and inline them only, at the moment you seem to be sending the whole site CSS inline which is going to add a lot of page weight).
Finally your high Cumulative Layout Shift (CLS) is (in part) because you are using JS to hide items (for example the modal with ID comp-modal appears to be hidden with JS) on page load, but they have already rendered by the time that JS runs, easily fixed by hiding them within your inline CSS rather than JavaScript.
Other than that you just need to follow the guidance that the Lighthouse report gives you (you may not have paid much attention to the "Diagnostics" section yet, start looking there at anything that has a red triangle or orange square next to it, each item provides useful information on things that may need optimisation.).
That should be enough to get you started.
I am working on a HTML canvas app that displays graphics to the screen. The graphics aren't important for the website, they just make things look pretty.
My problem is the app needs the cpu of the device to run at a certain speed or the frame rate becomes unacceptable.
Any modern phone/laptop can easily run the app, but of course not everyone has updated tech.
At that point I'd like to drop support for the device and stop rendering the animations because it will just do more harm than good.
This idea is pretty standard on the internet. For example if you want an image background for your site, but you don't want mobile phones to load the same large image as desktops then you just use some css queries to only serve the image to desktops.
This is how we can get new features pushed out while keeping backward compatibility.
However when it comes to detecting performance this isn't as easy of a task as it sounds. There's no way to get cpu specs with Javascript, and even if I could there's no way of telling what else the user is running on their machine.
This leaves me with 2 options, either run a small performance test before I start the canvas app. Or start the app and try to run a few frames and stop it if the frame rate is too low.
The problem is both of these options are pretty sketchy because the device may just have a "speed hiccup" at the start of the app, and so I shut down the animations for nothing.
Also if a user has a device that sits right on the border of the threshold sometimes the animations will load, and sometimes they won't which would probably be confusing.
Is there any "standard" on the internet to deal with this sort of problem? Would it be best to leave a footnote at the bottom of the site window when animations are turned off?
Or is it just something you have to accept when pushing the boundaries and dealing with performance?
I'm having a issue which is hard to debug. I'm using a Javascript library (the JQuery Flexslider plugin) in a number of different places on my site. It's all working fine except for one particular phone where it doesn't work and slows down everything on the page.
So far, I've only seen it happen on this one device. Other devices of the same type do not have the issue. This person has an iOS that's a few versions out of date and not much memory, so I think it's a memory issue.
An old hack was to move the carousel element that has the issue on the page with Javascript, but I want to find and fix the root issue.
How can I start debugging this? I'm not sure how to test for a memory issue on a device.
If you're on a Mac, then you can plug in and use remote debugging via Safari, where you'll have access to the tools, including the profiler (not sure the state of Safari support in Windows). There are numerous resources for showing how to remotely debug a device, unless it is a really old version of iOS you should be fine, you’ll have to enable the develop menu via settings but after that its plain sailing if you know your debugging tools.
I'd agree that it doesnt really sound like a memory issue, although jQuery tends to be hungry in that respect, I dont know the plugin in question but the quality of plugins is hugely variable in jQuery-land. Old phones and old versions of jQuery certainly never played well together.
When you say one phone, you mean one type of phone + iOS version? The question isnt clear, its almost reads like you have 2 identical phones/os's where 1 works and 1 does not.
If you use Chrome you can use the Heap profiler
First open your developer tool and start recording.
Next start using your page and try to replicate your issue, stop recording and review the stats.
This is likely not a memory issue, but a cpu issue. The way jQuery does animation is processor constrained on older dvices. Factors that are easiest to handle include:
size of the page (html length and complexity)
animation steps, length, and complexity
You have a couple of options here, but the simple answer is you are asking too much of the older processor. Assuming you are using this plugin http://www.woothemes.com/flexslider/ you could try disabling or simplifying some of the transition effects. animation and animationSpeed would be the first I would suggest.
If you are interested in not changing the experience for most users you could consider tying into the start and end functions on the callback api and checking the time it took to perform the first transition, then reinitialize a simpler version of the slideshow for that device.
The hard thing here is there isn't really a right answer. If one of the above options doesn't fix it you're likely looking at choosing/building a different slideshow, degrading the experience for everyone, or determining the best way you feel comfortable with choosing who gets the degraded experience.
I have made some pretty resource-intensive items on my new site's design, and I'm a bit concerned. While testing on different computers, I notice some simply cannot handle the computer generated art/animations nor 1080p video. This could be a problem.
So I'm already planning to test their Internet speed (or at least, that it's sufficient) using a "control file" and timing the response, but how can I (or what would be the best way) to do so for checking hardware?
So far I have:
Use a short 1080p video, test the time to download. Test start-finish time, see if there's lag.
Use a loading page with 2 gateways: one for regular, one for enhanced. Above the "door" to enhanced, have some heavy javascript animation - if it lags, they should click 'regular
'.
*loading page will likely be cookie-dependent overlay, don't want to send them to home page from search.
I'm not wild about either of those ideas, and I already strip the resource-intensive items for sizes under 700 or so. Kind of a "why should some suffer for others lacking" deal. Eventually all computers can handle it, but I can't be freezing their devices just to put on a good show.
Update
3 . Have an "awesome" page that records the destination URL, does some fast JS animation (totaling under 3 seconds), and says "testing device capabilities" then "proceed to site". This would automatically determine the best version and give them something cool to look at while it's testing.