Hello Meteor.js experts,
If you make a GET request to any page you will get something like that:
<!DOCTYPE html>
<html>
<head>
<!-- Some meta tags here -->
</head>
<body>
<!-- Bunch of scripts here -->
<script type="text/javascript" src="/app/app.js"></script>
</body>
</html>
I mean head of site, a bunch of scripts and that's all. No any markup code. I understand that Meteor is client side rendering framework. I need generate html on server side with this head and scripts for SEO. I need this scripts in order my application work on the client side normally, as usual Meteor application.
I tried to use Meteor-SSR, but it's not generate the scripts and head.
Is there any way to get this code (or only scripts list) on server side? And can I handle this script list? Can I remove some scripts out of there?
The "bunch of scripts" appears normally only in development mode.
Once you build for production (or simulate with --production flag), all of them (including your app.js) are bundled and minified into a single JS file. The scripts which are specific for debug are not included.
As to come back to your main concern, you could try Meteor-SSR package:
Now, you can render Blaze templates on the server very easily. And also, you can assign helpers for templates in the server as well.
An alternative which is not exactly SSR is the Fast Render package:
Fast Render can improve the initial load time of your app, giving you 2-10 times faster initial page loads. It provides the same effect as Server Side Rendering (SSR), but still sends data over the wire to avoid breaking one of Meteor’s core principles.
With this package, you keep the very same client-side rendering even at start up, but the initial data is sent within the HTML page, eliminating the waiting time for the script to subscribe and receive the data from that extra request.
Related
QQ:
What is the meaning of the next-head-count meta tag sometimes included in the header of pages served on a NextJs server/app?
Background
We have a next.js 9.0.3 server that behaves differently when built (build) and started (start) in AWS vs when built and started on a MacBook. (I think the root of it so far is that on AWS there is client-side render call when the page is presented, and on the Mac there is no client-side render called.) That's not really what my question is about though.
I'm in the process of trying to understand the differences and while doing the forensics I notice that /mypage.js HTML file initially served by the two platforms are different. The easiest difference to characterize here is that one platform serves a header with a next-head-count meta tag and the other does not:
<meta name="next-head-count" content="4"/>
So I ask my basic question above.
I've come across this scenario multiple times with the current app that I'm working on.
I have a large chunk of new CSS I would like to implement into a page. I have two options:
Add CSS to existing CSS bundle (minified CSS from ASP.NETs bundle utility), thus invalidating cache for that bundle
Create a new bundle and include it in the page (in the body), thus causing a new http request
Which would you choose? #1 invalidates the cache, but prevents a new http request. #2 creates a new http request but leverages cache for the other CSS bundle.
Depends on what kind of new CSS you're adding but generally speaking I'd go with scenario #2. I like to use a CDN for the framework CSS file, and then use my domain to host the website theme CSS and a page-specific CSS file. Make use of parallel downloads.
<!-- 1 http request to CDN for main framework, gets cached -->
<link rel="stylesheet" href="http://cdnjs.cloudflare.com/ajax/libs/foundation/5.5.3/css/foundation.min.css"/>
<!-- 1 http request to mydomain.com for main theme, gets cached -->
<link rel="stylesheet" href="http://domain.com/css/themes/modern.min.css"/>
<!-- 1 http request to mydomain.com for page-specific styles -->
<link rel="stylesheet" href="http://domain.com/css/pages/product-detail.css"/>
Depends upon the transmission rate.
In general it is much better to include the CSS in the <head> rather than a separate file.
When the CSS is in the head the Browser has all the CSS before it get the HTML. This way the Browser can start rendering the page even before the base HTML <body> has completed loading.
If the transmission rate is too slow and it takes a long time for the CSS to get to the Browser then a separate file may be called for.
If the CSS transmission time is greater than the HTTP request connect time, is when to start looking at a separate CSS file.
Using a CDN will add another DNS lookup if it is not already in use for other content.
Also be sure gzip is turned on.
#1 does not invalidate the cache if the HTML page is cached.
Cache does not do anything for a first time visitor, and a first time visitor may never be a visitor at all if the page takes to long to load.
A) <script src="https://apis.google.com/js/api:client.js"></script>
versus
B) <script src="https://apis.google.com/js/client.js"></script>
The only differnence being the api: before client.js.
CDN A is used in the Google Sign-In for Websites docs in the Building a button with a custom graphic section.
CDN B is used almost in the Google API Client Library for JavaScript (Beta) docs.
They both appear to work interchangeably.
Short answer: there is no difference
Long answer:
The Google JS client CDN is a bit weird because the actual JS you get is dynamically created based on the file name you provide.
You can load multiple components of the library by constructing the URL as module1:module2:module3.js
api is the core part and is always loaded even if you don't add it to the list of modules, because it handles loading the other modules.
Theoretically you could just include api.js and then dynamically load extra modules by calling gapi.load("module", callback) which is exactly what happens when you load api:client.js or just client.js
If for example you would want to use the API Client Library together with the new sign-in methods you could include api:client:auth2.js or client:auth2.js.
And for extra confusion you could even include https://apis.google.com/js/.js which is the same as https://apis.google.com/js/api.js
Use links only from the documentation!
Simple to check this:
1) Add to header of your page this script:
<script src="https://apis.google.com/js/client.js"></script>
Open DevTools -> Network
I see:
2) Change link to other script
<script src="https://apis.google.com/js/api.js"></script>
Open DevTools -> Network
I see:
api.js is the core, when client.js is the module.
Here a completely different content: https://apis.google.com/js/platform.js
I'm Trying to make a simple web browser in node-webkit, to polyfill features that Chromium doesn't support yet (time element, etc). I have had success in listening for the iframe.onload event and then appending a script tag with the polyfills, but this still means that features that I've polyfilled won't be detected by Modernizr or other feature detention.
I've tried loading the page using the http node module, appending a script tag and then turning the page source into a data URI for the frame but data uris essentially turn external pages into static html with no scripting, which renders many web pages unusable.
Also, loading a page through node's http module is proving extremely slow compared to loading through an iframe.
So, is there any other way? Ideally I run a script in the iframe before any other scripts are run.
Yes, I am using nwfaketop and nwdisable on the iframe.
The 'document-start' event should be helpful. See https://github.com/rogerwang/node-webkit/wiki/Window#document-start
See also Window.eval() in https://github.com/rogerwang/node-webkit/wiki/Window#windowevalframe-script
For maintainability reasons, I want to database drive my javascript, in that I only want to send the javascript which is needed based on the users options.
So, is it faster/less resource heavy to have links in the database pointing to javascript files, then using response.writefile to embed those files into the clientside page, or is it faster/less resource heavy to stick the javascript script straight into the database, and response.write it onto the screen as and when needed?
So, is it faster/less resource heavy to have links in the database pointing to javascript files
Usually yes.
External Javascript files can be cached by the browser, and will be loaded only once. Javascript code injected into the HTML page needs to be loaded every time, which increases bandwidth and loading times.
Also, having JavaScript code in a static file (instead of a dynamic one that fetches the code from the database on every request) is bound to be the fastest and least resource-intensive solution.
Don't use Response.Write.
Be aware that if you send the entire JS file once, the client will / should cache it so it doesn't have to be sent again.
DB lookups for every page just to get the relevant JS will be slow.
By only sending the links to the javascript to the client a seperate HTTP request will have to be created in order to go and get each file.
If you embed only the required javascript directly into the page when needed this prevents this. Look at jQuery, thats got a load of javascript available to the client that isn't being used.
Less HTTP requests generally results in a faster website so I would go with embedding the code directly.
Edit:
I disagree with the caching answers above. If you ensure only the smallest amount of javascript that is required is embedded then my answer should be faster. This page will be cached too!