responsiveimagescg / sizer-soze-frontend Goto Github PK

Currently Cross Origin Requests are being blocked in Firefox (and partially in Chrome) due to the lack of a CORS rule. I don’t know any external resources but I guess this affects:

• Google Webfonts
• jQuery(?)
• SizerSoze JS API?

EDIT: This blocks displaying the JSON results in Firefox (using Nightly, but guess it’s also for v29)

Firefox log:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://themes.googleusercontent.com/static/fonts/lato/v7/Kom15zUm24dIPfIRiNogNuvvDin1pK8aKteLpeZ5c0A.woff. This can be fixed by moving the resource to the same domain or enabling CORS.

We should… y’know, have a title. In there.

The script has a thirty second delay for the sake of async-loaded images. I figure there are three ways we can go with this:

Show results immediately after form submission:

1. Remove the delay, and maybe disclaim that the web-based tool only covers images loaded with the initial markup.
2. Reduce the delay, and add an interstitial “please hold…” page. I’d think a handful of seconds would mostly cover us here, yeah?

Email a link to a results page:
3) Leave it the way it is.

The email-for-results method feels kinda clunky to me, and I’m not sure the difference would outweigh the clunkiness.

Wat’chu think, @yoavweiss?

Hey everyone, great site! I was testing this out in IE and remove() isn't supported from the DOM4 spec, but that is what is currently being used to remove the breakpoints, so you get an exception and that kills the script. I suggest adding the remove() method to the prototype chain so that it works across all browsers.

Here is a reduction of the issue: http://jsfiddle.net/SvDVn/5/

Thanks!

I think we also need a theme song, but maybe that’s just me.

@starburst1977, can you work with @hellogeri on framing this thing out? We’ve been discussing this being a two-pager:

The first page being a quick description of what the site is all about, and an input that accepts a URL.

The second page (which will either be shown on submission of the URL or via an emailed link, depending on how the back-end delay plays out), will contain the results—and likely a URL input for additional testing. I’ve asked @nwtn to share some sample data so we can start blocking that out.

Thanks, guys!

Page in question:
http://ericportis.com/etc/demo/status-quo.html

Sizer Soze reports that it weighs 5.45MB.

Chrome and Safari think it weighs ~3.5MB.

Firefox consistently thinks the images weigh 1.333x the size reported in Safari and Chrome (?) and measures the page at ~4.8 MB. But its dev tools sizes don't match the content-length HTTP response header, so I'm considering this a Firefox bug?

I just want Sizer Soze to match something, or understand why it doesn’t.

Detailed per-resource breakdown:
http://ericportis.com/etc/resource-size-differences.html

they can only accept numbers, no letters

I don’t think we’re even using it.

Gonna wire up a D.O. droplet for this, and it’s asking for a hostname—should I stick with api.sizersoze.org?

I think front-end performance could be massively increased by a few tasks. Most of them can be handled by myself:

• Combine CSS to only 1 file or consider inlining it
• Serve minified CSS only in production
• Consider if all webfont styles are needed
• Add a few server rules (@yoavweiss should configure the server to run on these configs)
• Remove not needed CSS selectors
• Review JS for performance improvements
• Serve minified JS in production

Looks a little strange floating there, where it disconnects the little arrow and copy from the form it describes:

Ideally, it would look like this pre-results:

And like this post-results:

Just, y’know, with a nicer table in play.

@yoavweiss Can you make sure that the service box will accept CORS? Since we're doing this on the front end, browsers will error out without that.

Still got the background color from the container above.

TODO: offer @zachleat one (1) American dollar in exchange for adding a Top Secret Filament Group Project.

Looking like raw markup at the moment.

Anybody have anything that is Mad Decent™?

I like Digital Ocean. Pretty cheap and getting a deployment solution together relatively quickly is pretty easy. We can also likely just use Heroku for this.

When I host under http://localhost:8888/sizer/app/, resources are loaded from "/", so you get 404 errors

I can't help but think this is best handled as a service with an app that calls off to it.

This will enable us to split this up into two ends: The MVC end where we put the data together for the front end and make it all super fresh lookin, and the service end, where we do the crunchin. This will make testing a bit easier because we can mock the data that would be coming from the service for any unit tests.

Er’rybody that chipped in on this, somethin’ like the footer on movethewebforward.org?

I know @jlembeck had a look-see at wiring up the server side of the equation, but I’m not certain where that left off. If I recall correctly, the latest version of the script is Python instead of Bash, which meant Complications™?

@jlembeck:
If you have a minute or two free, you mind writing up the current score on this?

I haven’t dug through to see if anything is actually checking those selects, but we should get em working in there as well.

So, longterm I'd like to rewrite this entire thing in Node, but if we want this off the ground on the quickness, we can execute the old bash script using child_process.execFile, and feed in some HEAVILY SANITIZED arguments along the way.

This is potentially dangerous, as, ya know, user input. But we can also be pretty nasty about what we take in. We can slowly rewrite the service pieces in Node at that point, and get em all tested and what not.

Testing on http://sizersoze.org/ I get 502 responses for calls to http://api1.sizersoze.org/api/?...

I can only speculate why this happens, I guess production load is just too tough for it?

Any way I can help testing, let me know.

I'm partial to Express/EJS, as I'm pretty familiar to both. I'll defer to somebody who has written far more Node than I have: @garann, any new hotness to holla at/huge warnings on those?

Other tech choices can be talked in here as well: I assume Grunt for the build tool and nodeunit/qunit for tests?

We should really only have one wrapping the inputs, results, and step write-ups.

So.

A. We need to decide what information that Sizer Soze gives us is crucial to this site.

B. Once we have that, we need to mock a few different URL requests so we can build the models around it.

@garann - Do you have any experience with mocking responses for testing in Node?

Reads a little BEEP BEEP BOOP HERE IS A DATA. Not sure where this is best solved, but I’m guessing it’s not in front-end territory.

I've set up the service part, and significantly reduced the delay time it takes to get a response (currently it's around 30-60 seconds, depends on site).

Which got me thinking. If we decide that the front-end would simply wait until the service responds, we can have a static, JS-in-the-browser-only front-end, which will significantly ease its deployment.
Alternatively, we can do postback responses, which require a more complex front-end, but I'm not sure what are the benefits of that.

@jlembeck - what do you say?

All of the in content links are not working. e.g. 'choosing the best solution'

Hello,

I just tried Sizer Soze on a site I built recently and it seems as though no images were detected - the site is all Angular based and falls back on prerender.io's middleware for search engine indexing. Could this be why it failed to detect any images?

Sorry if this is a dumb question!

Thanks

@yoavweiss and @jlembeck, I leave the scary computer-y details to you.

Can currently kick things off by hitting enter, but that’s a little strange.

Nothin’ against the Roomba-cat, of course.

If the API times out or returns “parameters needed,” I think the loading spinner just goes on forever.