I am building a personal blog using Hugo and deploying it to Netlify, and I ran it, out of curiosity, through the Chrome Lighthouse. To my surprise, the results for desktop and mobile differ dramatically.
The blog is not optimized (yet) for mobiles, but it uses mostly relative sizes so the aspect on the mobile is what you would see by choosing "see desktop version" on a mobile Chrome.
There are three results that are particularly impacting: First Contentful Paint (FCP), Largest Contentful Paint (LCP) and Time to Interactive (TI).
The results are beow (in seconds), the number behind Desktop or Mobile is the performance index. In summary:
the results from localhost and the deployed site are negligeable (so this si snot a matter of latency, serving performance, ...)
LCP and TI are both bad for mobiles, at the same level of "badness" (which reinforces the point above).
http://localhost:1313
Desktop → 99
First Contentful Paint (FCP): 0.2 → OK
Largest Contentful Paint (LCP): 1.0 → OK
Time to Interactive (TI): 0.9 → OK
Mobile → 77
First Contentful Paint (FCP): 1.7 → OK
Largest Contentful Paint (LCP): 5.5 → NOT OK
Time to Interactive (TI): 5.0 → NOT OK
https://mysite.example.com
Desktop → 99
First Contentful Paint (FCP): 0.4 → OK
Largest Contentful Paint (LCP): 1.0 → OK
Time to Interactive (TI): 0.9 → OK
Mobile → 77
First Contentful Paint (FCP): 2.0 → ~OK
Largest Contentful Paint (LCP): 5.3 → NOT OK
Time to Interactive (TI): 5.0 → NOT OK
What can be the reason for such behaviour?
Chrome Lighthouse tests on mobile and desktop are testing more than just rendering at a different screen size. The mobile testing profile used by Lighthouse attempts to approximate the average mobile device user by throttling network speed and CPU power of the browser loading the page. This is referenced in the Lighthouse docs
Lighthouse reports the performance metrics as they would be experienced by a typical mobile user on a 4G connection and a mid-tier ~$200 phone. Even if it loads quickly on your device and network, users in other environments will experience the site very differently.
Read more in our guide to throttling.
The exact numbers used for the mobile profile are linked from the throttling doc, but suffice to say it's definitely slower than your desktop machine.
The desktop Lighthouse settings do not include network or CPU throttling, hence the slower performance measurements you are seeing when running with the mobile profile when compared to desktop.
Related
I'm running a learning app written in react. The average session duration is 15 Minutes. Recently some Safari users (mobile and desktop) reported that the apps feels laggy after a fair bit of use (answering questions).
I monitored memory used in safari and answered some questions in the app. After a while, there is a spike in page memory usage (a ridiculous amount). A minute later page memory goes up again and stays there. From there on the app feels quite laggy.
The vast majority of javascript events are Animation Frame Requested and Animation Frame Fired events. That's why I thought that animations may be the culprit. I'm using react-spring and found this open issue.
I can only run safari in a docker container on my Linux machine, as I don't have an apple device (https://github.com/sickcodes/Docker-OSX). Maybe that is the reason for the weirdly high amount of page memory usage (I wish I had that amount of RAM).
I'm kind of stuck and don't know how to proceed. Did anyone experience similar issues with react, react-spring and safari?
I am not a programmer nor developer and although I followed the links on Google to remove the problems it showed, I do not understand a thing. Therefore I would like to ask you to tell me in some comprehensible words what I should do to rectify the optimisations so that the speed of my pages is as it should be.
UPDATE
Reduce server response time
Your web server is TOO SLOW!
Getting a better ISP/Host is the easiest way to significantly speed up your page. This will speed things up about 10X. All those 600-900ms response times in the waterfall should be one tenth the time.
For example your style.css takes only 7 ms to download the file, but the server waited 632 ms to send the first byte. This is almost a 100X unnecessary delay.
URL: https://moreyouthfulskin.com/wp-content/themes/wellness-pro/style.css?ver=1.0.0
Loaded By: https://moreyouthfulskin.com/en/home/:59
Host: moreyouthfulskin.com
Request Start: 5.951 s
Time to First Byte: 632 ms
Content Download: 7 ms
Bytes In (downloaded): 7.9 KB
Uncompressed Size: 36.9 KB
Bytes Out (uploaded): 0.2 KB
This above data is from this link: Web Page Performance Test for https://moreyouthfulskin.com/en/home/
Leverage browser caching
The 1 day cache is not a big deal, it is a small issue. It is more of a warning. It is a web server setting. It is not worth much effort when you have so many other serious issues.
Eliminate render-blocking JavaScript and CSS in above-the-fold content
The CSS after the JS is big. This is usually caused by WP plug-ins. Only use plug-ins that do not degrade performance. Check your page speed be and after installing any plug-in. Then think about whether it is worth it.
Remove or at least speed up the redirects.
Your redirects are costing you because your web server is too slow. Get a new ISP. The two redirects took over 5 seconds. This means there is an unnecessary 5 second delay before the page even begins to load the first byte of the home page.
Optimize images, Minify JavaScript, and Minify CSS
At the bottom of Google Pagespeed results there is a link to Optimized images, Minified JavaScript, and Minified CSS. Download them, then upload them to the proper directory/folder on your server. This one is easy. If you cannot do this then you are in this way over your head.
END OF UPDATE
Your biggest issue is you have CSS and fonts being loaded after the JavaScript. This is costing you about 5 seconds load time.
Also your page load had two redirects using 2 seconds.
Your server needs to be configured to use a longer max-age cache .
Curently your cache is 14400 seconds. cache-control: public, max-age=14400
Is there a good solution for A|B Testing in mobile apps like online? I know with iOS it's against the TOS to have different user experiences with identical actions, but what about Android? And what about firms like Apsalar which claim to offer A|B Testing in their analytics for apps? How would one implement that?
Artisan mobile makes an A/B testing solution for iOS and Android.
The basic idea is that you drop the SDK in your app and then put it out in the app store. You can use the service to create A/B tests and optimize your application without having to touch the code or go back through the app store for each test.
For mobile apps, A/B testing basically works by replacing static, hard-coded objects with dynamic objects that can be controlled from a remote server.
This methodology raises a potential performance issue: What if the end user's device is not connected to pull configuration data for an object being tested? We've built Splitforce (http://splitforce.com) to seamlessly setup and manage A/B testing in mobile apps while controlling for performance risk.
Los details
Once the SDK and experiment has been integrated, non-technical product or marketing folks can setup new tests or tweak existing tests on-the-fly - without having to resubmit to the app stores or hassle engineers.
On first app launch, the mobile app requests configuration data from the server and then caches that data locally on the device. This is to both ensure a consistent user experience on subsequent app launches, and prevent corrupt test results by guaranteeing accurate attribution of conversion events to variations.
If the end user's connection fails or is timed-out on first app launch, the library displays a hard-coded 'default' variation. And to make sure that everything is looking good before you go live, we've built a 'shake to preview' functionality in debug mode that does just that :-)
Once the app is deployed with Splitforce event data are stored locally and sent back to the website to be displayed for each variation alongside measurements of observed improvement and statistical confidence.
Instructions on integration of the SDKs and new tests can be found at https://splitforce.com/documentation.
And how is it used?
We've seen Splitforce used to A/B test:
UI elements + layouts (color, text, images, ad/menu placements)
UX workflows
Game dynamics + rules
Prices + promotions
We've also seen the tool used to control mobile apps remotely, by essentially setting one variation of a test subject to 100%.
Yes there is: E.g. the company Leanplum offers a Visual Interface Editor for iOS and Android: This requires no coding, and Leanplum will automatically detect the elements and allow you to change them. No engineers or app store resubmissions required.
Apple must have updated their TOS (https://developer.apple.com/app-store/review/guidelines/#user-interface) - At least I am not aware of anything that prohibits altering the UI in a way that the Leanplum Visual Editor is doing it.
Generally that is achieved by method swizzling (iOS) and reflection (Android).
To learn more about the Leanplum Visual Interface Editor, check out leanplum.com. They offer a free 30-day trial.
(Disclaimer: I am an Engineer at Leanplum.)
I wrote a small open source project called Switchboard.
It let's you A/B test, remote configure and stage rollout things in your native mobile app. It contains a server component that specifies what information the application should have and 2 native clients for android and iOS.
You can find the codebase at github.com/keepsafe/switchboard and a blog post about how you can use it HERE
The new kid around the block is Arise.io. They provide an A/B testing service for iOS and Android.
I wrote MSActiveConfig, an extremely flexible framework to do remote configuration + A/B testing on iOS, with a portable format to be able to implement clients on other platforms: https://github.com/mindsnacks/MSActiveConfig.
This framework is being used in applications with more than 5 million users.
There have been a spate of new entrants in this field...you could check out Swerve, Appiterate, leanplum...all of them seem to be having SDKs for iOS as well, not really sure whether and how Apple TOS allows for that, but since there are some many of them doing it, there must be a way.
Yes, new entrants are showing up in app A/B testing practically every week! But, I think Appiterate has gone two steps ahead of other competitors by creating a visual interface, without any need to re-write code. I have seen their platform (you can ask for an invite. I got a demo within 12 hours) and believe me, it is actual WYSIWYG that they are providing.
I just heard that a company I do work for may be bringing in the Pyxis Mobile application development system. When I google it most of what I find is from the company's web site and that is not very informative from a geek perspective. Can any one shed some light on what sort of programming environment it is and what programing language is involved (please let there be a text based language). Any additional information would be great.
Note: the company/product changed their name to Verivo in January.
Full Disclosure - I work as an engineer at Pyxis Mobile. However, I have been in the mobile space for 7+ years and have evaluated several approaches to mobile so hopefully this is helpful.
Pyxis Mobile provides a set of tools and components to build cross platform mobile applications. Let me outline them first.
1. Application Studio - All application development, backend integration, user provisioning and application maintenance/debugging is done w/in this tool. Application Studio (for now) is a Windows based desktop app.
2. Application Clients - Pyxis Mobile provides native client runtimes for iPhone, iPad, BlackBerry, and Android devices. These runtimes get branded for the customer through a build service and are primed to point to a specific Application Server URL.
3. Application Server - Pyxis Mobile App Server runs on the .NET stack (on IIS). All client communication is proxied via this server. This server is able to connect to varied of backend systems (via the Plugin Framework listed below) and respond to the client in a mobile optimized manner. This server needs a SQL Server (2005 or newer) for configuration access, session management, logging and more.
4. Plugin Framework - The Plugin Framework is a backend component that provides system specific pre-built access to several of the enterprise and cloud based systems (Oracle, Siebel, SAP, Salesforce.com, social feeds, REST/SOAP web services, etc.) and also offers an API layer in .NET and Python (using IronPython) to allow even further customization. A plugin is essentially comprised of one or more DLLs or a Python file. These assets are then dynamically loaded to normalize communication between Pyxis Mobile and the customers' backend systems.
5. Push Services - This provides a cross-platform push layer that can poll a backend system for change and alert a mobile device via BlackBerry Push, Apple Push Notification Services (APNS) or Android's Cloud to Deice Messaging (C2DM).
6. OverWatch Analytics - This is an optional (but included) component to track users/devices and provide integrated analytics on what the users are using and what kind of devices and locales makes up your users.
The application itself is "coded" via configuration that is build in App Studio. Pyxis Mobile abstracts away from the code so that you can work at a higher level without having to worry about the wide array of device variances (GPS, touch screens, camera, accelerometer, push, screen resolution, etc.). You can drag fields onto a from, connect screens via menus or buttons, set up caching rules and more in this graphical utility. This configuration (essentially think of an XML like document) is interpreted by the native client layer to produce a rich application. There is also a scripting layer in Lua that allows to really customize behavior via code.
The real value of Pyxis Mobile comes up when you have change to make. The clients check for new configuration at app startup or if the server forces the client to get new configuration. This gives you great agility. Lets say once your application is deployed you want start using the swipe gesture to go next/prev through a set of records. This change on other platforms would mean writing some platform specific code to trap and interpret the swipe to perform a navigation (you couldn't trap a swipe on a non-touch screen). However, in Pyxis Mobile this is a simple configuration change that can be quickly deployed to the App Server and the clients automatically download and use the new configuration. No compilation, no redeployment or re-download for the end users.
I could keep going, but hope this provides some level of guidance.
Beware of Pyxis Mobile. While many of the things they say do work, there are some serious platform issues (as a geek) which I've experienced.
1) No version control system process. The Application studio can basically only be developed on by one person at a time or you risk having your changes overwritten by a fellow developer. The "principle of last save" is very much in play.
2) No unit test coverage. This isn't the biggest issue for a lot of people, but it's a concern for anyone who wants to work in the Enterprise world.
3) The middleware server gets you some value, but it's also a PITA to work with. There is no concept of "client side storage" unless you consider the middleware server the client side. If your phone goes out of coverage, your app won't work. Again, this might not be an issue for you.
4) The application has no true scripting language to work with. The middleware server allows you to intercept requests and responses and modify what you're doing there, but it's not the most elegant solution considering that a native application can have something as simple as "if this then X else Y." This can be accomplished with Pyxis, but the whole process is convoluted and more complicated than one would think it needs to be.
5) Lack of documentation. There's some training guides and the GUI is easy enough to get around for simple apps; however, when you need to do something with guts, you're left relying on Pyxis professional services. There's really no developer community to pose questions to.
I have more complaints, but they are more opinion oriented than Q/A oriented.
I just got note about the most recent comments. I don't want to turn this into a thread of back and forth, but did want to throw a couple of quick notes.
Regarding the points on version control and documentation/developer community - no big contest there. We are definitely working on these shortcommings. We have some basic pieces in place, but we have big plans to focus on this.
Regarding unit testing - we provide a very open interface to our middleware and backend components and they can be very easily unit tested with a bit of instrumentation. We run a ton of unit and integration tests internally. However, mobile unit testing is extremely difficult to get right. We'll investigate this further.
Regarding #4 around middleware and offline capabilities - things are a lot different now. With version 7.1, 7.2 and 7.3 our products have increasing become more capabale offline and now features a secure local database if necessary. I can provide more details as necessary, but you can certainly login and operate the app even if you are out of coverage for weeks at a time!
Regarding #5, we've had a scripting engine for over 2 years. Its Lua based and its actually quite powerful and fast. It was BlackBerry only till the most recent release. Given Apple's change of stance on allowing scripting we now allow scripting on BlackBerry, iPad, iPhone and Android as well now!
#RockMeetHardplace - feel free to reach out to me directly and I'll be happy to give you more detailed live demos of our latest platform. I am at - arunSPAMNOTatpyxismobiledotcom (drop the "SPAMNOT" and replace the at and dot). I happen to be the Director of Software and interested in knowing more about the issues you had.
I would like to start developing mobile-friendly versions of websites for my clients, however, I am baffled with options and google search wasn't very helpful - there is so many options and opinions, I've been reading for few days now and still have no idea how to start.
What's your opinion/experience about/with it?
My main points:
mobile devices supported (in order of relevance): iPhone 3G, iPhone 2G, Blackberry, Droid powered mobiles, other
phone friendly numbers, phone friendly emails
contact/register form working on each (or the most possible) devices listed
jQTouch seems superb (simple, quick, working), I'm not sure about it on blackberry/droid and I don't want to create 6 web versions for each mobile device - Makes even less sense if you consider, that I'm starting with small web (6-10 pages, 1 contact form, 3 register forms) to play with.
Thank you
my 2c;
the best approach is the one we use on the web as we know it; cross-browser development.
use (basic) html & css to start with (ensuring you'll reach as many handsets as possible) & progressively enhance by adding more complex stuff (javascript & more specific css) for more advanced devices.
jqtouch (which has to be combined with jquery if i'm not mistaking) is swell, but very much iphone-centric (some of the nifty css-stuff doesn't work anywhere else). a (slightly) more cross-platform js-framework is the jquery-like xui.
once you have something up and running, testing it on mobi.ready might be a good idea.
Have you heard of NetBiscuits?
http://www.netbiscuits.com/
Check out the mobiforge site, which is run by dotMobi. They have a very powerful tool called ready.mobi which you can use to get a health check on your mobile site. The results give advice on what you need to do to improve your site, so getting a really well optimised site is simply a case of testing and taking note of the recommendations. Mine now get 5/5 scores as a result of using it and work really well on any device, including many I never really tested it under. I can't recommend it enough.
Mobile Devices: See QuirksMode.org for charts, tutorials, and more to get your pages working on multiple mobile browsers. (Blackberry might be the hardest on your list)
Phone friendly links: Not sure why this would be difficult, as far as I am aware, all mobile browsers/OS's support the same mailto: protocol that desktops use. Most phones also support tel: so you can have links like:
Call Me
The only issue there is desktop computers generally don't have a way to handle that standard despite being able to link with Bluetooth phones. (Feature request for those in OS development)
Contact/Register Forms: Again, most mobile browser support basic form elements out of the box, the key here is more user experience. Anything you can do to reduce the amount of data entry will lead to more users filling out the form. (Remember the user's session info for a long time, they will go back to the page after they finish the 2 hour call from their mother)
I'd suggest going with a responsive framework like zurb or bootstrap. If you stick with what the frameworks have, you can have one codebase of the site that works in mobile browsers also.