I'm trying to reduce my page load and I'm loading https://www.paypalobjects.com/api/checkout.js however it is 136k compressed and 877k) uncompressed. Its contents don't seem minified and there is the comment in the code that says:
To debug, please use the unminified version of this script at
https://www.paypalobjects.com/api/checkout.src.js
I looked at https://www.paypalobjects.com/api/checkout.src.js and see that it is a mere 56.1k (234k uncompressed).
I performed a basic test with the smaller one locally in sandbox mode and it still shows the incontext window and did a transaction.
I noticed the that the larger https://www.paypalobjects.com/api/checkout.js does some sort of beacon calls for logging but what justifies the huge increase in size? It's not good for mobile users. Docs explaining the difference would also be useful.
Is it ok to use https://www.paypalobjects.com/api/checkout.src.js ?
It it ok to async the < script> tag too?
Related
We have been using the following library for months:
https://unpkg.com/react#15.3.0/dist/react.min.js
Yes - I know we can just reference 15.3 and get the URL rewrite to the latest, but they released a breaking change. That's another issue for another day. Don't get distracted.
Yesterday this simply stopped working. You'll notice that if you load the URL mentioned, that the file is TRUNCATED. Simply cuts off. This made everything we use react with break. Interestingly, if you go to the following URL (without the .js extension) - things work.
https://unpkg.com/react#15.3.0/dist/react.min
My question is - what the heck happened? Why did the URL we've been using for 8 months suddenly stop working, and who can we get to fix it. In the interim, we had a copy locally that we've started referencing (which we probably should have been doing to begin with, since we don't want the automatic upgrade). When things like this happen, who do you inform?
I'm not sure you'll find the answer as to why this file is no longer working here but based off of the website you could reached out to the creator on twitter: https://twitter.com/mjackson
On the website it says:
SUPPORT
unpkg is a free, best-effort service and cannot provide any uptime or
support guarantees.
i.e. you should probably only use this link if you are messing around with a small project and shouldn't be used for any website where you actually care about the uptime of the site.
What can cause the start render to be delayed even after the load event has fired?
Look at this webpagetest result
This is most probably a bug. For the moment, the iPhone instance on WebPageTest is quite recent and the author is still improving it:
The iOS support is just becoming stable though it's still under VERY active development so don't be surprised if there are a few rough edges (and a lot more limitations than the android testing).
- Patrick Meenan, 09-09-2015
The android tests are much more reliable.
If you check the page you tested without javascript (F1 > Disable Javascript in Chrome DevTools), you can see that most images are lazy-loaded, which mean they are loaded via a JS script checking if the images are in the viewport. As you can see, without JS the load time line is well after all assets loaded.
Also for other assets, like JS, you can add an async or defer attribute to de-synchronize your scripts loads.
Finally, some scripts can be even deliberately loaded after the load event using an attachment on the window load event to write <script> tags in the body when it's triggered as loadJS do for example.
You should read that by the way to better understand how rendering and events timing work.
Reading the Goole 2010 IO pdf of : "Architecting for Performance with Google Web Toolkit", I found this approach to reduce startup time :
Better: 2 round trips:
First:
- Host Page
- Script URL
- Initial Data
Second:
- Compiled Script
It is not the Default GWT setup:
4 round trips
- Host page
- Selection Script
- Compiled Script
- Initial Data
My problem is that I do not how to do to acheive the "2 round trip solution". Could you help me ?
It's actually rather easy:
inline the selection script in your page (can be done with a special GWT Linker, or using a JSP include directive for instance –I've successfully been using the latter, much easier– and add a <meta name='moduleName::gwt:property' content='baseUrl=moduleName/'> to tell the inlined selection script where to find the compiled permutation.
Technically, you could go even farther and replace the selection script with server-side content negotiation. I believe Google does that (e.g. for Google Groups) but it's a bit harder (made way simpler with modularization of the CrossSiteIframeLinker, but still not that easy).
for the initial data, see https://developers.google.com/web-toolkit/articles/dynamic_host_page and http://jectbd.com/?p=1174 (I've been using AutoBeans to pass user information and application settings to the GWT app)
I have a single-page web app that presents a multi-step photo management "wizard", split up across several discrete steps (photo upload, styling, annotation, publishing) via a tab strip. On switching steps I set the URL hash to #publishing-step (or whichever step was activated).
How do I set up Optimizely tests to run on the various discrete steps of the wizard?
The browser never leaves the page, so it only gets a single window.load event. Its DOM isn't getting scrapped or regenerated, but just switches what page elements are visible at any one time via display: none or block, so the part I am trying to figure out is really mostly about in what way I go about the Optimizely test setup itself - it's fine (and likely necessary) if all edits get applied at once.
This thing unfortunately has to work in IE9, so I can't use history.pushState to get pretty discrete urls for each step.
There's actually several ways you could go about doing this, and which option you choose will largely depend on what's easiest for you AND how you plan to analyze the data.
If you want to use Optimizely's analytics dashboard:
I would recommend creating one experiment which will activate a bunch of other experiments at different times. The activation experiment will be targeted to everyone and run immediately when they get to your wizard. The other experiments will be set up with manual activation and triggered by this experiment.
The activation experiment would have code like:
window.optimizely = window.optimizely || [];
function hashChanged() {
if(location.hash === 'publishing-step') {
window.optimizely.push(['activate', 0000000000]);
}
if(location.hash === 'checkout-step') {
window.optimizely.push(['activate', 1111111111]);
}
}
window.addEventListener('hashchange', hashChanged, false);
Or you could call window.optimizely.push(['activate', xxxxxxxxx]); directly from your site's code instead of creating an activation experiment and listening for hashchange.
If you want to use a 3rd party analytics tool like Google Analytics:
You could do this all in one experiment with code similar to above, but in each "if" section instead of activating an experiment, you could run your variation code that makes changes to the wizard and sends special tracking information to your analytics sweet for later reporting. You'll have to do your own statistical significance calculation for this method (as Optimizely's data won't be "clean"), but this method actually works out better usually if properly configured.
Alternatively you could use the method outlined above but still try to use the Optimizely analytics dashboard by creating custom events on your experiment and sending data to them using calls like window.optimizely.push(["trackEvent", "eventName"]);
This article may also be helpful to you.
You'll probably need to do this yourself, using Optimizely's JS API to trigger actions on their end and tell it what your users did: https://www.optimizely.com/docs/api
I was googling a lot in order to find a solution for my problems with UI Automation. I found a post that nice summarizes the issues:
There's no way to run tests from the command line.(...)
There's no way to set up or reset state. (...)
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
There's no way to programmatically retrieve the results of the test run. (...)
source: https://content.pivotal.io/blog/iphone-ui-automation-tests-a-decent-start
Problem no. 3 can be solved with jasmine (https://github.com/pivotal/jasmine-iphone)
How about other problems? Have there been any improvements introduced since that post (July 20, 2010)?
And one more problem: is it true that the only existing method for selecting a particular UI element is adding an accessibility label in the application source code?
While UI Automation has improved since that post was made, the improvements that I've seen have all been related to reliability rather than new functionality.
He brings up good points about some of the issues with using UI Automation for more serious testing. If you read the comments later on, there's a significant amount of discussion about ways to address these issues.
The topic of running tests from the command line is discussed in this question, where a potential solution is hinted at in the Apple Developer Forums. I've not tried this myself.
You can export the results of a test after it is run, which you could parse offline.
Finally, in regards to your last question, you can address UI elements without assigning them an accessibility label. Many common UIKit controls are accessible by default, so you can already target them by name. Otherwise, you can pick out views from their location in the display hierarchy, like in the following example:
var tableView = mainWindow.tableViews()[0];
As always, if there's something missing from the UI Automation tool that is important to you, file an enhancement request so that it might find its way into the next version of the SDK.
Have you tried IMAT? https://code.intuit.com/sf/sfmain/do/viewProject/projects.ginsu . It uses the native javascript sdk that Apple provides and can be triggered via command line or Instruments.
In response to each of your questions:
There's no way to run tests from the command line.(...)
Apple now provides this. With IMAT, you can kick off tests via command line or via Instruments. Before Apple provided the command line interface, we were using AppleScript to bring up Instruments and then kick off the tests - nasty.
There's no way to set up or reset state. (...)
Check out this state diagram: https://code.intuit.com/sf/wiki/do/viewPage/projects.ginsu/wiki/RecoveringFromTestFailures
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
Agreed. Both IMAT and tuneup.js (https://github.com/alexvollmer/tuneup_js#readme) allow for this.
There's no way to programmatically retrieve the results of the test run. (...)
Reading the trailing plist file is not trivial. IMAT provides a jUnit like report after a test run by reading the plist file and this is picked up by my CI Tool (Teamcity, Jenkins, CruiseControl)
Check out http://lemonjar.com/blog/?p=69
It talks about how to run UIA from the command line
Try to check the element hierarchy, the table can be placed over a UIScrollView.
var tableV = mainWindowTarget.scrollViews()[0].tableViews()[0].scrollToElementWithName("Name of element inside the cell");
the above script will work even the element is in 12th cell(but the name should be exactly the same as mentioned inside the cell)