recently we deployed our site to google app engine and everything deployed successfully.
now we enable pagespeed in settings.
now problem.
its making loading css in html head section with some wried script tag instead of style tag..
i tried every and many confirmation settings but nothing works..
i want to load google fonts css early in html (not working, for now disable filters related to css because of issue 1)
i want it to combine all my js to one file and compress it. (not working)
here is page speed configuration in yaml.
pagespeed:
enabled_rewriters:
- ConvertMetaTags
- ElideAttributes
- CollapseWhitespace
- CombineJs
- ProxyCss
- InlineCss
- MinifyCss
- RemoveComments
disabled_rewriters:
- FlushSubresources
- WebpOptimization
- InlineImages
- ImageStripColorProfile
- ProxyImages
- ProxyJs
- ImageRecompressPng
- ImageProgressiveJpeg
- ImageConvertToJpeg
- DeferJs
- MoveCssToHead
- InlineJs
- InlinePreviewImages
here is website www.justtotaltech.co.uk
and sometime its load css in html after refreshing page one or two times..
is there any to configure more advance settings of pagespeed in app.yaml or somewhere else like pagespeed service and mod_pagespeed
or is there any way to use external pagespeed service for appengine instead of one inbuit with it. (i tried this but it don't fetch content from origin domain (app engine))
someone said in below comments for removing pagespeed section and now site don't have it. but nothing work at all.
for the issue 3. I contacted pagespeed team for related issue previously and got the following response.
CombineJs AND CombineCss are disabled automatically whenever FlushSubresources is enabled. this option is currently enabled by default.
So disable FlushSubresources first then combinJs rewriter will work.
Another thing worth to say is that you can actually preview the pagespeed results.
For example:
view-source:http://www.justtotaltech.co.uk/services/software-development/?ModPagespeedFilters=combine_javascript,combine_css
It will be much easier to detect which filter cause the issue.
Workable Page Speed Config
pagespeed:
enabled_rewriters:
- MinifyCss
- CombineJs
- CombineCss
disabled_rewriters:
- FlushSubresources
Great question, as I am experiencing similar issues. I wanted to start by referring you to the google developer document page (which I am sure you have looked at):
https://developers.google.com/appengine/docs/python/config/appconfig
As they note there, "App Engine's support for PageSpeed is an experimental, innovative, and rapidly changing new feature for Google App Engine. Unfortunately, being on the bleeding edge means that we may make backwards-incompatible changes to App Engine's support for PageSpeed. We will inform the community when this feature is no longer experimental."
Thus, I am not surprised to hear you experienced performance changes that were somewhat arbitrary. Paraphrasing from the developer docs, I see the following in terms of testing (as that is what I am trying to do for a custom application as well). To work through things, you might try to be very deliberate and try different test configurations (which I assume that you have already). That, said, if you haven't, and you want to try a new configuration, perhaps to test some "risky" optimizations, you might expect that you could do so in a test Application Version while your users continue to use the default Application Version. Unfortunately, since updating the test version's configuration applies to all versions, the "risky" settings are applied to the version that your users use, too. Instead, to try out these settings, you could:
Turn off PageSpeed for your application, update PageSpeed configuration, and view your site using the PageSpeed chrome extension
Copy the relevant parts of your application to a separate test application that has its own application ID and versions.
If you do find any specific solutions to the issue, please post them here!
Related
I'm currently using Google Appengine to host a website with Golang as the backend. I have a custom domain setup and (sometimes) it works perfectly fine. My website requires some css and js files from the server. These were served perfectly in the past but now it randomly stops working. Both on the "mydomain.de" and on the "myapp.appspot.com" domains. Sometimes it works on the normal domain and then it works on the other and sometimes even on both. But if I reload the site after a couple of minutes it just shows me an old index.html file (that I have removed days ago).
Did someone experience this problem in the past and does anyone know a fix for this?
Thanks in advance.
Have you ruled out your browser cache as the source of the problem? If after getting a stale version, shift-reload (assuming Chrome or Firefox) brings up the desired version, then look into how to do "cache busting" for css and js, and check the app.yaml doc for how to set expiration times on static assets (assuming your index.html is static).
Ok, somehow I am serving ads in my NodeJS / AngularJS application, but I haven't include this myself.
There's some package or included link sending ads to the client, but the ads are not visible, and the adserve url changes with every request. (The url that can be seen in the screenshot below)
How do I find out which place in my application serves these ads?
PS: I am sure this doesn't come from my local dev pc, my other collegues have this issue as well.
A quick trick may be to search for the url in every files of your repository. If you use a cdn to load your librairies, try to look inside also (you can do that directly in chrome dev tool with ctrl/cmd f in the sources tab).
Hope it will help !
The "adserver" in my project turns out to be a tracking / analytics beacon included by the Realtime.co framework.
Thankfully, the author responded to my email very quickly, and they also provide a beacon-free version of their framework. So problem solved :)
I have a LocomotiveCMS site up and running on Heroku. I can edit my templates locally and push using Wagon. It works great!
However, I'd like to be able to serve a separate set of views for mobile devices (phones really) vs desktop/tablet. Can it be done easily? Will it require large modifications to the engine?
EDIT: I should add that I have done this before for a basic Rails app with no issues. I know how to detect a mobile device by examining the user agent and creating a separate folder (such as views_mobile) to store the mobile views. Would like to be able to do the same for LocomotiveCMS
That's a tough question. For the next version of LocomotiveCMS (v3), we'll use a full stack of middleware so that it will be easy to add your own custom behaviors.
But, for the current version of the engine, it's not that easy. However, I'm thinking about something. Perhaps you could create a Route constraint for the mobile detection (http://guides.rubyonrails.org/routing.html#advanced-constraints).
Then, you would modify your routes.rb by adding this:
match '*path' => 'locomotive/public/pages#show', page_path: 'mobile-index', constraint: MobileContraint.new
Never tested so it might not work :-) Happy patching!
Didier
Over Christmas I implemented some code to open a channel to my App Engine application using the channel API and it was working fine.
I recently returned to the code and find that it is broken, and the problem seems to lie in talkgadget that the client code is trying to load into a frame.
I took a snapshot of the code returned by /_ah/channel/jsapi on December 21 and I am comparing it to today's code.
When the older version tried to get talkgadget.google.com/talkgadget/d?token=[my-token] it was hardcoded to use http. Sensibly enough, the code was later changed to check the page's protocol in document.location and adapt to cases where https is used. The problem now is that when running in a chrome extension it grabs chrome-extension: as the protocol and naturally the channel fails to open in the extension.
Setting the base of the background page to my appspot URL does not change document.location, although I had some vague notion that it should. (Not sure what the standards say.)
Is there a workaround for this? One thought was to create my own iframe loaded from my site, but then it will nest the actual channel iframe, complicating things.
I wonder if Moishe or someone else on the App Engine team could comment on this. It seems like the this is a bug and the code should take into chrome extensions either by testing for the protocol and searching for a base tag as an alternative, or provide some way to configure this through the javascript object.
Yep, this is a bug. There's a fix submitted, and it's in the process of rolling out to production; it'll probably be out in about a week.
In the meantime, your idea of an iframe embedded in the extension should work.
We are considering hosting the core of our site (everything that doesn't need to be dynamically generated) on a CDN, so that our root domain (e.g. "http://example.com/") would point to the CDN, then everything dynamic would either point to an alternate second-level domain (e.g. "http://search.example.com/ for searches) or be layered on top of the static content by AJAX calls to an alternate domain (e.g. http://ajax.example.com/).
This seems like something that would be very desirable for lots of sites but I don't see much information even on the CDN home pages about doing whole-site caching. There is at least one obvious problem that occurs to me, which is that we currently detect whether the user is coming from a mobile browser or not and serve mobile content if they are coming from a mobile browser. The problem is that as far as I know, with most CDNs you can only store on version of a page, so if you cache the regular page, mobile browsers will see that instead of the mobile version (and obviously vice versa).
We could get around this to some degree by moving the mobile stuff to a separate domain like m.example.com but we would need the CDN to detect mobile browsers and redirect them to that domain (which we would also like to have hosted on the CDN, but pointing at the mobile content instead of the regular content, obviously).
It seems like this should be widely supported but I can't find much information on it. Has anyone done something similar? If so, what CDN did you use and how did you address this issue? Were there other significant hurdles that needed to be overcome?
Edited to add a couple of things I forgot:
We also considered redirecting to the mobile site using javascript but then obviously older phones without javascript would be left out in the cold and they are the ones that probably need the mobile version the most.
One constraint that may factor into any answers to this question is that we need the URLs of our primary site to be very specific for SEO purposes but we don't care at all about SEO for the mobile version.
We have rules at our CDN (EdgeCast) that will cache multiple versions (Desktop, Iphone, Blackberry, etc.) of the same incoming Url. The CDN rules append a querystring to the request to the origin server. Custom code at our origin server renders the proper version depending on the incoming querystring. For example:
Desktop: CDN requests /?nomobile origin server returns Desktop rendering
Iphone: CDN requests /?iphone origin server returns Iphone rendering
Blackberry: CDN requests /?mobile origin server returns Mobile rendering
As far as the CDN is concerned, there are 3 different Urls, so 3 different pages are cached. The querystring is completely transparent to the end user. Even if you use a responsive design with media queries, this approach is incredibly valuable in giving you the flexibility to alter the HTML at the server level.
If the rendering of your page is different for various devices (e.g. mobile phones) it is not a static content and should not be on your CDN.
Put only real static files on your CDN and consider a different caching strategy for your pages.
Anyhow instead of detecting the client's browser via JavaScript you could also do this on the server-side and actually I would recommend you that, instead of JavaScript. Then you could realize the redirect approach.
Hope that helps.