I am a newbie with progressive web apps. I want to increase the performance of my PWA but stuck at one point.
This is the error
Please help me to resolve this!!!
You may check this page on how to eliminate render-blocking JavaScript and CSS.
Critical-path styles are the styles that are required to render correctly everything that's above the fold.
You should inline these styles to avoid additional HTTP requests blocking initial rendering. You'll find that there's a collection of tools to help with this.
<head>
...
<style>critical CSS rules here</style>
...
</head>
Some additional tips:
You should consider figuring out what above-the-fold means for your users based on web analytics.
Also make sure you don't use #import statements in critical CSS as that'll also trigger additional HTTP requests.
Be sure not to inline too much CSS as that'll also slow down your initial render.
Read some more explanation/tips from Google and Varvy.
Related
I would like to integrate math equations in a Rails project. I see that there exist a well-maintained MathJax gem (https://rubygems.org/gems/mathjax-rails/versions/2.5.1). On the webpage of this gem, there is a section called "Why bother with another gem?", which argues mainly that MathJax is huge and makes it difficult to manage the project when it is entirely installed in a subdirectory of a rails project. However, on the MathJax webpage (http://docs.mathjax.org/en/latest/start.html) I see that MathJax is available through a CDN, so I guess there is no need for downloading its source into the Rails project (maybe the gem was made at a time when it was necessary to download MathJax?).
So my question is: is there an advantage that I am missing, of using the gem rather than defining my own few helpers to get MathJax from the CDN and configure it for my need?
Assuming all things work, I think the CDN is the best and simplest way. They give instructions, it's free, it should reduce the performance and deployment cost of the library on your app, and if anything doesn't work it'll be easier to get help since you haven't done anything framework-specific.
However, using a CDN adds a partial failure mode to your app: what happens when your app server returns your HTML, but the CDN is down or unreachable for the MathJax assets? Your users will see the TeX code instead of the rendered equations.
This is pretty unusual, but can happen. Sometimes the CDN is broken, other times the user's ISP screws up their DNS to the CDN but not to your app.
Whether this is a risk worth defending against depends on your app, your users, etc.
You can avoid it by hosting mathjax yourself (app server or CDN) but it'll be more work to set up, and if you're using a CDN at all you can still get these partial failures.
If you really want the equations to render every time your app serves a page take a look at the server side rendering options (nodejs) added to MathJax and KaTeX recently. I'm not aware of a gem bundling this up yet for rails but it'd be cool to have. There's a mathjax node server/service you could send requests to from rails (cache the requests), but that'll complicate deployment if you're used to having a single app. There's also someone calling KaTeX through execjs.
A week ago, I get a task to develop a site on mobile. After searching the engine, I choose jQuery Mobile! All things like more simple. Until now, I found something was wrong.
Maybe I lost myself, between responsive html and mobile page.
To test my page, I use two tools. One is the chrome developer, and other is the Opera Mobile Emulator!
As the e.g, I write a page with jQuery Mobile.To me, the first question is to change the border-radius size. My page link another css. But the CSS didn't work well, they can't make the right size. After some test, I have to change the file named jquery.mobile.css, to make it the size which I need.
After that, All things test under chrome is look ok,but the bad things happend.The page can't work well under the test tool Opera-mobile-Emulator!
After that, I added the code
<meta id="viewport" name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0">
to my page.Some thing began to look right.
The mobile page to me feel hard. What's the right way to develop them, with jQuery Mobile and how to test them quickly? Help me, the mobile page deeply hurt me. Is there something wrong to my method???
I don't think there is anything particularly wrong with your method or approach. The mobile stuff can be tricky and frustrating.
The big problem is dealing with multiple devices and trying to make it work right on all of them.
The trick I've found is to have 'slightly' different css for some devices. You don't need to change all the css just bits.
I have used this in the past, http://www.jquery4u.com/mobile/detect-mobile-devices-jquery/, and it seems to work pretty well.
There is also another tool called hammerjs, http://eightmedia.github.io/hammer.js/, which allows you to have swipe events on elements which i also use.
But ultimately, mobile development can be very frustrating and fiddly.
I am taking over development on a rails 3.2 application and am looking for the best way to improve page loading time. The site itself is more of a large dynamic website than an actual web application (the site is http://korduroy.tv/, a surf lifestyle community site), and while there is a couple of small pieces that differ from user to user, most of the site is the same experience for everyone.
Page loading time is fairly slow, and from looking at the server logs, it seems to be because each page is loading so much dynamic content (for example, most pages are loading resources from 10+ models). While I hope to go through and refactor what I can, I am looking for some basic performance wins. Knowing that most of the site is the same for every user, is their a way to aggressively cache the content on the server or even serve static content that has been generated through some kind of background job?
My initial thought was to create a job that uses a static site generator, maybe something like Jekyl, and basically creates a static copy of the site, which could then be served on a cdn. My gut is telling me this is probably not the way to do it, plus there are some pages (such as the user profile page), that need to be served dynamically.
Any recommendations would be great. Disclaimer, I come from front end land and have very little knowledge of best practices when it comes to server side optimizations. Thanks!
From what you write, I believe your biggest gain will be in implementing a fragment cache using a memcache store. See http://guides.rubyonrails.org/caching_with_rails.html as the definitive guide on rails caching.
You might be able to get away with a page cache or action caches for some of the content that doesn't depend on the user (like the homepage), but unless you're serving up millions of requests a day, I'm not sure this is necessary.
I notice that while the javascript and css seems to be compiled according to the rails asset pipeline, the images are missing the sha1 hashes that allow aggressive browser caching of the resources (since you don't have to worry about the contents changing, as they get new hashes when you change the images). The key here is enabling the asset pipeline, making sure you compile your assets as part of deployment (rake assets:precompile) and using the image_tag and asset_path helpers (or image-url sass helper). Also make sure that nginx is responding with code 304 (not modified) to your browser when you're refreshing a page. This won't affect the load on the rails server (unless you have both nginx and rails running on the same server), but will reduce the average page load time.
You can look into more advanced techniques like caching your sql queries, or optimizing these, but this can lead to increased complexity making it harder to maintain your codebase. Try the view caching first, and see if that gets the load time to an acceptable level.
I have a Rails app where I load up a base HTML layout and I fill in the main content with rows of divs from JSON. This works in 2 steps:
Render the HTML
Ajax call to get the JSON
This has the benefit of being able to cache the HTML layout which doesn't change much, but it seems to have more drawbacks:
2 HTTP requests
HTML isn't that complex, the generated html is where all the work is done, so I'm not saving that much on time probably.
Each request in my specific case requires that we check the current user, their roles, and some things related to that user, so those 2 calls are somewhat involved.
Granted, memcached will probably solve a lot of this, I am wondering if there are some best practices here. I'm thinking I could do this:
Render the first page of JSON inline, in a script block, along with the HTML. This would cut out those 2 server calls requiring user authentication. And, assuming 80% of the time you don't need to make the second ajax call (pagination/sorting in this case), that seems like a fairly good solution.
What are your thoughts on how to approach this?
There are advantages and disadvantages to doing stuff like this. In general I'd say it's only a good idea, if whatever you're delaying via an ajax call would delay the page load enough to annoy the end user for most of the use cases on your page.
A good example of this is browsing a repository on github. 90% of the time all you want is to navigate the files, so they use an ajax load to fill in the commit messages per file after the page load.
It sounds like you're trying to do this to speed up or do something fancy for your users, but I think you should consider instead, what part is slow, and what speed of page load (and maybe for what information on that page) on your users are expecting. As you say, using memcached or fragment caching might well give you the improvements you're looking for.
Are you using some kind of monitoring tool? I'm using the free version of New Relic RPM on Heroku. It gives a lot of data on request times for individual controller actions. Data like that could help you focus your optimization process.
Well, not really reinventing, however, we have a large content-based website which handles load (after we fixed the SQL pooling issue) to a certain point, then we just run out of steam. A lot of this is due to bad code we are trying to fix up, but a lot is just due to the level of requests etc.
We were considering page caching, because well, it's damn quick (yep... :D) but that doesn't work because we have certain fragments within the page which are specific to the logged in user. But, not all hope is lost...
I was wondering if it would be ideal to do the following:
Page level caching, with sweepers to clean out the pages when content is updated.
Replace the user-specific fragments with placeholders (and perhaps generic content like... 'View your Account, or Sign Up Here')
When the users page loads fire off an async request (AJAX, or, some would call it AJAH), which requests the 'dynamic' fragment, then place the content placeholders with this fragment..
The main issue I can see with this is that users with JS turned off wouldn't see the content, but I honestly don't think we would be too affected by this, and IMHO people who disable javascript, for the most part, are idiots (yes, I said it!).
I'd also be interested to know if I'm (no doubt) reinventing something, and if anyone can point me to a site which is already doing something like this it would be appreciated.
Thanks awesome SO community!
Ryan Bates covered this technique in Railscast 169: Dynamic Page Caching. It's worth taking a look at.
Have you thought about server-side fragment caching? I've used it extensively, and it couldn't be more awesome. You could simply cache the content 'fragments' and render normally whatever depends on the logged in user.
There are many good resources for fragment caching, I'd start at the documentation:
http://api.rubyonrails.org/classes/ActionController/Caching/Fragments.html
Also very good from the Scaling Rails series:
http://railslab.newrelic.com/2009/02/09/episode-7-fragment-caching
When serving static content or cached content starts to slow down serving the real working processes put a reverse proxy as frontend to your application. It will free processes to do real work and reduce slowdowns due to file system caches becoming inefficient. And it will help you to make "client side caching" shareable to multiple visitors. Have a look at the fantastic screen cast series about caching and scaling by NewRelic: http://railslab.newrelic.com/scaling-rails