##About JSFoo
JSFoo is India’s premier JavaScript conference. We launched JSFoo in 2011 as India’s first JavaScript conference. The JS community in India has grown phenomenally since. JavaScript now pervades every aspect of web development – browsers, apps, front-end, backend, mobile, and IoT.
##JSFoo 2016: Theme
Over the last few years, JavaScript has evolved to become the centerpiece of a complex web stack. Today, it is a prime subject of the obsession that lies with performance and speed. How can you get pages to load faster? How do you work with browser constraints to enhance speed? How do you measure performance? What actually is performance? In what ways do faster response times influence your architecture choices and plans? How is this new focus on faster page loads and apps working offline influencing the development of front-ends and backends as well as server side JS?
The theme for the 2016 edition is tackling speed and performance for JavaScript.
We are inviting full talks (40 mins), crisp talks (15 mins + 5 mins Q&A), and 3-6 hour long (hands-on) workshops from practitioners on the overall theme of speed and performance, including the following topics:
- Architecting for performance – case studies on how you got faster response times
- Best practices: debugging and profiling on the web, measuring performance
- Handling large volumes of data in the browser
- Building and deploying web apps eg webpack, travis
- Modern web technology: Angular 2, React
- Universal JavaScript: meteor js
- Progressive Web Apps
- JS off the web – raspberry pi, IoT
- The cutting edge: elm
This year, JSFoo will feature two days of talks on JavaScript (15-16 September) and a single day of talks on design (17 September) at Meta Refresh (call for proposals will open shortly).
Guidelines for submission
Every proposal MUST be accompanied by:
- A three minute preview video where the proposer gives an elevator pitch about the talk.
- Detailed outline of the talk – either in the form of draft slides, mind map and/or textual description.
- If you are proposing to speak on a topic where the code is not open-sourced yet, the editorial panel will consider your proposal only if the code is made open-source at least three weeks before the conference.
Without the above information, your proposal will not be considered for review.
If you are submitting a Workshop Proposal, you must clearly state:
- Background knowledge that participants must possess in order to attend your workshop.
- Details and links to software / packages which participants must install before coming to the workshop.
- Laptop configuration.
- Links to background reading material and GitHub repos.
- Duration of the workshop.
- Maximum number of participants who can attend your workshop.
- Instructor’s past experience with conducting workshops.
There is only one speaker per session. Workshops can have two or more instructors.
Entry is free for selected speakers.
Due to budgetary constraints, we prefer speakers closer to home. But if we think you stand out, we’ll provide a grant to cover part of your travel and accommodation to Bangalore. Grants are limited and are made available to speakers delivering full sessions (40 minutes or longer) only.
Commitment to open source
HasGeek believes in open source as the binding force of our community. If you are describing a codebase for developers to work with, we’d like for it to be available under a permissive open source licence. If your software is commercially licensed or available under a combination of commercial and restrictive open source licences (such as the various forms of the GPL), please consider picking up a sponsorship. We recognise that there are valid reasons for commercial licensing, but ask that you support us in return for giving you an audience. Your session will be marked on the schedule as a sponsored session.
Important dates:
Deadline for submitting proposals: 29 August 2015
Conference dates: 15-16 September
##Venue
JSFoo will be held at the MLR Convention Centre, J P Nagar.
##Contact
For more information about speaking proposals, tickets and sponsorships, contact info@hasgeek.com or call +91-7676332020.
TG
Tarun Garg
@tarungarg546
Optimizing Critical Rendering Path of Web app
Submitted Jul 26, 2016
Section:
Full talk
Technical level:
Beginner
This is not anymore hidden that web has become fat. By fat, I mean that average size of a web app has grown enormously since last few years. This is due to large images, animations, ads, widgets and not to forget frameworks. And as the size of web app increases, app loading time also increases and as a result of it, the user is left to see a blank screen or loading spinner for significant amount of time. But, why is that a problem, because all these things that have made the web fat are intended to be the enhancements to the web platform. So why should they make basic web performance suffer? Why should UX suffer because of UI?
We can do better
This is the notion on which the web has survived for so long and is going to survive a lot more. So solution to above problems that have made the web fat lies in Improving critical rendering path.
I can explain it better with an anatomy, suppose you are a user who wants to read news online. So, you navigate to a site named xyztimes.com. As a user what you want to see is article loading first, not ads,videos, animations, comments and widgets. So as a developer you need to ensure that first thing you deliver is Critical resources, then you can progressively load the rest. You have to manually decide and research about what is critical to the user. So that user could see the critical content first and rest of the things later. That is going to produce following two outcomes
- Making your web app resilient.
- Improving UX directly proportional to more engagements and hence more revenue
That is exactly notion behind Critical Rendering Path, that you should load what is critical to your user first and then progressively enhance the rest.
Progressive enhancement is best thing that happened to web.
But, in how much time shall we deliver the critical resources as Time to render is also UX metrics.
Answer is 1000ms. Yes only 1s and out of which majority of time will be spent by HTTP and server, so your browser has only around 300 ms to do everything required to render a page.
So, how do you do it? We would explore those options in this talk.
Outline
In this talk, we will see how to improve first rendering of your page and make it fit under our 1000ms budget of first render.
Slide :- https://tarungarg546.github.io/jsfoo-slides/
Requirements
Basic knowledge of web practices
Speaker bio
I am a fresher from YMCA University, Faridabad.
I have been into web development since last 2 years, so you can safely assume that I love web and it’s complexities. Lately, I have been learning and practicing a lot about how to improve the performance of a web app because #perfmatters and performance is what makes the engagement of user easy for developers. I have been learning about, how would you improve first render of your page quite a lot and I have tested each and every practice manually before believing anything, because web keeps changing and evolving. So, everytime you see something in web space, don’t guess it, test it.
My area of interest and research are ECMASCRIPT, critical render path, Service Worker{ offline web apps} and Node JS. I like coding standards pretty much because i believe in saying Your code is written once but it’ll be read many times, so I tend to adhere to those principles when programming either professionaly or in FOSS contributions.
Currently, I am working extensively in Angular JS, NodeJS{ mainly with express and build tooling} and Ionic. I also have grasp on build tools like gulp.
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}